debian unusable on niagara

debian unusable on niagara

[David Miller]

I really didn't expect this, and then I saw other users complaining
too.

1) Please remove the PROM console driver from the kernel config, it
   does nothing but get in the way.  This will fix the "console slow
   on bootup" problem everyone reports on niagara boxes.

   Putting "console=ttyHV0" on the kernel command line works as a
   workaround but it still clears the screen once using the PROM
   console and even that takes nearly a minute (!).

2) Please fix the GETTY setup so that it properly uses ttyS0 on
   Niagara.  Otherwise people have no console and can't use their
   machine at all after installation.

   Ubuntu does this by making sure there is an /etc/event.d/ttyS0
   file with a line saying "exec /sbin/getty -L ttyS0 9600 vt102"
   or similar.

Between the ultra45 unbootable problem and these, I'm really losing
faith... :-/

Re: debian unusable on niagara

[David Miller]

From: David Markey <dmarkey@comp.dit.ie>
Date: Thu, 23 Apr 2009 15:36:44 +0100

> I'm running debian5 on a t1000, once i got it going its 100% now.

Yes, but you must have hit the console problem.

Right?

Re: debian unusable on niagara

[David Markey]

David Miller wrote:
> From: David Markey <dmarkey@comp.dit.ie>
> Date: Thu, 23 Apr 2009 15:36:44 +0100
> 
>> I'm running debian5 on a t1000, once i got it going its 100% now.
> 
> Yes, but you must have hit the console problem.
> 
> Right?


Yep. I figured it out though.

And yes, i agree more work has to be put in to make debian work properly
on current SPARC servers, T series especially.

Re: debian unusable on niagara

[Andrew Robert Nicols]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Thu, Apr 23, 2009 at 07:44:21AM -0700, David Miller wrote:
> From: David Markey <dmarkey@comp.dit.ie>
> Date: Thu, 23 Apr 2009 15:36:44 +0100
> 
> > I'm running debian5 on a t1000, once i got it going its 100% now.
> 
> Yes, but you must have hit the console problem.
> 
> Right?

I hit it with Lenny on a T1000. Suspect it's the rootskel problem but
haven't looked into it properly yet. I did an install over ssh and was able
to log in via ssh to fix the issue on first boot. Alternatively, I could
have executed a shell on the box at the end of hte install and fixed it
there.

Keep meaning to look into it but time isn't with me this week.

Andrew

-- 
Systems Developer

e: andrew.nicols@luns.net.uk
im: a.nicols@jabber.lancs.ac.uk
t: +44 (0)1524 5 10147

Lancaster University Network Services is a limited company registered in
England and Wales. Registered number: 4311892. Registered office:
University House, Lancaster University, Lancaster, LA1 4YW

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: debian unusable on niagara

[Jurij Smakov]

Hi,

On Thu, Apr 23, 2009 at 07:09:43AM -0700, David Miller wrote:
> 
> I really didn't expect this, and then I saw other users complaining
> too.

Please note that I do not actively work on sparc port anymore. I'm still
poking it a bit whenever I have time, but lately it's been pretty
irregular.
 
> 1) Please remove the PROM console driver from the kernel config, it
>    does nothing but get in the way.  This will fix the "console slow
>    on bootup" problem everyone reports on niagara boxes.
> 
>    Putting "console=ttyHV0" on the kernel command line works as a
>    workaround but it still clears the screen once using the PROM
>    console and even that takes nearly a minute (!).

I'll file a bug against kernel for that. Do you know if removing that
driver could have any unintended consequences for non-Niagara machines?

> 2) Please fix the GETTY setup so that it properly uses ttyS0 on
>    Niagara.  Otherwise people have no console and can't use their
>    machine at all after installation.
> 
>    Ubuntu does this by making sure there is an /etc/event.d/ttyS0
>    file with a line saying "exec /sbin/getty -L ttyS0 9600 vt102"
>    or similar.

Which installer version did you test that with? I've tested the lenny
installer and it worked correctly with serial console (I remember we
pushed some fixes for it pretty late in lenny release cycle).

> Between the ultra45 unbootable problem and these, I'm really losing
> faith... :-/

I believe we fixed it in Lenny r1 release, it would be great to it if
you could upgrade to it and confirm it (or install from scratch using
5.0.1 media from http://www.debian.org/releases/lenny/debian-installer).

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Mon, 27 Apr 2009 23:29:47 +0100

> On Thu, Apr 23, 2009 at 07:09:43AM -0700, David Miller wrote:
>> 
>> 1) Please remove the PROM console driver from the kernel config, it
>>    does nothing but get in the way.  This will fix the "console slow
>>    on bootup" problem everyone reports on niagara boxes.
>> 
>>    Putting "console=ttyHV0" on the kernel command line works as a
>>    workaround but it still clears the screen once using the PROM
>>    console and even that takes nearly a minute (!).
> 
> I'll file a bug against kernel for that. Do you know if removing that
> driver could have any unintended consequences for non-Niagara machines?

No.

>> 2) Please fix the GETTY setup so that it properly uses ttyS0 on
>>    Niagara.  Otherwise people have no console and can't use their
>>    machine at all after installation.
>> 
>>    Ubuntu does this by making sure there is an /etc/event.d/ttyS0
>>    file with a line saying "exec /sbin/getty -L ttyS0 9600 vt102"
>>    or similar.
> 
> Which installer version did you test that with?

I downloaded the tftpboot image provided from the Download
section of the debian.org web site for Sparc.

> I've tested the lenny installer and it worked correctly with serial
> console (I remember we pushed some fixes for it pretty late in lenny
> release cycle).

It's not exactly a serial console, even though the niagara console is
implemented using a driver that sits on top of the serial core layer.

If you test on a non-niagara system with serial console, it's not the
same test.  Not even remotely.  The device name is different, it shows
up differently in sysfs, etc.

> I believe we fixed it in Lenny r1 release, it would be great to it if
> you could upgrade to it and confirm it (or install from scratch using
> 5.0.1 media from http://www.debian.org/releases/lenny/debian-installer).

I'll give it a try and report back.

Re: debian unusable on niagara

[Jurij Smakov]

On Mon, Apr 27, 2009 at 06:41:52PM -0700, David Miller wrote:
> I downloaded the tftpboot image provided from the Download
> section of the debian.org web site for Sparc.

Can you provide the exact URL? My worry is that you might have downloaded
one of the daily-built images, which may be in various states of brokenness.
The Lenny netboot image is at

http://ftp.nl.debian.org/debian/dists/lenny/main/installer-sparc/current/images/netboot/boot.img

The bug I've mentioned, and which should be resolved in this image, is 
http://bugs.debian.org/504721. I see, however, that we never got a
confirmation from the original reporter that the fix worked on his machine
(it did work for mine).
 
> > I've tested the lenny installer and it worked correctly with serial
> > console (I remember we pushed some fixes for it pretty late in lenny
> > release cycle).
> 
> It's not exactly a serial console, even though the niagara console is
> implemented using a driver that sits on top of the serial core layer.
> 
> If you test on a non-niagara system with serial console, it's not the
> same test.  Not even remotely.  The device name is different, it shows
> up differently in sysfs, etc.
> 
> > I believe we fixed it in Lenny r1 release, it would be great to it if
> > you could upgrade to it and confirm it (or install from scratch using
> > 5.0.1 media from http://www.debian.org/releases/lenny/debian-installer).
> 
> I'll give it a try and report back.

Thanks.
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Tue, 28 Apr 2009 08:54:07 +0100

> http://ftp.nl.debian.org/debian/dists/lenny/main/installer-sparc/current/images/netboot/boot.img

Yep, that's exactly the image I used.

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Tue, 28 Apr 2009 08:54:07 +0100

> The bug I've mentioned, and which should be resolved in this image, is 
> http://bugs.debian.org/504721. I see, however, that we never got a
> confirmation from the original reporter that the fix worked on his machine
> (it did work for mine).

So what is your system exactly?  Is it a niagara box?

Re: debian unusable on niagara

[Jurij Smakov]

On Tue, Apr 28, 2009 at 12:57:12AM -0700, David Miller wrote:
> From: Jurij Smakov <jurij@wooyd.org>
> Date: Tue, 28 Apr 2009 08:54:07 +0100
> 
> > The bug I've mentioned, and which should be resolved in this image, is 
> > http://bugs.debian.org/504721. I see, however, that we never got a
> > confirmation from the original reporter that the fix worked on his machine
> > (it did work for mine).
> 
> So what is your system exactly?  Is it a niagara box?

It's a SunBlade 1000, but the symptoms described in this bug (reporter's box
was Niagara) were the same on it, so I assumed that fixing it for my box fix
it for Niagara as well (which is not necessarily true).
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Tue, 28 Apr 2009 09:09:34 +0100

> On Tue, Apr 28, 2009 at 12:57:12AM -0700, David Miller wrote:
>> From: Jurij Smakov <jurij@wooyd.org>
>> Date: Tue, 28 Apr 2009 08:54:07 +0100
>> 
>> > The bug I've mentioned, and which should be resolved in this image, is 
>> > http://bugs.debian.org/504721. I see, however, that we never got a
>> > confirmation from the original reporter that the fix worked on his machine
>> > (it did work for mine).
>> 
>> So what is your system exactly?  Is it a niagara box?
> 
> It's a SunBlade 1000, but the symptoms described in this bug (reporter's box
> was Niagara) were the same on it, so I assumed that fixing it for my box fix
> it for Niagara as well (which is not necessarily true).

It won't, most likely because the device name is totally different
for Niagara's console device vs. the serial console device used
on all other types of boxes.

Re: debian unusable on niagara

[Jurij Smakov]

On Tue, Apr 28, 2009 at 01:44:57AM -0700, David Miller wrote:
> It won't, most likely because the device name is totally different
> for Niagara's console device vs. the serial console device used
> on all other types of boxes.

Installer's rootskel uses the attached code to detect whether console
is serial or not (by checking whether ioctl(0, TIOCGSERIAL, buffer)
succeeds). Can you compile and run it on Niagara's serial console, to
see whether this mechanism detects it correctly?

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: debian unusable on niagara

[Jurij Smakov]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

+ attachment for real.

On Sat, May 02, 2009 at 11:25:37AM +0100, Jurij Smakov wrote:
> On Tue, Apr 28, 2009 at 01:44:57AM -0700, David Miller wrote:
> > It won't, most likely because the device name is totally different
> > for Niagara's console device vs. the serial console device used
> > on all other types of boxes.
> 
> Installer's rootskel uses the attached code to detect whether console
> is serial or not (by checking whether ioctl(0, TIOCGSERIAL, buffer)
> succeeds). Can you compile and run it on Niagara's serial console, to
> see whether this mechanism detects it correctly?
> 
> Best regards,
> -- 
> Jurij Smakov                                           jurij@wooyd.org
> Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

[-- Attachment #2: console-type.c --]
[-- Type: text/x-csrc, Size: 830 bytes --]

/*
 * Licensed under GPLv2
 *
 * Adapted for Debian Installer by Frans Pop <fjp.debian.org> from
 * cttyhack from busybox 1.11, which is
 *
 * Copyright (c) 2007 Denys Vlasenko <vda.linux@googlemail.com>
 */

#include <sys/ioctl.h>
#include <stdio.h>

enum { VT_GETSTATE = 0x5603 }; /* get global vt state info */

int main(int argc, char ** argv)
{
	/*
	 * Use an (oversized) dummy buffer as we're not interested in
	 * returned values.
	 * TIOCGSERIAL normally uses serial_struct from <linux/serial.h>
	 * VT_GETSTATE normally uses vt_stat from <linux/vt.h>
	 */
	char buffer[1024]; /* filled by ioctl */

	if (ioctl(0, TIOCGSERIAL, buffer) == 0) {
		/* this is a serial console */
		printf("serial\n");
	} else if (ioctl(0, VT_GETSTATE, buffer) == 0) {
		/* this is linux virtual tty */
		printf("virtual\n");
	}

	return 0;
}

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Sat, 2 May 2009 11:28:05 +0100

> + attachment for real.

It prints "serial"

I suspect that PROM console device driver is getting in the way.

Please take that out of the kernel configuration ASAP.

Re: debian unusable on niagara

[Jurij Smakov]

On Sat, May 02, 2009 at 09:53:50AM -0700, David Miller wrote:
> From: Jurij Smakov <jurij@wooyd.org>
> Date: Sat, 2 May 2009 11:28:05 +0100
> 
> > + attachment for real.
> 
> It prints "serial"
> 
> I suspect that PROM console device driver is getting in the way.
> 
> Please take that out of the kernel configuration ASAP.

There is a bug filed for that (http://bugs.debian.org/525958), however
I don't know what effect removal of this driver will have on machines
which do not have another console (like no framebuffer device). I would
like to ask people to test this change before uploading it into the
archive. Unfortunately, the current kernel in instable is completely
broken, so the first step is to get it to boot again, kernel team should
be doing a new upload within the next few days.

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Sat, 2 May 2009 18:04:28 +0100

> There is a bug filed for that (http://bugs.debian.org/525958), however
> I don't know what effect removal of this driver will have on machines
> which do not have another console (like no framebuffer device). I would
> like to ask people to test this change before uploading it into the
> archive.

Would you stop with this?

We have a driver for every conceivable console device on sparc,
framebuffer, serial, or otherwise.

We know this will fix real bugs and increase the bootup time on
niagara by a factor of 10.

I can't believe discussion is even necessary for this. :-/

Re: debian unusable on niagara

[Jurij Smakov]

On Sat, May 02, 2009 at 01:14:49PM -0700, David Miller wrote:
> From: Jurij Smakov <jurij@wooyd.org>
> Date: Sat, 2 May 2009 18:04:28 +0100
> 
> > There is a bug filed for that (http://bugs.debian.org/525958), however
> > I don't know what effect removal of this driver will have on machines
> > which do not have another console (like no framebuffer device). I would
> > like to ask people to test this change before uploading it into the
> > archive.
> 
> Would you stop with this?
> 
> We have a driver for every conceivable console device on sparc,
> framebuffer, serial, or otherwise.
> 
> We know this will fix real bugs and increase the bootup time on
> niagara by a factor of 10.
> 
> I can't believe discussion is even necessary for this. :-/

I'm doing an honest effort here to make sure that we don't upload
another broken kernel (and I have my reasons, because, for example,
we had XVR-500 and XVR-2500 drivers disabled in Debian kernels until
recently). As I'm doing it in my free time, I don't see why I should
tolerate your tantrums, which seem to happen every time you report
problems with Debian. Sorry for being a bit harsh, but from now on
I'm going to discard any email from you which does not exclusively
contain constructive comments, patches, or other information which
helps to advance our common goal.

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: debian unusable on niagara

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Sat, 2 May 2009 21:56:24 +0100

> As I'm doing it in my free time, I don't see why I should tolerate
> your tantrums, which seem to happen every time you report problems
> with Debian.

I do this in my spare time too.

And it's not every time I report problems with Debian, it's every
time I try to just use Debian :-/

Here's my track record of installing Debian 5:

1) ultra45, kernel doesn't boot

2) niagara, no console

So you tell me what kind of impression I'm supposed to have?

> Sorry for being a bit harsh, but from now on I'm going to discard
> any email from you which does not exclusively contain constructive
> comments, patches, or other information which helps to advance our
> common goal.

You might want to think twice about alienating yourself from the one
person in the entire world who can actually fix any sparc kernel
problems that you want taken care of.

Re: debian unusable on niagara

[Josip Rodin]

Hi,

Now that the discussion has deteriorated to this silly and pointless level,
I don't want to quote any particular part.

Jurij, please don't ignore Dave just because he vented frustration in bug
reports. People do that, such is life. Dave, don't expect Jurij to blindly
trust your judgement. People don't do that, such is life.

The core pattern of these bug reports has been the simple fact that the
Debian kernel differs from the upstream kernel (first the X.org-related
patch, then the default kconfig). There doesn't appear to be any technical
reason for them to diverge (so much to cause bugs), so it looks like we
simply need to communicate more efficiently. That isn't going to happen if
we allow the communication to be either inexistant or based on accusations
and threats. So I suggest that we get some simple diffing done between the
two pieces of software as a basis for documenting any differences, or making
modifications so that they converge.

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Sun, 3 May 2009 00:54:15 +0200

> So I suggest that we get some simple diffing done between the two
> pieces of software as a basis for documenting any differences, or
> making modifications so that they converge.

If I had just once seen a "Dave, can you test this image out to make
sure this Niagara bug is fixed?", I would have been happy with any
result whatsoever.

But because that did not happen, I'm understandably irked that things
are broken the way that they are.

I have tons of machines to test on, and the knowledge to fix just
about anything, I just have to be asked.

Re: debian unusable on niagara

[Josip Rodin]

On Sat, May 02, 2009 at 05:06:04PM -0700, David Miller wrote:
> From: Josip Rodin <joy@entuzijast.net>
> Date: Sun, 3 May 2009 00:54:15 +0200
> 
> > So I suggest that we get some simple diffing done between the two
> > pieces of software as a basis for documenting any differences, or
> > making modifications so that they converge.
> 
> If I had just once seen a "Dave, can you test this image out to make
> sure this Niagara bug is fixed?", I would have been happy with any
> result whatsoever.
> 
> But because that did not happen, I'm understandably irked that things
> are broken the way that they are.
> 
> I have tons of machines to test on, and the knowledge to fix just
> about anything, I just have to be asked.

OK, but each distribution lives in a little (or large) ecosystem of their
own, and even in the case of Debian where the system is open for everyone to
enter, the actual act of entering the system is necessary in order for
anyone to participate.

In this case, where you want to be informed when there's new stuff in
Debian's sparc kernel, you might want to subscribe yourself to the
debian-sparc list[1] which is the only Debian sparc port mailing list and
the place where e.g. calls for testing new kernel images are sent to,
and maybe to the linux-2.6 package tracking system[2] where you can read
Debian's Linux kernel package changelogs, which will have references to
any sparc patches.

These are fairly general forums, so you will probably want to filter them
locally and scan the contents for sparc kernel-specific information.
(I guess you have the same problem with LKML already...)

[1] http://lists.debian.org/debian-sparc/
[2] http://packages.qa.debian.org/l/linux-2.6.html

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[Sam Ravnborg]

On Sun, May 03, 2009 at 01:41:40PM +0200, Josip Rodin wrote:
> On Sat, May 02, 2009 at 05:06:04PM -0700, David Miller wrote:
> > From: Josip Rodin <joy@entuzijast.net>
> > Date: Sun, 3 May 2009 00:54:15 +0200
> > 
> > > So I suggest that we get some simple diffing done between the two
> > > pieces of software as a basis for documenting any differences, or
> > > making modifications so that they converge.
> > 
> > If I had just once seen a "Dave, can you test this image out to make
> > sure this Niagara bug is fixed?", I would have been happy with any
> > result whatsoever.
> > 
> > But because that did not happen, I'm understandably irked that things
> > are broken the way that they are.
> > 
> > I have tons of machines to test on, and the knowledge to fix just
> > about anything, I just have to be asked.
> 
> OK, but each distribution lives in a little (or large) ecosystem of their
> own, and even in the case of Debian where the system is open for everyone to
> enter, the actual act of entering the system is necessary in order for
> anyone to participate.
> 
> In this case, where you want to be informed when there's new stuff in
> Debian's sparc kernel, you might want to subscribe yourself to the
> debian-sparc list[1] which is the only Debian sparc port mailing list and
> the place where e.g. calls for testing new kernel images are sent to,
> and maybe to the linux-2.6 package tracking system[2] where you can read
> Debian's Linux kernel package changelogs, which will have references to
> any sparc patches.

This solution does not scale at all. The distribution ecosystem
that integrate sparc kernel should contact the sparc maintainer.
We cannot expect the saprc maintainer to monitor the traffic
all relevant mailing lists - yet expect him to know them.

This simply does not scale neither work in practice.

Yes - you provided pointers to the debian lists but there is
a few more distributions around than just debian.

We could assume that the debian folks handling sparc are capable
of judging when to ask for help/advice from the sparc kernel maintainer.

	Sam

Re: debian unusable on niagara

[Josip Rodin]

On Sun, May 03, 2009 at 03:35:24PM +0200, Sam Ravnborg wrote:
> > > > So I suggest that we get some simple diffing done between the two
> > > > pieces of software as a basis for documenting any differences, or
> > > > making modifications so that they converge.
> > > 
> > > If I had just once seen a "Dave, can you test this image out to make
> > > sure this Niagara bug is fixed?", I would have been happy with any
> > > result whatsoever.
> > > 
> > > But because that did not happen, I'm understandably irked that things
> > > are broken the way that they are.
> > > 
> > > I have tons of machines to test on, and the knowledge to fix just
> > > about anything, I just have to be asked.
> > 
> > OK, but each distribution lives in a little (or large) ecosystem of their
> > own, and even in the case of Debian where the system is open for everyone to
> > enter, the actual act of entering the system is necessary in order for
> > anyone to participate.
> > 
> > In this case, where you want to be informed when there's new stuff in
> > Debian's sparc kernel, you might want to subscribe yourself to the
> > debian-sparc list[1] which is the only Debian sparc port mailing list and
> > the place where e.g. calls for testing new kernel images are sent to,
> > and maybe to the linux-2.6 package tracking system[2] where you can read
> > Debian's Linux kernel package changelogs, which will have references to
> > any sparc patches.
> 
> This solution does not scale at all. The distribution ecosystem
> that integrate sparc kernel should contact the sparc maintainer.
> We cannot expect the saprc maintainer to monitor the traffic
> all relevant mailing lists - yet expect him to know them.
> 
> This simply does not scale neither work in practice.
> 
> Yes - you provided pointers to the debian lists but there is
> a few more distributions around than just debian.
> 
> We could assume that the debian folks handling sparc are capable
> of judging when to ask for help/advice from the sparc kernel maintainer.

Sadly, from the last few examples, you can also see that expecting distro
kernel maintainers to contact the central one for all sorts of patches or
changes also doesn't work in practice.

Regarding scale - rather than assuming that it can't work, you should
calculate for yourself if the volume of the aforementioned forums is too
much a burden, there are statistics and archives available online.

David has indicated that he is willing to test other people's kernels on
his plethora of machines, which can be a fairly arduous task, so it
stands to reason that skimming a couple more mailing lists might be
sufficiently less arduous for him that he would we willing to do it.

In case of sparc, it should be mentioned that we're at most a stable
community, if not diminishing in size...

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[Sam Ravnborg]

> > 
> > We could assume that the debian folks handling sparc are capable
> > of judging when to ask for help/advice from the sparc kernel maintainer.
> 
> Sadly, from the last few examples, you can also see that expecting distro
> kernel maintainers to contact the central one for all sorts of patches or
> changes also doesn't work in practice.

Well - then lets educate them...
EOT from me.

	Sam

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Sun, 3 May 2009 13:41:40 +0200

> On Sat, May 02, 2009 at 05:06:04PM -0700, David Miller wrote:
>> From: Josip Rodin <joy@entuzijast.net>
>> Date: Sun, 3 May 2009 00:54:15 +0200
>> 
>> > So I suggest that we get some simple diffing done between the two
>> > pieces of software as a basis for documenting any differences, or
>> > making modifications so that they converge.
>> 
>> If I had just once seen a "Dave, can you test this image out to make
>> sure this Niagara bug is fixed?", I would have been happy with any
>> result whatsoever.
>> 
>> But because that did not happen, I'm understandably irked that things
>> are broken the way that they are.
>> 
>> I have tons of machines to test on, and the knowledge to fix just
>> about anything, I just have to be asked.
> 
> OK, but each distribution lives in a little (or large) ecosystem of their
> own, and even in the case of Debian where the system is open for everyone to
> enter, the actual act of entering the system is necessary in order for
> anyone to participate.

That's irrelevant to the specific issues being discussed here.

Jurij worked on a bug, reported by a niagara user.

He tested a fix on his non-niagara system, and had no feedback from
the niagara user.  He has no access to niagara systsms.

So he has no idea if the bug is fixed or not.

Jurij, who has worked with me time and time again, over and over,
knows that I have such systems can can test anything for him at
a moments notice.

He fails to ask me to do so, therefore the bug stays in an unknown
state and is in fact still broken.

> In this case, where you want to be informed when there's new stuff in
> Debian's sparc kernel,

This was a installer bug, so irrelevant to some of the problems being
discussed here.

The issue is one of communication.  If the debian sparc folks don't
communicate with me, things break.

This has been proven over and over again, and the distributions with
people who communicate actively with me over Sparc issues are the ones
that get this stuff fixed promptly before it sneaks into a real
release.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Sun, 3 May 2009 13:41:40 +0200

> OK, but each distribution lives in a little (or large) ecosystem of their
> own

I want to re-emphasize this: developers in other distributions
proactively communicate and interact with me.  Debian's doesn't.

And that, my friend, is the crucial difference.

Re: debian unusable on niagara

[David Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Sun, 3 May 2009 15:35:24 +0200

> This solution does not scale at all. The distribution ecosystem
> that integrate sparc kernel should contact the sparc maintainer.

Everyone read this carefully, it the critical point in all of
this.

I don't find garbage like this in Ubuntu and Fedora-sparc.  Why?
Because those developers contact me when they need help or need a
problem fixed.

End of story.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Sun, 3 May 2009 17:58:04 +0200

> David has indicated that he is willing to test other people's kernels on
> his plethora of machines, which can be a fairly arduous task, so it
> stands to reason that skimming a couple more mailing lists might be
> sufficiently less arduous for him that he would we willing to do it.
> 
> In case of sparc, it should be mentioned that we're at most a stable
> community, if not diminishing in size...

It's PUSH, not PULL that makes it scale!

People contact me when they need something tested, not the other
way around!

Do you think I have time to murk through every sparc distributions
mailing list looking for crap like this?  You must be crazy if 
you think that works and can scale.

Now the other way around, having people who concentrate in their
so-called "ecosystem" proactively contact me when a specific thing
need to be looked at, that does scale.

Re: debian unusable on niagara

[Josip Rodin]

On Sun, May 03, 2009 at 01:11:29PM -0700, David Miller wrote:
> I don't find garbage like this in Ubuntu and Fedora-sparc.  Why?
> Because those developers contact me when they need help or need a
> problem fixed.
> 
> End of story.

Doesn't that mean that they encounter a fairly small amount of
non-distro-specific sparc-related problems? Otherwise I don't see how
that procedure can scale.

Neither Ubuntu nor Fedora seem to distribute sparc versions as mainstream,
which would seem to explain why they aren't seeing enough problems for
these kinds of issues ever to escalate.

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Sun, 3 May 2009 22:44:43 +0200

> On Sun, May 03, 2009 at 01:11:29PM -0700, David Miller wrote:
>> I don't find garbage like this in Ubuntu and Fedora-sparc.  Why?
>> Because those developers contact me when they need help or need a
>> problem fixed.
>> 
>> End of story.
> 
> Doesn't that mean that they encounter a fairly small amount of
> non-distro-specific sparc-related problems? Otherwise I don't see how
> that procedure can scale.

Are you really this blind?

Assume there were 100 sparc supporting distributions.  What scales
better?  Having me on 100 fucking mailing lists looking for things or
having those sparc dist maintainers contact me or this mailing list
when something specific comes to their attention?

You tell me.

> Neither Ubuntu nor Fedora seem to distribute sparc versions as mainstream,
> which would seem to explain why they aren't seeing enough problems for
> these kinds of issues ever to escalate.

Ubuntu did.  And both the Fedora and Ubuntu sparc folks sit on
a sparc developer IRC channel and have direct access to me 24 hours
a day if they want to ask something or get something tested.

You're being dense and bringing up scarecrows to dismiss my
fundamental argument.  Which is that it doesn't make sense, nor scale,
for me to follow what ever dist in the world does with my work.

Re: debian unusable on niagara

[Julien Cristau]

On Sun, May  3, 2009 at 13:09:23 -0700, David Miller wrote:

> The issue is one of communication.  If the debian sparc folks don't
> communicate with me, things break.
> 
> This has been proven over and over again, and the distributions with
> people who communicate actively with me over Sparc issues are the ones
> that get this stuff fixed promptly before it sneaks into a real
> release.

As far as I can tell, the main issue is that nobody's actively working
on the debian sparc port in the first place.  And without active
maintainers, that port is actually a disservice to users and the sparc
linux community.

Cheers,
Julien

Re: debian unusable on niagara

[Josip Rodin]

On Sun, May 03, 2009 at 01:50:59PM -0700, David Miller wrote:
> >> I don't find garbage like this in Ubuntu and Fedora-sparc.  Why?
> >> Because those developers contact me when they need help or need a
> >> problem fixed.
> >> 
> >> End of story.
> > 
> > Doesn't that mean that they encounter a fairly small amount of
> > non-distro-specific sparc-related problems? Otherwise I don't see how
> > that procedure can scale.
> 
> Are you really this blind?
> 
> Assume there were 100 sparc supporting distributions.  What scales
> better?  Having me on 100 fucking mailing lists looking for things or
> having those sparc dist maintainers contact me or this mailing list
> when something specific comes to their attention?
> 
> You tell me.

Yes, that clearly wouldn't make sense. The point I'm trying to make is that
there aren't *nearly* as many places to watch, otherwise you would have run
into the same problem before. Just because your previous few contacts worked
one way, that doesn't mean that all the others would do the same.

> > Neither Ubuntu nor Fedora seem to distribute sparc versions as mainstream,
> > which would seem to explain why they aren't seeing enough problems for
> > these kinds of issues ever to escalate.
> 
> Ubuntu did.  And both the Fedora and Ubuntu sparc folks sit on
> a sparc developer IRC channel and have direct access to me 24 hours
> a day if they want to ask something or get something tested.
> 
> You're being dense and bringing up scarecrows to dismiss my
> fundamental argument.  Which is that it doesn't make sense, nor scale,
> for me to follow what ever dist in the world does with my work.

That's fine, but the issue came up when you actually noticed what they do
with your work, and complained. If you can't normally follow what they do,
then just don't do it, and let them work to clean up any bugs that happen
to them, what's wrong with that?

Sure, it would probably be better for you if they adjusted to your own
development model, and relied on you for every change that they want done,
and didn't object to any of your recommendations, but it's free software,
they choose to do things bit differently, what with all the separate lists,
BTS, installer, and ultimately separate users.

Their lack of full conformance to your standards isn't meant to be an
annoyance to you, simply the observation of their own local standards, where
people are encouraged to try and fix users' problems without engaging the
upstream maintainers every time. Yes, sometimes it fails, but in general it
seems to be working. It certainly seems to work in this case, where Debian
still remains one of the few living sparc linux distributions out there.

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[Josip Rodin]

On Mon, May 04, 2009 at 09:40:26AM +0200, Julien Cristau wrote:
> As far as I can tell, the main issue is that nobody's actively working
> on the debian sparc port in the first place.  And without active
> maintainers, that port is actually a disservice to users and the sparc
> linux community.

Even if nobody is currently volunteering to explicitly state that they are
working on the port as a whole (which has always been a fairly vague concept
anyway), the software is generally working fine (yes, even if it has bugs),
the buildds are happily churning (and are actually actively maintained),
new users do actually regularly come through, so I fail to see how it's
a disservice to everyone.

What is that statement supposed to mean, anyway? Would you prefer if
the port didn't exist at all?

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[Julien Cristau]

On Mon, May  4, 2009 at 11:12:38 +0200, Josip Rodin wrote:

> On Mon, May 04, 2009 at 09:40:26AM +0200, Julien Cristau wrote:
> > As far as I can tell, the main issue is that nobody's actively working
> > on the debian sparc port in the first place.  And without active
> > maintainers, that port is actually a disservice to users and the sparc
> > linux community.
> 
> Even if nobody is currently volunteering to explicitly state that they are
> working on the port as a whole (which has always been a fairly vague concept
> anyway), the software is generally working fine (yes, even if it has bugs),
> the buildds are happily churning (and are actually actively maintained),
> new users do actually regularly come through, so I fail to see how it's
> a disservice to everyone.
> 
And yet sid's kernel has been broken for some time without anyone
noticing.  And yet nobody replies when a package maintainer needs a
patch tested and asks on the port mailing list (which means X is broken
in lenny right now).

> What is that statement supposed to mean, anyway? Would you prefer if
> the port didn't exist at all?
> 
Than continue to exist without anyone volunteering to maintain it?  Yes.
But hey, you can still change that...

Cheers,
Julien

Re: debian unusable on niagara

[Josip Rodin]

On Mon, May 04, 2009 at 11:34:29AM +0200, Julien Cristau wrote:
> > > As far as I can tell, the main issue is that nobody's actively working
> > > on the debian sparc port in the first place.  And without active
> > > maintainers, that port is actually a disservice to users and the sparc
> > > linux community.
> > 
> > Even if nobody is currently volunteering to explicitly state that they are
> > working on the port as a whole (which has always been a fairly vague concept
> > anyway), the software is generally working fine (yes, even if it has bugs),
> > the buildds are happily churning (and are actually actively maintained),
> > new users do actually regularly come through, so I fail to see how it's
> > a disservice to everyone.
> > 
> And yet sid's kernel has been broken for some time without anyone
> noticing.

If you're talking about #525926, that's a) a relatively normal software bug
in unstable that gets found and fixed b) something that got resolved within
two weeks. I don't see how it's a reason to panic.

> And yet nobody replies when a package maintainer needs a patch tested and
> asks on the port mailing list (which means X is broken in lenny right
> now).

If you're referring to #488669, then this is a sore spot because that hit me
as well :) unsynchronized changes to the sparc kernel and X.org (both
upstream) caused it, and nobody caught it in time for release. Having a
person in Debian dedicated to trying to track it down preemptively would
have been very helpful, but it's still a bug not completely local to Debian,
and it's not really local to the sparc porting team because to fix it one
needs changes done in generic packages, meaning you'd have to track other
maintainers' schedules and releases. It's also not unfair to say that (once
reported and explained) the fixing is primarily in the jurisdiction of the
maintainers of kernel and X packages, because it isn't standard practice to
have porters do big sourceful uploads just to fix an architecture.

> > What is that statement supposed to mean, anyway? Would you prefer if
> > the port didn't exist at all?
> > 
> Than continue to exist without anyone volunteering to maintain it?  Yes.
> But hey, you can still change that...

I don't think we would gain much from cutting it off, and just because it
doesn't match one definition of an active port.

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[Florian Fainelli]

Hi,

Le Monday 04 May 2009 11:12:38 Josip Rodin, vous avez écrit :
> On Mon, May 04, 2009 at 09:40:26AM +0200, Julien Cristau wrote:
> > As far as I can tell, the main issue is that nobody's actively working
> > on the debian sparc port in the first place.  And without active
> > maintainers, that port is actually a disservice to users and the sparc
> > linux community.
>
> Even if nobody is currently volunteering to explicitly state that they are
> working on the port as a whole (which has always been a fairly vague
> concept anyway), the software is generally working fine (yes, even if it
> has bugs), the buildds are happily churning (and are actually actively
> maintained), new users do actually regularly come through, so I fail to see
> how it's a disservice to everyone.

A distribution developer should provide users with working kernels. Getting 
software x.y.z to work on sparc is something different. So rather than 
disservicing anyone it is just annoying not being able to boot a kernel or 
having it partially working for something as stupid as enabling/disabling the 
right kernel options.

>
> What is that statement supposed to mean, anyway? Would you prefer if
> the port didn't exist at all?

No as long as there are users for it, please maintain it, but focus your 
attention on kernels rather than geting the whole Debian package set to work.

My 2 cents.
-- 
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------

Re: debian unusable on niagara

[Josip Rodin]

On Mon, May 04, 2009 at 02:15:01PM +0200, Florian Fainelli wrote:
> > > As far as I can tell, the main issue is that nobody's actively working
> > > on the debian sparc port in the first place.  And without active
> > > maintainers, that port is actually a disservice to users and the sparc
> > > linux community.
> >
> > Even if nobody is currently volunteering to explicitly state that they are
> > working on the port as a whole (which has always been a fairly vague
> > concept anyway), the software is generally working fine (yes, even if it
> > has bugs), the buildds are happily churning (and are actually actively
> > maintained), new users do actually regularly come through, so I fail to see
> > how it's a disservice to everyone.
> 
> A distribution developer should provide users with working kernels. Getting 
> software x.y.z to work on sparc is something different. So rather than 
> disservicing anyone it is just annoying not being able to boot a kernel or 
> having it partially working for something as stupid as enabling/disabling the 
> right kernel options.
> 
> >
> > What is that statement supposed to mean, anyway? Would you prefer if
> > the port didn't exist at all?
> 
> No as long as there are users for it, please maintain it, but focus your 
> attention on kernels rather than geting the whole Debian package set to work.

The released kernel should actually be working for a large majority of
machines, so that goal is almost accomplished. IIRC, in etch, we didn't
support a few older classes of Ultra Enterprise machines out of the box
because brokenness with some ESP controller, and in lenny we miss the
Ultra 45 series because of that fake PCI controller patch undoing (in turn
related to broken X on other Ultra workstations).

Overall I've had very similar experiences with x86 machines. I've had to
work around server installations several times because of lack of support
for RAID controllers, and even my current laptop's X driver reliably oopses
the kernel whenever I use the docking station, which is also a regression
from the last release. I would be nice to be able to cry about the general
state of things in those cases too, now wouldn't it...

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Mon, 4 May 2009 10:29:17 +0200

> Sure, it would probably be better for you if they adjusted to your own
> development model, and relied on you for every change that they want done,
> and didn't object to any of your recommendations, but it's free software,
> they choose to do things bit differently, what with all the separate lists,
> BTS, installer, and ultimately separate users.

I never said that they need to run every change they want to
do past me, that would be rediclious.

Read what I actually said.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Mon, 4 May 2009 17:03:57 +0200

> The released kernel should actually be working for a large majority of
> machines, so that goal is almost accomplished. IIRC, in etch, we didn't
> support a few older classes of Ultra Enterprise machines out of the box
> because brokenness with some ESP controller, and in lenny we miss the
> Ultra 45 series because of that fake PCI controller patch undoing (in turn
> related to broken X on other Ultra workstations).

And Niagara systems had a completely busted console in lenny.

Re: debian unusable on niagara

[Josip Rodin]

On Mon, May 04, 2009 at 09:55:11AM -0700, David Miller wrote:
> > Sure, it would probably be better for you if they adjusted to your own
> > development model, and relied on you for every change that they want done,
> > and didn't object to any of your recommendations, but it's free software,
> > they choose to do things bit differently, what with all the separate lists,
> > BTS, installer, and ultimately separate users.
> 
> I never said that they need to run every change they want to
> do past me, that would be rediclious.
> 
> Read what I actually said.

You said that he didn't ask you to test that kernel on your Niagaras,
instead he let the Niagara user who contacted Debian via BTS test the
change. Well, that part wasn't particularly strange to me - had the user
actually reported back in time, and had someone followed up on it. I can't
say my first impulse would have been to bother you - it seems needless, when
there's already one person seemingly available to test - the same one who
reported it. The bug log indicates that there were several reporters,
actually.

I agree that it would be much better if Jurij (or anyone else for that
matter) remembered to ask you (or anyone else with that hardware and the
capacity to test for that matter) to test. But he's not the best target for
rebuke, because he clearly spent some effort (even if ultimately mistaken),
which wasn't reciprocated by user testing; everyone else watching could have
noticed it and intervened (and that didn't require much skill either).

The practical fix for this problem is not simply to criticize the people who
already contribute for not contributing enough or well enough, but instead
to get more people involved in handling the issues, so I explained how to do
that. If you yourself aren't available for that, that's just fine, the same
information went to all other list subscribers, so anyone else who wants to
volunteer is welcome.

-- 
     2. That which causes joy or happiness.

Re: debian unusable on niagara

[David Miller]

From: Josip Rodin <joy@entuzijast.net>
Date: Mon, 4 May 2009 19:33:12 +0200

> On Mon, May 04, 2009 at 09:55:11AM -0700, David Miller wrote:
>> > Sure, it would probably be better for you if they adjusted to your own
>> > development model, and relied on you for every change that they want done,
>> > and didn't object to any of your recommendations, but it's free software,
>> > they choose to do things bit differently, what with all the separate lists,
>> > BTS, installer, and ultimately separate users.
>> 
>> I never said that they need to run every change they want to
>> do past me, that would be rediclious.
>> 
>> Read what I actually said.
> 
> You said that he didn't ask you to test that kernel on your Niagaras,
> instead he let the Niagara user who contacted Debian via BTS test the
> change.

And that has nothing to do with asking me to run every change
through me.

This was an issue of ability to test a bug fix.

> I can't say my first impulse would have been to bother you - it
> seems needless, when there's already one person seemingly available
> to test - the same one who reported it. The bug log indicates that
> there were several reporters, actually.

If you don't have the necessary hardware and know that the sparc
kernel maintainer does, it absolutely should be your impulse.

The impulse definitely should not be "cower into a hole if the
bug reporter doesn't respond".