I recently upgraded to Mojave and now gitk no longer works. When I try to launch gitk I get a blank, unresponsive Wish gui. I suspect it has to do with Mojave's new security requirements on Apple Events but I didn't receive a prompt to grant permissions and I'm not sure how to grant those permissions. Any ideas how to get gitk working again?
I am running macOS 10.14.4. I have git installed via brew and is version 2.21.0
When I launch gitk I don't get any error messages, just a blank gui that is not responsive.
Related
I'm having trouble installing the Version 6 of the "CP210x Macintosh OS VCP Driver v6" on my mac OS Mojave.
The error is "unexpected reply from installKextFromBundle kOSKextReturnNotLoadable (-603946989) at -[AppDelegate takeInstallStep]_block_invoke_10:1290"
I have disabled the SIP on the mac, and trying to install this driver so that I can use the ESPxx family microcontrollers using the Arduino IDE.
I must have tried multiple times trying to install/ uninstall and have been unsuccessful so far.
The MacOS version is :
The installer is :
The USB interface is :
The only driver that is installed is :
$ ls -l /dev/cu*
crw-rw-rw- 1 root wheel 18, 1 Dec 8 18:54 /dev/cu.Bluetooth-Incoming-Port
Would appreciate if there is some one who can tell how to remove / clean up and install this driver clean.
Have run the ./uninstaller.sh multiple times, rebooted it and such.
Thanks
I received the same errors but I've successfully installed. I used Homebrew to brew install --cask silicon-labs-vcp-driver and the cask requires manually running the installer. I had Fast User Switching active and was logged-in with another admin user at the time. I found, after several failed install attempts on the first admin user's account, that the System Preferences authorisation pane was also displayed on the second admin user's account. I authorised and logged-out of the second user's account, then attempted to install from the .dmg I'd downloaded directly from https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers. That finally succeeded.
Every time I open GitHub for Mac it asks me to "add a new helper tool" and prompts me for my password. Every time I enter my password (I am an admin on this computer) but I see no noticeable changes afterwards and the prompt comes back every time I reopen GitHub. (See attached photo for the prompt window.)
I am running OSX Yosemite Version 10.10 on a Late 2012 Mac Mini (2.5 GHz Intel Core i5).
Unsure if this is related but I am running GitHub version "Reactive Barbecue (186)". According to the GitHub for Mac release notes this is NOT the newest version, but when I select "Check for updates" it says I have the latest version. Would a fresh install of GitHub solve this? This is more of a nuisance and doesn't noticeably impede my work.
I use GitHub daily for XCode pushes with my coworkers. They all use MacBook Airs and OSX Yosemite but do not have the same issue as me.
I was also having this problem.
Cause? Maybe GitHub.app was confused by multiple git installations: XCode's Command Line Tools and Homebrew's copy (a newer version and includes bash completion).
Running the shell command git credential-osxkeychain returned a "usage" line, so a helper was installed despite that message.
Fix: Downloading and running GitHub Desktop successfully installed its helper. I think GitHub Desktop.app is the new name for GitHub.app, so apparently they fixed the bug by now.
BTW: They wrote "If you're using GitHub for Mac or Windows, the upgrade is automatic.", but their automatic upgrade didn't fix this problem nor switch to "GitHub Desktop.app".
The only solution I found so far was to delete the GitHub for Mac application. Then I re-downloaded the app (the most recent version 193 "Big Feels").
It then gave me a popup saying I needed to uninstall the old version since OSX now comes with Git commands by default (or something like that?). Clicking "Uninstall now" made the app crash so I had to select "Uninstall later". This is sort of only a fix for the symptom since GitHub could keep telling me to uninstall every time I open it, but at least it says I have the most recent version now.
Use AppCleaner and nuke it. Reinstall.
I seem to be having issues with integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.
With xcode 6 running remotely via SSH the simulator time-out, when I run locally it succeeds.
Command
xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform=iOS Simulator,name=iPhone 5s' -derivedDataPath ./Build clean test
2014-08-19 10:46:36.591 xcodebuild[33966:381f] iPhoneSimulator: Timed out waiting 120 seconds for >simulator to boot, current state is 1.
Testing failed:
Test target BGO_Tests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1
Tested with recent Xcode 6 beta 6
Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).
Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:
xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."
Prelaunching
I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:
# First get the UDID you need
xcrun instruments -s
# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>
# and wait some time....
sleep 5
# Then launch your unit tests
xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>'
Old post
This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.
Apple follow up regarding Bug ID# 18001199:
The context provided by LaunchDaemons is not supported for running GUI
applications. The SSH service, and the default setup for Jenkins, are
both implemented as LaunchDaemons. In earlier versions of Xcode 5
xcodebuild could run tests on the iOS simulator in this context, but
that was never a supported configuration, and as you have noted that
is no longer working as of Xcode 6.
Unlike LaunchDaemons, LaunchAgents provide a context where you can run
GUI applications - if the user is logged in at the time, with a window
server / Aqua session. Converting your Jenkins configuration from
being a LaunchDaemon to being a LaunchAgent would avoid the reported
issue. You can also use launchd for running tests on the iOS simulator
from a SSH session, either by crafting a LaunchAgent and manually
loading / starting that, or by using "launchctl submit”.
Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.
As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.
If connecting with JNLP still does not solve it, try the solution mentioned in this comment.
i.e.: Run these on command line:
DevToolsSecurity -enable
sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"
security authorizationdb write system.privilege.taskport is-developer
See References here and here.
I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.
I ended up solving this on Xcode 5 by doing the steps here, essentially running:
sudo security authorizationdb write system.privilege.taskport allow
This will eliminate one class of these authentication popups. You’ll also need to run:
sudo DevToolsSecurity -enable
However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.
I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.
I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.
Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.
I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.
That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.
I finally managed to find a good simple solution. JNLP was causing numerous issues with our jenkins server.
Workaround for SSH timeout via https://corner.squareup.com/2015/07/ios-build-infrastructure.html
"Mavericks (10.9) and Yosemite (10.10) determine if a process can access accessibility hooks via the parentage of the accessing process. By putting launchd in the list of allowed processes, processes launched via SSH or Jenkins have access to the accessibility hooks across the system. To do this you can modify the TCC database, per this gist. A reboot is required to make the change take effect."
#!/bin/bash
# This will add lauchd to the list of allowed processes for accessibility access
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)"
# This outputs the rows in the TCC database
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'
echo "Restart is required for these changes to take effect"
Update 8/02/2016
This is now fixed in Xcode 7.2.1 ("Command line tool ‘xcodebuild test’ will no longer time out waiting for Simulator.app to launch")
I've seen this error before, one possibility is that since you probably downloaded the Xcode6 Beta from the internet (not the appstore as its not available yet), the machine you are trying to run it on will show a pop up asking you if you really want to open this app as its from the internet.
The same will happen when xcodebuild tries to launch the iPhone simulator app.
One thing you might want to try is to share screen with the machine and click "Open" in that pop up.
If that still doesn't work, I would try to:
Reset the Content & Settings of the simulator
Reboot the machine and make sure no simulator is running on start up (you can just choose not to re-open any app when restarting)
I am using OSX 10.7.5 from my MacBook Air to login to remote Linux workstation, running Suse (/etc/issue: SUSE Linux Enterprise Desktop 11 SP2 (x86_64) - Kernel \r (\l))
Everything was working fine until I started to play with macports latest X11, XQuartz XWindow System (XQuartz 2.7.4 (xorg-server 1.13.0)). By default OSX 10.7.5 comes with XQuartz 2.6.4 (xorg-server 1.10.6), however I've installed and made default XQuartz 2.7.4. I am now observing two issues:
(1) When logging to my remote Suse box (this is done via VPN tunnel btw, not sure if it matters), via 'user1> ssh -X user2#wks01' I am getting
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
This (at least appears) to be traced to the fact that there's no 'Security' extension on the new Xquarts server. Traced via ssh -vvv option, and then due to the fact that xauth is failing, so running it separately on MacBox, or remote Suse gives:
user2#wks04:~> xauth generate "$DISPLAY" .
trustedxauth: (argv):1: couldn't query Security extension on display "localhost:10.0"
'ssh -Y' logs in without warning
(2) What is also interesting, that in both ssh modes -X and -Y I am able to open and forward to my display any X-application that I have checked, including xclock, xlogo, xcalc and even eclipse. However running simple 'xterm' results in a hanging job (i.e. appears running), but xterm never displays on my Mac.
While rolling back to will XQuartz 2.6.4 probably help with the issues above (as all the above operations worked smoothly before), but I am curious now to understand the root of the matter.
Thank you in advance for your help,
Dmitry
Possible?
I think to do this I need to upgrade the AIR runtime on the Fire to 3, but the version in the app store won't install. I can't create an AIR apk that is both captive runtime and debug that I know of, so the debug version of the app has to run on the AIR runtime installed. Since the Fire comes with 2.7, 3.x apps won't run in debug mode.
Has anyone managed to get AIR 3 running on a Fire without using captive runtime?
To update AIR on your KF you have to get root privileges. Also keep in mind that android build on KF doesn't have any copy command (it cut off). So the best way I found is to flash your KF with modified (pre-rooted) stock version and then install new air.
Get pre-rooted stock version (I took it here). IMPORTANT: it installs via TWRP, google how to install TWRP on KF.
Put downloaded .zip and air_runtime.apk (latest AIR version) in the root of KF.
Reboot in Recovery mode (TWRP should load)
Flash this version.
On your PC open cmd and run "adb shell" (make sure you see your device in list when run "adb devices" otherwise check drivers).
Run "su" (if you downloaded secure version).
In shell go to sdcard ("ls" to get list of files/folders and "cd folder_name" to get into) and run "install air_runtime.apk /system/app/air_runtime.apk" (I think you can just run "install /sdcard/folder_with_air/air_runtime.apk /system/app/air_runtime.apk").
(7a. If it tells you that can't install because of file already exist, run the following two commands: "mount -o remount rw /system" (mount 'system' with read/write rights) and "mv /system/app/air_runtime.apk /system/app/air_runtime.bak" (rename air_runtime.apk into air_runtime.bak). Then repeat step 7.)
In KF just run (install) air_runtime.apk (use any file explorer, e.g. download ES File Explorer from Amazon).
Check AIR version in Applications.
That's all. Looks a bit complex, but in real it takes about 4-5 mins for me to update AIR (BUT I have TWRP already installed).
Hope it helps.
UPD. After your Kindle updates itself (version 6.3.1 currently the latest) you'll lose you SU privileges. AIR also will be rolled back to 2.7. You can prevent KF auto-updates (search on xda how to do it) or flash actual pre-rooted version (it gives you several months without problems).