app-admin/conky-1.10.0 fails to build. build.log and my emerge --info are in attachment. Reproducible: Always
Created attachment 413226 [details] build.log
Created attachment 413228 [details] emerge --info
There are lacking some dependencies: app-text/docbook2X I installed it, but now it asks for the command "man", being installed with man-db.
(In reply to jorgicio from comment #3) > There are lacking some dependencies: > app-text/docbook2X > > I installed it, but now it asks for the command "man", being installed with > man-db. I installed man-db, but it still asks for 'man'.
Same problem here.
Same here.
It happens because man binary (/usr/bin/man) doesn't have read permissions for others (I don't know why), just execution permissions. Therefore cmake's find_program can't find man binary as it is executed as portage user. A workaround is to add read permissions to man binary for others (sudo chmod o+r /usr/bin/man) or add portage to man group. I would recommend the second option. Somebody more experienced could explain why man has this permissions and which is the best way for solving this?
(In reply to Gerard Garcia from comment #7) > It happens because man binary (/usr/bin/man) doesn't have read permissions > for others (I don't know why), just execution permissions. Therefore cmake's > find_program can't find man binary as it is executed as portage user. > > A workaround is to add read permissions to man binary for others (sudo chmod > o+r /usr/bin/man) or add portage to man group. > > I would recommend the second option. > > Somebody more experienced could explain why man has this permissions and > which is the best way for solving this? Well, I use the first option, and change the permissions back after compilation finished. Everything goes well, thanks Gerard.
(In reply to Gerard Garcia from comment #7) > It happens because man binary (/usr/bin/man) doesn't have read permissions > for others (I don't know why), just execution permissions. Therefore cmake's > find_program can't find man binary as it is executed as portage user. To me the culprit is clearly cmake. There is an upstream issue about this problem, open since 2010 (OMG, 5 years!!!): http://cmake.org/Bug/view.php?id=10468 Maybe we should just stress the importance of changing this absurdity on cmake mailing list and bug tracker.
I'm not sure that it is a Cmake problem. For example, man binary in Ubuntu has read permissions for others so it would not fail there. It seems strange that man binary in Gentoo has these permissions.
(In reply to Gerard Garcia from comment #10) > I'm not sure that it is a Cmake problem. For example, man binary in Ubuntu > has read permissions for others so it would not fail there. It seems strange > that man binary in Gentoo has these permissions. There is no reason for an executable file to be readable for the same class of users who can execute it. It's always been so, for directories and files, due to security or "privacy" reasons. Cmake should just check if a program (an executable file) can be executed by the user, not if it is readable. Examples (you will find a few surprises...): $ find /usr/bin/ -perm 4711 $ find /usr/bin/ -perm 0711 Ok?
(In reply to Ivan Iraci from comment #11) > Examples (you will find a few surprises...): > $ find /usr/bin/ -perm 4711 > $ find /usr/bin/ -perm 0711 Or, more "astonishingly": $ find /bin/ -perm 4711 $ find /bin/ -perm 0711
May be related: https://github.com/brndnmtthws/conky/issues/100
(In reply to Ivan Iraci from comment #11) > (In reply to Gerard Garcia from comment #10) > > > I'm not sure that it is a Cmake problem. For example, man binary in Ubuntu > > has read permissions for others so it would not fail there. It seems strange > > that man binary in Gentoo has these permissions. > > There is no reason for an executable file to be readable for the same class > of users who can execute it. > > It's always been so, for directories and files, due to security or "privacy" > reasons. > > Cmake should just check if a program (an executable file) can be executed by > the user, not if it is readable. > > Examples (you will find a few surprises...): > $ find /usr/bin/ -perm 4711 > $ find /usr/bin/ -perm 0711 > > Ok? Ok, I guess it has its advantages. Anyway, not a lot of executables do this (at least in my system), seems a bit arbitrary.
(In reply to Alexandre from comment #13) > May be related: > > https://github.com/brndnmtthws/conky/issues/100 This is for Ascii issues and Lua 5.3, which is not available yet in Gentoo.
Anyway, I am masking app-admin/conky-1.10.0: it's an unusable crap. Config format changed, many lua APIs ceased to work, causes corruption in X (at least with awesomewm) and so on. Worst release in a decade!
The cmake problem is already reported in bug #486270 - for ages. You can work around it by doing FEATURES=-userpriv -usersandbox" emerge conky But I will try out the solution to add portage to the man group. I like this much better. However, I never tried out the lua bindings but hit an issue that after transferring my old config to the new format, the conky window was white and opaque. The reason was, that I defined own_window_color (in case no composite manager was running) and after commenting it out, conky works like before again. Only the color for my horizontal rulers and bars do not listen to my config any more and are white, which is a bit annoying.
*** Bug 562006 has been marked as a duplicate of this bug. ***
I forgot about the dependency on app-text/docbook2X. Sorry for the inconvenience. This is now fixed in git.
(In reply to Daniel Pielmeier from comment #19) > I forgot about the dependency on app-text/docbook2X. Sorry for the > inconvenience. > > This is now fixed in git. I still can't compile it. My build.log is below.
Created attachment 413768 [details] build2.log
Created attachment 413770 [details] new emerge_info Trying to compile on computer from my work, so its emerge --info may different.
(In reply to Sven Eden from comment #17) > The cmake problem is already reported in bug #486270 - for ages. > > You can work around it by doing > > FEATURES=-userpriv -usersandbox" emerge conky > > But I will try out the solution to add portage to the man group. I like this > much better. > > However, I never tried out the lua bindings but hit an issue that after > transferring my old config to the new format, the conky window was white and > opaque. > > The reason was, that I defined own_window_color (in case no composite > manager was running) and after commenting it out, conky works like before > again. > > Only the color for my horizontal rulers and bars do not listen to my config > any more and are white, which is a bit annoying. Building like that did the trick. I created a file called nouserpriv.conf inside /etc/portage/env. Its content is: FEATURES="-userpriv -usersandbox" Then, I added the following entry to a file I created called /etc/portage/package.env/envs: app-admin/conky nouserpriv.conf Then, Conky compiles fine.
Like Sven Eden mentioned above the issue about not finding /us/bin/man is a different bug #486270.
