Bug#565765: ruby1.9.1: FTBFS on sparc

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Lucas Nussbaum
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
| [hidden email]   http://www.lucas-nussbaum.net/ |
| jabber: [hidden email]             GPG: 1024D/023B3F4F |



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Jurij Smakov
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                                           [hidden email]
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Lucas Nussbaum
On 18/01/10 at 23:59 +0000, 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
| [hidden email]   http://www.lucas-nussbaum.net/ |
| jabber: [hidden email]             GPG: 1024D/023B3F4F |



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Jurij Smakov
On Tue, Jan 19, 2010 at 01:33:47PM +1300, Lucas Nussbaum wrote:

> On 18/01/10 at 23:59 +0000, 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                                           [hidden email]
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Josip Rodin-8
On Sat, Jan 23, 2010 at 11:13:02AM +0000, Jurij Smakov wrote:

> On Tue, Jan 19, 2010 at 01:33:47PM +1300, Lucas Nussbaum wrote:
> > On 18/01/10 at 23:59 +0000, 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,
<arch>@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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Jurij Smakov
On Sat, Jan 23, 2010 at 12:22:27PM +0100, Josip Rodin wrote:

> On Sat, Jan 23, 2010 at 11:13:02AM +0000, 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,
> <arch>@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                                           [hidden email]
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Lucas Nussbaum
On 23/01/10 at 12:04 +0000, 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 +0000, 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,
> > <arch>@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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Jurij Smakov
On Tue, Feb 02, 2010 at 08:17:51AM +0100, Lucas Nussbaum wrote:

> On 23/01/10 at 12:04 +0000, 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 +0000, 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,
> > > <arch>@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                                           [hidden email]
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Josip Rodin-8
On Sun, Feb 07, 2010 at 11:41:51AM +0000, 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,
> > > > <arch>@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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Marc Brockschmidt-4
In reply to this post by Jurij Smakov
Jurij Smakov <[hidden email]> writes:

> On Sat, Jan 23, 2010 at 12:22:27PM +0100, Josip Rodin wrote:
>> On Sat, Jan 23, 2010 at 11:13:02AM +0000, 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,
>> <arch>@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.

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Marc Brockschmidt-4
Marc Brockschmidt <[hidden email]> 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)

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Lucas Nussbaum
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
| [hidden email]   http://www.lucas-nussbaum.net/ |
| jabber: [hidden email]             GPG: 1024D/023B3F4F |



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Jurij Smakov
In reply to this post by Marc Brockschmidt-4
On Sun, Feb 21, 2010 at 05:09:58PM +0100, Marc Brockschmidt wrote:

> Marc Brockschmidt <[hidden email]> 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                                           [hidden email]
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Jurij Smakov
On Sun, Feb 21, 2010 at 10:01:10PM +0000, Jurij Smakov wrote:

> On Sun, Feb 21, 2010 at 05:09:58PM +0100, Marc Brockschmidt wrote:
> > Marc Brockschmidt <[hidden email]> 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      : 000000002cb41780
Cpu1ClkTck      : 000000002cb41780
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      : 000000001574ff27
Cpu2ClkTck      : 000000001574ff27
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                                           [hidden email]
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#565765: ruby1.9.1: FTBFS on sparc

Marc Brockschmidt-4
Jurij Smakov <[hidden email]> 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      : 000000001574ff27
> Cpu2ClkTck      : 000000001574ff27
> 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

attachment0 (202 bytes) Download Attachment