Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
On Mon, Oct 17, 2016 at 03:10:57AM +0100, Ben Hutchings wrote: > On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote: > [...] > > You should fix your package so that it works on the lowest supported > > hardware of each port. > > Right. > > > Autobuilding is only a small part of the problem, your package would > > also not run on many computers that Debian does support. > > > > That means nothing higher than SSE2 on amd64, and no SSE at all on i386. > [...] > > On i386 we cannot even assume MMX, as the earliest 686 models don't > have it. That is true, but what is supported and what is not is more complicated and depends on what exactly gcc/binutils define as "i686". The root of the problem is that the "earliest 686 model" is the Pentium Pro. The Pentium Pro does not support MMX, even though many 586 CPUs do. And much worse, what is supported by the Pentium Pro is not a subset of what is supported by all other 686 CPUs. MMX is supported by many 586 CPUs like the AMD K6 and the Pentium MMX, but it is not part of i686. Optional in 686 but emitted by the gcc i686 is CMOV, and that is the reason why even some desktop and laptop CPUs released as late as 2002 [1] will no longer be supported in stretch. Several 686 CPUs, including all VIA C3s (even the ones with CMOV) and all Geodes, do not support NOPL. Due to the OLPC laptop using Geode, binutils were upstream-patched in 2010 (sic) to no longer emit NOPL for i686. So what exactly gcc/binutils define as "i686" (and what will therefore be supported by the i386 port in stretch) does not only depend on what the earliest 686 CPUs supported back in 1995 - it does also depends on politics in 2010. > Ben. cu Adrian [1] Via C3 1.0T -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
On Sun, 2016-10-16 at 18:57 +0300, Adrian Bunk wrote: [...] > You should fix your package so that it works on the lowest supported > hardware of each port. Right. > Autobuilding is only a small part of the problem, your package would > also not run on many computers that Debian does support. > > That means nothing higher than SSE2 on amd64, and no SSE at all on i386. [...] On i386 we cannot even assume MMX, as the earliest 686 models don't have it. Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
Your upstream appear to be aware of this problem, but given that the packaged version is from after then, their first attempt evidently wasn't a full fix: https://github.com/torch/torch7/pull/755 https://sources.debian.net/src/lua-torch-torch7/0~20161002-geb397ad-1/lib/TH/generic/simd/simd.h/ (Also in that file, it looks like they support arm* but try to detect it with __NEON__ , which doesn't work on our buildds...)
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
On Sun, Oct 16, 2016 at 02:14:47PM +, lumin wrote: > Hi there, > > I encountered an unexpected FTBFS on amd64 that I can't repro.[1] > And I'd like to ask the list before fixing it by e.g. an binary > only upload. > > My package lua-torch-torch7/experimental fails[2] to build from > source because of an "illegal instruction" error at the debhelper > auto test stage. However from that buildlog I can't tell which > program to blame -- luajit or lua-torch-torch7. > > The upstream code indeed contains instruction specific stuff but > I have never encountered such failure on amd64 architecture. > Besides, I tested this package with debomatic-amd64[3] and the > result is quite healthy. > > So I have trouble allocating where the source of problem is. > > Cosmic ray? No, bug in your package: -DUSE_AVX -msse4.2 -DUSE_SSE4_2 -msse4.1 -DUSE_SSE4_1 -msse3 -DUSE_SSE3 -msse2 -DUSE_SSE2 > My questions: > > * should we suspect the health state of that amd64 buildd >machine «binet»? > * what should I do next? do a binary-only amd64 upload or >request (and how) for a rebuild against that package? >... You should fix your package so that it works on the lowest supported hardware of each port. Autobuilding is only a small part of the problem, your package would also not run on many computers that Debian does support. That means nothing higher than SSE2 on amd64, and no SSE at all on i386. Similar problems exist in your package on arm* regarding OMAP3/OMAP4/NEON. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
I can reproduce the FTBFS here. gdb says: (gdb) disas $rip,$rip+1 Dump of assembler code from 0x76948f7d to 0x76948f7e: => 0x76948f7d : pcmpeqq %xmm3,%xmm0 This is a SSE4.1 instruction, which my CPU doesn't support. BTW, please make your debian/rules honour DEB_BUILD_OPTIONS=nocheck. -- Jakub Wilk
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
On Sun, Oct 16, 2016 at 02:14:47PM +, lumin wrote: > My package lua-torch-torch7/experimental fails[2] to build from > source because of an "illegal instruction" error at the debhelper > auto test stage. However from that buildlog I can't tell which > program to blame -- luajit or lua-torch-torch7. > > The upstream code indeed contains instruction specific stuff but > I have never encountered such failure on amd64 architecture. > Besides, I tested this package with debomatic-amd64[3] and the > result is quite healthy. > > So I have trouble allocating where the source of problem is. > > Cosmic ray? > > My questions: > > * should we suspect the health state of that amd64 buildd >machine «binet»? I'd bet first on a real SIGILL. This can come from two sources: * using an instruction specific to a particular CPU, such as, say, ADDSUBPD on x86 with no SSE3, DMB on RasPi 1, MTVSRD on ppc64el when ran on qemu from jessie, etc * executing some junk memory Failing on the buildd but not on your home box suggests the former. If you don't have access to a diverse set of CPUs to test, I'd recommend using qemu _without_ kvm. You can choose a specific CPU to emulate via either QEMU_CPU=z80 or -cpu z80; "qemu-system-x86_64 -cpu help" to get the list of valid targets. Perversely, it's easier to test this from a non-x86 host as qemu-user+binfmt make running foreign binaries convenient -- if all what you have is a x86 box, I'd recommend qemu-system-x86_64 as using qemu-user for same ISA, while possible, is too tricky to get it right. qemu-system means you need to set up a whole virtual machine. > * what should I do next? do a binary-only amd64 upload or >request (and how) for a rebuild against that package? Please don't. It fails in the test suite, which means it'd break the same way on user systems that don't support that particular extension. > I encountered an unexpected FTBFS on amd64 that I can't repro.[1] > And I'd like to ask the list before fixing it by e.g. an binary > only upload. As the page at [1] is almost entirely red, I'd say you have a good deal more to investigate befor applying workarounds. Meow! > [1] > https://buildd.debian.org/status/package.php?p=lua-torch-torch7&suite=experimental > [2] > https://buildd.debian.org/status/fetch.php?pkg=lua-torch-torch7&arch=amd64&ver=0%7E20161013-g4f7843e-1&stamp=1476616893 > [3] > http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-torch7/0~20161013-g4f7843e-1/buildlog -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
On Sun, Oct 16, 2016 at 02:14:47PM +, lumin wrote: > I encountered an unexpected FTBFS on amd64 that I can't repro.[1] Your build log contains a) compile time checks for CPU features b) gcc options to enable such features in the generated code. This is not allowed, the package must support all machines supported by a given architecture. > And I'd like to ask the list before fixing it by e.g. an binary > only upload. > > My package lua-torch-torch7/experimental fails[2] to build from > source because of an "illegal instruction" error at the debhelper > auto test stage. However from that buildlog I can't tell which > program to blame -- luajit or lua-torch-torch7. > > The upstream code indeed contains instruction specific stuff but > I have never encountered such failure on amd64 architecture. Maybe the upstream checks are buggy and in this case they produced code that actually isn't supported in the host machine. > Besides, I tested this package with debomatic-amd64[3] and the > result is quite healthy. Does debomatic check for instructions not valid on all amd64 machines? > * should we suspect the health state of that amd64 buildd >machine «binet»? I don't think so. > * what should I do next? Start with fixing your package so that it doesn't compile with -msse4.2 etc. > do a binary-only amd64 upload Please don't. >request (and how) for a rebuild against that package? Please don't. -- WBR, wRAR signature.asc Description: PGP signature
