Re: DSA concerns for jessie architectures
On Sun, Jun 30, 2013 at 11:43 AM, Samuel Thibault samuel.thiba...@gnu.org wrote: Samuel Thibault, le Sun 30 Jun 2013 11:38:33 +0200, a écrit : Martin Zobel-Helas, le Sat 22 Jun 2013 19:26:44 +0200, a écrit : * hurd: no puppet/ruby broken (for 3 months+); I guess this went out of our radar somehow, and can be fixed not too hardly. Actually puppet is installable. debian-hurd: can somebody who actually knows how to make it work test it and report bugs if any? ruby2.0 has successfully been uploaded few hours ago. I just setup a simple fileserver configuration, linux-master hurd-slave, and seems to work fine. Same configuration was already working months ago with ruby1.8/1.9. [CC'ing ruby maintainers] Build brokenness is due to testsuite. I'll call make test basic and make test-all full 1.8 (EOL) - broken testsuite on all archs but ignored, so all succeed 1.9 - build runs both basic and full testsuites on all archs, none on ia64. sparc, kfbsd*. 2.0 - build runs basic testsuite only on all archs On hurd. a couple of patches made basic testsuite succeeding. Full one doesn't yet. That's why 2.0 turned into green and 1.9 won't (still to backport such patches btw) unless even 1.9 build starts ignoring/avoid running full testsuite. -- G..e -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABcaWC1=+D5YkFjcxy2opid1atBjdRX0QyjTîfd+d1hfk...@mail.gmail.com
Re: DSA concerns for jessie architectures - mips/mipsel
Hi Graham, ]] Graham Whaley sorry if you get an unwanted Cc on this, I'm not sure what, if any of the lists you're reading. I'd like to respond to your call for help regards the release qualification matrix, in particular for hardware (buildd and porter machines), and in particular for mips and mipsel arch. I wish to work with you to remedy some of the listed issues. I've started working with MIPS hardware vendors on availability and pricing of hardware. That's good news, once you have solid numbers, I'd be most interested in seeing them. Feel free to just mail d...@debian.org if the numbers are confidential. Having researched your current mips/mipsel setup and the requirements for jessie, the issues as I see them, and hopefully solutions, are: 1) reliability. Corelli and Gabrielli are unstable. I saw the thread way back where they were investigated, but it seems un-fixable (and the machines are now rather old). Let's work on replacing both of those, and maybe Lucatelli as well, as it appears to be the same hardware (but possibly stable?). I think this makes sense. 2) supportability. We'll work on this to see what the options are. I'm sure we all want boxes that can be maintained/replaced easily. 3) speed. I see 'mips' (but not mipsel in particular) listed as 'too slow'. Sure, Can somebody point me at some indication of the minimum requirement here (not that I'm particularly aiming at the minimum, I just wish to ensure we reach it :-). And, is this just pure single-multi-core/thread-machine speed, or is it a solvable problem by using multiple machines if necessary ? I think others have covered this: the buildds need to be able to keep up, which can be done with multiple machines. In addition the current MIPS machines are currently significantly slower than even armel (so that upgrading packages and running samhain take unreasonably long). These are single-core performance tasks and don't scale with the number of machines. 4) I see there is a note about an 'opcode implementation error' for a mipsel porter box. Sounds like a new machine(s) is needed there as well. Could somebody point me at some data on the opcode issue (more out of interest really...). The mono JIT doesn't work on our MIPS machines due to the machines not implementing the full architecture spec, AIUI. Porter and buildd boxes should not have hardware bugs like that. From the three types of machines I see you currently have I believe there are more modern versions of all of those, and possibly some others. I believe we will be able to locate hardware to solve the issues. That would be great. Ideally, we'd want fast, server class machines with working OOB (both power and console), that use standard hardware (SATA/SAS drives, etc) and that we have some kind of warranty for, so we can get them replaced when they fail. Ideally world-wide, so we can have them hosted where we want. -- Tollef Fog Heen, DSA UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761tjz890@qurzaw.varnish-software.com
Re: DSA concerns for jessie architectures - mips/mipsel
Hi DSA, all. I'd like to respond to your call for help regards the release qualification matrix, in particular for hardware (buildd and porter machines), and in particular for mips and mipsel arch. I wish to work with you to remedy some of the listed issues. I've started working with MIPS hardware vendors on availability and pricing of hardware. Having researched your current mips/mipsel setup and the requirements for jessie, the issues as I see them, and hopefully solutions, are: 1) reliability. Corelli and Gabrielli are unstable. I saw the thread way back where they were investigated, but it seems un-fixable (and the machines are now rather old). Let's work on replacing both of those, and maybe Lucatelli as well, as it appears to be the same hardware (but possibly stable?). 2) supportability. We'll work on this to see what the options are. I'm sure we all want boxes that can be maintained/replaced easily. 3) speed. I see 'mips' (but not mipsel in particular) listed as 'too slow'. Sure, Can somebody point me at some indication of the minimum requirement here (not that I'm particularly aiming at the minimum, I just wish to ensure we reach it :-). And, is this just pure single-multi-core/thread-machine speed, or is it a solvable problem by using multiple machines if necessary ? 4) I see there is a note about an 'opcode implementation error' for a mipsel porter box. Sounds like a new machine(s) is needed there as well. Could somebody point me at some data on the opcode issue (more out of interest really...). From the three types of machines I see you currently have I believe there are more modern versions of all of those, and possibly some others. I believe we will be able to locate hardware to solve the issues. Thanks, Graham -- Software Design Manager, MIPS platforms Imagination Technologies
Re: DSA concerns for jessie architectures - mips/mipsel
Hi, On 27/09/13 16:23, Graham Whaley wrote: I wish to work with you to remedy some of the listed issues. I've started working with MIPS hardware vendors on availability and pricing of hardware. I've wondered if SMP Loongson systems are anywhere to be found: http://bbs.lemote.com/viewthread.php?tid=43118 or if even the Lemote Hongri would be available someday: http://www.lemote.com/products/computer/hongri/ But I don't see Loongson 3A being an option until at the very least jessie kernels support it and are stable with all cores in use. This is just my opinion though and I can't speak for DSA. 3) speed. I see 'mips' (but not mipsel in particular) listed as 'too slow'. Sure, Can somebody point me at some indication of the minimum requirement here (not that I'm particularly aiming at the minimum, I just wish to ensure we reach it :-). And, is this just pure single-multi-core/thread-machine speed, or is it a solvable problem by using multiple machines if necessary ? On mipsel at least, I recall that libreoffice, openjdk-7, webkit seemed to have some difficulty building. Each source package is built on a single machine only, and the current machines are limited to = 1 GiB RAM I think so I expect heavy swapping takes place. I speculated some time ago (in a mail to the DSA list) that network-attached storage might help for low-powered buildds, but I didn't do any followup viability testing of this yet. I thought that a separate NAS (of any architecture) would have no particular limit on number of disks or RAM, should provide fault tolerance, and maybe help with provisioning too. Whereas current mipsel hardware may be limited to a single disk, perhaps not adequately cooled or designed for continuous running, without RAID or hot-swap, and either low in capacity or very slow (due to I/O latency) than could be achieved even over a 100Mbps link to dedicated storage hardware. During the wheezy freeze period, mipsel and others did develop large queues of (IIRC ~150) packages in Needs-Build state. That's something that having more (and reliable) buildds could help with even if the same spec as the existing ones. 4) I see there is a note about an 'opcode implementation error' for a mipsel porter box. Sounds like a new machine(s) is needed there as well. Could somebody point me at some data on the opcode issue (more out of interest really...). I suspect that might refer to this, quoting from OpenBSD[0] : Unfortunately, most of the Loongson 2F-based hardware available at that time suffers from serious problems in the processor's branch prediction logic, causing the system to freeze, for which errata information only exists in the Chinese documentation (chapter 15, missing from the English translation), the only English language information being an e-mail[1] on a toolchain mailing-list. [0]: http://www.openbsd.org/loongson.html [1]: https://sourceware.org/ml/binutils/2009-11/msg00387.html From the three types of machines I see you currently have I believe there are more modern versions of all of those, and possibly some others. I believe we will be able to locate hardware to solve the issues. I think Linux 3.2 detects and works around those bugs at least in kernel code, but looking at the output in dmesg may help to identify which boxes (if any) are affected. (I imagine it's a problem for userland binaries that were built before workarounds were added in binutils). Maybe the existing boxes were not affected, but it was a concern about acquiring newer Loongson 2F hardware? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5245fcfa.7040...@pyro.eu.org
Re: DSA concerns for jessie architectures
* Andreas Barth (a...@ayous.org) [130622 20:06]: Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. 2. We get the kernel team to accept the additional kernel config for 2e (I'm too lazy now to search for the bug report from ages ago, but the only difference needed to build kernels for our 2e-machines is an additional kernel config, no code changes necessary) 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. Currently mipsel is still marked as with DSA-concerns. Is the third option enough for DSA that the concerns are reasonably addressed for the moment (and the comment could be removed), or do we need to push on one of the other options as above? Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130816141958.ga3...@mails.so.argh.org
Re: DSA concerns for jessie architectures
On Fri, 16 Aug 2013, Andreas Barth wrote: Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. 2. We get the kernel team to accept the additional kernel config for 2e (I'm too lazy now to search for the bug report from ages ago, but the only difference needed to build kernels for our 2e-machines is an additional kernel config, no code changes necessary) 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. Currently mipsel is still marked as with DSA-concerns. Is the third option enough for DSA that the concerns are reasonably addressed for the moment (and the comment could be removed), or do we need to push on one of the other options as above? I think it's great that you are working on addressing the concerns, thanks again! Until we have deployed the machines mentioned you are currently it's still a concern however. Also, just two machines might be a bit few if we wand to replace eysler and eder. If we want to keep them then we also need to figure out something for their kernel. Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130816153402.gk1...@anguilla.noreply.org
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-release-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
Samuel Thibault, le Sun 30 Jun 2013 11:38:33 +0200, a écrit : lack of firewall support. Now that we use a userland driver for networking, it should be easy to interpose at least a simple BPF filter, I have added the task here: https://savannah.gnu.org/task/index.php?12723 debian-hurd, bug-hurd: anybody up for this? The eth0 interface is quite simple, plugging BPF into it should be easy. This was actually already done by Zheng Da some years ago in the incubator, named under eth-filter. It uses libpcap to parse input and output rules into BPF filters. I have improved it and imported it into the hurd package. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130728060001.go5...@type.wlan.youpi.perso.aquilenet.fr
Re: DSA concerns for jessie architectures
On Sun, Jul 21, 2013 at 21:06:31 +0200, Bernd Zeimetz wrote: 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. IIRC stadler and sompek are less stable than the others. And keep triggering unreproducible gcc ICEs. Seems to me the sparc port no longer has anybody working on it, and is on its last legs. I'm not sure it makes much sense to keep it in jessie. Cheers, Julien signature.asc Description: Digital signature
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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ec3137.1020...@bzed.de
Re: DSA concerns for jessie architectures
Martin Zobel-Helas, le Sat 22 Jun 2013 19:26:44 +0200, a écrit : * hurd: no puppet/ruby broken (for 3 months+); I guess this went out of our radar somehow, and can be fixed not too hardly. lack of firewall support. Now that we use a userland driver for networking, it should be easy to interpose at least a simple BPF filter, I have added the task here: https://savannah.gnu.org/task/index.php?12723 debian-hurd, bug-hurd: anybody up for this? The eth0 interface is quite simple, plugging BPF into it should be easy. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130630093833.ge5...@type.youpi.perso.aquilenet.fr
Re: DSA concerns for jessie architectures
Samuel Thibault, le Sun 30 Jun 2013 11:38:33 +0200, a écrit : Martin Zobel-Helas, le Sat 22 Jun 2013 19:26:44 +0200, a écrit : * hurd: no puppet/ruby broken (for 3 months+); I guess this went out of our radar somehow, and can be fixed not too hardly. Actually puppet is installable. debian-hurd: can somebody who actually knows how to make it work test it and report bugs if any? Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130630094334.gg5...@type.youpi.perso.aquilenet.fr
Re: DSA concerns for jessie architectures
On Sat, 22 Jun 2013, Kurt Roeckx wrote: They currently seem to be running linux-image-2.6.32-ferroceon 2.6.32-1+buildd41 Did someone try the mv78xx0 kernel on those yet? Lack of out of band access makes trying on these impossible for us. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624083606.ga15...@anguilla.noreply.org
Re: DSA concerns for jessie architectures (mips*)
On Sat, 22 Jun 2013, Andreas Barth wrote: * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. Also, if we buy more mipsel machines we could convert the mipsel swarms to mips ones (and so replace broken machines, see below) - mostly depends on how urgent you think this is. If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. AIUI these machines have a maximum memory of only 1GB. That's probably OK for now but might be problematic in the long term. 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. When do you expect them to be usable? If not any time soon then maybe we should try to get a couple of loongson 2f machines. Would four machines of this type be sufficient to replace all our exist swarm and 2e machines as buildds? If so, should we just get 5 (4buildd+1porterbox)? Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624085150.gc15...@anguilla.noreply.org
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wea...@debian.org wrote: On Sat, 22 Jun 2013, Andreas Barth wrote: * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. Also, if we buy more mipsel machines we could convert the mipsel swarms to mips ones (and so replace broken machines, see below) - mostly depends on how urgent you think this is. If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. AIUI these machines have a maximum memory of only 1GB. That's probably OK for now but might be problematic in the long term. 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. When do you expect them to be usable? If not any time soon then maybe we should try to get a couple of loongson 2f machines. Would four machines of this type be sufficient to replace all our exist swarm and 2e machines as buildds? If so, should we just get 5 (4buildd+1porterbox)? We have two 3A notebooks that Lemote donated directly to the student and mentor of the MIPS N32/N64 port GSoC project, the only blocking issue to use them as official buildd is supporting patches aren't accepted by upstream, otherwise they are working fine. A self-built version of Linux 3.6 with Lemote patches is used right now. It was a 4-core SMP system with 2GB RAM installed (upgrade seems hard for the notebook, though the CPU itself supports more), and was tested to be quite stable when doing test build of some mips64el packages. The stability of hardware is somewhat temperature-sensitive, which means when they are running with full parallel building load, they are only tested to be stable in a server room cooling to 17°C, but hang once every 1 or 2 days when put in a room of 25°C. There is no remote management facility available to the notebook, dunno for development boards or servers. We could ask Lemote for donation if we want those machines to provide build power of Debian, and I volunteer to help if needed. Regards, Aron -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w55dxzd7sz3r2kfz8cr2+yyrriqpvomlfvykrqx64k...@mail.gmail.com
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Calvium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6HMxq_1Myr0CRsQ8pHMsv04KFU_S9pRdUwD=j2mvrs...@mail.gmail.com
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 5:29 PM, Paul Wise p...@debian.org wrote: On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Calvium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen I believe Cavium's David Daney is on debian-mips, we can talk to him to see if there is any possibility of making donation. As for the GSoC project, the student seems to not get access to the hardware Cavium offered, nor the main mentor (Cc'ed), so there is no feedback about stability/other stuff about those hardware. Regards, Aron -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6v_b-veo1ep6nmssxuqxpvyo6yzqb+u7bhtbreb+y...@mail.gmail.com
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 05:34:42PM +0800, Aron Xu wrote: On Mon, Jun 24, 2013 at 5:29 PM, Paul Wise p...@debian.org wrote: On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Cavium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen I believe Cavium's David Daney is on debian-mips, we can talk to him to see if there is any possibility of making donation. It would be wonderful to refresh our mips environment as our current mips environment is not healthy. We gladly accept hardware donations but would appreciate if the donated hardware be equivalent to that available commercially. Of the four existing donated boxen that we operate at ubcece, one has never worked (fatally defective) and two are very unreliable. We also had to modify them to boot on power-up. Do the Cavium machines have any remote management features (similar to Sun ALOM, HP iLO, Dell DRAC) that allow access to a serial console and to power management? Alternatively, can they be configured to power on after a power loss so we can attach them to a remotely controlled power distribution unit? Do they boot from local storage? Any help you can provide in securing newer mips equipment is appreciated. We MUST refresh our mips environment if we wish to continue offering a mips port. As mentioned, we will need a number of machines to satisfy the various requirements (geographically distributed buildd machines, accessible porter machine(s), etc.). As for the GSoC project, the student seems to not get access to the hardware Cavium offered, nor the main mentor (Cc'ed), so there is no feedback about stability/other stuff about those hardware. Why were the GSoC students unable to obtain access to the hardware? Thanks, Luca -- Luca Filipozzi // Debian System Administration Team http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624140923.ga21...@emyr.net
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 10:09 PM, Luca Filipozzi lfili...@debian.org wrote: On Mon, Jun 24, 2013 at 05:34:42PM +0800, Aron Xu wrote: On Mon, Jun 24, 2013 at 5:29 PM, Paul Wise p...@debian.org wrote: On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Cavium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen I believe Cavium's David Daney is on debian-mips, we can talk to him to see if there is any possibility of making donation. It would be wonderful to refresh our mips environment as our current mips environment is not healthy. We gladly accept hardware donations but would appreciate if the donated hardware be equivalent to that available commercially. Of the four existing donated boxen that we operate at ubcece, one has never worked (fatally defective) and two are very unreliable. We also had to modify them to boot on power-up. Do the Cavium machines have any remote management features (similar to Sun ALOM, HP iLO, Dell DRAC) that allow access to a serial console and to power management? Alternatively, can they be configured to power on after a power loss so we can attach them to a remotely controlled power distribution unit? Do they boot from local storage? Any help you can provide in securing newer mips equipment is appreciated. We MUST refresh our mips environment if we wish to continue offering a mips port. As mentioned, we will need a number of machines to satisfy the various requirements (geographically distributed buildd machines, accessible porter machine(s), etc.). As for the GSoC project, the student seems to not get access to the hardware Cavium offered, nor the main mentor (Cc'ed), so there is no feedback about stability/other stuff about those hardware. Why were the GSoC students unable to obtain access to the hardware? David once said he has prepared the machine, but we haven't got response from him when asking for shell access. Also, are you interested in asking Lemote for there Loongson 3A machines? Regards, Aron -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4BvXT=yYidQ3BP6Q-a6vJa1_Dsd=jaq9x5wpjctfb...@mail.gmail.com
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 10:36:20PM +0800, Aron Xu wrote: On Mon, Jun 24, 2013 at 10:09 PM, Luca Filipozzi lfili...@debian.org wrote: On Mon, Jun 24, 2013 at 05:34:42PM +0800, Aron Xu wrote: On Mon, Jun 24, 2013 at 5:29 PM, Paul Wise p...@debian.org wrote: On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Cavium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen I believe Cavium's David Daney is on debian-mips, we can talk to him to see if there is any possibility of making donation. It would be wonderful to refresh our mips environment as our current mips environment is not healthy. We gladly accept hardware donations but would appreciate if the donated hardware be equivalent to that available commercially. Of the four existing donated boxen that we operate at ubcece, one has never worked (fatally defective) and two are very unreliable. We also had to modify them to boot on power-up. Do the Cavium machines have any remote management features (similar to Sun ALOM, HP iLO, Dell DRAC) that allow access to a serial console and to power management? Alternatively, can they be configured to power on after a power loss so we can attach them to a remotely controlled power distribution unit? Do they boot from local storage? Any help you can provide in securing newer mips equipment is appreciated. We MUST refresh our mips environment if we wish to continue offering a mips port. As mentioned, we will need a number of machines to satisfy the various requirements (geographically distributed buildd machines, accessible porter machine(s), etc.). As for the GSoC project, the student seems to not get access to the hardware Cavium offered, nor the main mentor (Cc'ed), so there is no feedback about stability/other stuff about those hardware. Why were the GSoC students unable to obtain access to the hardware? David once said he has prepared the machine, but we haven't got response from him when asking for shell access. That's unfortunate. Also, are you interested in asking Lemote for there Loongson 3A machines? Sure. My objective is to get functioning equipment so that the mips port is supported. I'm prepared to receive a mix of equipment from a number of vendors or just from one... as long the requirements (commercially available, warranty / support, out of band management, etc.) are met, I'm not partial one way or the other. The only challenge I see with the 3A machines is the comment about needing a lot of energy/time to get a working kernel... that would be a problem for us, obviously. Thanks, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624153448.ga26...@emyr.net
Re: DSA concerns for jessie architectures
On Sat, 2013-06-22 at 19:26 +0200, Martin Zobel-Helas wrote: 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. [...] 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: I've folded these in to an initial matrix for jessie, assuming that any architecture which was not explicitly mentioned is not currently a concern for DSA. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1372098990.4554.5.ca...@jacala.jungle.funky-badger.org
Re: DSA concerns for jessie architectures
]] Adam D. Barratt I've folded these in to an initial matrix for jessie, assuming that any architecture which was not explicitly mentioned is not currently a concern for DSA. Thanks, much appreciated! -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2wqpjxpew@rahvafeir.err.no
Re: DSA concerns for jessie architectures (mips*)
On Mon, 24 Jun 2013, Andreas Barth wrote: So, let's perhaps look at the situation again in two months and see where we are and if it's worth to do something else inbetween or not. Ok, please report back in two months time. Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624194626.gn15...@anguilla.noreply.org
Re: DSA concerns for jessie architectures (mips*)
On 06/24/2013 07:36 AM, Aron Xu wrote: On Mon, Jun 24, 2013 at 10:09 PM, Luca Filipozzi lfili...@debian.org wrote: On Mon, Jun 24, 2013 at 05:34:42PM +0800, Aron Xu wrote: On Mon, Jun 24, 2013 at 5:29 PM, Paul Wise p...@debian.org wrote: On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Cavium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen I believe Cavium's David Daney is on debian-mips, we can talk to him to see if there is any possibility of making donation. It would be wonderful to refresh our mips environment as our current mips environment is not healthy. We gladly accept hardware donations but would appreciate if the donated hardware be equivalent to that available commercially. Of the four existing donated boxen that we operate at ubcece, one has never worked (fatally defective) and two are very unreliable. We also had to modify them to boot on power-up. Do the Cavium machines have any remote management features (similar to Sun ALOM, HP iLO, Dell DRAC) that allow access to a serial console and to power management? Alternatively, can they be configured to power on after a power loss so we can attach them to a remotely controlled power distribution unit? Do they boot from local storage? Any help you can provide in securing newer mips equipment is appreciated. We MUST refresh our mips environment if we wish to continue offering a mips port. As mentioned, we will need a number of machines to satisfy the various requirements (geographically distributed buildd machines, accessible porter machine(s), etc.). As for the GSoC project, the student seems to not get access to the hardware Cavium offered, nor the main mentor (Cc'ed), so there is no feedback about stability/other stuff about those hardware. Why were the GSoC students unable to obtain access to the hardware? David once said he has prepared the machine, but we haven't got response from him when asking for shell access. The good news: Debian GNU/Linux 6.0 ebh5600-dd ttyS0 ebh5600-dd login: root Password: Last login: Tue Jun 4 11:25:39 PDT 2013 on ttyS0 Linux ebh5600-dd 3.9.4 #18 SMP PREEMPT Tue Jun 4 11:18:44 PDT 2013 mips64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@ebh5600-dd:~# uptime 15:11:53 up 20 days, 3:45, 1 user, load average: 0.00, 0.01, 0.05 root@ebh5600-dd:~# df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 910G 26G 838G 3% / tmpfs 2.0G 0 2.0G 0% /lib/init/rw udev 10M 24K 10M 1% /dev tmpfs 2.0G 0 2.0G 0% /dev/shm The slightly less good news: I am leaving on vacation until July 13, so I cannot get the thing on a public network until I get back. Also I don't recall any requests for shell access after the initial discussions about the system David Daney Also, are you interested in asking Lemote for there Loongson 3A machines? Regards, Aron -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c8b5f7.20...@gmail.com
Re: DSA concerns for jessie architectures (mips*)
On Mon, Jun 24, 2013 at 02:11:19PM -0700, David Daney wrote: On 06/24/2013 07:36 AM, Aron Xu wrote: On Mon, Jun 24, 2013 at 10:09 PM, Luca Filipozzi lfili...@debian.org wrote: On Mon, Jun 24, 2013 at 05:34:42PM +0800, Aron Xu wrote: On Mon, Jun 24, 2013 at 5:29 PM, Paul Wise p...@debian.org wrote: On Mon, Jun 24, 2013 at 4:51 PM, Peter Palfrader wrote: If our existing eight-year old hardware is the only mips machines we can reasonably get then that doesn't bode well for mips. We don't think relying on the SWARMs (alone) is an option. Perhaps Cavium will interested in providing newer hardware now that there is a MIPS N64 GSoC project underway. They offered some decent hardware last year in association with such a port: http://lists.debian.org/debian-mips/2012/02/msg1.html http://wiki.debian.org/SummerOfCode2013/Projects#MIPS_N32.2FN64_ABI_port http://wiki.debian.org/SummerOfCode2013/StudentApplications/EleanorChen I believe Cavium's David Daney is on debian-mips, we can talk to him to see if there is any possibility of making donation. It would be wonderful to refresh our mips environment as our current mips environment is not healthy. We gladly accept hardware donations but would appreciate if the donated hardware be equivalent to that available commercially. Of the four existing donated boxen that we operate at ubcece, one has never worked (fatally defective) and two are very unreliable. We also had to modify them to boot on power-up. Do the Cavium machines have any remote management features (similar to Sun ALOM, HP iLO, Dell DRAC) that allow access to a serial console and to power management? Alternatively, can they be configured to power on after a power loss so we can attach them to a remotely controlled power distribution unit? Do they boot from local storage? Any help you can provide in securing newer mips equipment is appreciated. We MUST refresh our mips environment if we wish to continue offering a mips port. As mentioned, we will need a number of machines to satisfy the various requirements (geographically distributed buildd machines, accessible porter machine(s), etc.). As for the GSoC project, the student seems to not get access to the hardware Cavium offered, nor the main mentor (Cc'ed), so there is no feedback about stability/other stuff about those hardware. Why were the GSoC students unable to obtain access to the hardware? David once said he has prepared the machine, but we haven't got response from him when asking for shell access. The good news: Debian GNU/Linux 6.0 ebh5600-dd ttyS0 ebh5600-dd login: root Password: Last login: Tue Jun 4 11:25:39 PDT 2013 on ttyS0 Linux ebh5600-dd 3.9.4 #18 SMP PREEMPT Tue Jun 4 11:18:44 PDT 2013 mips64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@ebh5600-dd:~# uptime 15:11:53 up 20 days, 3:45, 1 user, load average: 0.00, 0.01, 0.05 root@ebh5600-dd:~# df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 910G 26G 838G 3% / tmpfs 2.0G 0 2.0G 0% /lib/init/rw udev 10M 24K 10M 1% /dev tmpfs 2.0G 0 2.0G 0% /dev/shm The slightly less good news: I am leaving on vacation until July 13, so I cannot get the thing on a public network until I get back. That's great! Happy to continue the conversation regarding these machines when you return. Have a good vacation. Also I don't recall any requests for shell access after the initial discussions about the system Ah! Seems like some miscommunication or misunderstanding. Thanks for correcting the record. Let's chat when you get back, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130624215058.ga...@emyr.net
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) [130622 19:27]: [please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] According to lists.d.o the status of debian-ports is: dead list. It at least isn't the list for all porters to read. * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. We're about to get newer machines which are both stable and fast (the two instable machines are pre-alpha versions, and should be replaced; but this is not an architecture-topic but rather an machine-topic). Also, if we buy more mipsel machines we could convert the mipsel swarms to mips ones (and so replace broken machines, see below) - mostly depends on how urgent you think this is. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. 2. We get the kernel team to accept the additional kernel config for 2e (I'm too lazy now to search for the bug report from ages ago, but the only difference needed to build kernels for our 2e-machines is an additional kernel config, no code changes necessary) 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130622180631.gy28...@mails.so.argh.org
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-release-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-release-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
Re: DSA concerns for jessie architectures
On Sat, Jun 22, 2013 at 09:21:29PM +0200, Arnaud Patard wrote: Martin Zobel-Helas zo...@debian.org writes: * 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 ? There is no mx78xx0 kernel in the Debian archive as far as I can see. There is a linux-image-3.2.0-4-iop32x however. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130622194113.ga...@roeckx.be
Re: DSA concerns for jessie architectures
Kurt Roeckx k...@roeckx.be writes: On Sat, Jun 22, 2013 at 09:21:29PM +0200, Arnaud Patard wrote: Martin Zobel-Helas zo...@debian.org writes: * 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 ? There is no mx78xx0 kernel in the Debian archive as far as I can see. There is a linux-image-3.2.0-4-iop32x however. Sorry, I made a typo. It's mv78xx0: http://packages.debian.org/wheezy/linux-image-3.2.0-4-mv78xx0 Arnaud -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877ghmaq0i@lebrac.rtp-net.org
Re: DSA concerns for jessie architectures
On Sat, Jun 22, 2013 at 09:45:17PM +0200, Arnaud Patard wrote: Kurt Roeckx k...@roeckx.be writes: On Sat, Jun 22, 2013 at 09:21:29PM +0200, Arnaud Patard wrote: Martin Zobel-Helas zo...@debian.org writes: * 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 ? There is no mx78xx0 kernel in the Debian archive as far as I can see. There is a linux-image-3.2.0-4-iop32x however. Sorry, I made a typo. It's mv78xx0: http://packages.debian.org/wheezy/linux-image-3.2.0-4-mv78xx0 They currently seem to be running linux-image-2.6.32-ferroceon 2.6.32-1+buildd41 Did someone try the mv78xx0 kernel on those yet? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130622195145.ga1...@roeckx.be
