#39836 closed enhancement (fixed)
when xcode license was not accepted there should be a helpful error message
Reported by: | fabian@… | Owned by: | neverpanic (Clemens Lang) |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 2.3.0 |
Component: | base | Version: | 2.1.3 |
Keywords: | Cc: | larryv (Lawrence Velázquez), cooljeanius (Eric Gallager) | |
Port: |
Description (last modified by larryv (Lawrence Velázquez))
For example I just installed valgrind and got this error (for some reason xcode didn't have the EULA marked as accepted anymore):
$ sudo port install valgrind ... ---> Building valgrind Error: org.macports.build for port valgrind returned: command execution failed To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port valgrind failed frankfa@palmtree:~/repo/nativesdk (1) $ sudo port install valgrind ---> Computing dependencies for valgrind ---> Building valgrind Error: org.macports.build for port valgrind returned: command execution failed Please see the log file for port valgrind for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_valgrind/valgrind/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port valgrind failed
So I
$ cat /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_valgrind/valgrind/main.log ... :info:build You have not agreed to the Xcode license agreements, please run 'xcodebuild -license' (for user-level acceptance) or 'sudo xcodebuild -license' (for system-wide acceptance) from within a Terminal window to review and agree to the Xcode license agreements. ...
And the error is clear. However, for less experienced users, it might be very confusing. How about adding a less generic error message for this case, or maybe even run xcodebuild -license for the user if this happens.
Change History (10)
comment:1 Changed 11 years ago by larryv (Lawrence Velázquez)
Component: | ports → base |
---|---|
Description: | modified (diff) |
comment:2 Changed 11 years ago by fabian@…
Thank you for fixing the formatting, I wasn't aware how to do this nicely in trac.
I agree that accepting the license for the user is a bad idea. If you start
$ xcodebuild -license
the user would still have to type agree, etc by him/herself. However, I agree that just failing with a nice error message should be enough and it will cause less headaches for folks that run port commands in automated scripts.
comment:3 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
What method would you propose MacPorts use to determine 1) if the installed version of Xcode has a license that must be accepted at the command line (old versions didn't), and 2) if so, whether or not it has been accepted?
comment:4 Changed 11 years ago by drkp (Dan Ports)
We could look for that error message in the log. It would be nice to display it directly to users rather than require them to look through the build log.
I don't think there's a good way to check whether the license has been accepted short of trying xcodebuild and seeing if it fails. xcodebuild -version
works even if the license has been accepted, and xcodebuild -license
behaves the same whether you've already accepted the license or not.
comment:7 Changed 11 years ago by cooljeanius (Eric Gallager)
This is a more specific instance of #38662
comment:8 Changed 11 years ago by neverpanic (Clemens Lang)
Milestone: | → MacPorts Future |
---|---|
Owner: | changed from macports-tickets@… to cal@… |
Status: | new → assigned |
comment:9 Changed 11 years ago by neverpanic (Clemens Lang)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Changeset r115900 adds this and is due with MacPorts 2.3.
comment:10 Changed 11 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future → MacPorts 2.3.0 |
---|
We should not (and probably cannot) agree to the license for the user, but perhaps we can test for license acceptance before starting a build and fail more gracefully.