Re: DSA concerns for jessie architectures
On Sun, Jul 21, 2013 at 09:06:31PM +0200, Bernd Zeimetz wrote: On 06/22/2013 07:26 PM, Martin Zobel-Helas wrote: * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. I think all machines except stadler and sompek are US IIIi machines. The problem with US IIIi is, that sun never published the cpu specs - they would have done it if somebody would have paid for the lawyers to look trough them before publishing. US IIi support was implemented by a student working at SUN under NDA and US IV and later was published. So I think if dropping (official) support for US IIIi CPUs would keep the port alive, we should do that. Running Debian on the more recent machines makes more sense anyway imho. The older ones are nice, but they consume a lt of power. If you drop support for US II and IIIi, we basicly have 2 boxes left, of which one acts as sparc buildd and the other as sparc64 and sparc buildd. Those 2 boxes in their current state really can't keep up, specially since they're not stable at all when trying to use multiple cores. You would also be missing a porterbox. I thought the plan was to drop 32 bit support and move to sparc64? But that still doesn't seem to have moved to the Debian archive. Is there something holding back moving to sparc64? There is also Matthias Klose mail asking what to do with gcc. sparc is still on gcc-4.6 and I think he isn't willing to maintain that any longer. Kurt -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130808173254.ga25...@roeckx.be
Re: DSA concerns for jessie architectures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/22/2013 07:26 PM, Martin Zobel-Helas wrote: * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. I think all machines except stadler and sompek are US IIIi machines. The problem with US IIIi is, that sun never published the cpu specs - they would have done it if somebody would have paid for the lawyers to look trough them before publishing. US IIi support was implemented by a student working at SUN under NDA and US IV and later was published. So I think if dropping (official) support for US IIIi CPUs would keep the port alive, we should do that. Running Debian on the more recent machines makes more sense anyway imho. The older ones are nice, but they consume a lt of power. - -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJR7DExAAoJEOs2Fxpv+UNffpcP/2Rs12KtUr1R8Fj/SUFsGTGi Qq4IyIsq6T9+0be/Q2NT+8vKhqy9eAfLIGPYfEfMP/gQUXHxqURF7452FCum5pCe PPbhpGMFL67rX9I9tdNbYGEcD6KnHksHc64PaV4FkCd5W/dvQzaVHxfP5I7TjFL2 JQVrfqYTi546kPN7kqo6YhNNC+jFRBJOxB+2RhdEddg12xU9/08/YIy865qJqXSP 0X+xBfiGu040AKUC+Ml4ZjFGKDnCOKhuuAKDYnyZLjLSFjTkE00WowKDS8JmJRLC ls89Xha2K4Sk01io+f4iermCjRsHD/GvS4mNIG5HsEQYHROdWoCFNRl4hAdGI0zZ CvFnxaJLwQ+cd0dsoFO/OkuRLTYOrjHKTniOjrWcgaOl0L6C6K4Jhyh+jpl2GmO/ sUs/K3jtUBos5Q1ojetmm/rAXjEFe3giOokosUP1DOB8fWUnYqRDYf5ODOeEucot nzl6lfvp+g2nQVQAAOqpSqxCYYhue23Mg8ZYfW1L/I8mNIvClrcSVfHAAP3URQeY eDGoyPNX6AIYiFX8J121ynfMa/TujGURfoPcQWWGFb3NyJ4/RM/FrTAAseldcIlW 2nfpRUX118LEYLQ6Jj4JQn7Ci6lL+SUgI2HfSRu/5a1aoBrEVhVF5ItUbMU6B0Vx YTnzPB7WteSULAbu90Iz =H+fH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ec3137.1020...@bzed.de
DSA concerns for jessie architectures
[please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] Comrades! At our recent Essen sprint, DSA went through the release qualification matrix (for wheezy, as there isn't one for jessie, yet) and defined a set of requirements that we consider necessary for us to support a port for the next stable release. We have limited these requirements to whether DSA can support a port well or not, and we wanted to establish these requirements early in the release cycle so that our concerns can be addressed. Our requirements for machines are not new; they are: * reliability - The stable release manager requires that we operate three machines for each port: two buildd machines in different locations and one porter machine. These machines must be reliable (see mips for counterexample). * out of band management - We require the ability to manage the machines independently of their primary network interface: serial console or better, remotely-controllable power. * supportability - We require that the machines be commercialy available (within financial constraints) and that they be supportable through a warranty or post-warranty support or are otherwise easy to replace. * stability - We require that the machine's architecture have an actively-maintained stable kernel in the archive. * environment - We require that packages critical for DSA operations be available: puppet, samhain, syslog-ng, ferm/pf, etc. Historically, we have not been enforcing these requirements strictly and this has caused / continues to cause us significant operational challenges resulting in our inability to render the service levels that should reasonably be expected of us. Therefore, we believe it is important that all debian.org machines meet these requirements. Based on the list of requirements enumerated above, we currentlty are concerned about the following architectures from the perspective of using them as debian.org machines: * armel: no remote management (being worked on); no archive kernel for the machines we use. * armhf: no remote management (being worked on). * hurd: no puppet/ruby broken (for 3 months+); lack of firewall support. * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. * s390/x: no stable kernels; not sourceable within our budgets (currently relying on sponsors - this has not been a problem so far). We believe that it is the responsibility of the porter community to either source hardware or provide DSA with proposals regarding the hardware Debian should buy. We encourage the porter community to actively assist DSA with the resolution of the above noted concerns regarding various ports. Thanks, Martin Zobel-Helas Debian System Administration Team -- It pays to be obvious, especially if you have a reputation for being subtle. Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B signature.asc Description: Digital signature
Re: DSA concerns for jessie architectures
* Martin Zobel-Helas (zo...@debian.org) wrote: [please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] * armel: no remote management (being worked on); no archive kernel for the machines we use. * armhf: no remote management (being worked on). Generally I've seen most ARM boards managed via separate PDUs and serial concentrators; there are ARM systems that as I understand are built for remote management - but if you've got PDUs setup then you can control nigh on anything; and given the current draw on many of those machines it doesn't need to be expensive PDUs, simple USB driven relay setups can be sufficient (although it gets hairier if you want to control hard drive power etc). Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130622175739.GB25102@gallifrey
Re: DSA concerns for jessie architectures
Martin Zobel-Helas zo...@debian.org writes: [please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] Comrades! At our recent Essen sprint, DSA went through the release qualification matrix (for wheezy, as there isn't one for jessie, yet) and defined a set of requirements that we consider necessary for us to support a port for the next stable release. We have limited these requirements to whether DSA can support a port well or not, and we wanted to establish these requirements early in the release cycle so that our concerns can be addressed. Our requirements for machines are not new; they are: * reliability - The stable release manager requires that we operate three machines for each port: two buildd machines in different locations and one porter machine. These machines must be reliable (see mips for counterexample). * out of band management - We require the ability to manage the machines independently of their primary network interface: serial console or better, remotely-controllable power. * supportability - We require that the machines be commercialy available (within financial constraints) and that they be supportable through a warranty or post-warranty support or are otherwise easy to replace. * stability - We require that the machine's architecture have an actively-maintained stable kernel in the archive. * environment - We require that packages critical for DSA operations be available: puppet, samhain, syslog-ng, ferm/pf, etc. Historically, we have not been enforcing these requirements strictly and this has caused / continues to cause us significant operational challenges resulting in our inability to render the service levels that should reasonably be expected of us. Therefore, we believe it is important that all debian.org machines meet these requirements. Based on the list of requirements enumerated above, we currentlty are concerned about the following architectures from the perspective of using them as debian.org machines: * armel: no remote management (being worked on); no archive kernel for the machines we use. afair buildd are: marvell DB-78x00 - should be supported by armel kernel flavour mx78xx0 thecus n2100 - should be supported by armel kernel flavour iop32x Please, can you explain what's exactily missing on kernel support side ? thanks, Arnaud -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo6yar46@lebrac.rtp-net.org
