Summary: | app-crypt/gpgme-1.8.0-r3 failed to build with gcc 7.1.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | klaus818 |
Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, josef64, jstein, slyfox, tsmksubc |
Priority: | Normal | Keywords: | UPSTREAM |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://dev.gnupg.org/T3214 | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=624308 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 617524 | ||
Attachments: |
build.log
gpgme-1.8.0-gcc-7.patch |
Description
klaus818
2017-07-03 07:05:27 UTC
From the "emerge --info" you have currently set gcc-7.1.0 and the attached build.log is from a gcc-7.1.0 build. But this Bug blocks currently gcc-6 I can this bug not reproduce. [ebuild R ] app-crypt/gpgme-1.8.0-r3:1/11::gentoo USE="cxx qt5 -common-lisp -python -static-libs" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 0 KiB build here fine with gcc-6.3.0 and with gcc-7.1.0-r1 Have you rely rebuild your complete system with gcc-7.1.0-r1? Sorry, wrong title... I checked it with gcc-6.3.0 and no problem. I can't build it with gcc-7.1.0. Hi, I appreciate you taking the time to test packages with newer gcc, it will be more productive for the eco-system if you can work directly with upstream to resolve these issues that are not gentoo specific. Bug tracking of upstream is here[1] Thanks! [1] https://dev.gnupg.org/ For me git upstream compiles just fine. 1.8.0 needs two patches (both are missing headers): https://dev.gnupg.org/rM5e27bf98b4c48cf6a239bcc94b7b67515ff339e7 https://dev.gnupg.org/rM60064c665ec98a2a994fc6c8ad701e60b963ce7e Created attachment 482072 [details, diff]
gpgme-1.8.0-gcc-7.patch
(In reply to Sergei Trofimovich from comment #4) > For me git upstream compiles just fine. Then the issue will be fixed when a new release is introduced, carrying downstream patches for a masked version of gcc doesn't make much sense at this point, upstream fixing (as done in this case) should be the goal. Good to know. Lots of fixes in master on top of 1.9.0 to make may feature work, they refuse to release 1.9.1. I recently tried to compile master and have sandbox violation for tests[1], this is new. I do not understand these guys. [1] https://lists.gnupg.org/pipermail/gnupg-devel/2017-July/032940.html Applied to gpgme-1.8.0-r3. Thanks! (In reply to Alon Bar-Lev from comment #8) > Lots of fixes in master on top of 1.9.0 to make may feature work, they > refuse to release 1.9.1. > > I recently tried to compile master and have sandbox violation for tests[1], > this is new. Likely better to file this on dev.gnupg.org, but indeed the /run/user switch rather than using socket in $GNUPGHOME has been interesting. It should only try to use it if /run/user/$UID actually exists though? Can you try in a chroot where it does not exist? We might want/needd to add a sandbox exception to it, as this is mostly a downstream issue, which might be reason for no upstream action. (In reply to Kristian Fiskerstrand from comment #10) > (In reply to Alon Bar-Lev from comment #8) > > Lots of fixes in master on top of 1.9.0 to make may feature work, they > > refuse to release 1.9.1. > > > > I recently tried to compile master and have sandbox violation for tests[1], > > this is new. > > Likely better to file this on dev.gnupg.org, but indeed the /run/user switch > rather than using socket in $GNUPGHOME has been interesting. It should only > try to use it if /run/user/$UID actually exists though? Can you try in a > chroot where it does not exist? We might want/needd to add a sandbox > exception to it, as this is mostly a downstream issue, which might be reason > for no upstream action. upon double-checking, defs.scm in tests does gpgconf --create-socketdir so the /run/user/UID/gnupg path is created unconditionally in tests. (In reply to Kristian Fiskerstrand from comment #11) > (In reply to Kristian Fiskerstrand from comment #10) > > (In reply to Alon Bar-Lev from comment #8) > > > Lots of fixes in master on top of 1.9.0 to make may feature work, they > > > refuse to release 1.9.1. > > > > > > I recently tried to compile master and have sandbox violation for tests[1], > > > this is new. > > > > Likely better to file this on dev.gnupg.org, but indeed the /run/user switch > > rather than using socket in $GNUPGHOME has been interesting. It should only > > try to use it if /run/user/$UID actually exists though? Can you try in a > > chroot where it does not exist? We might want/needd to add a sandbox > > exception to it, as this is mostly a downstream issue, which might be reason > > for no upstream action. > > upon double-checking, defs.scm in tests does gpgconf --create-socketdir so > the /run/user/UID/gnupg path is created unconditionally in tests. ehrm, ignore this comment, wrong package's tests (gnupg itself...) (In reply to Kristian Fiskerstrand from comment #12) > (In reply to Kristian Fiskerstrand from comment #11) > > (In reply to Kristian Fiskerstrand from comment #10) > > > (In reply to Alon Bar-Lev from comment #8) > > > > Lots of fixes in master on top of 1.9.0 to make may feature work, they > > > > refuse to release 1.9.1. > > > > > > > > I recently tried to compile master and have sandbox violation for tests[1], > > > > this is new. > > > > > > Likely better to file this on dev.gnupg.org, but indeed the /run/user switch > > > rather than using socket in $GNUPGHOME has been interesting. It should only > > > try to use it if /run/user/$UID actually exists though? Can you try in a > > > chroot where it does not exist? We might want/needd to add a sandbox > > > exception to it, as this is mostly a downstream issue, which might be reason > > > for no upstream action. > > > > upon double-checking, defs.scm in tests does gpgconf --create-socketdir so > > the /run/user/UID/gnupg path is created unconditionally in tests. > > ehrm, ignore this comment, wrong package's tests (gnupg itself...) oh, this is gnupg change? if sandbox is active then it will fail anything at /run to be created. the tests (gpg, gpgme) should not create anything outside of the builddir or $TMPDIR. there should be a variable for /run prefix for tests, somekind of environment to be applied during tests. (In reply to Alon Bar-Lev from comment #13) From 2.0.20 changelog, you might want to try to see if you can reproduce with .19 , as it likely isn't a change in gpgme * A socket directory for a non standard GNUGHOME is now created on the fly under /run/user. Thus "gpgconf --create-socketdir" is now optional. The use of "gpgconf --remove-socketdir" to clean up obsolete socket directories is however recommended to avoid cluttering /run/user with useless directories. (In reply to Kristian Fiskerstrand from comment #14) > (In reply to Alon Bar-Lev from comment #13) > > From 2.0.20 changelog, you might want to try to see if you can reproduce > with .19 , as it likely isn't a change in gpgme > > * A socket directory for a non standard GNUGHOME is now created on > the fly under /run/user. Thus "gpgconf --create-socketdir" is now > optional. The use of "gpgconf --remove-socketdir" to clean up > obsolete socket directories is however recommended to avoid > cluttering /run/user with useless directories. Upstream should care of this, right? But these guys are not responsive. Recently, they also added this[1] to kill all daemons. This is insane. You have a good relationship with them, please ask them to not modify the system state during build/test in all of their packages. [1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=a226eca84670ef4e171c3a54e7caefb3a89254a4 (In reply to Alon Bar-Lev from comment #15) > (In reply to Kristian Fiskerstrand from comment #14) > > (In reply to Alon Bar-Lev from comment #13) > > > > From 2.0.20 changelog, you might want to try to see if you can reproduce > > with .19 , as it likely isn't a change in gpgme > > > > * A socket directory for a non standard GNUGHOME is now created on > > the fly under /run/user. Thus "gpgconf --create-socketdir" is now > > optional. The use of "gpgconf --remove-socketdir" to clean up > > obsolete socket directories is however recommended to avoid > > cluttering /run/user with useless directories. > > Upstream should care of this, right? But these guys are not responsive. > On the /run issue there is some pushback, as they claim it is required to be writable under LSB etc, which is why I'm wondering if there is need for sandbox excemption on it, or we need local patching.. for access to components etc they have added --build-prefix and GNUPG_BUILDDIR envvar > Recently, they also added this[1] to kill all daemons. This is insane. GNUPGHOME env var should be set at that stage, so it should only affect the temporary running component? If it affects more, please file a bug report so I can look into it.
> On the /run issue there is some pushback, as they claim it is required to be
> writable under LSB etc, which is why I'm wondering if there is need for
> sandbox excemption on it, or we need local patching.. for access to
> components etc they have added --build-prefix and GNUPG_BUILDDIR envvar
>
fwiw, if we were to do anything here it'd likely be in common/homedir.c in _gnupg_socketdir_internal, by either changing bases array, or directly returning a flag value including 2 upon checking e.g an ENV variable, I _think_ that should result in it using socket only in gnupg homedir, but that will break noexec/NFS gnupg homedirs etc which is part of rationale for using /run to begin with
(In reply to Kristian Fiskerstrand from comment #17) > > On the /run issue there is some pushback, as they claim it is required to be > > writable under LSB etc, which is why I'm wondering if there is need for > > sandbox excemption on it, or we need local patching.. for access to > > components etc they have added --build-prefix and GNUPG_BUILDDIR envvar > > > > fwiw, if we were to do anything here it'd likely be in common/homedir.c in > _gnupg_socketdir_internal, by either changing bases array, or directly > returning a flag value including 2 upon checking e.g an ENV variable, I > _think_ that should result in it using socket only in gnupg homedir, but > that will break noexec/NFS gnupg homedirs etc which is part of rationale for > using /run to begin with PoC: https://download.sumptuouscapital.com/gentoo/gnupg-hack-force-homedir.txt (In reply to Kristian Fiskerstrand from comment #18) > https://download.sumptuouscapital.com/gentoo/gnupg-hack-force-homedir.txt Thanks! This is a a very good tiny patch for downstream. However, for upstream I expect a patch that defines where to put the socket the path should be: custom_location(), // if available "/run", "/var/run" the mechanism of gnupg_homedir() is probably obsoleted in their eyes. (In reply to Alon Bar-Lev from comment #19) > the mechanism of gnupg_homedir() is probably obsoleted in their eyes. yes and no, it reverts back to homedir if certain conditions are met, which is what is being leveraged in the patch already (flag of 2 being no /run etc), Upstream might not be unwelcome to some env var to have a custom directory, it is already being discussed in the comment such as 477 /* It has been suggested to first check XDG_RUNTIME_DIR envvar. 478 * However, the specs state that the lifetime of the directory MUST 479 * be bound to the user being logged in. Now GnuPG may also be run 480 * as a background process with no (desktop) user logged in. Thus 481 * we better don't do that. */ .. but that doesn't exclude some other var not set in other environments... but yes, this is just a quick hack to demonstrate where changes can be done to get something like this, I don't have a strong interest in upstreaming it myself as things mostly works for me :) (In reply to Kristian Fiskerstrand from comment #20) > I don't have a strong interest in upstreaming it > myself as things mostly works for me :) This is a must, they need to port all of their tests of at least gnupg/gpgme to use this mechanism. We cannot keep maintain this as downstream. Another option would be to whitebox sandbox, but then we still affect system state by killing user's daemons or interacting with these. (In reply to Alon Bar-Lev from comment #21) > (In reply to Kristian Fiskerstrand from comment #20) > > I don't have a strong interest in upstreaming it > > myself as things mostly works for me :) > > This is a must, they need to port all of their tests of at least gnupg/gpgme > to use this mechanism. We cannot keep maintain this as downstream. Another > option would be to whitebox sandbox, but then we still affect system state > by killing user's daemons or interacting with these. whenever using a custom --homedir a separate folder is created under /run/user/$UID/gnupg for the socket, so I don't see how it would impact system state per se.. but .. can you open a separate bug for it so we don't forget this discussion, and if you want to help clean up the patch to have something that can be upstreamed it'd be much appreciated; I can certainly try to help on actually doing so .. (In reply to Kristian Fiskerstrand from comment #22) > (In reply to Alon Bar-Lev from comment #21) > > (In reply to Kristian Fiskerstrand from comment #20) > > > I don't have a strong interest in upstreaming it > > > myself as things mostly works for me :) > > > > This is a must, they need to port all of their tests of at least gnupg/gpgme > > to use this mechanism. We cannot keep maintain this as downstream. Another > > option would be to whitebox sandbox, but then we still affect system state > > by killing user's daemons or interacting with these. > > whenever using a custom --homedir a separate folder is created under --homedir in this case actually referring to GNUPGHOME env var (mechanism is the same, but that ensures it affects all tools from that environment) |