Processed: Re: Bug#649038: elfutils FTBFS on kfreebsd
Processing commands for cont...@bugs.debian.org: tags 649038 + patch Bug #649038 [elfutils] elfutils FTBFS on kfreebsd Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 649038: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649038 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
tags 649038 + patch
thanks
Hi,
After applying the fix for #615507, the remaining test failure I see is:
FAIL: run-native-test.sh
allregs: cannot attach to process: Function not implemented
which is an expected consequence of Bug #570805 (and is not necessarily
a bug, but a request for kFreeBSD linprocfs to behave more like Linux).
It will always happen when building with sbuild.
Therefore, please either skip or ignore this test failure on kfreebsd-*
(patch attached).
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- tests/run-native-test.sh.orig
+++ tests/run-native-test.sh
@@ -78,6 +78,12 @@
test $native -eq 0 || testrun $@ -p $native /dev/null
}
+# On the Debian buildds, GNU/kFreeBSD linprocfs /proc/$PID/maps does
+# not give absolute paths due to sbuild's bind mounts (bug #570805)
+# therefore the next two test programs are expected to fail with
+# cannot attach to process: Function not implemented.
+[ $(uname) = GNU/kFreeBSD ] exit 77
+
native_test ${abs_builddir}/allregs
native_test ${abs_builddir}/funcretval
Bug#649038: elfutils FTBFS on kfreebsd
On Mon, 2013-11-11 at 23:31 +0100, Robert Millan wrote: On 11/11/2013 15:32, Mark Wielaard wrote: On Sun, 2013-11-10 at 00:45 +0100, Robert Millan wrote: Nothing as far as ELF compliance is concerned. This tag is ment to be consumed by the kernel ELF loader only. For elfutils elflint it also matters for things like STB_GNU_UNIQUE and STT_GNU_IFUNC. Does ELFOSABI_FREEBSD indicate the binaray can or cannot contain such symbol types or bindings? No, it just gives information about the kernel-user ABI. AFAIK STB_GNU_UNIQUE and STT_GNU_IFUNC are userland facilities. Is this correct? It tells the shared library loader, ld.so, about the features of the ELF file, so it can resolve symbols with those bindings and/or types. elflint assumes those only occur with ELFOSABI_LINUX currently. Well I suppose you could extend this assumption to cover ELFOSABI_FREEBSD as well? Though presence of ELFOSABI_FREEBSD is not enough to determine that they are available. Indeed. Normally for the GNU toolchain, ELFOSABI_NONE describes generic ELF files, which don't use GNU extensions like STB_GNU_UNIQUE and STT_GNU_IFUNC. And ELFOSABI_LINUX describe ELF files which do use such GNU extensions. What is the convention on Debian/kfreebsd? /proc/PID/maps, /proc/PID/exe, /proc/PID/mem, Mostly OK I think. /proc/TID/status It seems we don't have this. At least not in 9.0. :-( This one is mostly just used as a workaround to see whether ptrace correctly propagates a SIGSTOP on attach/detach. It can probably be ignored if ptrace behaves. and /proc/PID/auvx Neither... That was a type BTW. Should have been auxv. It is sometimes possible to get at the AUXV information in a different way. If not available only some functionality is degraded. And /proc/kallsyms and /proc/modules are used to inspect kernel modules with libdwfl. Nope. For module listing we have kldstat() / kldfind() / kldnext(). See libdwfl/linux-proc-maps.c (backend for dwfl_linux_proc_report) and libdwfl/linux-kernel-modules.c (backend for dwfl_linux_kernel_report_kernel and dwfl_linux_kernel_report_modules). Someone might want to provide backends for kfreebsd if the corresponding libdwfl dwfl_linux_* functionality is wanted there. The kernel parts probably won't easily work, the user space parts probably will assuming the /proc interface is linprocfs style and sufficiently compatible. Is it possible to disable this functionality on kFreeBSD? A quick linprocfs solution seems like dead-end, and we really don't have the manpower to write new backends from scratch. Well, it doesn't do much harm. It just means you cannot easily introspect the kernel and kernel modules with elfutils/libdwfl. But that is not functionality many programs want/need anyway. If they do, then there are probably other issues they have to deal with that make them depend on the linux kernel anyway. Cheers, Mark -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On 13/11/2013 10:48, Mark Wielaard wrote: And ELFOSABI_LINUX describe ELF files which do use such GNU extensions. What is the convention on Debian/kfreebsd? Well, we used to provide these features before ELFOSABI_LINUX became a requirement for having them. Now we can't provide them anymore (sigh). Fortunately this doesn't (yet) break any essential functionality. This one is mostly just used as a workaround to see whether ptrace correctly propagates a SIGSTOP on attach/detach. It can probably be ignored if ptrace behaves. [...] That was a type BTW. Should have been auxv. It is sometimes possible to get at the AUXV information in a different way. If not available only some functionality is degraded. Thanks for the details. Unortunately manpower is scarce, but it may be useful for looking into this someday. Well, it doesn't do much harm. It just means you cannot easily introspect the kernel and kernel modules with elfutils/libdwfl. But that is not functionality many programs want/need anyway. If they do, then there are probably other issues they have to deal with that make them depend on the linux kernel anyway. I recommend that route then ;-) Thank you -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On Sun, 2013-11-10 at 00:45 +0100, Robert Millan wrote: ELFOSABI_FREEBSD indicates this binary has been built to run on kFreeBSD and uses its kernel ABI. If a binary is set to ELFOSABI_LINUX, then the kernel will enable Linux emulation mode, i.e. Linux syscall interface. Aha. Interesting. Just curious. On Debain GNU/FreeBSD wouldn't the emulation mode be more natural? Kernel modules are also built as ELF files, but AFAIK their e_ident is not checked for. - If it is the correct OS ABI then what would an elflint program need to know about it to make sure all its requirements are met? Nothing as far as ELF compliance is concerned. This tag is ment to be consumed by the kernel ELF loader only. For elfutils elflint it also matters for things like STB_GNU_UNIQUE and STT_GNU_IFUNC. Does ELFOSABI_FREEBSD indicate the binaray can or cannot contain such symbol types or bindings? elflint assumes those only occur with ELFOSABI_LINUX currently. - The other failures look like issues with the /proc interface on the install. Does the /proc interface follow the Linux kernel /proc interface that some of the tests rely on? Yes. But as there's no standard covering Linux-style /proc, it can't ever be 100% complete. FreeBSD developers provide an emulated linprocfs for compatibility purposes and try to keep up, but depending on what you do it might not work. Also, this is only provided on GNU/kFreeBSD. FreeBSD systems either use the native FreeBSD-style /proc or none at all. If you want to support FreeBSD as well, it's better if you use sysctls or whatever you need for what you're testing. This is mainly for the libdwl dwfl_linux_* group of functions. /proc/PID/maps, /proc/PID/exe, /proc/PID/mem, /proc/TID/status and /proc/PID/auvx are used to inspect user space binaries with libdwfl. And /proc/kallsyms and /proc/modules are used to inspect kernel modules with libdwfl. See libdwfl/linux-proc-maps.c (backend for dwfl_linux_proc_report) and libdwfl/linux-kernel-modules.c (backend for dwfl_linux_kernel_report_kernel and dwfl_linux_kernel_report_modules). Someone might want to provide backends for kfreebsd if the corresponding libdwfl dwfl_linux_* functionality is wanted there. The kernel parts probably won't easily work, the user space parts probably will assuming the /proc interface is linprocfs style and sufficiently compatible. Cheers, Mark -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On Mon, Nov 11, 2013 at 03:32:09PM +0100, Mark Wielaard wrote: - The other failures look like issues with the /proc interface on the install. Does the /proc interface follow the Linux kernel /proc interface that some of the tests rely on? Yes. But as there's no standard covering Linux-style /proc, it can't ever be 100% complete. FreeBSD developers provide an emulated linprocfs for compatibility purposes and try to keep up, but depending on what you do it might not work. Also, this is only provided on GNU/kFreeBSD. FreeBSD systems either use the native FreeBSD-style /proc or none at all. If you want to support FreeBSD as well, it's better if you use sysctls or whatever you need for what you're testing. This is mainly for the libdwl dwfl_linux_* group of functions. /proc/PID/maps, /proc/PID/exe, /proc/PID/mem, /proc/TID/status and /proc/PID/auvx are used to inspect user space binaries with libdwfl. And /proc/kallsyms and /proc/modules are used to inspect kernel modules with libdwfl. See libdwfl/linux-proc-maps.c (backend for dwfl_linux_proc_report) and libdwfl/linux-kernel-modules.c (backend for dwfl_linux_kernel_report_kernel and dwfl_linux_kernel_report_modules). Someone might want to provide backends for kfreebsd if the corresponding libdwfl dwfl_linux_* functionality is wanted there. The kernel parts probably won't easily work, the user space parts probably will assuming the /proc interface is linprocfs style and sufficiently compatible. My understanding is that the part from /proc that we need for user space works, except in a chroot where the path that is mentioned is not relative to the chroot. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On 11/11/2013 15:32, Mark Wielaard wrote: On Sun, 2013-11-10 at 00:45 +0100, Robert Millan wrote: ELFOSABI_FREEBSD indicates this binary has been built to run on kFreeBSD and uses its kernel ABI. If a binary is set to ELFOSABI_LINUX, then the kernel will enable Linux emulation mode, i.e. Linux syscall interface. Aha. Interesting. Just curious. On Debain GNU/FreeBSD wouldn't the emulation mode be more natural? Not really... It wouldn't solve anything and instead raise wrong expectations about the APIs we provide. Then we'd struggle trying to live up to those expectations. Most of Debian userland is not biased towards Linux syscall interface. It generally just interacts with glibc. Nothing as far as ELF compliance is concerned. This tag is ment to be consumed by the kernel ELF loader only. For elfutils elflint it also matters for things like STB_GNU_UNIQUE and STT_GNU_IFUNC. Does ELFOSABI_FREEBSD indicate the binaray can or cannot contain such symbol types or bindings? No, it just gives information about the kernel-user ABI. AFAIK STB_GNU_UNIQUE and STT_GNU_IFUNC are userland facilities. Is this correct? elflint assumes those only occur with ELFOSABI_LINUX currently. Well I suppose you could extend this assumption to cover ELFOSABI_FREEBSD as well? Though presence of ELFOSABI_FREEBSD is not enough to determine that they are available. /proc/PID/maps, /proc/PID/exe, /proc/PID/mem, Mostly OK I think. /proc/TID/status It seems we don't have this. At least not in 9.0. :-( and /proc/PID/auvx Neither... And /proc/kallsyms and /proc/modules are used to inspect kernel modules with libdwfl. Nope. For module listing we have kldstat() / kldfind() / kldnext(). See libdwfl/linux-proc-maps.c (backend for dwfl_linux_proc_report) and libdwfl/linux-kernel-modules.c (backend for dwfl_linux_kernel_report_kernel and dwfl_linux_kernel_report_modules). Someone might want to provide backends for kfreebsd if the corresponding libdwfl dwfl_linux_* functionality is wanted there. The kernel parts probably won't easily work, the user space parts probably will assuming the /proc interface is linprocfs style and sufficiently compatible. Is it possible to disable this functionality on kFreeBSD? A quick linprocfs solution seems like dead-end, and we really don't have the manpower to write new backends from scratch. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Please consider outputting the contents of tests/test-suite.log so that it appears in the build log. Here are examples of how some other packages have done this: http://codesearch.debian.net/search?q=cat.*test.*suite\.log The new failure is related to a libc0.1 header: FAIL: run-disasm-x86.sh === In file included from command-line:0:0: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h ^ compilation terminated. I don't seem to be able to reproduce the segfault I saw once in dwfl-bug-fd-leak. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Control: tags -1 + patch On 20:07, Steven Chamberlain wrote: FAIL: run-disasm-x86.sh === In file included from command-line:0:0: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h ^ compilation terminated. I found out what this is. Some tests use -m32 which requires gcc-multilib, and the control file doesn't properly express this for kfreebsd-amd64. Please apply this patch: --- debian/control.orig 2013-11-04 19:56:45.0 + +++ debian/control 2013-11-10 22:07:29.690884199 + @@ -1,7 +1,7 @@ Source: elfutils Priority: optional Maintainer: Kurt Roeckx k...@roeckx.be -Build-Depends: debhelper (= 8.1.3), autotools-dev, autoconf, automake, bzip2, zlib1g-dev, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, dpkg-dev (= 1.16.1~), gcc-multilib [amd64] +Build-Depends: debhelper (= 8.1.3), autotools-dev, autoconf, automake, bzip2, zlib1g-dev, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, dpkg-dev (= 1.16.1~), gcc-multilib [any-amd64] Build-Conflicts: autoconf2.13, automake1.4 Standards-Version: 3.8.4 Section: libs If the build still fails after this (due to schroot issue), a DD will be able to provide a binNMU. Thanks, Regards -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#649038: elfutils FTBFS on kfreebsd
Processing control commands: tags -1 + patch Bug #649038 [elfutils] elfutils FTBFS on kfreebsd Added tag(s) patch. -- 649038: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649038 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On Sun, Nov 10, 2013 at 10:12:38PM +, Steven Chamberlain wrote: Control: tags -1 + patch On 20:07, Steven Chamberlain wrote: FAIL: run-disasm-x86.sh === In file included from command-line:0:0: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h ^ compilation terminated. I found out what this is. Some tests use -m32 which requires gcc-multilib, and the control file doesn't properly express this for kfreebsd-amd64. Please apply this patch: I should have known to use any-amd64. Anyway, with that patch applied I end up with: FAIL: run-native-test.sh /home/kroeckx/elfutils-0.157/tests/allregs: dwfl_module_register_names: Callback returned failure FAIL: dwfl-bug-fd-leak == ./dwfl-bug-fd-leak: dwfl_module_getelf: Callback returned failure So it's still going to fail on the buildds. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On 10/11/13 22:59, Kurt Roeckx wrote: Anyway, with that patch applied I end up with: FAIL: run-native-test.sh /home/kroeckx/elfutils-0.157/tests/allregs: dwfl_module_register_names: Callback returned failure FAIL: dwfl-bug-fd-leak == ./dwfl-bug-fd-leak: dwfl_module_getelf: Callback returned failure Was that with sbuild or similar chroot environment? These look like the original issue from bug #649038. So it's still going to fail on the buildds. We could work around that by a porter building it outside of sbuild and doing a binNMU. It's not a permanent solution, but it would at least allow elfutils' other RC bug fixes to migrate meanwhile. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Steven Chamberlain ste...@pyro.eu.org (2013-11-10): We could work around that by a porter building it outside of sbuild and doing a binNMU. It's not a permanent solution, but it would at least allow elfutils' other RC bug fixes to migrate meanwhile. As a mere spectator, it looks like porter uploads happened a few times already, so one might want to get the issue fixed once and for all. Mraw, KiBi. signature.asc Description: Digital signature
Bug#649038: elfutils FTBFS on kfreebsd
On Mon, Nov 11, 2013 at 12:30:16AM +0100, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2013-11-10): We could work around that by a porter building it outside of sbuild and doing a binNMU. It's not a permanent solution, but it would at least allow elfutils' other RC bug fixes to migrate meanwhile. As a mere spectator, it looks like porter uploads happened a few times already, so one might want to get the issue fixed once and for all. I've done the uploads myself in the past. But I'll do a source upload with the Build-Depends fixed first. Kurt PS: It's not a binNMU, that would be increasing the version number. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On 10/11/13 22:59, Kurt Roeckx wrote: FAIL: run-native-test.sh FAIL: dwfl-bug-fd-leak On 10/11/13 23:17, Steven Chamberlain wrote: Was that with sbuild or similar chroot environment? These look like the original issue from bug #649038. Could I please check this; you saw those failures because of using sbuild or similar? I just want to make sure the success I had is going to be repeatable, and not something unique to my build environment. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On Sun, Nov 10, 2013 at 11:50:06PM +, Steven Chamberlain wrote: On 10/11/13 22:59, Kurt Roeckx wrote: FAIL: run-native-test.sh FAIL: dwfl-bug-fd-leak On 10/11/13 23:17, Steven Chamberlain wrote: Was that with sbuild or similar chroot environment? These look like the original issue from bug #649038. Could I please check this; you saw those failures because of using sbuild or similar? That's in a schroot on falla.debian.org. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Hi, debian-bsd@ was not put in Cc: for this bug, so the recent discussion was probably not seen yet by people who can answer: On Tue, 22 Oct 2013 16:02:18 +0200, Mark Wielaard wrote: Two questions: - Would it help to just disable the testsuite on the kfreebsd arch? Clearly the package itself build fine. But some tests are failing. Although it would be nice to have 100% PASS as on GNU/Linux, the failures don't look too terrible for a new architecture that has not been tested upstream. - Could someone describe the real issue on kfreebsd? Looking at the test failures it looks like there are two issues: - elflint doesn't know about the OS ABI FreeBSD. - Is this correct in the ELF files? I don't know whether kfreebsd is supposed to follow the user space ELF OS ABI or the kernel one. - If it is the correct OS ABI then what would an elflint program need to know about it to make sure all its requirements are met? - The other failures look like issues with the /proc interface on the install. Does the /proc interface follow the Linux kernel /proc interface that some of the tests rely on? Or is the issue simple that the buildd uses a chroot with /proc not mounted? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Currently I see some different testsuite failures than before. This was in a sid chroot on kfreebsd-amd64 (not using bind mounts) : run-native-test.sh passes for me. FAIL: run-disasm-x86.sh that failure is new. ../config/test-driver: line 95: 44771 Segmentation fault $@ $log_file 21 FAIL: dwfl-bug-fd-leak this one is in the same place as the original Bug#649038, but it is segfaulting now whereas it failed 'cleanly' with error message before. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On 10/11/2013 00:18, Steven Chamberlain wrote: - elflint doesn't know about the OS ABI FreeBSD. - Is this correct in the ELF files? Yes. I don't know whether kfreebsd is supposed to follow the user space ELF OS ABI or the kernel one. I'm not sure what you mean by this. ELFOSABI_FREEBSD indicates this binary has been built to run on kFreeBSD and uses its kernel ABI. If a binary is set to ELFOSABI_LINUX, then the kernel will enable Linux emulation mode, i.e. Linux syscall interface. Kernel modules are also built as ELF files, but AFAIK their e_ident is not checked for. - If it is the correct OS ABI then what would an elflint program need to know about it to make sure all its requirements are met? Nothing as far as ELF compliance is concerned. This tag is ment to be consumed by the kernel ELF loader only. - The other failures look like issues with the /proc interface on the install. Does the /proc interface follow the Linux kernel /proc interface that some of the tests rely on? Yes. But as there's no standard covering Linux-style /proc, it can't ever be 100% complete. FreeBSD developers provide an emulated linprocfs for compatibility purposes and try to keep up, but depending on what you do it might not work. Also, this is only provided on GNU/kFreeBSD. FreeBSD systems either use the native FreeBSD-style /proc or none at all. If you want to support FreeBSD as well, it's better if you use sysctls or whatever you need for what you're testing. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#649038: elfutils FTBFS on kfreebsd
Processing control commands: severity -1 serious Bug #649038 [elfutils] elfutils FTBFS on kfreebsd Severity set to 'serious' from 'normal' -- 649038: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649038 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Two questions: - Would it help to just disable the testsuite on the kfreebsd arch? Clearly the package itself build fine. But some tests are failing. Although it would be nice to have 100% PASS as on GNU/Linux, the failures don't look too terrible for a new architecture that has not been tested upstream. - Could someone describe the real issue on kfreebsd? Looking at the test failures it looks like there are two issues: - elflint doesn't know about the OS ABI FreeBSD. - Is this correct in the ELF files? I don't know whether kfreebsd is supposed to follow the user space ELF OS ABI or the kernel one. - If it is the correct OS ABI then what would an elflint program need to know about it to make sure all its requirements are met? - The other failures look like issues with the /proc interface on the install. Does the /proc interface follow the Linux kernel /proc interface that some of the tests rely on? Or is the issue simple that the buildd uses a chroot with /proc not mounted? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On Tue, Oct 22, 2013 at 04:02:18PM +0200, Mark Wielaard wrote: Two questions: - Would it help to just disable the testsuite on the kfreebsd arch? Clearly the package itself build fine. But some tests are failing. Although it would be nice to have 100% PASS as on GNU/Linux, the failures don't look too terrible for a new architecture that has not been tested upstream. - Could someone describe the real issue on kfreebsd? Looking at the test failures it looks like there are two issues: - elflint doesn't know about the OS ABI FreeBSD. - Is this correct in the ELF files? I don't know whether kfreebsd is supposed to follow the user space ELF OS ABI or the kernel one. - If it is the correct OS ABI then what would an elflint program need to know about it to make sure all its requirements are met? As far as I know, that error is just ignored. - The other failures look like issues with the /proc interface on the install. Does the /proc interface follow the Linux kernel /proc interface that some of the tests rely on? Or is the issue simple that the buildd uses a chroot with /proc not mounted? The problem here is that the /proc interface inside a chroot gives a the filename as seen from outside the chroot and so we can't find that file in the chroot. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
On Tue, Oct 22, 2013 at 03:21:49PM +0200, Niels Thykier wrote: Control: severity -1 serious On Fri, Sep 20, 2013 at 08:42:21PM +0200, Michael Biebl wrote: That doesn't make it this build failure non RC though. Failure to build on a buildd is not an RC bug. It builds perfectly fine on kfreebsd, just not in a chroot. Kurt I am sorry, but I believe the release team disagree with your assertion here in general. Should you believe elfutils to be an exceptional case, then I am willing to hear your arguments (please CC debian-release@l.d.o). However, in that case, I will at the very least insist that you will ensure that elfutils is built on all architectures on every upload /in a timely fashion/ - for reference, I consider 20 days to be unacceptable. The current practise just results in RC bug fixes being stuck in sid (e.g. #701271)... I didn't do a manual upload on kfreebsd yet because there is also an issue on ia64 for which I'm still waiting for feedback from the porters. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#649038: elfutils FTBFS on kfreebsd
Processing commands for cont...@bugs.debian.org: severity 649038 normal Bug #649038 [elfutils] elfutils FTBFS on kfreebsd Severity set to 'normal' from 'serious' block 649038 by 570805 Bug #649038 [elfutils] elfutils FTBFS on kfreebsd 649038 was blocked by: 570805 615507 649038 was not blocking any bugs. Ignoring request to alter blocking bugs of bug #649038 to the same blocks previously set thanks Stopping processing here. Please contact me if you need assistance. -- 649038: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649038 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
severity 649038 normal block 649038 by 570805 thanks On Fri, Sep 20, 2013 at 08:14:00PM +0200, Michael Biebl wrote: severity 649038 serious thanks Hi Kurt, since kfreebsd is a release architecture, this makes this bug RC, as it blocks testing migration. If libelf is not supposed to be built on kfreebsd, please request it's removal from testing and make the package linux-any. This is NOT a bug in elfutils, it never has been. This has always been a kernel bug that nobody seems to be willing to fix. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
Am 20.09.2013 20:40, schrieb Kurt Roeckx: severity 649038 normal block 649038 by 570805 thanks On Fri, Sep 20, 2013 at 08:14:00PM +0200, Michael Biebl wrote: severity 649038 serious thanks Hi Kurt, since kfreebsd is a release architecture, this makes this bug RC, as it blocks testing migration. If libelf is not supposed to be built on kfreebsd, please request it's removal from testing and make the package linux-any. This is NOT a bug in elfutils, it never has been. This has always been a kernel bug that nobody seems to be willing to fix. That doesn't make it this build failure non RC though. As said, if the package is not supposed to be built on kfreebsd (atm), please request its removal from kfreebsd-* until this has been fixed. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#649038: elfutils FTBFS on kfreebsd
On Thu, Nov 17, 2011 at 02:33:41AM +, peter green wrote: package: elfutils version: 0.152-1 severity: serious From the debian buildd logs for 0.152-1+b1 (copy/paste taken from the kfreebsd-i386 one but kfreebsd-amd64 looks similar) This is #570805. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649038: elfutils FTBFS on kfreebsd
package: elfutils version: 0.152-1 severity: serious From the debian buildd logs for 0.152-1+b1 (copy/paste taken from the kfreebsd-i386 one but kfreebsd-amd64 looks similar) make[2]: Entering directory `/build/buildd-elfutils_0.152-1+b1-kfreebsd-i386-3v8mAz/elfutils-0.152/tests' /usr/bin/make check-TESTS make[3]: Entering directory `/build/buildd-elfutils_0.152-1+b1-kfreebsd-i386-3v8mAz/elfutils-0.152/tests' Extracting symbols... done PASS: run-arextract.sh PASS: run-arsymtest.sh PASS: newfile PASS: test-nlist PASS: update1 PASS: update2 PASS: update3 PASS: update4 PASS: run-show-die-info.sh PASS: run-get-files.sh PASS: run-get-lines.sh PASS: run-get-pubnames.sh PASS: run-get-aranges.sh PASS: run-allfcts.sh PASS: run-show-abbrev.sh PASS: run-line2addr.sh PASS: hash PASS: newscn PASS: run-strip-test.sh PASS: run-strip-test2.sh PASS: run-strip-test3.sh PASS: run-strip-test4.sh PASS: run-strip-test5.sh PASS: run-strip-test6.sh PASS: run-strip-test7.sh PASS: run-strip-test8.sh PASS: run-unstrip-test.sh PASS: run-unstrip-test2.sh PASS: run-ecp-test.sh PASS: run-ecp-test2.sh PASS: run-elflint-test.sh unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/addr2line unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/elfcmp unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/elflint unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/findtextrel unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/ld unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/nm unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/objdump unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/readelf unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/size unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../src/strip unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../libelf/libelf.so unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../libdw/libdw.so unsupported OS ABI e_ident[7] == 'FreeBSD' *** failure in ../libasm/libasm.so SKIP: run-elflint-self.sh PASS: run-ranlib-test.sh PASS: run-ranlib-test2.sh PASS: run-ranlib-test3.sh PASS: run-ranlib-test4.sh PASS: run-addrscopes.sh PASS: run-strings-test.sh PASS: run-funcscopes.sh PASS: run-find-prologues.sh PASS: run-allregs.sh PASS: run-readelf-test1.sh PASS: run-readelf-test2.sh PASS: run-readelf-test3.sh PASS: run-readelf-test4.sh ./allregs: dwfl_module_register_names: No such file or directory FAIL: run-native-test.sh PASS: run-bug1-test.sh PASS: dwfl-bug-addr-overflow PASS: run-addrname-test.sh ./dwfl-bug-fd-leak: dwfl_module_getelf: No such file or directory FAIL: dwfl-bug-fd-leak PASS: dwfl-bug-report PASS: run-dwfl-bug-offline-rel.sh PASS: run-dwfl-addr-sect.sh PASS: run-disasm-x86.sh PASS: run-disasm-x86-64.sh PASS: run-early-offscn.sh PASS: run-dwarf-getmacros.sh PASS: run-test-flag-nobits.sh PASS: run-prelink-addr-test.sh PASS: msg_tst PASS: sha1-tst PASS: asm-tst1 PASS: asm-tst2 PASS: asm-tst3 PASS: asm-tst4 PASS: asm-tst5 PASS: asm-tst6 PASS: asm-tst7 PASS: asm-tst8 PASS: asm-tst9 = 2 of 69 tests failed (1 test was not run) Please report to http://bugzilla.redhat.com/bugzilla/ = -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
