Bug#652598: aboot FTBFS in unstable
Jonathan Nieder wrote: So what are the possible means of getting around the problem? Me providing a login to an Alpha with an up-to-date unstable chroot? A sponsored upload of aboot? Does that require at least a DM to prepare the package? Could you become a DD? I'm confident in your skills and ethics, for what little that's worth. Even assuming a dd could be found or created who was prepared to build and upload a package on alpha i'm not convinced that a binary package that can only be built on a debian-ports.org architecture should be in the official archive. I can't seem to find any policy directly prohibiting it but packages must be buildable within the same release. would seem to imply to me that all arch all packages should be buildable on at least one release architecture. If that takes a long time, in the meantime would it be possible to get an alpha cross-toolchain packaged so the package can be built on non-alpha machines? I'd be happy to help with that. (See [1] for a starting point.) [1] http://bugs.debian.org/623953#20 I'm not a dd myself but that sounds like the way to go to me if it's desired to keep aboot-cross and aboot-core in the official archive. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
Looks like the cause is that isolib.h #include-s asm/stat.h from linux-libc-dev which conflicts in namespace with sys/stat from glibc. So in the spirit of aboot (1.0~pre20040408-2) unstable; urgency=low * Include userspace headers from lib/isolib.c instead of kernel headers; this isn't kernel code anyway, and the kernel headers don't work right on i386 the way they're being used. does this patch help? The patch may be sufficient to get aboot building on most architectures (which, I guess, would address the RC nature of this bug since Alpha is not a release arch), but my recent test of building aboot on an Alpha suggests that there are a lot more fixes required to get this package building fully again on Alpha (the architecture aboot is intended for). Also upstream is pretty much unresponsive and has apparently forgotten the password to the official sourceforge repo, so Matt Turner (Gentoo developer, who I have CCed) and I are planning to fork aboot so that we can give it some needed attention. For the purposes of this RC bug I guess I should try the patch on aboot, build it on a PC and see if that is capable of making a working boot disc for an Alpha. It may be a few days before I can do that. Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
On Fri, Jan 20, 2012 at 5:24 AM, Michael Cree mc...@orcon.net.nz wrote: Looks like the cause is that isolib.h #include-s asm/stat.h from linux-libc-dev which conflicts in namespace with sys/stat from glibc. So in the spirit of aboot (1.0~pre20040408-2) unstable; urgency=low * Include userspace headers from lib/isolib.c instead of kernel headers; this isn't kernel code anyway, and the kernel headers don't work right on i386 the way they're being used. does this patch help? The patch may be sufficient to get aboot building on most architectures (which, I guess, would address the RC nature of this bug since Alpha is not a release arch), but my recent test of building aboot on an Alpha suggests that there are a lot more fixes required to get this package building fully again on Alpha (the architecture aboot is intended for). Also upstream is pretty much unresponsive and has apparently forgotten the password to the official sourceforge repo, so Matt Turner (Gentoo developer, who I have CCed) and I are planning to fork aboot so that we can give it some needed attention. For the purposes of this RC bug I guess I should try the patch on aboot, build it on a PC and see if that is capable of making a working boot disc for an Alpha. It may be a few days before I can do that. Cheers Michael. Here's the equivalent Gentoo bug report and patch/workaround: https://bugs.gentoo.org/364697 Thanks, Matt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
On Fri, Jan 20, 2012 at 11:24:49PM +1300, Michael Cree wrote: For the purposes of this RC bug I guess I should try the patch on aboot, build it on a PC and see if that is capable of making a working boot disc for an Alpha. It may be a few days before I can do that. Note that the source package upload must be accompanied by a build of the Arch: all package built from aboot source, and this package can only be built on alpha. So there's not much point in preparing a fix that only fixes the build on non-alpha architectures, and there's also not much point in preparing a fix without a DD being in a position to build and upload alpha binary packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#652598: aboot FTBFS in unstable
On 21/01/12 08:47, Steve Langasek wrote: On Fri, Jan 20, 2012 at 11:24:49PM +1300, Michael Cree wrote: For the purposes of this RC bug I guess I should try the patch on aboot, build it on a PC and see if that is capable of making a working boot disc for an Alpha. It may be a few days before I can do that. Note that the source package upload must be accompanied by a build of the Arch: all package built from aboot source, and this package can only be built on alpha. So there's not much point in preparing a fix that only fixes the build on non-alpha architectures, and there's also not much point in preparing a fix without a DD being in a position to build and upload alpha binary packages. And that's a fundamental problem. None of us Alpha porters working on the Alpha port at Debian-Ports are DDs, nevertheless we have over 95% of the unstable distribution built, and would like to start work on getting aboot fixed and updated. So what are the possible means of getting around the problem? Me providing a login to an Alpha with an up-to-date unstable chroot? A sponsored upload of aboot? Does that require at least a DM to prepare the package? Cheers Michael. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
Michael Cree wrote: And that's a fundamental problem. None of us Alpha porters working on the Alpha port at Debian-Ports are DDs, nevertheless we have over 95% of the unstable distribution built, and would like to start work on getting aboot fixed and updated. So what are the possible means of getting around the problem? Me providing a login to an Alpha with an up-to-date unstable chroot? A sponsored upload of aboot? Does that require at least a DM to prepare the package? Could you become a DD? I'm confident in your skills and ethics, for what little that's worth. If that takes a long time, in the meantime would it be possible to get an alpha cross-toolchain packaged so the package can be built on non-alpha machines? I'd be happy to help with that. (See [1] for a starting point.) [1] http://bugs.debian.org/623953#20 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
reassign 652598 src:aboot 1.0~pre20040408-3 tags 652598 + upstream patch quit Hi, peter green wrote: package: aboot severity: serious Aboot FTBFS with the following error Yep, I can reproduce this; thanks for filing it. Just some quick tips for the future: 1. Please use Source: aboot, not Package: aboot. 2. Please indicate what version the report concerns. Doing those things makes the maintainers' lives easier, for example by saving them from spending time trying to track down the cause of the bug using the wrong source package (think: automake vs automake1.11) or the wrong version of the source code (think: sid versus wheezy). [...] In file included from ../include/isolib.h:10:0, from isomarkboot.c:33: /usr/include/x86_64-linux-gnu/asm/stat.h:68:8: error: redefinition of ‘struct stat’ /usr/include/x86_64-linux-gnu/bits/stat.h:46:8: note: originally defined here Looks like the cause is that isolib.h #include-s asm/stat.h from linux-libc-dev which conflicts in namespace with sys/stat from glibc. So in the spirit of aboot (1.0~pre20040408-2) unstable; urgency=low * Include userspace headers from lib/isolib.c instead of kernel headers; this isn't kernel code anyway, and the kernel headers don't work right on i386 the way they're being used. does this patch help? By the way, do you know which package changed to introduce this build failure? (I would have guessed glibc, but I haven't found a relevant change.) Curious, Jonathan diff --git a/include/isolib.h b/include/isolib.h index 392327a..7353da1 100644 --- a/include/isolib.h +++ b/include/isolib.h @@ -1,13 +1,7 @@ #ifndef isolib_h #define isolib_h -#ifndef __KERNEL_STRICT_NAMES - /* ask kernel to be careful about name-space pollution: */ -# define __KERNEL_STRICT_NAMES -# define fd_set kernel_fd_set -#endif - -#include asm/stat.h +#include sys/stat.h extern int iso_read_super (void * data, int quiet); extern int iso_open (const char * filename); -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
tags 652598 +wheezy sid thanks 1. Please use Source: aboot, not Package: aboot. I'll start doing that if and when the official rc bugs list introduces sane handling of such bugs. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650999 Until then IMO having the bug actually visible to those looking to fix rc bugs is more important than some corner cases involving packages that do crazy things with source/binary package names. 2. Please indicate what version the report concerns. Yeah sorry about that, I usually include it. Still the version of this package in unstable hasn't changed in a VERY long time. What I did forget to do though is tag which realeases this bug applied to, doing so now. Looks like the cause is that isolib.h #include-s asm/stat.h from linux-libc-dev which conflicts in namespace with sys/stat from glibc. So in the spirit of aboot (1.0~pre20040408-2) unstable; urgency=low * Include userspace headers from lib/isolib.c instead of kernel headers; this isn't kernel code anyway, and the kernel headers don't work right on i386 the way they're being used. does this patch help? It makes the package build on amd64 sid. I have no way of testing if the resulting package works. By the way, do you know which package changed to introduce this build failure? (I would have guessed glibc, but I haven't found a relevant change.) hmm, asm/stat.h doesn't seem to have changed at all since squeeze and none of the changes in sys/stat.h or bits/stat,h look relavent on a quick glance I wonder if it's a change in default defines and their handling similar to the one that caused the struct user issues on arm*. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652598: aboot FTBFS in unstable
package: aboot severity: serious Aboot FTBFS with the following error make[1]: Entering directory `/aboot-1.0~pre20040408/tools' gcc -g -O2 -Wall -I. -I../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -c -o isomarkboot.o isomarkboot.c In file included from ../include/isolib.h:10:0, from isomarkboot.c:33: /usr/include/x86_64-linux-gnu/asm/stat.h:68:8: error: redefinition of ‘struct stat’ /usr/include/x86_64-linux-gnu/bits/stat.h:46:8: note: originally defined here /usr/include/x86_64-linux-gnu/asm/stat.h:82:16: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ token /usr/include/x86_64-linux-gnu/asm/stat.h:108:16: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ token make[1]: *** [isomarkboot.o] Error 1 make[1]: Leaving directory `/aboot-1.0~pre20040408/tools' make: *** [build-aboot-cross-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Build command 'cd aboot-1.0~pre20040408 dpkg-buildpackage -b -uc' failed. E: Child process failed root@debian:/# This was initially noticed in the buildd logs for armhf and s390x. Further I have reproduced it locally on amd64 sid and amd64 wheezy. The package builds successfully in amd64 squeeze. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
