Processing of gnumach_1.8+git20180218-1_hurd-i386.changes
gnumach_1.8+git20180218-1_hurd-i386.changes uploaded successfully to localhost along with the files: gnumach_1.8+git20180218-1.dsc gnumach_1.8+git20180218.orig.tar.bz2 gnumach_1.8+git20180218-1.debian.tar.bz2 gnumach-common_1.8+git20180218-1_all.deb gnumach-dev_1.8+git20180218-1_hurd-i386.deb gnumach-image-1-486_1.8+git20180218-1_hurd-i386.deb gnumach-image-1-xen-486_1.8+git20180218-1_hurd-i386.deb gnumach-image-1.8-486-dbg_1.8+git20180218-1_hurd-i386.deb gnumach-image-1.8-486_1.8+git20180218-1_hurd-i386.deb gnumach-image-1.8-xen-486-dbg_1.8+git20180218-1_hurd-i386.deb gnumach-image-1.8-xen-486_1.8+git20180218-1_hurd-i386.deb gnumach_1.8+git20180218-1_hurd-i386.buildinfo kernel-image-1.8-486-di_1.8+git20180218-1_hurd-i386.udeb kernel-image-1.8-xen-486-di_1.8+git20180218-1_hurd-i386.udeb Greetings, Your Debian queue daemon (running on host usper.debian.org)
gnumach_1.8+git20180218-1_hurd-i386.changes is NEW
binary:gnumach-common is NEW. binary:gnumach-common is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
/proc availability on buildds
I was unpleasantly surprised to see gnustep-base/1.25.1-2 FTBFS on GNU/Hurd because of a testsuite failure (NSProcessInfo -systemUptime returning 0). The reason for the test failure is this: | checking kernel support for /proc filesystem... no | checking support for /proc psinfo struct... no | checking link to exe of process in /proc... no 1.25.1-1 built successfully on the very same host (mahler) a month ago: | checking kernel support for /proc filesystem... yes | checking support for /proc psinfo struct... no | checking link to exe of process in /proc... /proc/self/exe Could you please explain what causes this different behavior -- is it a bug in the gnustep-base package that it assumes /proc is available on GNU/Hurd? I'm pretty sure someone (Samuel?) told me long time ago that it is safe to assume that, for buildd setups specifically.
Re: /proc availability on buildds
Yavor Doganov, on dim. 18 févr. 2018 23:52:32 +0200, wrote: > | checking kernel support for /proc filesystem... no Looking at the actual test: grep 'proc' /proc/mounts It seems there was a temporary issue on mahler: $ cat /proc/mounts cat: /proc/mounts: (os/kern) invalid right Rebooting seems to fix it, I have requeued gnustep-base. Something to keep an eye on. Samuel
Re: /proc availability on buildds
Samuel Thibault wrote: > Yavor Doganov, on dim. 18 févr. 2018 23:52:32 +0200, wrote: > > | checking kernel support for /proc filesystem... no > It seems there was a temporary issue on mahler: > [...] > Rebooting seems to fix it, I have requeued gnustep-base. Thanks very much, built successfully.
