Re: Bits from the release team (freeze time line)
Am 27.12.2013 03:16, schrieb Steve McIntyre: > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: >> >> On a related note, DSA have concerns with the current arm* and mips* >> hardware. While there have been promises of new hardware to replace >> some of the current buggy machines, the offers are currently not >> leading to concrete results. Porters of these architectures should >> contact DSA and figure out a solution to avoid a situation where an >> architecture is in jeopardy due to insufficient buildd or porter >> machines. > > Ummm, WTH? We've been looking into possible *upgrades* to replace some > of the armel and armhf buildds with faster and (ideally) more easily > managed machines, but I *seriously* disagree with any suggestion that > the current machines are "buggy". I can see that with the some of the > known-buggy mips* machines, but I don't accept that the arm* machines > could/should be classified this way. openjdk-6 fails to build on armel, because the testsuite hangs / times out. Not just once, but this seems to be a common failure. Builds fine on ipa.debian.net. Matthias -- 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/52f7b980.9010...@debian.org
Re: Bits from the release team (freeze time line)
On 2013-12-28 15:02, Antonio Terceiro wrote: > On Fri, Dec 27, 2013 at 09:47:41PM +0100, Niels Thykier wrote: >> On 2013-12-27 21:08, Antonio Terceiro wrote: >>> Hi, >>> >>> On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: We are happy to use results from other automated tests (like autopkgtest [DEP8]) in the same way, as soon as someone runs them on the entire archive and gives us a machine-readable list of the results. [DEP8] http://dep.debian.net/deps/dep8/ >>> >>> I am playing with something for this. It's in a very initial stage, so >>> take it with a grain of salt: >>> >>> http://dep8.debian.net/ >>> >>> Please have a look at http://dep8.debian.net/data/packages.json and let >>> me know what other information you would need there. >>> >> >> Hi Antonio, >> >> Thanks for looking into it. At first glance, the exported json looks >> good! I am a bit curious on how we will distinguish a "has-no-tests" >> from a "not-tested-yet" case. > Hi, Sorry, forgot to follow up on this. > My idea was not providing any data at all for packages that do not have > DEP-8 tests. > Okay, will packages then be in a "await testing"-state or so for packages with autopkgtest that are yet to be scheduled? >> Does your runner support retesting packages when a dependency is >> updated? E.g. if a new version of APT is uploaded, will it schedule the >> tests for python-apt (assuming the latter has DEP-8 tests)[1]? It is by >> no means a blocker, but I know there has been interest in the feature. > > That was actually one of my initial assumptions, so the runner was > designed around this feature. It will run tests for a package again when > there is a new version of the package or of any package in it dependency > chain. > Great. :) > One concern I have, though: reusing your example, suppose there are new > versions of both Python and APT, and python-apt tests break. How would > we know which of them is to blame? Will both of them be blocked from > migrating to testing? > I would say both, until we either get a manual judgement. Of course, if a future upload of one of the packages makes the problem go ahead, they can both be "unblamed" (provided that they are not blamed for another package). >> Before we can integrate it, we will probably need some way of fetching >> it securely (e.g. via https or ssh). > > no problem, it should be trivial to put https up. > Great. Looking forward to seeing this in action. :) ~Niels -- 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/52d12930.2000...@thykier.net
Re: Bits from the release team (freeze time line)
On 27/12/13 11:53, Peter Palfrader wrote: On Fri, 27 Dec 2013, Steve McIntyre wrote: On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: On a related note, DSA have concerns with the current arm* and mips* hardware. While there have been promises of new hardware to replace some of the current buggy machines, the offers are currently not leading to concrete results. Porters of these architectures should contact DSA and figure out a solution to avoid a situation where an architecture is in jeopardy due to insufficient buildd or porter machines. Ummm, WTH? We've been looking into possible *upgrades* to replace some of the armel and armhf buildds with faster and (ideally) more easily managed machines, but I *seriously* disagree with any suggestion that the current machines are "buggy". I can see that with the some of the known-buggy mips* machines, but I don't accept that the arm* machines could/should be classified this way. I think I agree with you here. Mips* is hard to come by and a real problem. Arm* is a slightly smaller issue because we have no way to remotely power cycle the machines, and because a couple of them have died or developed disk issues. Other than that they seem to be fine. Eventuallly replacing the existing HW with newer stuff might still be nice, but it is - at least IMO - not a blocker. There are a number of companies offering free or very cheap indeed hosting for Raspberry Pis that includes remote power cycling. Can Debian make use of these services by providing more powerful ARM hardware instead of the Pis and making use of the existing remote power systems? Please note I'm in no way suggesting that a Pi is a useful buildd system. The two companies I came across where: http://blog.raspberrycolocation.com/ http://www.edis.at/en/server/colocation/austria/raspberrypi/ In terms of hardware I'm currently experimenting with a Cubietruck which is a dual core A20 (ARMv7) with 2gb of RAM, a SATA port, gig ethernet and a serial console for just under $100. This provides at least twice as much RAM as the current buidd's that I can see the data on from the status page. With a bit of work you can run mainline kernels on it but not with current kernels from Debian, Jessie and Wheezy userspace just work with both mainline and the 3.4 kernel from the sunix people. -- Tim Fletcher -- 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/52c1c78d.6010...@night-shade.org.uk
Re: Bits from the release team (freeze time line)
Hi, First of all thanks for your answer, it's really appreciated to have more details. On Sat, Dec 28, 2013 at 07:51:21PM +, Luca Filipozzi wrote: > On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote: > > On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: > > > On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > > > > However, using words like "known-buggy mips* machines" is just FUD > > > > against the mips*-ports, and plainly inacceptable, so please stop > > > > doing that. (For reference, there is no mipsel machine which has > > > > hardware bugs affecting daily operations. There are two mips machines > > > > which are pre-series and are not as stable as I wish, but as builddadm > > > > I was more occupied recently with arm* machines not stable then with > > > > mips machines not stable. This all doesn't mean I think nothing should > > > > be changed, but please do not FUD against mips* (or any other > > > > architecture).) > > > > > > builddadm does not keep the machines running, DSA does. ball is ancient, > > > > I agree that ball, rem and mayer are indeed ancient. That said despite > > their age, they are about twice faster as armel and armhf build daemons > > for building for example libreoffice or qt4-x11. Does they cause any > > problem from the administration point of view? > > The mipsel machines are working reliably but are probably not replacable if > one > dies. They could use more memory and it'd be helpful if they booted from SATA > (so that we can source new disks if/when the current PATA disks die). For the record, I have a ready to use swarm system that can be used as a spare if needed and shipped from France, plus a few PATA disks. It clearly don't fix the issue, but it might be useful in case something happen in the very short term. We are currently working on long term a solution for both mips and mipsel. You should get some news about the mipsel one very soon. > > > corelli and gabrielli are unstable under load and lucatelli does need > > > occasional reboots too, IIRC. > > > > I agree that corelli and gabrielli are unstable, though it's clearly not > > related with the load. I am not aware of any issue with lucatelli, do > > you have some more details? > > Of the four Movidis mips machines that I received at ubcece, one was dead on > arrival, > two have proven unreliable and only one is stable. All four were received > with > notes indicating that their eth0 was faulty, suggesting that they failed QA. > The one that is stable is often so overloaded that we can't actually run any > of > our regular system administration tasks since the entire system is just > thrashing > (because there are 2 buildd instances running concurrently, and g++ with large > parallelism just eats memory) I have reduced a bit the parallelism on lucatelli, I hope it will fix/reduce the problem. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20131229204910.gh15...@hall.aurel32.net
Re: Bits from the release team (freeze time line)
On Sat, Dec 28, 2013 at 07:51:21PM +, Luca Filipozzi wrote: > On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote: > > On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: > > > On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > I think that our core point is that we need the porter community (internal and > external) to source production-quality buildd hardware with requisite out of > band > managment (console & power, minimum). DSA is happy to organize the purchase > of hardware, if we're pointed to an acceptable vendor. Having clear DSA requirements for buildds and/or porter boxen would likely go a long way to improving the available build infrastructure. Especially if it was accompanied by documentation on; - How to become a porter box contributor/maintainer - DSA process for internal and external porter boxen - Contributing CPU cycles to Debian in general Cheers, Jeremiah -- 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/20131229151052.GD12111@sylph
Re: Bits from the release team (freeze time line)
Hi, On Sat Dec 28, 2013 at 19:51:21 +, Luca Filipozzi wrote: > On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote: > > On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: > > > On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > > > > However, using words like "known-buggy mips* machines" is just FUD > > > > against the mips*-ports, and plainly inacceptable, so please stop > > > > doing that. (For reference, there is no mipsel machine which has > > > > hardware bugs affecting daily operations. There are two mips machines > > > > which are pre-series and are not as stable as I wish, but as builddadm > > > > I was more occupied recently with arm* machines not stable then with > > > > mips machines not stable. This all doesn't mean I think nothing should > > > > be changed, but please do not FUD against mips* (or any other > > > > architecture).) > > > > > > builddadm does not keep the machines running, DSA does. ball is ancient, > > > > I agree that ball, rem and mayer are indeed ancient. That said despite > > their age, they are about twice faster as armel and armhf build daemons > > for building for example libreoffice or qt4-x11. Does they cause any > > problem from the administration point of view? > > The mipsel machines are working reliably but are probably not replacable if > one > dies. They could use more memory and it'd be helpful if they booted from SATA > (so that we can source new disks if/when the current PATA disks die). also, ball and rem currently sit in a a 4U case, which occupies (together with wiggum.debconf.org) 1/3 of the full rack we have at man-da. If we could get better boxes (or replace the machines at all), that would be nice. Cheers, Martin -- Martin Zobel-Helas Debian 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 -- 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/20131228200013.gb3...@ftbfs.de
Re: Bits from the release team (freeze time line)
On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote: > On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: > > On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > > > However, using words like "known-buggy mips* machines" is just FUD > > > against the mips*-ports, and plainly inacceptable, so please stop > > > doing that. (For reference, there is no mipsel machine which has > > > hardware bugs affecting daily operations. There are two mips machines > > > which are pre-series and are not as stable as I wish, but as builddadm > > > I was more occupied recently with arm* machines not stable then with > > > mips machines not stable. This all doesn't mean I think nothing should > > > be changed, but please do not FUD against mips* (or any other > > > architecture).) > > > > builddadm does not keep the machines running, DSA does. ball is ancient, > > I agree that ball, rem and mayer are indeed ancient. That said despite > their age, they are about twice faster as armel and armhf build daemons > for building for example libreoffice or qt4-x11. Does they cause any > problem from the administration point of view? The mipsel machines are working reliably but are probably not replacable if one dies. They could use more memory and it'd be helpful if they booted from SATA (so that we can source new disks if/when the current PATA disks die). > > corelli and gabrielli are unstable under load and lucatelli does need > > occasional reboots too, IIRC. > > I agree that corelli and gabrielli are unstable, though it's clearly not > related with the load. I am not aware of any issue with lucatelli, do > you have some more details? Of the four Movidis mips machines that I received at ubcece, one was dead on arrival, two have proven unreliable and only one is stable. All four were received with notes indicating that their eth0 was faulty, suggesting that they failed QA. The one that is stable is often so overloaded that we can't actually run any of our regular system administration tasks since the entire system is just thrashing (because there are 2 buildd instances running concurrently, and g++ with large parallelism just eats memory) I think that our core point is that we need the porter community (internal and external) to source production-quality buildd hardware with requisite out of band managment (console & power, minimum). DSA is happy to organize the purchase of hardware, if we're pointed to an acceptable vendor. That said, if the external hardware community is interested in having Debian ported to their architecture, then we should not need to purchase hardware. Nor should we need to accept buggy pre-production hardware. So, our concern remains: buildd and porter boxen for the mips* and arm* need some attention from the porter community. Let's work together to get some newer, more capable, bug-free hardware lined up. Maybe even "under warranty" :) 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/20131228195121.ga8...@emyr.net
Re: Bits from the release team (freeze time line)
On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: > On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > > However, using words like "known-buggy mips* machines" is just FUD > > against the mips*-ports, and plainly inacceptable, so please stop > > doing that. (For reference, there is no mipsel machine which has > > hardware bugs affecting daily operations. There are two mips machines > > which are pre-series and are not as stable as I wish, but as builddadm > > I was more occupied recently with arm* machines not stable then with > > mips machines not stable. This all doesn't mean I think nothing should > > be changed, but please do not FUD against mips* (or any other > > architecture).) > > builddadm does not keep the machines running, DSA does. ball is ancient, I agree that ball, rem and mayer are indeed ancient. That said despite their age, they are about twice faster as armel and armhf build daemons for building for example libreoffice or qt4-x11. Does they cause any problem from the administration point of view? > corelli and gabrielli are unstable under load and lucatelli does need > occasional reboots too, IIRC. I agree that corelli and gabrielli are unstable, though it's clearly not related with the load. I am not aware of any issue with lucatelli, do you have some more details? Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20131228181425.gb15...@hall.aurel32.net
Re: Bits from the release team (freeze time line)
On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > However, using words like "known-buggy mips* machines" is just FUD > against the mips*-ports, and plainly inacceptable, so please stop > doing that. (For reference, there is no mipsel machine which has > hardware bugs affecting daily operations. There are two mips machines > which are pre-series and are not as stable as I wish, but as builddadm > I was more occupied recently with arm* machines not stable then with > mips machines not stable. This all doesn't mean I think nothing should > be changed, but please do not FUD against mips* (or any other > architecture).) builddadm does not keep the machines running, DSA does. ball is ancient, corelli and gabrielli are unstable under load and lucatelli does need occasional reboots too, IIRC. But mips and mipsel might not actually be the same bucket you'd want to use, that seems to be the key takeaway here. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bits from the release team (freeze time line)
On Fri, Dec 27, 2013 at 09:47:41PM +0100, Niels Thykier wrote: > On 2013-12-27 21:08, Antonio Terceiro wrote: > > Hi, > > > > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: > >> We are happy to use results from other automated tests (like > >> autopkgtest [DEP8]) in the same way, as soon as someone runs them on > >> the entire archive and gives us a machine-readable list of the > >> results. > >> > >> [DEP8] http://dep.debian.net/deps/dep8/ > > > > I am playing with something for this. It's in a very initial stage, so > > take it with a grain of salt: > > > > http://dep8.debian.net/ > > > > Please have a look at http://dep8.debian.net/data/packages.json and let > > me know what other information you would need there. > > > > Hi Antonio, > > Thanks for looking into it. At first glance, the exported json looks > good! I am a bit curious on how we will distinguish a "has-no-tests" > from a "not-tested-yet" case. My idea was not providing any data at all for packages that do not have DEP-8 tests. > Does your runner support retesting packages when a dependency is > updated? E.g. if a new version of APT is uploaded, will it schedule the > tests for python-apt (assuming the latter has DEP-8 tests)[1]? It is by > no means a blocker, but I know there has been interest in the feature. That was actually one of my initial assumptions, so the runner was designed around this feature. It will run tests for a package again when there is a new version of the package or of any package in it dependency chain. One concern I have, though: reusing your example, suppose there are new versions of both Python and APT, and python-apt tests break. How would we know which of them is to blame? Will both of them be blocked from migrating to testing? > Before we can integrate it, we will probably need some way of fetching > it securely (e.g. via https or ssh). no problem, it should be trivial to put https up. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Bits from the release team (freeze time line)
On 2013-12-27 21:08, Antonio Terceiro wrote: > Hi, > > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: >> We are happy to use results from other automated tests (like >> autopkgtest [DEP8]) in the same way, as soon as someone runs them on >> the entire archive and gives us a machine-readable list of the >> results. >> >> [DEP8] http://dep.debian.net/deps/dep8/ > > I am playing with something for this. It's in a very initial stage, so > take it with a grain of salt: > > http://dep8.debian.net/ > > Please have a look at http://dep8.debian.net/data/packages.json and let > me know what other information you would need there. > Hi Antonio, Thanks for looking into it. At first glance, the exported json looks good! I am a bit curious on how we will distinguish a "has-no-tests" from a "not-tested-yet" case. Does your runner support retesting packages when a dependency is updated? E.g. if a new version of APT is uploaded, will it schedule the tests for python-apt (assuming the latter has DEP-8 tests)[1]? It is by no means a blocker, but I know there has been interest in the feature. Before we can integrate it, we will probably need some way of fetching it securely (e.g. via https or ssh). Great work so far and thanks for looking into it! ~Niels [1] If python-apt's tests were to fail in that case, APT would be blamed for it by default as APT might have broken backwards compatibility. -- 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/52bde76d.6030...@thykier.net
Re: Bits from the release team (freeze time line)
Hi, On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: > We are happy to use results from other automated tests (like > autopkgtest [DEP8]) in the same way, as soon as someone runs them on > the entire archive and gives us a machine-readable list of the > results. > > [DEP8] http://dep.debian.net/deps/dep8/ I am playing with something for this. It's in a very initial stage, so take it with a grain of salt: http://dep8.debian.net/ Please have a look at http://dep8.debian.net/data/packages.json and let me know what other information you would need there. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Bits from the release team (freeze time line)
On Fri, 27 Dec 2013 12:53:32 +0100 Peter Palfrader wrote: > Arm* is a slightly smaller issue because we have no way to remotely > power cycle the machines Linaro may be able to help here. We've developed software to allow remote interaction with a selection of APC PDU units and this is routinely used in LAVA when boards fail to soft reboot within a timeout, leading to a fully automated power cycle with configurable delays. It would need the purchase of a suitable APC unit (older models work, support up to 8 boards and can cost £30-50 each, newer 0U rack based PDUs are supported as well) and changes in the lab to connect the power supply to each board into the PDU instead of directly into the mains. The software is designed for use only inside trusted networks and has no authentication support, so it would need to run behind SSH or some other authentication layer. https://git.linaro.org/people/matthew.hart/lavapdu.git I've done some rudimentary packaging but it's alpha software currently, although in routine production use with LAVA. https://git.linaro.org/people/neil.williams/lavapdu.git The software is intended to be extensible to other APC units as the control interface menus have a common structure, but small tweaks may be needed for some units. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Bits from the release team (freeze time line)
* Steve McIntyre (st...@einval.com) [131227 03:17]: > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: > > > >On a related note, DSA have concerns with the current arm* and mips* > >hardware. While there have been promises of new hardware to replace > >some of the current buggy machines, the offers are currently not > >leading to concrete results. Porters of these architectures should > >contact DSA and figure out a solution to avoid a situation where an > >architecture is in jeopardy due to insufficient buildd or porter > >machines. > > Ummm, WTH? We've been looking into possible *upgrades* to replace some > of the armel and armhf buildds with faster and (ideally) more easily > managed machines, but I *seriously* disagree with any suggestion that > the current machines are "buggy". I can see that with the some of the > known-buggy mips* machines, but I don't accept that the arm* machines > could/should be classified this way. Sorry, but I *seriously* disagree with this statement. If we apply common standards (and I think we should), then either arm* and mips* have hardware issues or none of them. On all those architectures we speak about build power and the options to refresh hardware, and looking at buildd.d.o it doesn't look like mips* does worse by far than arm, but rather the other way. However, using words like "known-buggy mips* machines" is just FUD against the mips*-ports, and plainly inacceptable, so please stop doing that. (For reference, there is no mipsel machine which has hardware bugs affecting daily operations. There are two mips machines which are pre-series and are not as stable as I wish, but as builddadm I was more occupied recently with arm* machines not stable then with mips machines not stable. This all doesn't mean I think nothing should be changed, but please do not FUD against mips* (or any other architecture).) 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/20131227131907.gg16...@mails.so.argh.org
Re: Bits from the release team (freeze time line)
On Fri, 27 Dec 2013, Steve McIntyre wrote: > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: > > > >On a related note, DSA have concerns with the current arm* and mips* > >hardware. While there have been promises of new hardware to replace > >some of the current buggy machines, the offers are currently not > >leading to concrete results. Porters of these architectures should > >contact DSA and figure out a solution to avoid a situation where an > >architecture is in jeopardy due to insufficient buildd or porter > >machines. > > Ummm, WTH? We've been looking into possible *upgrades* to replace some > of the armel and armhf buildds with faster and (ideally) more easily > managed machines, but I *seriously* disagree with any suggestion that > the current machines are "buggy". I can see that with the some of the > known-buggy mips* machines, but I don't accept that the arm* machines > could/should be classified this way. I think I agree with you here. Mips* is hard to come by and a real problem. Arm* is a slightly smaller issue because we have no way to remotely power cycle the machines, and because a couple of them have died or developed disk issues. Other than that they seem to be fine. Eventuallly replacing the existing HW with newer stuff might still be nice, but it is - at least IMO - not a blocker. 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/20131227115332.gl23...@anguilla.noreply.org
Re: Bits from the release team (freeze time line)
On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: > >On a related note, DSA have concerns with the current arm* and mips* >hardware. While there have been promises of new hardware to replace >some of the current buggy machines, the offers are currently not >leading to concrete results. Porters of these architectures should >contact DSA and figure out a solution to avoid a situation where an >architecture is in jeopardy due to insufficient buildd or porter >machines. Ummm, WTH? We've been looking into possible *upgrades* to replace some of the armel and armhf buildds with faster and (ideally) more easily managed machines, but I *seriously* disagree with any suggestion that the current machines are "buggy". I can see that with the some of the known-buggy mips* machines, but I don't accept that the arm* machines could/should be classified this way. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/20131227021631.gh8...@einval.com
Re: Bits from the release team (freeze time line)
On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: > > With a recent upload, the default gcc version on s390x changed to gcc > 4.8. However, on powerpc, ia64 and sparc, the default gcc version is > still gcc 4.6. As this version will not be supported in Jessie, we are > now giving an official warning to powerpc. For sparc and ia64, we > already gave an official warning. [SPRINTBITS] Quoting from IRC: 12:54 < aurel32> infinity: looks like you are listed as a powerpc porter 12:55 < aurel32> infinity: i think it's about time to take a decision about gcc 4.8 becoming the default 12:55 < aurel32> otherwise powerpc will be added to fucked arches, and will die a few months after 16:33 < infinity> aurel32: Yeah, we should JFDI. Frankly, I think we should have a conversation in Debian about the "ports get to pick their default GCC version" thing being an outdated concept. 16:34 < infinity> aurel32: If the release criteria are "well supported upstream" or "enough porters in Debian to make up for it", I'd contend that "keeping up to date with the current compiler" fits in with that, just like it does for the current glibc. 16:35 < infinity> aurel32: Anyhow, Ubuntu's been using gcc-4.8 on ppc for ages with no particularly ill effects. So, I'm not quite sure what authority I speak with here, but +1 from me for moving PPC to gcc-4.8 and, in fact, another +1 from me to just keep it lock step with whatever x86 is set to. We've done this in Ubuntu for years, with only very minimal pain when some small bug slips in (but no worse than the x86-specific bugs one gets on a new compiler update), and it's just saner to deal with this way. ... 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/20131227004404.gt10...@0c3.net
