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 mips, mipsel buildds: Unable to disable core dumps
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-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
gnupg FTBFS on mips*:
https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=mips&ver=2.0.22-1&stamp=1381015396
[...]
Making all in tests
make[3]: Entering directory `/«PKGBUILDDIR»/tests'
Making all in openpgp
make[4]: Entering directory `/«PKGBUILDDIR»/tests/openpgp'
echo '#!/bin/sh' >./gpg_dearmor
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[2]: Leaving directory `/«PKGBUILDDIR»'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [build-arch] Error 2
Cheers,
Andreas
--- 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 ---
