Re: sparc/debian/linux procedures
On Thu, May 07, 2009 at 02:00:35AM +0100, Martin wrote: [...] My question is - when I find things that worked in Ubuntu sparc but not on Debian, what is the proper procedure for resolving the issue? Is there a checklist or flowchart anywhere public that should be followed when issues are found? I'm guessing the first step is probably to determine whether it's a kernel issue or an issue external to the kernel so that a bug report can be filed with the correct team (while also checking to see if the issue has already been reported), but again that's just a guess. A general procedure might be: 1. Identify which package(s) are causing the problem. 2. Attempt to identify what conditions / factors / circumstances trigger the issue. All the normal rules about writing bug reports apply. 3. File a bug report against the relevant Debian package. 4. Assist the package maintainer with any follow up queries. Sounds about right. If it's a generic kernel problem, it can be reported directly to sparcli...@vger.kernel.org, which is upstream list dedicated to the discussion of sparc kernel issues. Reporting it in Debian (against linux-2.6 package) is fine too, it just may take longer to propagate to upstream. In either case, if you feel like you are stuck and the bug is not getting enough attention, dropping a message to this list is fine. It is also very useful if you can do occasional tests of kernels in unstable or the daily builds of Debian installer, available from http://www.debian.org/devel/debian-installer If you have time and access to a version of the package that does work, it might be helpful to track down which differences are causing the problem, and if possible, submit a patch. Certainly, including a reference / pointer to the nearest version of Ubuntu package that works would be helpful. If the bug turns out to be something that is not specific to Debian and is a more general problem then the packages maintainer may forward it (upstream) to the main developers for that package. Any guidance would be greatly appreciated. Does the above help? I'm far from an expert on this; I'm just an end-user, but the above procedure has worked for me. HTH Cheers, - Martin -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
Jurij Smakov wrote: On Thu, May 07, 2009 at 02:00:35AM +0100, Martin wrote: [...] My question is - when I find things that worked in Ubuntu sparc but not on Debian, what is the proper procedure for resolving the issue? Is there a checklist or flowchart anywhere public that should be followed when issues are found? I'm guessing the first step is probably to determine whether it's a kernel issue or an issue external to the kernel so that a bug report can be filed with the correct team (while also checking to see if the issue has already been reported), but again that's just a guess. A general procedure might be: 1. Identify which package(s) are causing the problem. 2. Attempt to identify what conditions / factors / circumstances trigger the issue. All the normal rules about writing bug reports apply. 3. File a bug report against the relevant Debian package. 4. Assist the package maintainer with any follow up queries. Sounds about right. If it's a generic kernel problem, it can be reported directly to sparcli...@vger.kernel.org, which is upstream list dedicated to the discussion of sparc kernel issues. Reporting it in Debian (against linux-2.6 package) is fine too, it just may take longer to propagate to upstream. In either case, if you feel like you are stuck and the bug is not getting enough attention, dropping a message to this list is fine. It is also very useful if you can do occasional tests of kernels in unstable or the daily builds of Debian installer, available from http://www.debian.org/devel/debian-installer If you have time and access to a version of the package that does work, it might be helpful to track down which differences are causing the problem, and if possible, submit a patch. Certainly, including a reference / pointer to the nearest version of Ubuntu package that works would be helpful. If the bug turns out to be something that is not specific to Debian and is a more general problem then the packages maintainer may forward it (upstream) to the main developers for that package. Martin/Jurij, Thanks for the guidelines, I really appreciate it. One current concern (which I've brought up in the past but probably didn't follow proper procedure) is still the conflict between the tulip and dmfe ethernet kernel modules on both the Sun Netra X1 and Sunfire V100 platforms, as well as their eth0/eth1 numbering being swapped - which neither issue exists with Ubuntu. I haven't tested the latest unstable or daily builds of Debian though nor have I looked into detail how Ubuntu went about resolving the issue. I'll follow the guidelines above and see what can be done. Thanks again, Brian -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
- Original Message - From: Brian Thompson br...@eng.wayne.edu To: Jurij Smakov ju...@wooyd.org; Martin inku...@interalpha.co.uk Cc: debian-sparc@lists.debian.org Sent: Thursday, May 07, 2009 3:01 PM Subject: Re: sparc/debian/linux procedures One current concern (which I've brought up in the past but probably didn't follow proper procedure) is still the conflict between the tulip and dmfe ethernet kernel modules on both the Sun Netra X1 and Sunfire V100 platforms, as well as their eth0/eth1 numbering being swapped - which neither issue exists with Ubuntu. The ethx numbering can be cured through the use of udev config files. You can force the system to give a static ethx mapping to an Ethernet card via its MAC address. Jim -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: sparc/debian/linux procedures
On Thu, 07 May 2009 15:15:55 CST, Jim MacKenzie writes: The ethx numbering can be cured through the use of udev config files. You can force the system to give a static ethx mapping to an Ethernet card via its MAC address. or, if you dislike udev (like me), then nameif does that job very well, too. nameif belongs to the net-tools package, it'll certainly be installed. regards az -- + Alexander Zangerl + DSA 42BD645D + (RSA 5B586291) Fachbegriffe der Informatik, Strong international Encryption: Triple-ROT13 -- Carsten Lechte signature.asc Description: Digital Signature
Re: sparc/debian/linux procedures
[ Apologies for the cross post ] On Mon, 2009-05-04 at 15:26 -0400, Brian Thompson wrote: All, snip It's my understanding that there are a team of people who are focused on the sparc kernel itself (which is used by Debian as well as some of the other distributions - Aurora, etc). This is a subset of the kernel developers. David Miller is (I believe) the key man. It's also my understanding that there are a team of people who are focused on making sure that the sparc port of Debian works properly as a complete Debian OS distribution for sparc. It's more of a loose affiliation, but yes, these are some of the Debian developers on the debian-sparc list. In addition, I understand that there's also a team of people who are focused on making sure that the Debian distribution as whole (non-arch specific) functions properly and that changes on one port don't end up inadvertently causing problems for other Debian ports. Again, more a loose affiliation - this is essentially the work of the Debian developers. A small number of developers have responsibility for over all integration (i.e. the release team, buildd maintainers, etc.) but most work is done on a package by package basis with a small number of folks working on each (often one or two). Likewise I understand that there's a team of people who are focused on making sure that the linux kernel as a whole functions properly and that changes specific to one arch don't end up inadvertently causing problems for other linux kernel archs. This is, in general the Linux kernel developers; although, again, their responsibilities and organisational structure vary. My question is - when I find things that worked in Ubuntu sparc but not on Debian, what is the proper procedure for resolving the issue? Is there a checklist or flowchart anywhere public that should be followed when issues are found? I'm guessing the first step is probably to determine whether it's a kernel issue or an issue external to the kernel so that a bug report can be filed with the correct team (while also checking to see if the issue has already been reported), but again that's just a guess. A general procedure might be: 1. Identify which package(s) are causing the problem. 2. Attempt to identify what conditions / factors / circumstances trigger the issue. All the normal rules about writing bug reports apply. 3. File a bug report against the relevant Debian package. 4. Assist the package maintainer with any follow up queries. If you have time and access to a version of the package that does work, it might be helpful to track down which differences are causing the problem, and if possible, submit a patch. Certainly, including a reference / pointer to the nearest version of Ubuntu package that works would be helpful. If the bug turns out to be something that is not specific to Debian and is a more general problem then the packages maintainer may forward it (upstream) to the main developers for that package. Any guidance would be greatly appreciated. Does the above help? I'm far from an expert on this; I'm just an end-user, but the above procedure has worked for me. HTH Cheers, - Martin -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
sparc/debian/linux procedures
All, First I have to say this email isn't targeted at any specific people by name but rather to all of those who are interested in seeing further linux sparc development (and especially Debian sparc development). I've been trying to follow the current debate regarding niagara testing/ bug fixes and I have to admit that the bureaucracy is a bit intimidating at best. I've recently (over the past year or so) started focusing on Debian now that Canonical no longer officially supports sparc on Ubuntu, figuring that although most of our hardware here is older hardware, moving towards Debian directly will at least give the OS a chance at remaining up to date. It's my understanding that there are a team of people who are focused on the sparc kernel itself (which is used by Debian as well as some of the other distributions - Aurora, etc). It's also my understanding that there are a team of people who are focused on making sure that the sparc port of Debian works properly as a complete Debian OS distribution for sparc. In addition, I understand that there's also a team of people who are focused on making sure that the Debian distribution as whole (non-arch specific) functions properly and that changes on one port don't end up inadvertently causing problems for other Debian ports. Likewise I understand that there's a team of people who are focused on making sure that the linux kernel as a whole functions properly and that changes specific to one arch don't end up inadvertently causing problems for other linux kernel archs. My question is - when I find things that worked in Ubuntu sparc but not on Debian, what is the proper procedure for resolving the issue? Is there a checklist or flowchart anywhere public that should be followed when issues are found? I'm guessing the first step is probably to determine whether it's a kernel issue or an issue external to the kernel so that a bug report can be filed with the correct team (while also checking to see if the issue has already been reported), but again that's just a guess. And, I'm by no means asking for professional assistance or intending to criticize anyone's prior efforts. I really would like to understand the big picture though so that I know all of the steps starting with discovering a new issue to the issue being resolved in the next Debian release. That way I can follow through and assist where I can while at the same time not stepping on anyones toes. Any guidance would be greatly appreciated. Thanks, Brian -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
