Created attachment 480096 [details] build.log Portage 2.3.6 (python 3.4.6-final-0, default/linux/amd64/13.0/desktop/plasma/systemd, gcc-7.1.0, glibc-2.24-r3, 4.12.0-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-4.12.0-gentoo-x86_64-Intel-R-_Core-TM-_i3-5005U_CPU_@_2.00GHz-with-gentoo-2.4.1 KiB Mem: 8091508 total, 3327184 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Mon, 03 Jul 2017 05:00:01 +0000 sh bash 4.4_p12 ld GNU ld (Gentoo 2.28 p1.2) 2.28 app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl: 5.24.1-r2::gentoo dev-lang/python: 2.7.13::gentoo, 3.4.6::gentoo dev-util/cmake: 3.8.2::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1::gentoo sys-apps/openrc: 0.27.2::gentoo sys-apps/sandbox: 2.10-r4::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r3::gentoo sys-devel/automake: 1.13.4-r1::gentoo, 1.15.1::gentoo sys-devel/binutils: 2.28-r2::gentoo sys-devel/gcc: 6.3.0::gentoo, 7.1.0-r1::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r4::gentoo sys-devel/make: 4.2.1-r1::gentoo sys-kernel/linux-headers: 4.10::gentoo (virtual/os-headers) sys-libs/glibc: 2.24-r3::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FCFLAGS="-O2 -pipe -march=native" FEATURES="assume-digests binpkg-logs candy compress-build-logs config-protect-if-modified distlocks ebuild-locks fail-clean fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe -march=native" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo cdda cdr cli cracklib crypt cups cxx dbus declarative dri dts dvd dvdr efiemu emboss encode epub exif fam fax ffmpeg firefox flac fortran gdbm gif glamor google gpm grub gstreamer gtk hwaccel iconv ipv6 jpeg kde kipi kwallet lame lcms ldap libnotify lm_sensors mad mng modules monolithic mp3 mp4 mpeg mtp multilib ncurses networkmanager nls nptl office ogg openal opencl opengl openmp opus pam pango pch pcre pdf phonon pim plasma png policykit postproc postscript ppds pulseaudio qml qt3support qt5 readline scanner scrobbler sdl seccomp semantic-desktop session spell ssl startup-notification svg system-ffmpeg system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-sqlite systemd tcpd threads tiff truetype udev udisks unicode upower usb vaapi vc vorbis vpx vulkan wayland webp widgets wifi wxwidgets x264 x265 xattr xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="sony_dscf1" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev synaptics" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby21 ruby22" SANE_BACKENDS="hp" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= app-crypt/gpgme-1.8.0-r3::gentoo was built with the following: USE="cxx qt5 -common-lisp -python -static-libs" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_4 -python3_5 -python3_6"
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)
