Your message dated Sat, 28 Dec 2013 20:17:26 +0100 with message-id <[email protected]> and subject line Re: Bug#730846: gnupg2: FTBFS on mips, mipsel: gpg: Fatal: can't disable core dumps: Operation not permitted has caused the Debian Bug report #730846, regarding gnupg2: FTBFS on mips* "can't disable core dumps: Operation not permitted" to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 730846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730846 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: gnupg2 Version: 2.0.22-2 Severity: serious Hi, Your package FTBFS on mips* with: """ echo "../../g10/gpg2 --homedir . --no-options --no-greeting \ --no-secmem-warning --batch --dearmor" >>./gpg_dearmor chmod 755 ./gpg_dearmor ./gpg_dearmor > ./pubring.gpg < ./pubring.asc gpg: Fatal: can't disable core dumps: Operation not permitted make[4]: *** [pubring.gpg] Error 2 make[4]: Leaving directory `/«PKGBUILDDIR»/tests/openpgp' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/«PKGBUILDDIR»/tests' make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»' make[1]: Leaving directory `/«PKGBUILDDIR»' dh_auto_build: make -j1 returned exit code 2 make: *** [build-arch] Error 2 """ ~Niels
--- End Message ---
--- Begin Message ---On Sun, Dec 01, 2013 at 01:36:12PM +0100, Aurelien Jarno wrote: > On Sat, Nov 30, 2013 at 10:42:54PM -0500, Eric Dorland wrote: > > Control: reassign -1 buildd.debian.org > > Control: severity -1 important > > Control: retitle -1 mips, mipsel buildds: Unable to disable core dumps > > > > As pointed out by Bastian Blank in > > <[email protected]>: > > > > > Turns out it does fail. There seems to be a kernel bug that makes it > > > fails if anything tries to set a value of RLIM_INFINITY: > > > > > > | getrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0 > > > | setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = -1 > > > | EPERM (Operation not permitted) > > > > > > Workaround is to also set the hard limit to a smaller value. > > > > All values equals or below 0x7ffffffe should work. > > Note that this problem is being working on in the last few months, but > it involves a lot of people. The problem is an inconsistency in the > definition of RLIM64_INFINITY between kernel and userland. It has been > there for almost 7 years, but only really appeared when the prlimit64 > syscall has been wired on the kernel side. > > So far we have been able to agree that the problem should be fixed on > the glibc side. It has been fixed upstream, and the fix has been > backported in sid. However to get it fully fixed on the build daemons, > we also have to fix it in glibc/wheezy. An upload is currently being > prepared, then the step afterwards will be to get it installed on the > build daemons. > The fix has gone to eglibc wheezy stable-proposed-updates, it will be released with 7.4. In the meantime DSA has been kind enough to install this version on the build daemons, so the problem is now fixed from this point of view. We have requeued the know affected packages, that is gnupg2 and ocaml-extunix, they have been built and uploaded on both mips and mipsel. I am therefore closing this bug. -- Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net
--- End Message ---
