Opened 10 years ago
Last modified 10 years ago
#46949 new defect
pairs: build failure Generating pairs_SRCS.icns
Reported by: | Greisby (Greisberger Christophe) | Owned by: | NicosPavlov |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | mkae (Marko Käning), RJVB (René Bertin) | |
Port: | pairs |
Description
All the KDE ports fail to build on my machine:
- Yosemite 10.10.1
- Xcode 6.1.1
When I check the log files, I always see a command line with iconutil to generate a icns file from a iconset, followed by a failed copy of the icns. When I check the build directory, the iconset file is present, but not the icns file that should have been generated. Executing the command with sudo generates the icns and I can then successfully resume the build. Ports with lots of icons are a pain… I have to repeat this for each icon.
I tried settings the suid bit, the sticky bit, replacing /usr/bin/iconutil with a script that does a sudo. Nothing. The icns never gets generated. I'm really clueless.
Example:
:info:build [100%] Generating pairs_SRCS.icns :info:build cd /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game && /usr/bin/iconutil --convert icns --output /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.iconset :info:build Copying OS X content game/pairs.app/Contents/Resources/pairs_SRCS.icns :info:build /HDD/opt/local/bin/cmake -E copy /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns game/pairs.app/Contents/Resources/pairs_SRCS.icns :info:build Error copying file "/HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns" to "game/pairs.app/Contents/Resources/pairs_SRCS.icns". :info:build make[2]: *** [game/pairs.app/Contents/Resources/pairs_SRCS.icns] Error 1 :info:build make[2]: *** Waiting for unfinished jobs....
Attached, the full build log for the port pairs.
Attachments (1)
Change History (12)
Changed 10 years ago by Greisby (Greisberger Christophe)
comment:1 Changed 10 years ago by mf2k (Frank Schima)
Keywords: | kde iconutil yosemite removed |
---|---|
Owner: | changed from macports-tickets@… to nicos@… |
Port: | pairs added |
Summary: | KDE ports fail due to iconutil to generating icons → pairs: build failure Generating pairs_SRCS.icns |
comment:2 Changed 10 years ago by Greisby (Greisberger Christophe)
Well, renaming the summary was not really necessary I think. This problem occurs for all KDE ports that have ICNS generated from iconsets. Pairs was only an example to show the error.
comment:3 Changed 10 years ago by mkae (Marko Käning)
Cc: | mk@… rjvbertin@… added |
---|---|
Version: | 2.3.3 |
Interesting, just a few days ago I was successfully installing MacPorts anew on Yosemite up to parley and konversation without problems. I didn't encounter failing builds due to iconutil... How can that be?
comment:4 Changed 10 years ago by RJVB (René Bertin)
The unspecified (!!) error is here:
:info:build Copying OS X content game/pairs.app/Contents/Resources/pairs_SRCS.icns :info:build /HDD/opt/local/bin/cmake -E copy /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns game/pairs.app/Contents/Resources/pairs_SRCS.icns :info:build Error copying file "/HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns" to "game/pairs.app/Contents/Resources/pairs_SRCS.icns".
Somehow the process tries to copy to a relative directory (game/pairs.app/Contents/Resources/pairs_SRCS.icns
). I don't see an actual error when executing iconutil, so I can only guess that there is no ./game/pairs.app/Contents/Resources tree .
I don't have 10.10 but Marko could test that port easily enough. On 10.9 I get the same kind of output
> port build pairs && port log pairs | & fgrep pairs_SRCS.icns Generating pairs_SRCS.icns cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_pairs/pairs/work/build/game && /usr/bin/iconutil --convert icns --output /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.iconset Copying OS X content game/pairs.app/Contents/Resources/pairs_SRCS.icns /opt/local/bin/cmake -E copy /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_kde_pairs/pairs/work/build/game/pairs_SRCS.icns game/pairs.app/Contents/Resources/pairs_SRCS.icns
@greisberger: did you try to repeat the failed command? If repeating it works, could you please try to set the number of concurrent build jobs to 1 (for starters) in your /HDD/opt/local/etc/macports/macports.conf, clean port:pairs and repeat the build?
comment:5 follow-up: 6 Changed 10 years ago by Greisby (Greisberger Christophe)
@mk: Well, the key is perhaps "on a new Yosemite" I had successively Mountain Lion, Mavericks and Yosemite on m machine, with the corresponding MacPorts, Xcode & command line tools. But I now remember that I already had this problem when I migrated to Yosemite (following https://trac.macports.org/wiki/Migration). I then had these icon generation errors for the 1st time, but forgot to report them at this time.
@rjvbertin: Yes, the error is in the cop, because the icon generation command a few lines before does not create the icon, although the command is correct. Repeating the port command does not help. It fails exactly at the same point. To successfully install a port, I have to:
- sudo port install <port>
- if ok, cool, stop here
- get last icontool command list in the build log
- execute this command with sudo in a terminal
- go back to step 1
I don't know very well MacPorts internals, but since I do a "sudo port install", I imagine that icontool should be called with root rights, exactly like when I execute the icontool command with sudo. That's really weird.
As far as I can remember, this happened to me only for KDE ports. I don't know if there are other, non-KDE ports that use icontool to generate icns files. Do you know any? I could try one to see if it's really linked to KDE ports.
comment:6 Changed 10 years ago by RJVB (René Bertin)
Replying to greisberger@…:
- else get last icontool command line in the build log
- execute this command with sudo in a terminal
- go back to step 1
... I don't know very well MacPorts internals, but since I do a "sudo port install", I imagine that icontool should be called with root rights, exactly like when I execute the icontool command with sudo.
No, there's a non-privileged macports user (macports
), and the port command executes as much as possible as that user, to reduce the risk of overwriting things it shouldn't.
The only logical explanation I see (not that I *understand* said logic) is that there is a permissions issue while executing iconutil as the macports user. You could try to test that by doing sudo -u macports
instead of simply sudo in step 4) above. If that too fails, you'll have to check the permissions on iconutil's input files and directories as well as on the target directory. If that doesn't fail, I'm stymied (a umask issue??).
What are the permissions on your iconutil executable (ls -l /usr/bin/iconutil
)?
I don't know if there are other, non-KDE ports that use icontool to generate icns files. Do you know any?
Sadly, no.
comment:7 Changed 10 years ago by Greisby (Greisberger Christophe)
Source (and target) directory rights:
ls -ld /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/ drwxr-xr-x 18 macports admin 612 Mar 13 12:50 /HDD/opt/local/var/macports/build/_HDD_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_pairs/pairs/work/build/game/
Permissions for the iconutil executable:
-rwxr-xr-x 1 root wheel 156944 Sep 10 2014 /usr/bin/iconutil
Seems OK for me.
And indeed, executing the command line with sudo -u macports
at step 4 works also.
The icns file is generated.
I'm really mystified...
comment:8 Changed 10 years ago by Greisby (Greisberger Christophe)
I tool a look to the macports home directory, I only noticed one strange thing: Library is owned by root.
Is it normal?
sudo ls -al /Users/macports/ total 0 drwxr-xr-x 11 root admin 374 Feb 25 2013 . drwxr-xr-x 11 root admin 374 Nov 2 15:51 .. drwx------+ 3 macports staff 102 Feb 25 2013 Desktop drwx------+ 3 macports staff 102 Feb 25 2013 Documents drwx------+ 3 macports staff 102 Feb 25 2013 Downloads drwxr-xr-x 3 root admin 102 Apr 27 2012 Library drwx------+ 3 macports staff 102 Feb 25 2013 Movies drwx------+ 3 macports staff 102 Feb 25 2013 Music drwx------+ 3 macports staff 102 Feb 25 2013 Pictures drwxr-xr-x+ 4 macports staff 136 Feb 25 2013 Public drwxr-xr-x+ 3 macports staff 102 Feb 25 2013 Sites
Library:
Paradise-in-Zenon:Libraries Greisby$ sudo ls -alR /Users/macports/Library/ total 0 drwxr-xr-x 3 root admin 102 Apr 27 2012 . drwxr-xr-x 11 root admin 374 Feb 25 2013 .. drwxr-xr-x 9 root admin 306 Nov 7 11:56 Preferences /Users/macports/Library//Preferences: total 88 drwxr-xr-x 9 root admin 306 Nov 7 11:56 . drwxr-xr-x 3 root admin 102 Apr 27 2012 .. drwx------ 4 root admin 136 Oct 19 2012 KDE -rw------- 1 macports macports 258 Jan 12 2014 com.apple.HIToolbox.plist -rw------- 1 macports wheel 58 Jan 7 2014 com.apple.LaunchServices.plist -rw-r--r-- 1 macports admin 16914 Oct 29 2012 com.apple.dt.Xcode.plist -rw------- 1 macports macports 161 Jan 10 2014 com.apple.ibtool.plist -rw------- 1 macports macports 4313 Nov 7 11:56 com.trolltech.plist -rw------- 1 macports macports 112 Nov 4 15:25 xcodebuild.plist /Users/macports/Library//Preferences/KDE: total 0 drwx------ 4 root admin 136 Oct 19 2012 . drwxr-xr-x 9 root admin 306 Nov 7 11:56 .. drwx------ 4 root admin 136 Oct 19 2012 cache-Paradise-in-Zenon.local drwxr-xr-x 3 root admin 102 Oct 19 2012 share /Users/macports/Library//Preferences/KDE/cache-Paradise-in-Zenon.local: total 2080 drwx------ 4 root admin 136 Oct 19 2012 . drwx------ 4 root admin 136 Oct 19 2012 .. -rw-r--r-- 1 root admin 1058755 Oct 19 2012 ksycoca4 -rw-r--r-- 1 root admin 440 Oct 19 2012 ksycoca4stamp /Users/macports/Library//Preferences/KDE/share: total 0 drwxr-xr-x 3 root admin 102 Oct 19 2012 . drwx------ 4 root admin 136 Oct 19 2012 .. drwxr-xr-x 3 root admin 102 Oct 19 2012 config /Users/macports/Library//Preferences/KDE/share/config: total 8 drwxr-xr-x 3 root admin 102 Oct 19 2012 . drwxr-xr-x 3 root admin 102 Oct 19 2012 .. -rw------- 1 root admin 29 Oct 19 2012 kdebugrc
comment:9 Changed 10 years ago by RJVB (René Bertin)
That seems surprising, but as you can see macports
does have read access to the things that count, and can (probably) also change the files in ~/Library/Preferences (not replace them, though).
You could try to do sudo chown -R macports ~macports
to hand over the home directory to the user, but I think that if that were the problem your manual sudo -u macports iconutil ...
command would have failed too.
comment:10 Changed 10 years ago by RJVB (René Bertin)
At this point it is probably a good idea to post a pointer to your latest findings on the macports-dev ML, and ask there what might be going on.
comment:11 Changed 10 years ago by Greisby (Greisberger Christophe)
Well, changing the ownership did not help. I'll ask on the ML.
pairs build log