Re: Release sprint results - team changes, auto-rm and arch status
On 2014-01-05 08:16, Steve Langasek wrote: On Tue, Dec 31, 2013 at 10:34:49AM +0100, Niels Thykier wrote: [...] On a related note, I suspect a good part of this problem would go away if we had an automated tool to deal with the case where a (sid-only) FTBFS is ignored. It happens sometimes that the maintainer does nothing (or, maybe, does not realise the package FTBFS on arch X) and neither the porters nor the buildd admins filed a bug for it. Then it is not until the package gets in way of a transition (or some other RC bug fix), that the package gets its RC bug. I have seen a package stuck in sid for at least 90 days and still no RC bug - the only thing wrong was an Out of date binaries on some architecture (don't remember which package nor which architecture). Historically, it was considered the porters' responsibilities to deal with these packages that are failing to build in unstable. Indeed, this was even expressed in the release criteria at one time: a port is not releasable unless it's x% up-to-date, because not being up-to-date for any reason (buildds offline, porters not signing builds timely, toolchain or individual packages regressing on one particular architecture) causes problems for testing migration. Maybe it's time to draw a new line on https://buildd.debian.org/stats/graph2-week-big.png, corresponding to what's actually needed for a port to be releasable? I believe that requirement is still present (in a slightly different form and vastly more implicit[1]), the problem is Debian has grown. The back of the envelope number for that graph is 98%, so hurd is the only one failing this requirement at the moment. Lets take an example and put 98% into concrete numbers for amd64. Currently, the buildd page for amd64[2] lists the following numbers for the following states: * installed: 10862 * failed: 4 * build-attempted: 44 * bd-uninstallable: 6 * auto-not-for-us: 109 We simplify a bit and say 50 of these are out of date (i.e. latest version has not been built yet) and 10850 are up to date. That means amd64 currently have 50 out of 10900 possible packages out of date, which translates to about 0.06% out of date packages blocking testing migration. In fact, amd64 can have up to about 218 packages FTBFS without amd64 crossing that line. This number is similar for many architectures. While a package often fails on more than one architecture at the time, it rarely fails on all architectures (except the maintainer upload)[3]. So the architectures can easily cover 400+ FTBFS without any single one of them passing their 98% line[4]. But that is still 400+ packages stuck in sid potentially blocking transitions or RC bug fixes from reaching testing. Or up to 400 unfiled RC bugs... Example aside, what we can see is that kfreebsd + sparc (and ia64) is currently the lowest, but still got 98.5%. If we push it to 99%, we would be killing all architectures except i386, amd64 and armhf. Actually, I could be tempted to push the requirement to 99%. Architectures still have over half a year and the only have to improve at most 0.6%. Using amd64 as baseline, that would translate to 60 packages or about 10 packages a month (over 6 months). ~Niels [1] https://release.debian.org/jessie/arch_policy.html Archive coverage: The architecture needs to have successfully compiled the *current version* of the overwhelming part of the archive, excluding architecture-specific packages. /Our back-of-the-envelope number is 98% of the archive. [...]/ Actually, the requirement is a mix of the one list and having built 98% of all packages in the archive - except we excuse ourselves by saying that we do not have a good accurate way to find the 100% mark for a given architecture (due to arch specific packages etc.). But if the up to dates falls below 98%, then the architecture certainly do not have 98% of the current version. [2] https://buildd.debian.org/status/architecture.php?a=amd64suite=sid [3] Well, more often than I would like. [4] In fact, I take the pessimism to an unrealistic/theoretical level and let it cover over 1500 packages without any architecture crossing the 98%-line. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c91eac.9050...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On Tue, Dec 31, 2013 at 10:34:49AM +0100, Niels Thykier wrote: You rightly point out that keeping the architectures in testing has a cost, because the architectures will block testing migration. But are the kfreebsd archs actually causing testing blockages, in practice? If there are such blockages, can you give us more information about how this has been the case? I have been seeing quite a few packages FTBFS on kFreeBSD being stuck in sid with fixes for RC bugs in testing. Of course, this problem is by no means exclusive to kFreeBSD - other architectures (sometimes, even i386 or amd64) also features on that list of blockers. The only purely factual data I got currently, is the little snippet at the bottom of Britney's log. I am not sure how reliable it is, so I'll refrain from using it as an argument. But I think we (i.e. the distribution) could do with an accurate data source on this topic! I agree, it would be nice to have solid data on this. On a related note, I suspect a good part of this problem would go away if we had an automated tool to deal with the case where a (sid-only) FTBFS is ignored. It happens sometimes that the maintainer does nothing (or, maybe, does not realise the package FTBFS on arch X) and neither the porters nor the buildd admins filed a bug for it. Then it is not until the package gets in way of a transition (or some other RC bug fix), that the package gets its RC bug. I have seen a package stuck in sid for at least 90 days and still no RC bug - the only thing wrong was an Out of date binaries on some architecture (don't remember which package nor which architecture). Historically, it was considered the porters' responsibilities to deal with these packages that are failing to build in unstable. Indeed, this was even expressed in the release criteria at one time: a port is not releasable unless it's x% up-to-date, because not being up-to-date for any reason (buildds offline, porters not signing builds timely, toolchain or individual packages regressing on one particular architecture) causes problems for testing migration. Maybe it's time to draw a new line on https://buildd.debian.org/stats/graph2-week-big.png, corresponding to what's actually needed for a port to be releasable? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-29 04:14, Steve Langasek wrote: Hi Niels, Hi Steve, Sorry for the long overdue answer, On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. I wonder, how is the release team measuring this? For the other ports that you mention, you've pointed to concrete technical problems that are in line with the previously-documented release qualification guidelines. kfreebsd, OTOH, is only listed as having insufficient install base. But what is sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are greater than a number of our ports. The formulation is very poor indeed. What we are concerned about is that kFreeBSD basically have not improved since it became a technical preview. There is a related mailing thread only on d-release[1] You rightly point out that keeping the architectures in testing has a cost, because the architectures will block testing migration. But are the kfreebsd archs actually causing testing blockages, in practice? If there are such blockages, can you give us more information about how this has been the case? Cheers, I have been seeing quite a few packages FTBFS on kFreeBSD being stuck in sid with fixes for RC bugs in testing. Of course, this problem is by no means exclusive to kFreeBSD - other architectures (sometimes, even i386 or amd64) also features on that list of blockers. The only purely factual data I got currently, is the little snippet at the bottom of Britney's log. I am not sure how reliable it is, so I'll refrain from using it as an argument. But I think we (i.e. the distribution) could do with an accurate data source on this topic! On a related note, I suspect a good part of this problem would go away if we had an automated tool to deal with the case where a (sid-only) FTBFS is ignored. It happens sometimes that the maintainer does nothing (or, maybe, does not realise the package FTBFS on arch X) and neither the porters nor the buildd admins filed a bug for it. Then it is not until the package gets in way of a transition (or some other RC bug fix), that the package gets its RC bug. I have seen a package stuck in sid for at least 90 days and still no RC bug - the only thing wrong was an Out of date binaries on some architecture (don't remember which package nor which architecture). ~Niels [1] https://lists.debian.org/debian-release/2013/12/msg00416.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c28fb9.9090...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On Tue, Dec 31, 2013 at 4:34 AM, Niels Thykier wrote: I wonder, how is the release team measuring this? For the other ports that you mention, you've pointed to concrete technical problems that are in line with the previously-documented release qualification guidelines. kfreebsd, OTOH, is only listed as having insufficient install base. But what is sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are greater than a number of our ports. The formulation is very poor indeed. What we are concerned about is that kFreeBSD basically have not improved since it became a technical preview. Out of curiosity, what metric are you using to quantify improvement? One metric that may worth thinking about is usage growth. Since the first kfreebsd release (Feb 2011), kfreebsd-amd64 usage [1] has grown about 400% (100 * 80 popcon submissions / 20 popcon submissions). kfreebsd-i386 [2] got a spike of adoption with squeeze and has indeed sort of stagnated since then. Looking at the popular architectures over the same timeframe, amd64 [3] grew at a very similar rate to kfreebsd-amd64 of about 333% (100 * 100,000 popcon submissions / 30,000 popcon submissions). i386 [4] also stagnated over the same timeframe, and may be on the decline. So, at least with respect to usage growth, similar results are seen for the popular linux architectures and kfreebsd over the last 3 years. As for absolute usage numbers, of course kfreebsd is much smaller than the most popular linux archs, with their 20 years of growth (vice 3). Assume debian had popcon in 1996 (3 years after the first linux release), I doubt the absolute popcon numbers would differ much from what we see today with kfreebsd. We would probably see somewhere in the 100s of submissions, with (and this is really hand wavy) something like 10x that number of actual installations. Best wishes, Mike [1] http://popcon.debian.org/stat/sub-kfreebsd-amd64.png [2] http://popcon.debian.org/stat/sub-kfreebsd-i386.png [3] http://popcon.debian.org/stat/sub-amd64.png [4] http://popcon.debian.org/stat/sub-i386.png -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mm1yw8rjx1jpgtyu_dofyutoh4qd9f1son4ubs0-uc...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
]] Niels Thykier The release team will generally remove the endangered architectures from testing. What happens from there on is beyond the jurisdiction of the release team (or, at least, beyond the jurisdiction that the release team wants). Though it has been implied by the FTP masters and the DSA that they are (both) generally opposed to keeping architectures in sid, which are no longer (or unlike to become) a release architecture. We (DSA) don't mind architectures being in sid only, but we object to there not being a stable release that buildds and porter boxes can run. At the same time, I believe it's a release criteria that buildds and porter boxes are available and run by DSA, so there's a small bootstrapping problem there. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2sitihb7f@rahvafeir.err.no
Re: Release sprint results - team changes, auto-rm and arch status
On 23 December 2013 16:54, Niels Thykier ni...@thykier.net wrote: On 2013-12-23 00:54, Dimitri John Ledkov wrote: On 22 December 2013 16:56, Cyril Brulebois k...@debian.org wrote: Dimitri John Ledkov x...@debian.org (2013-12-22): On 28 November 2013 20:04, Niels Thykier ni...@thykier.net wrote: * Architecture Status * ia64 in danger * sparc/ppc/mips/kfreebsd at risk * s390 dropped from testing Is ppc - powerpc or ppc64? powerpc. (For ppc64, same answer as below.) Is ppc64 looking healthy enought to become a release architecture for jessie? Not in the archive, therefore not something we can release. What about x32? Is it going to become a release architecture for jessie? Same answer as above. Pardon my ignorance but: * how do architectures move from ports to the archive? They are accepted into the archive by the FTP masters. This step is (as I understand it) largely between the FTP masters and the porters/advocates of that architecture (see [1]). [1] http://ftp-master.debian.org/archive-criteria.html * And does such a move require them to become official architectures? Not sure what official is defined as (in this context). But I suppose Well, I was going by the official term from http://www.debian.org/ports/ which also doesn't seem to define what it means. E.g. stable, stable+testing, stable+testing+sid, or testing+sid, sid-only. Any combo, as long as it's in the archive? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluivrfmyjp-rjj6fvffjjxwvxdertm_bwc74sfgyd0+...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-12-23 00:54, Dimitri John Ledkov wrote: On 22 December 2013 16:56, Cyril Brulebois k...@debian.org wrote: Dimitri John Ledkov x...@debian.org (2013-12-22): On 28 November 2013 20:04, Niels Thykier ni...@thykier.net wrote: * Architecture Status * ia64 in danger * sparc/ppc/mips/kfreebsd at risk * s390 dropped from testing Is ppc - powerpc or ppc64? powerpc. (For ppc64, same answer as below.) Is ppc64 looking healthy enought to become a release architecture for jessie? Not in the archive, therefore not something we can release. What about x32? Is it going to become a release architecture for jessie? Same answer as above. Pardon my ignorance but: * how do architectures move from ports to the archive? They are accepted into the archive by the FTP masters. This step is (as I understand it) largely between the FTP masters and the porters/advocates of that architecture (see [1]). [1] http://ftp-master.debian.org/archive-criteria.html * And does such a move require them to become official architectures? Not sure what official is defined as (in this context). But I suppose getting an architecture into sid is more official than having it on ports. That said; it does not make it a release architecture. * What's the difference between release, official, and ports architectures? I believe the short story is something like: A release architecture is an architecture included in the release. This implies that the architecture is in testing (e.g. like amd64) or is being accepted into testing by the release team. Build regressions on such architectures are RC by default. A ports architecture is on solely hosted on debian-ports and is not in sid. It cannot be considered as a release architecture. Again, not sure what official is defined as for this context. If it is an architecture in the official archive (i.e. in sid). Then the architecture has been bootstrap into sid (or is being bootstrapped into sid). Such an architecture /can/ be considered as a release architecture by the release team. NB: The above may be over simplified in some cases. Maybe we should create a flow diagram of the ports-life cycle ? * Do the the endangered architectures imply removal from the archive, to elsewhere? (ports or /dev/null) The release team will generally remove the endangered architectures from testing. What happens from there on is beyond the jurisdiction of the release team (or, at least, beyond the jurisdiction that the release team wants). Though it has been implied by the FTP masters and the DSA that they are (both) generally opposed to keeping architectures in sid, which are no longer (or unlike to become) a release architecture. ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52b86ac0.20...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 28 November 2013 20:04, Niels Thykier ni...@thykier.net wrote: * Architecture Status * ia64 in danger * sparc/ppc/mips/kfreebsd at risk * s390 dropped from testing Is ppc - powerpc or ppc64? Is ppc64 looking healthy enought to become a release architecture for jessie? What about x32? Is it going to become a release architecture for jessie? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUiqY53hiFZ1yKRYb=x6kn-budkcdsnfi1+ymsmpbq6...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
Dimitri John Ledkov x...@debian.org (2013-12-22): On 28 November 2013 20:04, Niels Thykier ni...@thykier.net wrote: * Architecture Status * ia64 in danger * sparc/ppc/mips/kfreebsd at risk * s390 dropped from testing Is ppc - powerpc or ppc64? powerpc. (For ppc64, same answer as below.) Is ppc64 looking healthy enought to become a release architecture for jessie? Not in the archive, therefore not something we can release. What about x32? Is it going to become a release architecture for jessie? Same answer as above. Mraw, KiBi. signature.asc Description: Digital signature
Re: Release sprint results - team changes, auto-rm and arch status
On 22 December 2013 16:56, Cyril Brulebois k...@debian.org wrote: Dimitri John Ledkov x...@debian.org (2013-12-22): On 28 November 2013 20:04, Niels Thykier ni...@thykier.net wrote: * Architecture Status * ia64 in danger * sparc/ppc/mips/kfreebsd at risk * s390 dropped from testing Is ppc - powerpc or ppc64? powerpc. (For ppc64, same answer as below.) Is ppc64 looking healthy enought to become a release architecture for jessie? Not in the archive, therefore not something we can release. What about x32? Is it going to become a release architecture for jessie? Same answer as above. Pardon my ignorance but: * how do architectures move from ports to the archive? * And does such a move require them to become official architectures? * What's the difference between release, official, and ports architectures? * Do the the endangered architectures imply removal from the archive, to elsewhere? (ports or /dev/null) -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluif_recnysrpssa5w7tvyr6yg0xjiwa27yispd2whv...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
Le 15/12/2013 13:03, Niels Thykier a écrit : Keeping them around is different from them being considered as release architectures (or even just keeping them in testing). Keeping these architectures in testing do involve a burden, like blocking testing migration when they FTBFS[1]. And what about (somehow automatically, like RC-buggy packages) removing packages from testing only on these architectures? Maybe I am misreading you proposal, but it seems to me that a change like that would undermine the concept of build regressions being RC for release architectures. Alternatively, we would end up with second-rate release architectures[1], where build regressions are no longer RC bugs. However, at that point I am not sure we are willing to call it a release architecture. My proposal was in response to dropping a release architecture altogether. I had the feeling that this new intermediate status (let's call it partial, second-rate, or technological preview) would not be too much additional work. [1] Assuming here you don't want packages to be removed from amd64/i386 when a maintainer uploads a truly broken package to sid and leaves it there for 3 months. There has been examples of this in the past. If you look for it, you can probably find an example of it in the archive right now as well. I don't understand this remark. My proposal doesn't affect release architectures such as amd64/i386. And removals would be only from testing. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52aece6a.9050...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-29 10:48, Svante Signell wrote: On Thu, 2013-11-28 at 21:04 +0100, Niels Thykier wrote: In this new and exciting update from your Debian Release Team... kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. s390 and Hurd will not be release architectures for Jessie. s390 was replaced by s390x in Wheezy and this completes that transition. As for Hurd; we do not believe it is ready. Particularly, we believe that it does not surpass kFreeBSD in user interest or install base. Hi, Sorry for the late reply to your request. Any chances of having Hurd as a technology preview, like kFreeBSD was for squeeze? A lot of development has been going on lately, and the number of committed people is higher than for many of the release architectures. Of course RC bugs for GNU/Hurd should not hinder transitions of packages to testing, as pointed out earlier. Thanks! I appreciate that hurd-i386 appears to be one of the architectures with most active porters. I would indeed love to see some of architectures copy hurd-i386 in this regard. However, I am afraid, we are not going to accept Hurd as a technology preview as we intend to remove the notation of technology preview in Jessie. Technology previews have not quite worked as we had hoped; adding another one is unlikely to solve that problem. ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ad98d0.6090...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-29 10:27, Stéphane Glondu wrote: Le 28/11/2013 21:52, Niels Thykier a écrit : [...] Keeping them around is different from them being considered as release architectures (or even just keeping them in testing). Keeping these architectures in testing do involve a burden, like blocking testing migration when they FTBFS[1]. And what about (somehow automatically, like RC-buggy packages) removing packages from testing only on these architectures? Cheers, Maybe I am misreading you proposal, but it seems to me that a change like that would undermine the concept of build regressions being RC for release architectures. Alternatively, we would end up with second-rate release architectures[1], where build regressions are no longer RC bugs. However, at that point I am not sure we are willing to call it a release architecture. ~Niels [1] Assuming here you don't want packages to be removed from amd64/i386 when a maintainer uploads a truly broken package to sid and leaves it there for 3 months. There has been examples of this in the past. If you look for it, you can probably find an example of it in the archive right now as well. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ad9a81.1020...@thykier.net
Re: IPMI/LOM/DRAC/ILO/etc. (was Re: Release sprint results - team changes, auto-rm and arch status)
On Thu, 5 Dec 2013 14:32:32 +0100 (CET), Thorsten Glaser t.gla...@tarent.de wrote: On Wed, 4 Dec 2013, Tollef Fog Heen wrote: Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all that serial console + networked power switch? I suspect Debian would be Isn’t “serial console + networked power switch” preferable? See http://fish2.com/ipmi/ (“IPMI: Freight Train to Hell”, in case someone already read it, but it seems a new version, PDF-only for now, is out). What about the “firm”ware (software) running on these embedded devices? Should it not be replaced with Debian, too? The software on the networked power switch might suffer from the same flaws, and a networked power switch doesn't help if the device doesn't come on with the power for some reason. Greetings Marc, who prefers built-in OOB management if it's on a dedicated Ethernet -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vp1cw-0003yn...@swivel.zugschlus.de
IPMI/LOM/DRAC/ILO/etc. (was Re: Release sprint results - team changes, auto-rm and arch status)
On Wed, 4 Dec 2013, Tollef Fog Heen wrote: Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all that serial console + networked power switch? I suspect Debian would be Isn’t “serial console + networked power switch” preferable? See http://fish2.com/ipmi/ (“IPMI: Freight Train to Hell”, in case someone already read it, but it seems a new version, PDF-only for now, is out). What about the “firm”ware (software) running on these embedded devices? Should it not be replaced with Debian, too? bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1312051430250.14...@tglase.lan.tarent.de
Re: Release sprint results - team changes, auto-rm and arch status
On 4 December 2013 07:32, Tollef Fog Heen tfh...@err.no wrote: Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all that serial console + networked power switch? I suspect Debian would be more interested in the 3A 2001 server, any idea about cost for that? (And same question for remote management.) I've not seen any IPMI/BMC like capabilities natively on any of the Loongson boards yet, so was planning on having a separate box(es) to do remote power and console access. For a small farm (upto 4 boxes) it's not too expensive. For a larger farm (8 boxes) it is more, but still within my reach. When we get to that point then I intend to work with the DSA team to see what they presently have, and what they will need. It's on my list of needs :-) I'll be interested on the 3A 2001 reply though - that is more likely to have in-built remote capabilities. Graham -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738m9cbq7@qurzaw.varnish-software.com
Re: Release sprint results - team changes, auto-rm and arch status
On Wed, Dec 4, 2013 at 3:32 PM, Tollef Fog Heen tfh...@err.no wrote: ]] David Kuehling Aron == Aron Xu a...@debian.org writes: And here you are: http://item.taobao.com/item.htm?id=22206048695 Price is CNY 3999 right now, seems to be much cheaper than before (I remember it was about CNY6999). I recently ordered the Xinghuo 3A 6100 directly from lemote.com, by emailing the sales people (can give you the email address I used in private mail). Payment was in advance via international bank transfer, $600 plus shipment and german import tax/customs. Machine was delivered via TNT within a few days. It looks pretty solidly build. Metal enclosure, pretty standard mini-ITX/ATX equipment AFAICS. Large enough to hold at least one 3.5 harddisk (a 2.5 drive is preinstalled, two SATA sockets provided on board). Has another case fan mounted above the hard-drive, so shouldn't easyly overheat. Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all that serial console + networked power switch? I suspect Debian would be more interested in the 3A 2001 server, any idea about cost for that? (And same question for remote management.) It was once mentioned to be CNY 10,000~12,000 by a community people, but we'd ask Lemote for the actual pricing and remote management. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7mb+qrzf5s3se-ept6oz-9dhmfijgl+g-hn+1nxvr...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
Hi, On Mon, Dec 02, 2013 at 07:35:59PM +, Graham Whaley wrote: Hi. As Aron says, the Loongson 3A boards may offer us some solution here, for mipsel anyhow, and maybe that offers us a mid-term solution for mips(be) whilst I work on other hardware options. The Loongson 3A CPU patches are 'in flight' over at linux-mips.org I believe. We will be testing the stability of those patches on a 3.12 kernel hopefully this week. If we find issues, we'll work with Loongson and others to fix them. If we then get a set of working patches in the path to upstream.? Thanks a lot for working on that, this is greatly appreciated. If this works out, my intention is to purchase three 3A motherboards to donate for mipsel use (2x buildd, 1x porter I'd expect?). Then *maybe* we From my experience with Loongson 3A two buildds would be able to cope easily with the rate of new packages. For the porter box, I am sure users will be very happy with a Loongson 3A ;-). could move one of the BCM91250 Swarm boards over from mipsel to mips(be) whilst I work on some other BE options? One additional big endian Swarm would clearly help, but maybe we should use it as a porter box, as the users currently complain it is unstable and reboots alone. We have enough buildd power, but as one of the Octeon is unstable and reboots alone we have to requeue packages from time to time (which is easier than users to restart their hand build). I potentially have one spare 3A motherboard we could get installed and running pretty soon whilst I purchase more if this works out. They are the 'LS3A-RS780E' 3A board btw. You can find a PDF named: LS3A-RS780E-develop board user manual_V1.0.pdfhttp://www.loongson.cn/dev/ftp/doc/01user%20manual/loongson3a/LS3A-RS780E-develop%20board%20user%20manual_V1.0.pdf here: http://www.loongson.cn/dev/ftp/doc/01user%20manual/loongson3a/ It is in Chinese, but the pictures show you the board layout etc. - it is basically a full sized PC ATX mobo with AMD chipset and 3A processor. I really wish there were a way from sw to tell which 2F CPUs had the issues (early revisions) and which (newer ones) do not, but afaik there is not (unless somebody knows differently? - some 'hidden' silicon version register maybe?). They would make OK mipsel porter boxes if nothing else, and are easily available. As to other BE board options, I'm hoping to have some news in the new year. Things are looking promising, but they just take time to work out. Ok great, thanks. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203083345.ga10...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
On Tuesday, December 3, 2013, Hector Oron wrote: Hello, 2013/12/2 Graham Whaley graham.wha...@gmail.com javascript:;: If this works out, my intention is to purchase three 3A motherboards to donate for mipsel use (2x buildd, 1x porter I'd expect?). Then *maybe* we could move one of the BCM91250 Swarm boards over from mipsel to mips(be) whilst I work on some other BE options? What do you think of Lemote Spark 3A 6100 machines? As those as suitable as the motherboards you propose? As mentioned previously, we have a board donated by Lemote, which I believe is a very early version of the board that have been used for their internal testing. From the experience I get from that board, stability is good (no hang or crash so far) and performance do not differ from the one produced by Loongson, and it's even better because Lemote people are much easier to be reached for support than Loongson (they are really helpful when we were dealing with some PMON upgrading issues). Thanks, Aron
Re: Release sprint results - team changes, auto-rm and arch status
Hello, 2013/12/3 Aron Xu a...@debian.org: What do you think of Lemote Spark 3A 6100 machines? As those as suitable as the motherboards you propose? As mentioned previously, we have a board donated by Lemote, which I believe is a very early version of the board that have been used for their internal testing. From the experience I get from that board, stability is good (no hang or crash so far) and performance do not differ from the one produced by Loongson, and it's even better because Lemote people are much easier to be reached for support than Loongson (they are really helpful when we were dealing with some PMON upgrading issues). Debian is currently being bitten by MIPS chinese prototype boards that behave unreliably and are hard to replace. I, personally, think that being able to buy (if needed) hardware is not bad idea either, for the sake of replacements, redundancies, etc... Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caodfweg8se0to1outpxp+lrvycffokn3_njg5c85vnhw57a...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On Tuesday, December 3, 2013, Hector Oron wrote: Hello, 2013/12/3 Aron Xu a...@debian.org javascript:;: What do you think of Lemote Spark 3A 6100 machines? As those as suitable as the motherboards you propose? As mentioned previously, we have a board donated by Lemote, which I believe is a very early version of the board that have been used for their internal testing. From the experience I get from that board, stability is good (no hang or crash so far) and performance do not differ from the one produced by Loongson, and it's even better because Lemote people are much easier to be reached for support than Loongson (they are really helpful when we were dealing with some PMON upgrading issues). Debian is currently being bitten by MIPS chinese prototype boards that behave unreliably and are hard to replace. I, personally, think that being able to buy (if needed) hardware is not bad idea either, for the sake of replacements, redundancies, etc... Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. I wonder what do you mean by prototype boards? IIRC those 2E boxes are not prototypes but was available for purchase, but because they are old and 2F CPUs replaces its position... Well the bad thing is that there are 3 versions of 2F that has/had been put in production and only the last one does not have the NOP hardware bug... I once used a 2F box for a couple of days and I now feel that 3A boards are much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy than Loongson's boards (Lemote's are available for purchase online without the need of contacting beforehand). Thanks, Aron
Re: Release sprint results - team changes, auto-rm and arch status
Hello Aron, 2013/12/3 Aron Xu a...@debian.org: On Tuesday, December 3, 2013, Hector Oron wrote: Debian is currently being bitten by MIPS chinese prototype boards that behave unreliably and are hard to replace. I, personally, think that being able to buy (if needed) hardware is not bad idea either, for the sake of replacements, redundancies, etc... I wonder what do you mean by prototype boards? IIRC those 2E boxes are not prototypes but was available for purchase, but because they are old and 2F CPUs replaces its position... Well the bad thing is that there are 3 versions of 2F that has/had been put in production and only the last one does not have the NOP hardware bug... Apologies for the confusion, allow me to clarify, I was referring to 'mips' Octeon boards, either those were prototypes or failed QA, so out of four boards send to ubcece: - One board was DOA - Two boards are really unreliable - One board is somehow stable All of the above came with notes saying that eth0 was broken. We do not want to repeat the same mistake for the mipsel port. I once used a 2F box for a couple of days and I now feel that 3A boards are much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy than Loongson's boards (Lemote's are available for purchase online without the need of contacting beforehand). Yes, I found a Spark 3A 6100 at taobao site. I was planning to get one for myself and check whether it can be worth it for Debian infrastructure. So, I was wondering if you had experience with it and if there is mainline supported kernel, bootloader, etc... in essence, is it able to run buildd software with Debian software components (doing minimal enablement)? Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caodfwef_fvadeog9vfxfaxtpkzi5ab5rbp7mup9ku2aku+c...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On Tue, Dec 3, 2013 at 8:31 PM, Hector Oron hector.o...@gmail.com wrote: Hello Aron, 2013/12/3 Aron Xu a...@debian.org: On Tuesday, December 3, 2013, Hector Oron wrote: Debian is currently being bitten by MIPS chinese prototype boards that behave unreliably and are hard to replace. I, personally, think that being able to buy (if needed) hardware is not bad idea either, for the sake of replacements, redundancies, etc... I wonder what do you mean by prototype boards? IIRC those 2E boxes are not prototypes but was available for purchase, but because they are old and 2F CPUs replaces its position... Well the bad thing is that there are 3 versions of 2F that has/had been put in production and only the last one does not have the NOP hardware bug... Apologies for the confusion, allow me to clarify, I was referring to 'mips' Octeon boards, either those were prototypes or failed QA, so out of four boards send to ubcece: - One board was DOA - Two boards are really unreliable - One board is somehow stable All of the above came with notes saying that eth0 was broken. We do not want to repeat the same mistake for the mipsel port. Of course, the board they donated are not intended for being buildd/porterbox but just for continuing the development of 64-bit port. What Graham mentioned for replacing existing Debian mipsel hardware are production boards sell by Loongson, Inc. I once used a 2F box for a couple of days and I now feel that 3A boards are much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy than Loongson's boards (Lemote's are available for purchase online without the need of contacting beforehand). Yes, I found a Spark 3A 6100 at taobao site. I was planning to get one for myself and check whether it can be worth it for Debian infrastructure. So, I was wondering if you had experience with it and if there is mainline supported kernel, bootloader, etc... in essence, is it able to run buildd software with Debian software components (doing minimal enablement)? As mentioned in previous mails, all Loongson 3A products do not have proper upstream kernel support currently (patches at linux-mips but not accepted), and a new group of people are now working on it to see if the problem can be solved. For boards with Loongson CPUs they use PMON, which combines the functionality of BIOS and bootloader. PMON of all the boards I have seen are decent to use, i.e. having at least 32bit DMA support and 4x2GB DDR3 RDIMMs, some of them support 40bit DMA (most of Lemote's products do). UDIMM support is not good at the moment and the supported single memory bank size is limited to 2GB for RDIMM. So in most cases there's no need to flash PMON except you want to enable 40bit DMA support for those who doesn't have it before. And after choosing a properly built kernel then almost (if not) all Debian packages are working as expected. We have run Debian mipsel buildd software for a couple of months without problem, and now we are running the mips64el version without problem. Stuff relies on kernel features heavily wasn't work as expected as the kernel we used isn't using standard Debian config (e.g. lacking of aufs support, etc). Thanks, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4ggejftop73ammioa+yd8mu_isp6itzg5wjfqfs1x...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On Wed, Dec 4, 2013 at 2:29 AM, Graham Whaley graham.wha...@gmail.com wrote: On 3 December 2013 12:31, Hector Oron hector.o...@gmail.com wrote: Hello Aron, 2013/12/3 Aron Xu a...@debian.org: On Tuesday, December 3, 2013, Hector Oron wrote: Debian is currently being bitten by MIPS chinese prototype boards that behave unreliably and are hard to replace. I, personally, think that being able to buy (if needed) hardware is not bad idea either, for the sake of replacements, redundancies, etc... I wonder what do you mean by prototype boards? IIRC those 2E boxes are not prototypes but was available for purchase, but because they are old and 2F CPUs replaces its position... Well the bad thing is that there are 3 versions of 2F that has/had been put in production and only the last one does not have the NOP hardware bug... Apologies for the confusion, allow me to clarify, I was referring to 'mips' Octeon boards, either those were prototypes or failed QA, so out of four boards send to ubcece: - One board was DOA - Two boards are really unreliable - One board is somehow stable All of the above came with notes saying that eth0 was broken. We do not want to repeat the same mistake for the mipsel port. I once used a 2F box for a couple of days and I now feel that 3A boards are much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy than Loongson's boards (Lemote's are available for purchase online without the need of contacting beforehand). Yes, I found a Spark 3A 6100 at taobao site. I was planning to get one for myself and check whether it can be worth it for Debian infrastructure. So, I was wondering if you had experience with it and if there is mainline supported kernel, bootloader, etc... in essence, is it able to run buildd software with Debian software components (doing minimal enablement)? Does anybody have a URL for purchase of those Spark 6100 machines? I had a surf on taobao, but completely failed to find anything lemote or loongson. I did check recently with the European distributor (tekmote) if they were going to sell the '3A mini-pc or desktop', and they said no :-( And here you are: http://item.taobao.com/item.htm?id=22206048695 Price is CNY 3999 right now, seems to be much cheaper than before (I remember it was about CNY6999). Thanks, Aron -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5hztfnwgzuu3_uqgjj6j5emmwwtkbcyrjhuyftnd3...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On 3 December 2013 12:31, Hector Oron hector.o...@gmail.com wrote: Hello Aron, 2013/12/3 Aron Xu a...@debian.org: On Tuesday, December 3, 2013, Hector Oron wrote: Debian is currently being bitten by MIPS chinese prototype boards that behave unreliably and are hard to replace. I, personally, think that being able to buy (if needed) hardware is not bad idea either, for the sake of replacements, redundancies, etc... I wonder what do you mean by prototype boards? IIRC those 2E boxes are not prototypes but was available for purchase, but because they are old and 2F CPUs replaces its position... Well the bad thing is that there are 3 versions of 2F that has/had been put in production and only the last one does not have the NOP hardware bug... Apologies for the confusion, allow me to clarify, I was referring to 'mips' Octeon boards, either those were prototypes or failed QA, so out of four boards send to ubcece: - One board was DOA - Two boards are really unreliable - One board is somehow stable All of the above came with notes saying that eth0 was broken. We do not want to repeat the same mistake for the mipsel port. I once used a 2F box for a couple of days and I now feel that 3A boards are much better than 2E/2F. Also, Lemote's Spark 6100 machine is easier to buy than Loongson's boards (Lemote's are available for purchase online without the need of contacting beforehand). Yes, I found a Spark 3A 6100 at taobao site. I was planning to get one for myself and check whether it can be worth it for Debian infrastructure. So, I was wondering if you had experience with it and if there is mainline supported kernel, bootloader, etc... in essence, is it able to run buildd software with Debian software components (doing minimal enablement)? Does anybody have a URL for purchase of those Spark 6100 machines? I had a surf on taobao, but completely failed to find anything lemote or loongson. I did check recently with the European distributor (tekmote) if they were going to sell the '3A mini-pc or desktop', and they said no :-( Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Re: Release sprint results - team changes, auto-rm and arch status
Aron == Aron Xu a...@debian.org writes: And here you are: http://item.taobao.com/item.htm?id=22206048695 Price is CNY 3999 right now, seems to be much cheaper than before (I remember it was about CNY6999). I recently ordered the Xinghuo 3A 6100 directly from lemote.com, by emailing the sales people (can give you the email address I used in private mail). Payment was in advance via international bank transfer, $600 plus shipment and german import tax/customs. Machine was delivered via TNT within a few days. It looks pretty solidly build. Metal enclosure, pretty standard mini-ITX/ATX equipment AFAICS. Large enough to hold at least one 3.5 harddisk (a 2.5 drive is preinstalled, two SATA sockets provided on board). Has another case fan mounted above the hard-drive, so shouldn't easyly overheat. That said, it comes with some chines Linux derivate pre-installed, but I didn't yet find the time to put Debian on it. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg Fingerprint: B63B 6AF2 4EEB F033 46F7 7F1D 935E 6F08 E457 205F pgpZRgprZOAlx.pgp Description: PGP signature
Re: Release sprint results - team changes, auto-rm and arch status
]] David Kuehling Aron == Aron Xu a...@debian.org writes: And here you are: http://item.taobao.com/item.htm?id=22206048695 Price is CNY 3999 right now, seems to be much cheaper than before (I remember it was about CNY6999). I recently ordered the Xinghuo 3A 6100 directly from lemote.com, by emailing the sales people (can give you the email address I used in private mail). Payment was in advance via international bank transfer, $600 plus shipment and german import tax/customs. Machine was delivered via TNT within a few days. It looks pretty solidly build. Metal enclosure, pretty standard mini-ITX/ATX equipment AFAICS. Large enough to hold at least one 3.5 harddisk (a 2.5 drive is preinstalled, two SATA sockets provided on board). Has another case fan mounted above the hard-drive, so shouldn't easyly overheat. Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all that serial console + networked power switch? I suspect Debian would be more interested in the 3A 2001 server, any idea about cost for that? (And same question for remote management.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738m9cbq7@qurzaw.varnish-software.com
Re: Release sprint results - team changes, auto-rm and arch status
Wouter Verhelst wou...@debian.org (2013-12-02): It will revert to throwaway chroots the minute LVM gets unbroken in stable. What's the bug report for the issue you're mentioning? In the meanwhile, I think tarball-based chroots are an alternative as far as sbuild/schroot are concerned. How are the other powerpc buildds (e.g. parry, porpora) set up? Mraw, KiBi. signature.asc Description: Digital signature
Re: Release sprint results - team changes, auto-rm and arch status
Hello, 2013/12/2 Cyril Brulebois k...@debian.org: Wouter Verhelst wou...@debian.org (2013-12-02): It will revert to throwaway chroots the minute LVM gets unbroken in stable. What's the bug report for the issue you're mentioning? [..] zumbi waldi: are there plans to fix lvm2 snapshot in stable? (#659762) - I was wondering because buildd network, running stable, is affected, would you recommend to leave out from lvm2 snapshot to tarball based build chroots instead? [..] waldi zumbi: the bts is wrong. the bug is fixed in 2.02.95-8 [..] waldi and stable seems to have some crash on drbd connection fail, i still have no traceback as it never makes it to the log waldi and no time to make a lab setup and properly check it out FWIW, ARM buildds are quite fine on stable LVM snaphots. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAODfWeEmeUTaFJ5Q05OWyY3_6BpUWULqS7fJ8B=tmmubz-w...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On 30/11/13 17:56, Jakub Wilk wrote: * Niels Thykier ni...@thykier.net, 2013-11-28, 21:04: Starting today, all non-key packages with RC bugs in Jessie for more than 15 days will be considered for auto-removal, even if they have reverse dependencies. This also means that the removal of these packages will cause the removal of all their reverse dependencies. I can see these headlines: Jessie, The Smallest Debian Release Since Potato. I, on the other hand, can see how the results of this would rather be the much shorter freeze and the strive for quality versus quantity. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529c6aa7.1050...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
Wouter Verhelst wou...@debian.org (2013-12-02): It will revert to throwaway chroots the minute LVM gets unbroken in stable. FWIW, ARM buildds are quite fine on stable LVM snaphots. Hrm, ARM is little-endian, right? LVM snapshots are apparently (according to the buildd maintainers who run that) unstable on m68k, too, but I set up mine with btrfs to experiment with the latter (since itâs not a release arch, yada yada) and it works pretty well, except some builds (very few, and I havenât seen it in a while, might be fixed in recent kernels) abort with âfoo.lo: not a valid libtool objectâ, which a give-back will fix. That being said, m68k buildds run unstable (of course), and I go through great pain to make sure that most, if not all, of them _can_ run stock kernels from the archive. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l7i267$m01$1...@ger.gmane.org
Re: Release sprint results - team changes, auto-rm and arch status
Cyril Brulebois writes (Re: Release sprint results - team changes, auto-rm and arch status): Wouter Verhelst wou...@debian.org (2013-12-02): It will revert to throwaway chroots the minute LVM gets unbroken in stable. What's the bug report for the issue you're mentioning? Someone has already mentioned #659762. But looking at lvm's buglist shows loads and loads of bugs related to snapshots. I and people I know have experienced several different kinds of races with various versions of lvm2 in stable and oldstable. It seems that a big part of the problem is the design of the interaction with udev. I haven't looked at the code but I have had a handwaving explanation of the design from a friend who was digging into the code to try to track down their own race bug. From that explanation I concluded that the problem was a terrible design. Personally, the main symptom I experience is that my netbook fills up with stale snapshots which can't be removed. Stopping udev makes it possible to remove them. I haven't reportded this bug because it seems that the lvm2 bug list is absolutely full of reports of race bugs. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21148.36629.854701.138...@chiark.greenend.org.uk
Re: Release sprint results - team changes, auto-rm and arch status
On Mon, Dec 2, 2013 at 08:30:45 +0100, Wouter Verhelst wrote: Op 28-11-13 21:04, Niels Thykier schreef: It has also come to our attention that a few buildds do not use throw-away chroots. This sometimes results in unclean builds and we have therefore decided to only consider architectures which use throw-away chroots for all suites on all buildds as candidate release architectures. You're talking about praetorius here. It will revert to throwaway chroots the minute LVM gets unbroken in stable. There's a few solutions here: - praetorius is disabled - you get over your objections to tarball-based schroots - somebody else runs praetorius But we feel that reusing chroots is just no longer acceptable. Cheers, Julien signature.asc Description: Digital signature
Re: Release sprint results - team changes, auto-rm and arch status
On Mon, Dec 02, 2013 at 08:22:50AM +0100, Tollef Fog Heen wrote: ]] Aurelien Jarno Also note that the latest batches of the Loongson-2F CPUs have the bug fixed. That doesn't help us when the MIPS porters seem to be unable to get us any reasonable machine with the bug fixed, even after repeated proddings. Which bug? Loongson 2F have this NOP bug, while Loongson 2E doesn't have it. Unfortunately for DSA, we don't have kernel support in the Debian package for the 2E version, but it is something we are planning to work on. IIRC, aba has been poking at this on and off for about six months, but that doesn't help us until we actually have machines racked and set up as porter boxes/buildds. He has been successful in getting new faster machines, but unfortunately the kernel support is still lacking. So we are looking for other alternatives. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131202144004.gk4...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-12-02 08:30, Wouter Verhelst wrote: Op 28-11-13 21:04, Niels Thykier schreef: It has also come to our attention that a few buildds do not use throw-away chroots. This sometimes results in unclean builds and we have therefore decided to only consider architectures which use throw-away chroots for all suites on all buildds as candidate release architectures. You're talking about praetorius here. It will revert to throwaway chroots the minute LVM gets unbroken in stable. I already reverted it, due to popular request. The bug is supposedly fixed in stable, although we'll see if that's actually the case. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f2a882f7d1f4b7cea0c970b719e41...@hub.kern.lc
Re: Release sprint results - team changes, auto-rm and arch status
Hi. As Aron says, the Loongson 3A boards may offer us some solution here, for mipsel anyhow, and maybe that offers us a mid-term solution for mips(be) whilst I work on other hardware options. The Loongson 3A CPU patches are 'in flight' over at linux-mips.org I believe. We will be testing the stability of those patches on a 3.12 kernel hopefully this week. If we find issues, we'll work with Loongson and others to fix them. If we then get a set of working patches in the path to upstream.? If this works out, my intention is to purchase three 3A motherboards to donate for mipsel use (2x buildd, 1x porter I'd expect?). Then *maybe* we could move one of the BCM91250 Swarm boards over from mipsel to mips(be) whilst I work on some other BE options? I potentially have one spare 3A motherboard we could get installed and running pretty soon whilst I purchase more if this works out. They are the 'LS3A-RS780E' 3A board btw. You can find a PDF named: LS3A-RS780E-develop board user manual_V1.0.pdfhttp://www.loongson.cn/dev/ftp/doc/01user%20manual/loongson3a/LS3A-RS780E-develop%20board%20user%20manual_V1.0.pdf here: http://www.loongson.cn/dev/ftp/doc/01user%20manual/loongson3a/ It is in Chinese, but the pictures show you the board layout etc. - it is basically a full sized PC ATX mobo with AMD chipset and 3A processor. I really wish there were a way from sw to tell which 2F CPUs had the issues (early revisions) and which (newer ones) do not, but afaik there is not (unless somebody knows differently? - some 'hidden' silicon version register maybe?). They would make OK mipsel porter boxes if nothing else, and are easily available. As to other BE board options, I'm hoping to have some news in the new year. Things are looking promising, but they just take time to work out. Graham On 2 December 2013 14:40, Aurelien Jarno aurel...@aurel32.net wrote: On Mon, Dec 02, 2013 at 08:22:50AM +0100, Tollef Fog Heen wrote: ]] Aurelien Jarno Also note that the latest batches of the Loongson-2F CPUs have the bug fixed. That doesn't help us when the MIPS porters seem to be unable to get us any reasonable machine with the bug fixed, even after repeated proddings. Which bug? Loongson 2F have this NOP bug, while Loongson 2E doesn't have it. Unfortunately for DSA, we don't have kernel support in the Debian package for the 2E version, but it is something we are planning to work on. IIRC, aba has been poking at this on and off for about six months, but that doesn't help us until we actually have machines racked and set up as porter boxes/buildds. He has been successful in getting new faster machines, but unfortunately the kernel support is still lacking. So we are looking for other alternatives. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131202144004.gk4...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
Hello, 2013/12/2 Graham Whaley graham.wha...@gmail.com: If this works out, my intention is to purchase three 3A motherboards to donate for mipsel use (2x buildd, 1x porter I'd expect?). Then *maybe* we could move one of the BCM91250 Swarm boards over from mipsel to mips(be) whilst I work on some other BE options? What do you think of Lemote Spark 3A 6100 machines? As those as suitable as the motherboards you propose? Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caodfwefbhel5ahbgawlsrnqvj9puzoergf8j3z-5us7gmhg...@mail.gmail.com
Re: Release sprint results - team changes, auto-rm and arch status
On Sat, Nov 30, 2013 at 11:25:01PM +, Ben Hutchings wrote: MUL is a MIPS32 instruction, which is not present on MIPS3 CPUs like the Loongson 2, MULT + MFLO should be used instead. There is no CPU bug there, it's like trying to build x86 code with SSE4 instructions, and then saying that all x86 CPUs which do not support the SSE4 instructions are buggy. That was only the first problem; read the whole entry. The other problem can be attributed to a bug in the CPU... or not. The fact that mono works on one CPU and not on the other, while they have different instruction sets can not be attributed to the NOP issue. Without the analysis done in this same blog entry, the MUL issue could also have been taken for a CPU bug. Said otherwise, if a code works on a Pentium Pro, but not on a Pentium, one can't be sure that the problem is the F0 0F bug. It could also be code using the cmov instruction. Also note that the latest batches of the Loongson-2F CPUs have the bug fixed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131201213355.ga21...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
]] Aurelien Jarno Also note that the latest batches of the Loongson-2F CPUs have the bug fixed. That doesn't help us when the MIPS porters seem to be unable to get us any reasonable machine with the bug fixed, even after repeated proddings. IIRC, aba has been poking at this on and off for about six months, but that doesn't help us until we actually have machines racked and set up as porter boxes/buildds. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u1vg1it@qurzaw.varnish-software.com
Re: Release sprint results - team changes, auto-rm and arch status
Op 28-11-13 21:04, Niels Thykier schreef: It has also come to our attention that a few buildds do not use throw-away chroots. This sometimes results in unclean builds and we have therefore decided to only consider architectures which use throw-away chroots for all suites on all buildds as candidate release architectures. You're talking about praetorius here. It will revert to throwaway chroots the minute LVM gets unbroken in stable. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: OpenPGP digital signature
Re: Release sprint results - team changes, auto-rm and arch status
* Niels Thykier ni...@thykier.net, 2013-11-28, 21:04: Starting today, all non-key packages with RC bugs in Jessie for more than 15 days will be considered for auto-removal, even if they have reverse dependencies. This also means that the removal of these packages will cause the removal of all their reverse dependencies. I can see these headlines: Jessie, The Smallest Debian Release Since Potato. Default Urgency === We believe that it should be acceptable for most uploads to unstable to be uploaded with medium urgency, to reduce the delay for testing migrations. Huh. §5.6.7 says that Urgency “is a description of how important it is to upgrade to this version from previous ones”. How can possibly RT decide that from now on it's more important to upgrade most packages? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130165651.gc2...@jwilk.net
Re: Release sprint results - team changes, auto-rm and arch status
On Sat, Nov 30, 2013 at 05:56:51PM +0100, Jakub Wilk wrote: * Niels Thykier ni...@thykier.net, 2013-11-28, 21:04: Hi, We believe that it should be acceptable for most uploads to unstable to be uploaded with medium urgency, to reduce the delay for testing migrations. Huh. §5.6.7 says that Urgency “is a description of how important it is to upgrade to this version from previous ones”. How can possibly RT decide that from now on it's more important to upgrade most packages? I've to agree with Jakub here. It feels wrong to abuse the urgency to lower the staging periode in unstable before a testing migration. If the package is not fit for a release, or disruptive, or whatever I had the feeling that there is a mutual understanding within the project, to use experimental. If a transitional period within unstable is required without breaking testing we often enough used rc bugs against our own packages. And now we start to fiddle with urgency settings and place bets on the required testing periode in unstable? We can of course discuss lowering this hold back time archive wide, but working around the discussion with this proposal feels not right. Sven -- There we were, the three of us, the thief the king and I. Finally, we were forced to see, we were equals in the night. [Streetlight Manifesto - The three of us] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130174112.gb17...@garkbit.lan
Re: Release sprint results - team changes, auto-rm and arch status
At DebConf there was an interesting proposal by Colin and Steve to reduce testing migration times for packages that have an succeeding autopkgtest. This would increase motivation for adding autopkgtests to packages. More importantly, it would speed up testing propigation, without a sacrifice in test quality. The only blocker seemed to be setting up a system to run the autopkgtests and communicate the urgency hints to britney. Reducing the upload urgency to medium by default both seems to have hard to quantify risks in reducing the quality of testing, and undercuts the motivation for this proposal. So I'm curious why this result came out of the RM team meeting. -- see shy jo signature.asc Description: Digital signature
Re: Release sprint results - team changes, auto-rm and arch status
Joey Hess writes (Re: Release sprint results - team changes, auto-rm and arch status): Reducing the upload urgency to medium by default both seems to have hard to quantify risks in reducing the quality of testing, and undercuts the motivation for this proposal. So I'm curious why this result came out of the RM team meeting. I've heard it observed that it's rather odd that a developer doing an upload can only reduce the delay from the default, and not increase it. I found this a moderately convincing line of reasoning but arguably it should be accompanied by a change to the migration times associated with each of the urgency levels. At DebConf there was an interesting proposal by Colin and Steve to reduce testing migration times for packages that have an succeeding autopkgtest. [...] I agree that that was an interesting proposal but it seems separate to me. It's certainly a lot more work. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21146.20827.702731.661...@chiark.greenend.org.uk
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-29 09:22, Aurelien Jarno wrote: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: Note that s390x and powerpc could also do with more porters, but at this time we are not giving an official warning for them. I see on http://release.debian.org/jessie/arch_qualify.html that you are concerned by the fact s390x is still using gcc 4.6. This has been decided to switch to gcc-4.8 a few weeks ago and it has been already implemented in the SVN. It's only waiting for an upload from Matthias Klose. Great; I have updated the table to list this pending fix. ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529a551e.6020...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
Ian Jackson ijack...@chiark.greenend.org.uk writes: I've heard it observed that it's rather odd that a developer doing an upload can only reduce the delay from the default, and not increase it. I found this a moderately convincing line of reasoning but arguably it should be accompanied by a change to the migration times associated with each of the urgency levels. Yes, this is the same reaction that I had. I was a bit surprised at first, and then realized that this means that things like early-release translation updates, typo fixes, or (from a different direction) major new releases that would benefit from extra testing can be set to low, and others can be set to medium, and that will actually make more sense. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874n6tr1ib@windlord.stanford.edu
Re: Release sprint results - team changes, auto-rm and arch status
On Fri, 2013-11-29 at 15:12 +0100, Aurelien Jarno wrote: On Fri, Nov 29, 2013 at 01:57:39PM +, Ben Hutchings wrote: On Fri, 2013-11-29 at 09:22 +0100, Aurelien Jarno wrote: Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. Whatever, mips has one reliable buildd which is not enough. Two actually with ball.d.o which is not an octeon. My point is to say that Octeon boxes are not unstable, but the Octeon boxes *we have* as part of the Debian infrastructure are unstable. This of course has to be fixed. Yes. - mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the NOP implementation error from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. They are affected by that or a very similar issue, as demonstrated by Jo Shields recently: http://apebox.org/wordpress/rants/545/ MUL is a MIPS32 instruction, which is not present on MIPS3 CPUs like the Loongson 2, MULT + MFLO should be used instead. There is no CPU bug there, it's like trying to build x86 code with SSE4 instructions, and then saying that all x86 CPUs which do not support the SSE4 instructions are buggy. That was only the first problem; read the whole entry. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Release sprint results - team changes, auto-rm and arch status
Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. - mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the NOP implementation error from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129082243.ga9...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: Note that s390x and powerpc could also do with more porters, but at this time we are not giving an official warning for them. I see on http://release.debian.org/jessie/arch_qualify.html that you are concerned by the fact s390x is still using gcc 4.6. This has been decided to switch to gcc-4.8 a few weeks ago and it has been already implemented in the SVN. It's only waiting for an upload from Matthias Klose. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129082250.ga10...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
Le jeudi 28 novembre 2013 à 21:04 +0100, Niels Thykier a écrit : We have stopped considering ia64 as a blocker for testing migration. The architectures sparc, mips and mipsel also cause concern: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. s390 and Hurd will not be release architectures for Jessie. Two words: THANK. YOU. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385714898.24216.1074.camel@dsp0698014
Re: Release sprint results - team changes, auto-rm and arch status
On 11/29/2013 09:48 AM, Josselin Mouette wrote: s390 and Hurd will not be release architectures for Jessie. Two words: THANK. YOU. However, m68k will be. *preparing to run as fast as I can* -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529855e3.5040...@physik.fu-berlin.de
Re: Release sprint results - team changes, auto-rm and arch status
Le 28/11/2013 21:52, Niels Thykier a écrit : I've found the builds on the less used architectures have been useful for flushing out unusual bugs, particularly when the code ships with many test cases and it exposes problems for big endian machines, etc. Also, kFreeBSD and HURD are both kind of special in that they are not Linux, it would be good to keep one or the other around even if other architectures are culled more aggressively. Keeping them around is different from them being considered as release architectures (or even just keeping them in testing). Keeping these architectures in testing do involve a burden, like blocking testing migration when they FTBFS[1]. And what about (somehow automatically, like RC-buggy packages) removing packages from testing only on these architectures? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52985e1f.2080...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On Thu, 2013-11-28 at 21:04 +0100, Niels Thykier wrote: In this new and exciting update from your Debian Release Team... kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. s390 and Hurd will not be release architectures for Jessie. s390 was replaced by s390x in Wheezy and this completes that transition. As for Hurd; we do not believe it is ready. Particularly, we believe that it does not surpass kFreeBSD in user interest or install base. Any chances of having Hurd as a technology preview, like kFreeBSD was for squeeze? A lot of development has been going on lately, and the number of committed people is higher than for many of the release architectures. Of course RC bugs for GNU/Hurd should not hinder transitions of packages to testing, as pointed out earlier. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385718518.3926.24.ca...@g3620.my.own.domain
Re: Release sprint results - team changes, auto-rm and arch status
On 11/29/13 10:22, Aurelien Jarno wrote: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. Octeon is one of the most active MIPS ports in Linux upstream. Lately, there is renewed interest in this platform, due to some new Octeon-based router products by Ubiquity being extremely cheap, performant and hence, relatively speaking, very popular. Those run a modified Debian distribution (*not* a derivative, Debian's apt sources are recommended by the vendor) This obviously isn't sufficient for Debian to consider mips as a release architecture, but the statement octeon is unstable is obviously overly broad and incorrect, as Aurelien also points out. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52985dce.3080...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On Fri, 2013-11-29 at 09:22 +0100, Aurelien Jarno wrote: Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. Whatever, mips has one reliable buildd which is not enough. - mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the NOP implementation error from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. They are affected by that or a very similar issue, as demonstrated by Jo Shields recently: http://apebox.org/wordpress/rants/545/ Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Release sprint results - team changes, auto-rm and arch status
On Fri, Nov 29, 2013 at 01:57:39PM +, Ben Hutchings wrote: On Fri, 2013-11-29 at 09:22 +0100, Aurelien Jarno wrote: Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. Whatever, mips has one reliable buildd which is not enough. Two actually with ball.d.o which is not an octeon. My point is to say that Octeon boxes are not unstable, but the Octeon boxes *we have* as part of the Debian infrastructure are unstable. This of course has to be fixed. - mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the NOP implementation error from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. They are affected by that or a very similar issue, as demonstrated by Jo Shields recently: http://apebox.org/wordpress/rants/545/ MUL is a MIPS32 instruction, which is not present on MIPS3 CPUs like the Loongson 2, MULT + MFLO should be used instead. There is no CPU bug there, it's like trying to build x86 code with SSE4 instructions, and then saying that all x86 CPUs which do not support the SSE4 instructions are buggy. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129141214.gb14...@ohm.rr44.fr
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-28 21:04, Niels Thykier wrote: In this new and exciting update from your Debian Release Team... Thanks for the updates! Architecture Status === ia64 causes us concern for the following reasons: We have stopped considering ia64 as a blocker for testing migration. This means that the out-of-date and uninstallability criteria on ia64 will not hold up transitions from unstable to testing for packages. It is expected that unless drastic improvement occurs, ia64 will be removed from testing on Friday 24th January 2014. What is the correct way to handle FTBFS (or other RC) bugs that only affect ia64 (and therefore will block migration): * downgrade severity to non-RC? * tag jessie-ignore? * wait for 2014-01-24? * ... E.g. #650753 Andreas PS: I remember some recent discussion about arch or port tags/pseudopackages/... that seems to have died without actions :-( -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298a6e8.1020...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 04:14, Steve Langasek wrote: Hi Niels, On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. I wonder, how is the release team measuring this? For the other ports that you mention, you've pointed to concrete technical problems that are in line with the previously-documented release qualification guidelines. kfreebsd, OTOH, is only listed as having insufficient install base. But what is sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are greater than a number of our ports. You rightly point out that keeping the architectures in testing has a cost, because the architectures will block testing migration. But are the kfreebsd archs actually causing testing blockages, in practice? If there are such blockages, can you give us more information about how this has been the case? I have had unusual issues on kFreeBSD with reSIProcate although that is partly because the unit tests are so exhaustive that they expose obscure bugs, e.g. http://list.resiprocate.org/archive/resiprocate-devel/msg08488.html It could be argued that the cost of these other architectures is not a one-sided equation - their presence contributes in some way to the overall quality of the software that people include in Debian. So the net cost may be lower than people really think, but of course that doesn't take away the fact that it is a cost that has to be paid to keep these ports there. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298b686.8030...@pocock.com.au
Re: Release sprint results - team changes, auto-rm and arch status
Daniel Pocock writes (Re: Release sprint results - team changes, auto-rm and arch status): I have had unusual issues on kFreeBSD with reSIProcate although that is partly because the unit tests are so exhaustive that they expose obscure bugs, e.g. http://list.resiprocate.org/archive/resiprocate-devel/msg08488.html I think this is a good example of the kind of bug that is sometimes blamed on a port even though it probably isn't really a port-specific bug. It seems likely to me that that bug is, at root, a race of some kind. And it just so happens that the race is lost on kFreeBSD - sometimes. Detecting such a race is valuable to the project; it's certainly not a disbenefit. After all, a race that happens to us sometimes is likely to happen to users sometimes. Debugging races in the field is very difficult. Much better to have them show up in a porter's build test, than to have them show up later on users' machines. So if anything, I think bugs like this one are an argument for keeping kFreeBSD (and other minority ports) with as high a status as practical; not an argument for throwing it out. It could be argued that the cost of these other architectures is not a one-sided equation - their presence contributes in some way to the overall quality of the software that people include in Debian. Exactly. So the net cost may be lower than people really think, but of course that doesn't take away the fact that it is a cost that has to be paid to keep these ports there. We should be wary of setting the clearly visible and accountable costs of keeping a port, up against the difficult to measure and mostly invisible benefits in terms of reduced need to do in-the-field diagnosis of obscure bugs (for us and our users). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21144.49806.334906.353...@chiark.greenend.org.uk
Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 16:36, Ian Jackson wrote: It seems likely to me that that bug is, at root, a race of some kind. And it just so happens that the race is lost on kFreeBSD - sometimes. Detecting such a race is valuable to the project; it's certainly not a disbenefit. After all, a race that happens to us sometimes is likely to happen to users sometimes. Yes, to a point. On the other hand, each RC architecture where build-time tests are fatal inflates some subset of ordinary bugs to Severity:serious - if we'd seen this bug (or a similar sometimes-fails bug) in real life, even if there's a way to reproduce it on (say) x86 Linux, would it necessarily have RC severity? Perhaps this particular bug would - I have no idea how often it happens, or what functionality it breaks - but Daniel's phrasing implied that this particular regression test suite is far more thorough than what we'd consider to be a major effect on the usability of a package (Severity:important). S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298cda1.1060...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 18:23, Simon McVittie wrote: On 29/11/13 16:36, Ian Jackson wrote: It seems likely to me that that bug is, at root, a race of some kind. And it just so happens that the race is lost on kFreeBSD - sometimes. Detecting such a race is valuable to the project; it's certainly not a disbenefit. After all, a race that happens to us sometimes is likely to happen to users sometimes. Yes, to a point. On the other hand, each RC architecture where build-time tests are fatal inflates some subset of ordinary bugs to Severity:serious - if we'd seen this bug (or a similar sometimes-fails bug) in real life, even if there's a way to reproduce it on (say) x86 Linux, would it necessarily have RC severity? Perhaps this particular bug would - I have no idea how often it happens, or what functionality it breaks - but Daniel's phrasing implied that this particular regression test suite is far more thorough than what we'd consider to be a major effect on the usability of a package (Severity:important). The test suite is executed on every upload and if it isn't 100% successful the build fails and the package does not propagate on any platform. This race condition is 100% reproducible on the porter boxes too, I'm yet to find the root cause though. Of particular note, it only occurs on some of the more recent builds, so it appears to have been introduced by some upstream change in the last 6 months. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298ec78.70...@pocock.com.au
Re: Release sprint results - team changes, auto-rm and arch status
On Friday, November 29, 2013, Aurelien Jarno wrote: Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. - mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the NOP implementation error from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. I've got anther 3A board today, which is an official product of Loongson, Inc. that can be purchased on the market. We have made
Re: Release sprint results - team changes, auto-rm and arch status
(Re-posting, pressed send accidentally.) On Friday, November 29, 2013, Aurelien Jarno wrote: Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. - mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the NOP implementation error from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. We've got anther 3A board today, which is an official product of Loongson, Inc. that can be purchased on the market. We are able to run a Sid mips64el system on the board without any visible glitch like the previous one from Lemote, so I think 3A boards like the ones we have are really good candidates for replacing old mipsel buildds and porter boxes. They are much faster (by being quad-core, and some boards have 2 CPU config), and support larger memory (standard config is 4GB). Also there are willing party that is considering donating several to Debian. What we need to fix are their kernels and PMON: 1. Kernel support isn't upstreamed, and we have only succeeded in merging the patch set to 3.6 and some lower versions which can produce a working binary. We are running 3.6 for Lemote products and 2.6.36 for Loongson ones. 2. Different boards use quite different PMON, most of them support 2GB DDR3 RDIMM, so the maximum configuration will be limited to 4x2GB. This could be a smaller issue comparing with the first one though, we are working with Lemote to see if 8GB UDIMM can be officially supported on their boards. Thanks, Aron -- Regards, Aron Xu
Re: Release sprint results - team changes, auto-rm and arch status
Le Fri, Nov 29, 2013 at 04:45:10PM +0100, Daniel Pocock a écrit : It could be argued that the cost of these other architectures is not a one-sided equation - their presence contributes in some way to the overall quality of the software that people include in Debian. So the net cost may be lower than people really think, but of course that doesn't take away the fact that it is a cost that has to be paid to keep these ports there. Hello Daniel, I think that the mere ‘presence’ as a release architecture sould not be counted on the positive side of the equation, because one can definitely perform mass screening for bugs by rebuilding the archive on non-release architectureps. This is similar in spirit to the Mayhem project that reported 4,801 bugs this summer (http://forallsecure.com/mayhem.html). Having Debian as an intermediate between mass-screeners and upstream authors is a big work overhead for us, or at least for me. The more we screen, the more it means that I need to concentrate on the old software at the expense of the new software, and become an human email proxy instead of a software packager. I am somehow glad to provide this service from time to time, but I also think that it is the duty of the people interested in mass-screens to innovate and find ways to reach upstream directly. Of course, Debian can help with projects such as the ‘new PTS‘ or http://upstream-metadata.debian.net/. By the way, thanks to the release team for the very nice summary that started this thread, for the auto-removals, and everything else. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130012105.ga19...@falafel.plessy.net
Re: Release sprint results - team changes, auto-rm and arch status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/11/13 21:04, Niels Thykier wrote: Architecture Status === ia64 causes us concern for the following reasons: * binutils issues (#718047, #720404), resulting in build failures blocking transitions * many packages link to libunwind on ia64, which causes issues if used at boot time (as the library is in /usr) and means nearly 3000 packages need to be rebuilt when the SONAME changes. The ingrained nature also leads to libunwind8 currently depending on libunwind7 (which is no longer built) * d-i in a virtualised environment on top of HP-UX is broken (see https://lists.debian.org/debian-boot/2013/11/msg00017.html) We have stopped considering ia64 as a blocker for testing migration. This means that the out-of-date and uninstallability criteria on ia64 will not hold up transitions from unstable to testing for packages. It is expected that unless drastic improvement occurs, ia64 will be removed from testing on Friday 24th January 2014. The architectures sparc, mips and mipsel also cause concern: * [sparc] cannot run stable kernels. Kernels in sid have issues too with some machines. * [sparc] gcc randomly crashes, SMP not working * [sparc] only one porter * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable - mipsel loongson have CPU bugs - swarm is a decade old kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. Architectures still causing us concern at that point will join ia64 in no longer being considered for britney migrations and may be dropped from testing after a further period. s390 and Hurd will not be release architectures for Jessie. s390 was replaced by s390x in Wheezy and this completes that transition. As for Hurd; we do not believe it is ready. Particularly, we believe that it does not surpass kFreeBSD in user interest or install base. Note that s390x and powerpc could also do with more porters, but at this time we are not giving an official warning for them. I've found the builds on the less used architectures have been useful for flushing out unusual bugs, particularly when the code ships with many test cases and it exposes problems for big endian machines, etc. Also, kFreeBSD and HURD are both kind of special in that they are not Linux, it would be good to keep one or the other around even if other architectures are culled more aggressively. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSl6aKAAoJEOm1uwJp1aqDhsEP/jVlnrrriK9nF//yIpqZey/z qF17Wa4O8R160LRwr0N8C4VZ9gYxDkMHlVLswwY0QTez7ZwQNjOlWHnEFscINPBN l9fprEoG2cQ1pzY9voY+ba5jQ0NHXvD36cgTk0PIAXXaG+FEriWxFq/9X+2koHBp QXluhSWMWY3TplLNQKNTU1uj01+L4lFVrPmzZP7guQjQLVcZuoJ5Kd8/JiaZ12Fl FtdC0DDVTg3QKCw7+ljhMmryfQ39XHeV84QzgWkcYXx/boh0+mXi5AYOrlffnRq/ ypBC4Kcf+CxRLafYcsrtgA5sDr4rPzC6zh91ewXGd5F0pi+m+Ofx53lkq1TDjcJQ sZzSAQjarVeTjZt6Sb0n9fllBMBNg4b6D6idYKrY+wcGNecNK/YoCWItY8jmr+5L NJfD0ykFsEr+Y53aJyU/0Gv9ahkciXeN2Bvw3ujYbBmU2wVRO3WlgNrMlbzPesIj n8pNWqEcCszN82g0463ldg+KnzCTxRw/3PGaACwx/reT3m1Iy+JonBISSEIs0Hjg 7rEdUgj2FE338aUEgokJOzPO8UrLaz/G+YshdRntGPqwY+WLzsa+8odltUhR3v+d 4R13WPIs4gxOKLcBbwsSXbjZ0FI1M1xumRfNQt+5J6TeaXs7t/XkbwDU2skhZLyR YFastfqPuNmfjMpu7N6A =hOWV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5297a68a.8020...@pocock.com.au
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-28 21:24, Daniel Pocock wrote: I've found the builds on the less used architectures have been useful for flushing out unusual bugs, particularly when the code ships with many test cases and it exposes problems for big endian machines, etc. Also, kFreeBSD and HURD are both kind of special in that they are not Linux, it would be good to keep one or the other around even if other architectures are culled more aggressively. Keeping them around is different from them being considered as release architectures (or even just keeping them in testing). Keeping these architectures in testing do involve a burden, like blocking testing migration when they FTBFS[1]. In theory they could all stay in sid provided that the relevant teams approve it. I believe the FTP masters are the authority on that. However, I would not be surprised if DSA were to object to maintaining machines running sid. ~Niels [1] Having them in testing as a F***ED and BREAK arch would remove that burden, but you might as well just use sid then. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5297acf1.4070...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
]] Niels Thykier However, I would not be surprised if DSA were to object to maintaining machines running sid. With the (grumbling) exception of new architectures where there is sometimes a bootstrapping problem, we want to run stable on buildds and porter boxes, yes. -- Tollef Fog Heen, with his DSA hat on. UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2wqjsxlks@rahvafeir.err.no
Re: Release sprint results - team changes, auto-rm and arch status
Hi Niels, On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. I wonder, how is the release team measuring this? For the other ports that you mention, you've pointed to concrete technical problems that are in line with the previously-documented release qualification guidelines. kfreebsd, OTOH, is only listed as having insufficient install base. But what is sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are greater than a number of our ports. You rightly point out that keeping the architectures in testing has a cost, because the architectures will block testing migration. But are the kfreebsd archs actually causing testing blockages, in practice? If there are such blockages, can you give us more information about how this has been the case? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
