Bug#565765: ruby1.9.1: FTBFS on sparc
found 565765 1.9.1.376-1 thanks On 07/03/10 at 09:46 +0100, Marc Brockschmidt wrote: > Lucas Nussbaum writes: > > Something else that puzzles me is that ruby1.9.1 1.9.1.376-1 (the > > version currently in testing) built fine on sparc back in August, when > > it was uploaded. See > > https://buildd.debian.org/fetch.cgi?pkg=ruby1.9.1;ver=1.9.1.376-1;arch=sparc;stamp=126038086 > > > > Marc, could you try to build 1.9.1.376-1 on lebrun and/or spontini? > > Done on lebrun, this time with a build log (attached). This shows the same > behaviour I saw when building .378-1 manually, it just hangs in the test > suite. OK, marking as found in 1.9.1.376-1. Also, as discussed on IRC, I uploaded a porter upload built on sperger (where the package built fine). That should allow the package to migrate to testing. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
Lucas Nussbaum writes: > Something else that puzzles me is that ruby1.9.1 1.9.1.376-1 (the > version currently in testing) built fine on sparc back in August, when > it was uploaded. See > https://buildd.debian.org/fetch.cgi?pkg=ruby1.9.1;ver=1.9.1.376-1;arch=sparc;stamp=126038086 > > Marc, could you try to build 1.9.1.376-1 on lebrun and/or spontini? Done on lebrun, this time with a build log (attached). This shows the same behaviour I saw when building .378-1 manually, it just hangs in the test suite. Marc -- Fachbegriffe der Informatik - Einfach erklärt 123: Sprache Ein Dialekt, der eine Akademie und eine Armee besitzt. (Harvard-Prof. Edward Keenan) ruby1.9.1_1.9.1.376-1.log.bz2 Description: Binary data pgpVuNF4ireOx.pgp Description: PGP signature
Bug#565765: ruby1.9.1: FTBFS on sparc
On 25/02/10 at 11:29 +0100, Josip Rodin wrote: > On Mon, Feb 22, 2010 at 05:30:29PM +0100, Marc Brockschmidt wrote: > > > Any chance of upgrading one of the buildds to 2.6.32 to see if it > > > helps? > > > > DSA told me that they do not want to run any non-standard (aka, > > non-Debian stable) kernel on these machines, not even for short > > tests. I'm not sure that's the best way to handle this, but I can't > > change it. > > lebrun and schroeder had built many packages in the past with non-standard > kernels, indeed testing on them helped improve the standard upstream kernel, > and obviously we eventually do have to upgrade the buildds so it's a good > policy to find out if that's possible early enough. The one major data point > that you may be missing here is that a few months ago I got stuck trying to > to upgrade from the 2.6.28 to the 2.6.29 kernel built by new gcc on > schroeder. The same happened with .30 and .31; didn't test .32 yet but > there's no real indication that it would work. We've asked Dave Miller for > help, and he's promised to look into it. These heisenbuggy Ruby failures > sound like another thing you'd want him to look into. Something else that puzzles me is that ruby1.9.1 1.9.1.376-1 (the version currently in testing) built fine on sparc back in August, when it was uploaded. See https://buildd.debian.org/fetch.cgi?pkg=ruby1.9.1;ver=1.9.1.376-1;arch=sparc;stamp=126038086 Marc, could you try to build 1.9.1.376-1 on lebrun and/or spontini? This could allow to pin down the problem to a toolchain regression (or change, at least). Thanks -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Mon, Feb 22, 2010 at 05:30:29PM +0100, Marc Brockschmidt wrote: > > Any chance of upgrading one of the buildds to 2.6.32 to see if it > > helps? > > DSA told me that they do not want to run any non-standard (aka, > non-Debian stable) kernel on these machines, not even for short > tests. I'm not sure that's the best way to handle this, but I can't > change it. lebrun and schroeder had built many packages in the past with non-standard kernels, indeed testing on them helped improve the standard upstream kernel, and obviously we eventually do have to upgrade the buildds so it's a good policy to find out if that's possible early enough. The one major data point that you may be missing here is that a few months ago I got stuck trying to to upgrade from the 2.6.28 to the 2.6.29 kernel built by new gcc on schroeder. The same happened with .30 and .31; didn't test .32 yet but there's no real indication that it would work. We've asked Dave Miller for help, and he's promised to look into it. These heisenbuggy Ruby failures sound like another thing you'd want him to look into. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
Jurij Smakov writes: > On Wed, Feb 24, 2010 at 05:06:04PM +0100, Lucas Nussbaum wrote: >> I think that the two remaining options are: >> (1) remove the ruby1.9.1 binaries for sparc, and have ruby1.9.1 added to >> P-a-s on sparc. >> (2) accept that ruby1.9.1 can only be built on porter boxes, not on the >> buildds. > Most important question is whether it can be built on whatever > box/environment used by DSA for security uploads. Is there a chance > they would be willing to run a test build for us? Errrm, the security buildds for sparc are called spontini and lebrun... Marc -- Fachbegriffe der Informatik - Einfach erklärt 118: Chipkarten auslesen Mit rauchender Salpetersäure rumblubbern und schief anschielen. (Matthias Brüstle) pgpc5snEUHztt.pgp Description: PGP signature
Bug#565765: ruby1.9.1: FTBFS on sparc
On Wed, Feb 24, 2010 at 05:06:04PM +0100, Lucas Nussbaum wrote: > On 22/02/10 at 17:30 +0100, Marc Brockschmidt wrote: > > Jurij Smakov writes: > > > On spontini: > > > > > > Linux spontini 2.6.26-2-sparc64-smp #1 SMP Thu Feb 11 03:39:06 UTC 2010 > > > sparc64 GNU/Linux > > > > > > cat /proc/cpuinfo > > > cpu : TI UltraSparc II (BlackBird) > > > fpu : UltraSparc II integrated FPU > > > prom: OBP 3.11.26 1998/04/15 14:52 > > > type: sun4u > > > ncpus probed: 2 > > > ncpus active: 2 > > > D$ parity tl1 : 0 > > > I$ parity tl1 : 0 > > > Cpu0ClkTck : 1574ff27 > > > Cpu2ClkTck : 1574ff27 > > > MMU Type: Spitfire > > > State: > > > CPU0: online > > > CPU2: online > > > > > > Any chance of upgrading one of the buildds to 2.6.32 to see if it > > > helps? > > > > DSA told me that they do not want to run any non-standard (aka, > > non-Debian stable) kernel on these machines, not even for short > > tests. I'm not sure that's the best way to handle this, but I can't > > change it. > > I gave a try on smetana, but could not reproduce the same failure. > > I don't see any way forward, since the failure is only reproducible on > the buildds. Also, analyzing that failure might require quite a lot of > sparc expertise, which I don't have. > > I think that the two remaining options are: > (1) remove the ruby1.9.1 binaries for sparc, and have ruby1.9.1 added to > P-a-s on sparc. > (2) accept that ruby1.9.1 can only be built on porter boxes, not on the > buildds. Most important question is whether it can be built on whatever box/environment used by DSA for security uploads. Is there a chance they would be willing to run a test build for us? > Ruby is clearly in a bad state on SPARC, and upstream doesn't want to > support it (http://redmine.ruby-lang.org/issues/show/1172), so (1) is > probably the more reasonable option. It it's not actively supported upstream on sparc, then I don't think it's feasible for us to do it, given dwindling developer interest in the sparc port. What major fallout would removal of ruby (along with all its reverse-deps) cause? Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On 22/02/10 at 17:30 +0100, Marc Brockschmidt wrote: > Jurij Smakov writes: > > On spontini: > > > > Linux spontini 2.6.26-2-sparc64-smp #1 SMP Thu Feb 11 03:39:06 UTC 2010 > > sparc64 GNU/Linux > > > > cat /proc/cpuinfo > > cpu : TI UltraSparc II (BlackBird) > > fpu : UltraSparc II integrated FPU > > prom: OBP 3.11.26 1998/04/15 14:52 > > type: sun4u > > ncpus probed: 2 > > ncpus active: 2 > > D$ parity tl1 : 0 > > I$ parity tl1 : 0 > > Cpu0ClkTck : 1574ff27 > > Cpu2ClkTck : 1574ff27 > > MMU Type: Spitfire > > State: > > CPU0: online > > CPU2: online > > > > Any chance of upgrading one of the buildds to 2.6.32 to see if it > > helps? > > DSA told me that they do not want to run any non-standard (aka, > non-Debian stable) kernel on these machines, not even for short > tests. I'm not sure that's the best way to handle this, but I can't > change it. I gave a try on smetana, but could not reproduce the same failure. I don't see any way forward, since the failure is only reproducible on the buildds. Also, analyzing that failure might require quite a lot of sparc expertise, which I don't have. I think that the two remaining options are: (1) remove the ruby1.9.1 binaries for sparc, and have ruby1.9.1 added to P-a-s on sparc. (2) accept that ruby1.9.1 can only be built on porter boxes, not on the buildds. Ruby is clearly in a bad state on SPARC, and upstream doesn't want to support it (http://redmine.ruby-lang.org/issues/show/1172), so (1) is probably the more reasonable option. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
Jurij Smakov writes: > On spontini: > > Linux spontini 2.6.26-2-sparc64-smp #1 SMP Thu Feb 11 03:39:06 UTC 2010 > sparc64 GNU/Linux > > cat /proc/cpuinfo > cpu : TI UltraSparc II (BlackBird) > fpu : UltraSparc II integrated FPU > prom: OBP 3.11.26 1998/04/15 14:52 > type: sun4u > ncpus probed: 2 > ncpus active: 2 > D$ parity tl1 : 0 > I$ parity tl1 : 0 > Cpu0ClkTck : 1574ff27 > Cpu2ClkTck : 1574ff27 > MMU Type: Spitfire > State: > CPU0: online > CPU2: online > > Any chance of upgrading one of the buildds to 2.6.32 to see if it > helps? DSA told me that they do not want to run any non-standard (aka, non-Debian stable) kernel on these machines, not even for short tests. I'm not sure that's the best way to handle this, but I can't change it. Marc -- BOFH #28: CPU radiator broken pgpdY6qaFOGCD.pgp Description: PGP signature
Bug#565765: ruby1.9.1: FTBFS on sparc
On Sun, Feb 21, 2010 at 10:01:10PM +, Jurij Smakov wrote: > On Sun, Feb 21, 2010 at 05:09:58PM +0100, Marc Brockschmidt wrote: > > Marc Brockschmidt writes: > > [ruby1.9.1 woes] > > > Sorry for the delay. I've now done a test-build on lebrun, which got > > > further than our last build-log. I didn't finish the build, though, as > > > CPU cycles on sparc are currently needed for the build queue. > > > > > > I've given back ruby1.9.1 now, let's see if this also works under > > > sbuild. > > > > It doesn't. I couldn't believe it, so I did yet another manual build, > > which now hangs in the test suite: > > TestProc#test_splat_without_respond_to: 0.00 s: . > > TestProc#test_to_proc: 0.00 s: . > > TestProc#test_to_s: 0.00 s: . > > TestProcess#test_abort: > > > > The compile problem just went away. The build environments are > > identical: Both the failing buildd-triggered process and my manual > > rebuild used snapshots of the same lv source. Any ideas? > > Did you save the log of your manual build, by any chance? To make things even more complicated, it builds without problems (no crashes, no hangs during tests) on my SunBlade 1000, in a sid chroot created today. Two obvious difference are the kernel version and CPU type, on my machine: Linux debian 2.6.32-trunk-sparc64-smp #1 SMP Mon Jan 11 02:14:07 UTC 2010 sparc64 GNU/Linux cat /proc/cpuinfo cpu : TI UltraSparc III (Cheetah) fpu : UltraSparc III integrated FPU pmu : ultra3 prom: OBP 4.16.4 2004/12/18 05:18 type: sun4u ncpus probed: 2 ncpus active: 2 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 2cb41780 Cpu1ClkTck : 2cb41780 MMU Type: Cheetah State: CPU0: online CPU1: online On spontini: Linux spontini 2.6.26-2-sparc64-smp #1 SMP Thu Feb 11 03:39:06 UTC 2010 sparc64 GNU/Linux cat /proc/cpuinfo cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU prom: OBP 3.11.26 1998/04/15 14:52 type: sun4u ncpus probed: 2 ncpus active: 2 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 1574ff27 Cpu2ClkTck : 1574ff27 MMU Type: Spitfire State: CPU0: online CPU2: online Any chance of upgrading one of the buildds to 2.6.32 to see if it helps? Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Sun, Feb 21, 2010 at 05:09:58PM +0100, Marc Brockschmidt wrote: > Marc Brockschmidt writes: > [ruby1.9.1 woes] > > Sorry for the delay. I've now done a test-build on lebrun, which got > > further than our last build-log. I didn't finish the build, though, as > > CPU cycles on sparc are currently needed for the build queue. > > > > I've given back ruby1.9.1 now, let's see if this also works under > > sbuild. > > It doesn't. I couldn't believe it, so I did yet another manual build, > which now hangs in the test suite: > TestProc#test_splat_without_respond_to: 0.00 s: . > TestProc#test_to_proc: 0.00 s: . > TestProc#test_to_s: 0.00 s: . > TestProcess#test_abort: > > The compile problem just went away. The build environments are > identical: Both the failing buildd-triggered process and my manual > rebuild used snapshots of the same lv source. Any ideas? Did you save the log of your manual build, by any chance? -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
Hi, Outcome of the discussion on debian-qa@ about this issue: - ruby1.9.1 still fails on both lebrun and spontini - needs to be tried on smetana (porter box with the higher chances to reproduce the failure) Any help is welcomed... -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
Marc Brockschmidt writes: [ruby1.9.1 woes] > Sorry for the delay. I've now done a test-build on lebrun, which got > further than our last build-log. I didn't finish the build, though, as > CPU cycles on sparc are currently needed for the build queue. > > I've given back ruby1.9.1 now, let's see if this also works under > sbuild. It doesn't. I couldn't believe it, so I did yet another manual build, which now hangs in the test suite: TestProc#test_splat_without_respond_to: 0.00 s: . TestProc#test_to_proc: 0.00 s: . TestProc#test_to_s: 0.00 s: . TestProcess#test_abort: The compile problem just went away. The build environments are identical: Both the failing buildd-triggered process and my manual rebuild used snapshots of the same lv source. Any ideas? Marc -- Fachbegriffe der Informatik - Einfach erklärt 129: Knigge Kofler des erfolgreichen Kommunizierens (Heinrich Konrad Bartels) pgplpJUd53Vbs.pgp Description: PGP signature
Bug#565765: ruby1.9.1: FTBFS on sparc
Jurij Smakov writes: > On Sat, Jan 23, 2010 at 12:22:27PM +0100, Josip Rodin wrote: >> On Sat, Jan 23, 2010 at 11:13:02AM +, Jurij Smakov wrote: >> > Josip, are you running lebrun these days? Can you try reproducing the >> > failure there and getting more information about it (logs are not very >> > informative)? I'm a bit reluctant to do a porter upload knowing that >> > the package cannot be built on buildds for some reason. >> The buildd is always run by the people on the handy architecture alias, >> @buildd.debian.org, I'm Cc:ing them - currently aba and zobel. >> I'm the local admin and if they're busy I can give it a shot, but you'd >> have to help me out regarding the proper procedure in the chroots >> (we don't want to taint anything). > I think that just trying to build it in a fresh sid pbuilder chroot on > this machine (not under buildd) would be useful. If it's indeed a > kernel issue, then we should still see the FTBFS. Sorry for the delay. I've now done a test-build on lebrun, which got further than our last build-log. I didn't finish the build, though, as CPU cycles on sparc are currently needed for the build queue. I've given back ruby1.9.1 now, let's see if this also works under sbuild. Marc -- BOFH #349: Stray Alpha Particles from memory packaging caused Hard Memory Error on Server. pgp2E4WxvfHiy.pgp Description: PGP signature
Bug#565765: ruby1.9.1: FTBFS on sparc
On Sun, Feb 07, 2010 at 11:41:51AM +, Jurij Smakov wrote: > > > > > Josip, are you running lebrun these days? Can you try reproducing the > > > > > failure there and getting more information about it (logs are not > > > > > very > > > > > informative)? I'm a bit reluctant to do a porter upload knowing that > > > > > the package cannot be built on buildds for some reason. > > > > > > > > The buildd is always run by the people on the handy architecture alias, > > > > @buildd.debian.org, I'm Cc:ing them - currently aba and zobel. > > > > I'm the local admin and if they're busy I can give it a shot, but you'd > > > > have to help me out regarding the proper procedure in the chroots > > > > (we don't want to taint anything). > > > > > > I think that just trying to build it in a fresh sid pbuilder chroot on > > > this machine (not under buildd) would be useful. If it's indeed a > > > kernel issue, then we should still see the FTBFS. > > > > Hi, > > > > Any news on that? > > I haven't seen any replies. Josip, did you have a chance to try and > reproduce the failure using pbuilder? No, I was waiting for the buildd maintainers to get back to us. Apparently that's too hopeful :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Tue, Feb 02, 2010 at 08:17:51AM +0100, Lucas Nussbaum wrote: > On 23/01/10 at 12:04 +, Jurij Smakov wrote: > > On Sat, Jan 23, 2010 at 12:22:27PM +0100, Josip Rodin wrote: > > > On Sat, Jan 23, 2010 at 11:13:02AM +, Jurij Smakov wrote: > > > > Josip, are you running lebrun these days? Can you try reproducing the > > > > failure there and getting more information about it (logs are not very > > > > informative)? I'm a bit reluctant to do a porter upload knowing that > > > > the package cannot be built on buildds for some reason. > > > > > > The buildd is always run by the people on the handy architecture alias, > > > @buildd.debian.org, I'm Cc:ing them - currently aba and zobel. > > > I'm the local admin and if they're busy I can give it a shot, but you'd > > > have to help me out regarding the proper procedure in the chroots > > > (we don't want to taint anything). > > > > I think that just trying to build it in a fresh sid pbuilder chroot on > > this machine (not under buildd) would be useful. If it's indeed a > > kernel issue, then we should still see the FTBFS. > > Hi, > > Any news on that? I haven't seen any replies. Josip, did you have a chance to try and reproduce the failure using pbuilder? Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On 23/01/10 at 12:04 +, Jurij Smakov wrote: > On Sat, Jan 23, 2010 at 12:22:27PM +0100, Josip Rodin wrote: > > On Sat, Jan 23, 2010 at 11:13:02AM +, Jurij Smakov wrote: > > > Josip, are you running lebrun these days? Can you try reproducing the > > > failure there and getting more information about it (logs are not very > > > informative)? I'm a bit reluctant to do a porter upload knowing that > > > the package cannot be built on buildds for some reason. > > > > The buildd is always run by the people on the handy architecture alias, > > @buildd.debian.org, I'm Cc:ing them - currently aba and zobel. > > I'm the local admin and if they're busy I can give it a shot, but you'd > > have to help me out regarding the proper procedure in the chroots > > (we don't want to taint anything). > > I think that just trying to build it in a fresh sid pbuilder chroot on > this machine (not under buildd) would be useful. If it's indeed a > kernel issue, then we should still see the FTBFS. Hi, Any news on that? Thanks - Lucas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Sat, Jan 23, 2010 at 12:22:27PM +0100, Josip Rodin wrote: > On Sat, Jan 23, 2010 at 11:13:02AM +, Jurij Smakov wrote: > > Josip, are you running lebrun these days? Can you try reproducing the > > failure there and getting more information about it (logs are not very > > informative)? I'm a bit reluctant to do a porter upload knowing that > > the package cannot be built on buildds for some reason. > > The buildd is always run by the people on the handy architecture alias, > @buildd.debian.org, I'm Cc:ing them - currently aba and zobel. > I'm the local admin and if they're busy I can give it a shot, but you'd > have to help me out regarding the proper procedure in the chroots > (we don't want to taint anything). I think that just trying to build it in a fresh sid pbuilder chroot on this machine (not under buildd) would be useful. If it's indeed a kernel issue, then we should still see the FTBFS. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Sat, Jan 23, 2010 at 11:13:02AM +, Jurij Smakov wrote: > On Tue, Jan 19, 2010 at 01:33:47PM +1300, Lucas Nussbaum wrote: > > On 18/01/10 at 23:59 +, Jurij Smakov wrote: > > > On Tue, Jan 19, 2010 at 06:58:18AM +1300, Lucas Nussbaum wrote: > > > > Package: src:ruby1.9.1 > > > > Version: 1.9.1.378-1 > > > > Severity: serious > > > > > > > > Hi, > > > > > > > > ruby1.9.1 FTBFS on sparc with the following error: > > > > > make[2]: Leaving directory > > > > > `/build/buildd-ruby1.9.1_1.9.1.378-1-sparc-KMvrBv/ruby1.9.1-1.9.1.378' > > > > > compiling bigdecimal > > > > > Aborted > > > > > make[1]: *** [mkmain.sh] Error 134 > > > > > make: *** [debian/stamp-makefile-build] Error 2 > > > > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > > > > > > > Also, we have #545345 (ruby1.9.1: test suite fails on sparc). For which > > > > upstream said (in the redmine bug) that Sparc is no supported. > > > > > > > > Sparc porters, could you help us investigate this? > > > > > > > > This is extremely worrying, because we still need to transition all ruby > > > > 1.9.0 packages to 1.9.1 (so we can drop 1.9.0) before the squeeze > > > > release. Not releasing ruby1.9.1 on sparc isn't really an option because > > > > of all the reverse-dependencies. > > > > > > I can't reproduce neither FTBFS nor test failure on my sparc box > > > running up-to-date sid, tried it a couple of times today. I can make > > > the build log and binary packages available, if needed. > > Josip, are you running lebrun these days? Can you try reproducing the > failure there and getting more information about it (logs are not very > informative)? I'm a bit reluctant to do a porter upload knowing that > the package cannot be built on buildds for some reason. The buildd is always run by the people on the handy architecture alias, @buildd.debian.org, I'm Cc:ing them - currently aba and zobel. I'm the local admin and if they're busy I can give it a shot, but you'd have to help me out regarding the proper procedure in the chroots (we don't want to taint anything). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Tue, Jan 19, 2010 at 01:33:47PM +1300, Lucas Nussbaum wrote: > On 18/01/10 at 23:59 +, Jurij Smakov wrote: > > On Tue, Jan 19, 2010 at 06:58:18AM +1300, Lucas Nussbaum wrote: > > > Package: src:ruby1.9.1 > > > Version: 1.9.1.378-1 > > > Severity: serious > > > > > > Hi, > > > > > > ruby1.9.1 FTBFS on sparc with the following error: > > > > make[2]: Leaving directory > > > > `/build/buildd-ruby1.9.1_1.9.1.378-1-sparc-KMvrBv/ruby1.9.1-1.9.1.378' > > > > compiling bigdecimal > > > > Aborted > > > > make[1]: *** [mkmain.sh] Error 134 > > > > make: *** [debian/stamp-makefile-build] Error 2 > > > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > > > > > Also, we have #545345 (ruby1.9.1: test suite fails on sparc). For which > > > upstream said (in the redmine bug) that Sparc is no supported. > > > > > > Sparc porters, could you help us investigate this? > > > > > > This is extremely worrying, because we still need to transition all ruby > > > 1.9.0 packages to 1.9.1 (so we can drop 1.9.0) before the squeeze > > > release. Not releasing ruby1.9.1 on sparc isn't really an option because > > > of all the reverse-dependencies. > > > > I can't reproduce neither FTBFS nor test failure on my sparc box > > running up-to-date sid, tried it a couple of times today. I can make > > the build log and binary packages available, if needed. Josip, are you running lebrun these days? Can you try reproducing the failure there and getting more information about it (logs are not very informative)? I'm a bit reluctant to do a porter upload knowing that the package cannot be built on buildds for some reason. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On 18/01/10 at 23:59 +, Jurij Smakov wrote: > On Tue, Jan 19, 2010 at 06:58:18AM +1300, Lucas Nussbaum wrote: > > Package: src:ruby1.9.1 > > Version: 1.9.1.378-1 > > Severity: serious > > > > Hi, > > > > ruby1.9.1 FTBFS on sparc with the following error: > > > make[2]: Leaving directory > > > `/build/buildd-ruby1.9.1_1.9.1.378-1-sparc-KMvrBv/ruby1.9.1-1.9.1.378' > > > compiling bigdecimal > > > Aborted > > > make[1]: *** [mkmain.sh] Error 134 > > > make: *** [debian/stamp-makefile-build] Error 2 > > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > > > Also, we have #545345 (ruby1.9.1: test suite fails on sparc). For which > > upstream said (in the redmine bug) that Sparc is no supported. > > > > Sparc porters, could you help us investigate this? > > > > This is extremely worrying, because we still need to transition all ruby > > 1.9.0 packages to 1.9.1 (so we can drop 1.9.0) before the squeeze > > release. Not releasing ruby1.9.1 on sparc isn't really an option because > > of all the reverse-dependencies. > > I can't reproduce neither FTBFS nor test failure on my sparc box > running up-to-date sid, tried it a couple of times today. I can make > the build log and binary packages available, if needed. Hi Jurij, Couldn't we just blame the buildds, then, and proceed with a porter upload? Which kernel are you running? lebrun is running 2.6.26-2-sparc64-smp. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
On Tue, Jan 19, 2010 at 06:58:18AM +1300, Lucas Nussbaum wrote: > Package: src:ruby1.9.1 > Version: 1.9.1.378-1 > Severity: serious > > Hi, > > ruby1.9.1 FTBFS on sparc with the following error: > > make[2]: Leaving directory > > `/build/buildd-ruby1.9.1_1.9.1.378-1-sparc-KMvrBv/ruby1.9.1-1.9.1.378' > > compiling bigdecimal > > Aborted > > make[1]: *** [mkmain.sh] Error 134 > > make: *** [debian/stamp-makefile-build] Error 2 > > dpkg-buildpackage: error: debian/rules build gave error exit status 2 > > Also, we have #545345 (ruby1.9.1: test suite fails on sparc). For which > upstream said (in the redmine bug) that Sparc is no supported. > > Sparc porters, could you help us investigate this? > > This is extremely worrying, because we still need to transition all ruby > 1.9.0 packages to 1.9.1 (so we can drop 1.9.0) before the squeeze > release. Not releasing ruby1.9.1 on sparc isn't really an option because > of all the reverse-dependencies. I can't reproduce neither FTBFS nor test failure on my sparc box running up-to-date sid, tried it a couple of times today. I can make the build log and binary packages available, if needed. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565765: ruby1.9.1: FTBFS on sparc
Package: src:ruby1.9.1 Version: 1.9.1.378-1 Severity: serious Hi, ruby1.9.1 FTBFS on sparc with the following error: > make[2]: Leaving directory > `/build/buildd-ruby1.9.1_1.9.1.378-1-sparc-KMvrBv/ruby1.9.1-1.9.1.378' > compiling bigdecimal > Aborted > make[1]: *** [mkmain.sh] Error 134 > make: *** [debian/stamp-makefile-build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 Also, we have #545345 (ruby1.9.1: test suite fails on sparc). For which upstream said (in the redmine bug) that Sparc is no supported. Sparc porters, could you help us investigate this? This is extremely worrying, because we still need to transition all ruby 1.9.0 packages to 1.9.1 (so we can drop 1.9.0) before the squeeze release. Not releasing ruby1.9.1 on sparc isn't really an option because of all the reverse-dependencies. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
