Re: hurd-i386 qualification for Wheezy
On Thu, May 24, 2012 at 06:08:16PM +0100, Adam D. Barratt wrote: On 19.05.2012 19:04, Adam D. Barratt wrote: I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. I do not think it is sensible to release an architecture that is in broken/fucked. That's what something like debian ports is for. In order to release hurd, even as a tech preview, we need hurd in testing and users actually testing it. This is a problem at this stage because: * there isn't a functional D-I port yet * it doesn't support debian style networking (ifupdown etc) * it doesn't support any meaningful available new hardware (USB, SATA) * its archive coverage is far lower than required Thus, I do not see how we can release with the architecture. More precisely, I do not think that the architecture will give our users the same support and stability as any other architecture in the stable release, and I think that the architecture's inclusion will negatively impact the release process as a whole. Hence, I have updated the architecture release table (http://release.debian.org/wheezy/arch_qualify.html) to mark hurd as 'no' as a candidate for a release. I'm aware that this will not be the news that is wanted, but I do believe that it is the correct decision, and it would not be right to delay this further. Neil signature.asc Description: Digital signature
Re: hurd-i386 qualification for Wheezy
Neil McGovern, le Wed 30 May 2012 09:53:53 +0100, a écrit : In order to release hurd, even as a tech preview, we need hurd in testing and users actually testing it. This is a problem at this stage because: * there isn't a functional D-I port yet ?? It is functional. The last bug I was seeing, and which used to be worked around so people can use it, is now solved. It's now just about package installability. * it doesn't support debian style networking (ifupdown etc) Patch pending upload. * it doesn't support any meaningful available new hardware (USB, SATA) * its archive coverage is far lower than required Agreed. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530085856.gg3...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
On Wed, 2012-05-30 at 09:53 +0100, Neil McGovern wrote: On Thu, May 24, 2012 at 06:08:16PM +0100, Adam D. Barratt wrote: On 19.05.2012 19:04, Adam D. Barratt wrote: I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. I do not think it is sensible to release an architecture that is in broken/fucked. That's what something like debian ports is for. In order to release hurd, even as a tech preview, we need hurd in testing and users actually testing it. This is a problem at this stage because: An almost up-to-date web page about GNU/Hurd is available at: http://wiki.debian.org/Debian_GNU/Hurd * there isn't a functional D-I port yet It work perfectly well as far as I know. There are still bugs to be handled by the DMs, for example grub2: #670069, #634799, #670186, #670189 * it doesn't support debian style networking (ifupdown etc) ifupdown is supported, see wnpp bug #672212 * it doesn't support any meaningful available new hardware (USB, SATA) SATA support is in the works. * its archive coverage is far lower than required What is required, currently the percentage is 77%. How large was it when kFreeBSD was released as a tech preview in Squeeze. Take a look at the bug page, to find out how the percentage could increase: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd; 39 important bugs with patches 14 normal bug with patches 7 forwarded important and normal bugs 4 bugs pending uploads etc The introduction of GNU/Hurd in testing is not only in the hands of the porters. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338369264.8802.329.ca...@s1499.it.kth.se
Re: hurd-i386 qualification for Wheezy
Svante Signell, le Wed 30 May 2012 11:14:24 +0200, a écrit : * its archive coverage is far lower than required What is required, currently the percentage is 77%. No, it is rather 76%. How large was it when kFreeBSD was released as a tech preview in Squeeze. Simple, see the graph at that date: around 85%. Take a look at the bug page, to find out how the percentage could increase: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-hurd@lists.debian.org;tag=hurd; 39 important bugs with patches 14 normal bug with patches Those could probably be raised to important actually. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530092337.gk3...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
On Wed, 2012-05-30 at 11:23 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:14:24 +0200, a écrit : * its archive coverage is far lower than required What is required, currently the percentage is 77%. No, it is rather 76%. It would be interesting to know how large the percentage would be if all the pending bugs were attended (and including mono, that one is in the works). Is it possible to derive an estimate? -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338370284.8802.334.ca...@s1499.it.kth.se
Re: hurd-i386 qualification for Wheezy
Svante Signell, le Wed 30 May 2012 11:31:24 +0200, a écrit : On Wed, 2012-05-30 at 11:23 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:14:24 +0200, a écrit : * its archive coverage is far lower than required What is required, currently the percentage is 77%. No, it is rather 76%. It would be interesting to know how large the percentage would be if all the pending bugs were attended (and including mono, that one is in the works). Is it possible to derive an estimate? Since there are about 1 source packages, it's almost exactly 0.01% per fixed package (plus reverse dependencies). Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530093401.go3...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
On Wed, 2012-05-30 at 11:34 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:31:24 +0200, a écrit : On Wed, 2012-05-30 at 11:23 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:14:24 +0200, a écrit : * its archive coverage is far lower than required What is required, currently the percentage is 77%. No, it is rather 76%. It would be interesting to know how large the percentage would be if all the pending bugs were attended (and including mono, that one is in the works). Is it possible to derive an estimate? Since there are about 1 source packages, it's almost exactly 0.01% per fixed package (plus reverse dependencies). The tricky part are the reverse dependencies, e.g. how many more packages will build when the psmisc bug, #673485, is closed? Can this be derived with the aid of http://people.debian.org/~sthibault/graph-top.txt or http://people.debian.org/~sthibault/graph-total-top.txt -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338370977.8802.339.ca...@s1499.it.kth.se
Re: hurd-i386 qualification for Wheezy
Adam D. Barratt, le Sat 19 May 2012 19:04:40 +0100, a écrit : I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. We can as well not aim at an official release, and make an unofficial release. In my opinion that'd be already great. I have already uploaded installation CD snapshots from times to times, I'll do another with the rebuilt arch soon (otherwise people who install from CDs end up upgrading all packages :) ). Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530095455.gq3...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
Dropping the d-r Cc, they don't really care. Svante Signell, le Wed 30 May 2012 11:42:57 +0200, a écrit : On Wed, 2012-05-30 at 11:34 +0200, Samuel Thibault wrote: Since there are about 1 source packages, it's almost exactly 0.01% per fixed package (plus reverse dependencies). The tricky part are the reverse dependencies, e.g. how many more packages will build when the psmisc bug, #673485, is closed? Can this be derived with the aid of http://people.debian.org/~sthibault/graph-top.txt or http://people.debian.org/~sthibault/graph-total-top.txt It's the child. column, yes, here 37. In that particular case, there are also a dozen packages in my mbox. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530100716.gs3...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
On 30/05/12 10:54, Samuel Thibault wrote: We can as well not aim at an official release, and make an unofficial release. In my opinion that'd be already great. Sounds good, I'd love for hurd-i386 to be able to go through the motions of a release even if it's not part of the official one. Ideally I'd want to be able to download install media with jigdo, pulling packages from official mirrors (only). I'm not sure if that's possible until hurd-i386 actually enters testing? And if there are bugs / missing functionality making this not possible yet, well, that's where work is needed :) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc65f0a.9080...@pyro.eu.org
Re: hurd-i386 qualification for Wheezy
Ansgar Burchardt, le Mon 28 May 2012 13:10:32 +0200, a écrit : Samuel Thibault sthiba...@debian.org writes: - We are rebuiding the archive without debian-ports, it should be over before the end of May. debian-ports now only contains packages helpful for users; it is no longer used by the buildds since the archive rebuild started. I keep track of packages that were not yet rebuilt on [1]. It's now down to 583 packages (from 7000+ in the end of April). Note that this includes packages in experimental which I believe are not that important. A hundred of them are indeed from experimental, which I indeed hadn't scheduled for rebuild, now being done, since that can't hurt. For the rest, ~40 fail due to an oddity in the linker which does not seem to happen on Linux, but might end up there too, I'll have to dig more and detail about it on d-devel and d-gcc. 65 are waiting for the fix in libusb (#668950). A few dozens are waiting for the fix in psmisc (#673485) for php5 installability. Others are failing, mostly due to the switch to gcc-4.7 or other broken transitions, or are depending on unavailable packages, and marked as such in the wanna-build database (and thus considered as out of date). There is one odd case: gadfly can't be binNMU-ed, see #623578. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529225612.gp6...@type.famille.thibault.fr
Re: hurd-i386 qualification for Wheezy
Hi, Samuel Thibault sthiba...@debian.org writes: - We are rebuiding the archive without debian-ports, it should be over before the end of May. debian-ports now only contains packages helpful for users; it is no longer used by the buildds since the archive rebuild started. I keep track of packages that were not yet rebuilt on [1]. It's now down to 583 packages (from 7000+ in the end of April). Note that this includes packages in experimental which I believe are not that important. Ansgar [1] http://ftp-master.debian.org/users/ansgar/hurd-d-p.txt -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk8s8st3@deep-thought.43-1.org
Re: hurd-i386 qualification for Wheezy
On 19.05.2012 19:04, Adam D. Barratt wrote: Very quickly following up on a possible nomenclature issue and a couple of other things. On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote: - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. That's not what the phrase tech preview was used to mean for kfreebsd-* at least. [...] I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. Regards, Adam -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e5cd4db270a3b1679caf32483191a...@mail.adsl.funky-badger.org
Re: hurd-i386 qualification for Wheezy
On Thu, 2012-05-24 at 18:08 +0100, Adam D. Barratt wrote: On 19.05.2012 19:04, Adam D. Barratt wrote: Very quickly following up on a possible nomenclature issue and a couple of other things. On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote: - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. That's not what the phrase tech preview was used to mean for kfreebsd-* at least. [...] I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. Is there a definition of what broken and fucked means, so this could be related to. Also, is tech preview defined somewhere. Were there any descriptions made/discussions when kFreeBSD was introduced for Squeeze? -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337880647.8802.197.ca...@s1499.it.kth.se
Re: [Fwd: Re: hurd-i386 qualification for Wheezy]
On Thu, 2012-05-24 at 19:35 +0200, Svante Signell wrote: Looks like group reply in my mailer means reply only to the mailing list I have defined a filter for? Anyway, forwarding to debian-release too. *checks headers* You wanted reply all, predictably enough. Which means this is now annoyingly unthreaded. You also didn't copy -hurd on your forward... On Thu, 2012-05-24 at 18:08 +0100, Adam D. Barratt wrote: I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. Is there a definition of what broken and fucked means, so this could be related to. Well, the question was primarily aimed at members of the Release Team, who know what the terms mean. In short, an architecture is broken if a source package may migrate even though doing so causes new uninstallability on that architecture. A fucked architecture is one on which source packages may migrate even if the packages have not yet been built on the architecture. Also, is tech preview defined somewhere. Were there any descriptions made/discussions when kFreeBSD was introduced for Squeeze? Phil already addressed this. Regards, Adam -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337883952.25124.6.ca...@jacala.jungle.funky-badger.org
Re: hurd-i386 qualification for Wheezy
Hi Samuel, On Samstag, 19. Mai 2012, Samuel Thibault wrote: Concerning hardware support, Linux 2.6.32 network drivers are now included and will be used by default in the coming days. That provides a fairly good coverage of not too-new hardware. We are working on integrating the linux AHCI driver to support SATA HDDs. Concerning X.org, drivers which do not require drm should be working. At worse, the vesa driver should work. There is no USB support, no sound support. On a (very) personal note, the apparent lack of HW support is making it look very bad… Which lack, more precisely? no usb = no keyboard (+other things, obviously) no sata = pretty bad in 2012 no drm xorg drivers + no sound = also pretty bad. cheers, Holger, I am excited to see the hurd come alive, finally! but... -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205211044.40297.hol...@layer-acht.org
Re: hurd-i386 qualification for Wheezy
Holger Levsen, le Mon 21 May 2012 10:44:39 +0200, a écrit : Holger, I am excited to see the hurd come alive, finally! but... A lot of people are excited, yes. Extremely few have to to contribute. The result is not surprising: we've spent the extremely little time we have on making it at least work. If people want something, they have to help on it. (not to be taken personnally, it's really a general comment, that also applies to kFreeBSD, to Xorg, the debian installer in general, etc. etc.) Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521084945.gt7...@type.famille.thibault.fr
Re: hurd-i386 qualification for Wheezy
Samuel Thibault, le Mon 21 May 2012 10:49:45 +0200, a écrit : Holger Levsen, le Mon 21 May 2012 10:44:39 +0200, a écrit : Holger, I am excited to see the hurd come alive, finally! but... A lot of people are excited, yes. Extremely few have to to contribute. have come to The result is not surprising: we've spent the extremely little time we have on making it at least work. And actually, it's also surprising to see what we have managed to achieve, despite the very small available manpower. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521090717.ga10...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
On Mon, 2012-05-21 at 10:44 +0200, Holger Levsen wrote: Hi Samuel, ... Which lack, more precisely? no usb = no keyboard (+other things, obviously) no sata = pretty bad in 2012 no drm xorg drivers + no sound = also pretty bad. Well, currently GNU/Hurd works OK in a VM, like kvm. A lot of development and porting can be made there. For DMs and DDs there are a number of public Hurd boxes available: http://www.gnu.org/software/hurd/public_hurd_boxen.html And don't forget that we are talking a tech preview, like kFreeBSD with Squeeze, not a full release. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337592330.5450.27.ca...@hp.my.own.domain
Re: hurd-i386 qualification for Wheezy
Svante Signell, le Mon 21 May 2012 11:25:30 +0200, a écrit : On Mon, 2012-05-21 at 10:44 +0200, Holger Levsen wrote: Which lack, more precisely? no usb = no keyboard (+other things, obviously) no sata = pretty bad in 2012 no drm xorg drivers + no sound = also pretty bad. Well, currently GNU/Hurd works OK in a VM, like kvm. More than that, it should with with any machine that is not recent, i.e. IDE disk and network boards supported by linux 2.6.32. I'm working on an AHCI driver for SATA devices, but that can only work if I don't have to spend my time on other issues. And don't forget that we are talking a tech preview, like kFreeBSD with Squeeze, not a full release. Yes. People tend to forget that some time ago, Linux itself had been very bad at supporting not so recent hardware... It's only now that it is mainstream that it's a lot less a problem. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521093148.gd10...@type.bordeaux.inria.fr
Re: hurd-i386 qualification for Wheezy
On Sat, May 19, 2012 at 08:20:13PM +0200, Andreas Barth wrote: For security updates (i.e. after release), we need two DSAed buildds. Having DSAed buildds allows also to do autosigning, which shortens the time span for getting builds into the archive. This isn't strictly required, but not doing so will sometimes lead to annoying delays for testing transitions (when the architecture is in testing, and the mark this arch is too slow removed). The security team basically already requires autosigning for security suites. But given that we only build security on DSAed buildds, the two can go hand in hand. Just a very minor clarification. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: hurd-i386 qualification for Wheezy
Hello, Adam D. Barratt, le Wed 16 May 2012 13:19:46 +0100, a écrit : Comments on / additions and corrections to the content of http://release.debian.org/wheezy/arch_qualify.html would be appreciated, as would any other information you think is relevant to helping us determine hurd-i386's status for the release. First, a quick summary of points that we believe are important: - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. - We are rebuiding the archive without debian-ports, it should be over before the end of May. debian-ports now only contains packages helpful for users; it is no longer used by the buildds since the archive rebuild started. - The archive coverage has passed 75%, and we believe it is fairly good already for a non-Linux non-BSD architecture, i.e. which was almost not exposed to upstream at all. Our long-term goal is of course to continue to port further packages, and the general trend as seen on https://buildd.debian.org/stats/graph.png is positive. - The buildds are keeping up fine nowadays, so the 96% uptodate figure should improve once the current issues are resolved. - It is fine to us to see problematic binary builds (e.g. blocking testing migrations eventually) be removed, even if they have a couple of rev-deps. Some questions/open issues for the release team: - About entering testing: apart for the archive rebuild, is there any remaining requirement or improvement from our side to fulfill still, or is it just for the release team to decide? - How are discussions about the concerns-* fields coordinated? Is the release team going to inquire those, or should we? - About buildd-fast-sec, we do have some fast buildd, it is a matter of enabling a security chroot after a testing distribution is introduced. - About buildd-dsa, we are fine with a DSA'd buildd, if DSA is happy to maintain it, they will however probably have to learn a few Hurd things? We don't know to what extend DSA have to tinker with the machine, but we would be happy to help. Now some more verbosity: Concerning portbox, it should probably be rather pointed at exodar, strauss is running on quite old and slow hardware. Concerning the installer, there is just one bug left during template loading that we need to find a proper fix for (our current images use a workaround). Concerning the archive coverage, the 76% figure should be accurate for the current state. The freeze period should allow us to continue increasing it more easily (no new upstream releases). If you look at the current buildd figures, we are rather at 75%, this is due to current transitions, the gcc-4.7 FTBFSes, and webkit FTBFS (about to be fixed). Concerning buildds, we have set up a 4th one in a third place, improving redundancy. Concerning installability, it currently can not really be measured because the latest upstream webkit release is once more broken for some trivial reasons, #669059, making a big part of gnome uninstallable. The haskell transition doesn't help either :) Concerning buildd-fast-sec and buildd-dsa, we simply haven't taken time to set them up, essentially to spend it on other tasks. We welcome advise on when would be preferrable to spent time on it. Concerning hardware support, Linux 2.6.32 network drivers are now included and will be used by default in the coming days. That provides a fairly good coverage of not too-new hardware. We are working on integrating the linux AHCI driver to support SATA HDDs. Concerning X.org, drivers which do not require drm should be working. At worse, the vesa driver should work. There is no USB support, no sound support. Concerning the debian-ports packages, it is probably good to provide more details. The status is tracked on our wiki page: http://wiki.debian.org/Debian_GNU/Hurd The packages that had been there and are now gone have simply been merged in main, except in one case, gcc-4.6 and binutils, described a couple of paragraphs below. The remaining packages are either - new Hurd-specific packages (marked hurd-any). - patched packages which are now waiting for an upload to main. Some of them have actually already been merged upstream. We were building packages with debian-ports essentially because patches for non-released non-Linux architectures take time to be accepted, and in a few important cases stalled progress because there is always something broken, even if only in a trivial way, particularly for a non-Linux and non-*BSD arch. With the recent fix of pulseaudio (at last!), we have started on 30th April to rebuild the whole archive without debian-ports for good measure. It is currently at 5500 over 7300 packages, with k* and g* behind, so we expect it to complete before the end of May. The exception to patches being merged to main is about an issue
Re: hurd-i386 qualification for Wheezy
(Ewww, long lines) Please keep in mind I'm quite new in the release team, so I'll just reply on some points that stroke me. I don't speak for the team as a whole. Samuel Thibault sthiba...@debian.org (19/05/2012): - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. Starting a testing distribution for an arch less than a month before a freeze doesn't smell too good to me. - It is fine to us to see problematic binary builds (e.g. blocking testing migrations eventually) be removed, even if they have a couple of rev-deps. Including big packages like say webkit or kde4libs or anything similar? Concerning the archive coverage, the 76% figure should be accurate for the current state. The freeze period should allow us to continue increasing it more easily (no new upstream releases). If you look at the current buildd figures, we are rather at 75%, this is due to current transitions, the gcc-4.7 FTBFSes, and webkit FTBFS (about to be fixed). I wouldn't be very happy to see unblock requests just to get hurd-i386 fixes in testing, if that's what you're suggesting. We already have plenty of work to do without having to deal with that kind of requests. Concerning installability, it currently can not really be measured because the latest upstream webkit release is once more broken for some trivial reasons, #669059, making a big part of gnome uninstallable. The haskell transition doesn't help either :) Exactly the kind of situation that led my asking about removals of problematic binaries above. Concerning hardware support, Linux 2.6.32 network drivers are now included and will be used by default in the coming days. That provides a fairly good coverage of not too-new hardware. We are working on integrating the linux AHCI driver to support SATA HDDs. Concerning X.org, drivers which do not require drm should be working. At worse, the vesa driver should work. There is no USB support, no sound support. On a (very) personal note, the apparent lack of HW support is making it look very bad… Concerning the debian-ports packages, it is probably good to provide more details. The status is tracked on our wiki page: http://wiki.debian.org/Debian_GNU/Hurd From there, basic stuff like working local sockets and select() might be missing… “Get Xorg + gnome/kde/xfce (xfce should work, kde is missing working dbus (due to local socket auth and bugs in select() cornercases)) + some webbrowser working (iceweasel 9 works, though not https).” Bottom line for me: - way too late in the release cycle to consider adding hurd-i386 to testing (even as a bad arch). - not happy with unblocking packages just to get hurd-i386 fixes in, already plenty of bugs to deal with on real architectures. Mraw, KiBi. signature.asc Description: Digital signature
Re: hurd-i386 qualification for Wheezy
Hi,
Very quickly following up on a possible nomenclature issue and a couple
of other things.
On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote:
- We of course aim at tech preview for wheezy only, not a full
release. Our goal is to establish a testing distribution for wheezy
which does not block others ports (i.e. so-called fuckedarch), and get
a full testing for wheezy+1.
That's not what the phrase tech preview was used to mean for
kfreebsd-* at least.
They were added to testing via {fucked,broken}arches some time in
mid-2009 (it's mentioned in a dda posting in July, the britney config
change didn't hit get until August), declared to be release
architectures in October and were also removed from fuckedarches soon
after - i.e. kfreebsd-* specific issues became RC and out-of-dateness on
those architectures was a blocker for migration. At some point before
February 2010 (when I committed the change which had been lurking
uncommitted on the live code branch) they were removed from brokenarches
too and installability issues became RC.
I'm not sure we've ever released with an architecture which was in
either broken or fucked, but hopefully someone will correct me if I'm
mistaken on that.
Some questions/open issues for the release team:
[...]
- How are discussions about the concerns-* fields coordinated? Is the
release team going to inquire those, or should we?
Either works, although I suspect we can manage to ask ourselves about
the {S,}RM ones... ;-) Feel free to ask DSA and the security team,
preferably somewhere public that could be pointed to for the record.
- About buildd-dsa, we are fine with a DSA'd buildd, if DSA is happy
to maintain it, they will however probably have to learn a few Hurd
things? We don't know to what extend DSA have to tinker with the
machine, but we would be happy to help.
I think the prevailing view recently has been that having DSAed buildds
and porter boxes is generally preferable; this might be something to
cover under the above discussion with DSA.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1337450680.29502.34.ca...@jacala.jungle.funky-badger.org
Re: hurd-i386 qualification for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120519 20:06]: On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote: - About buildd-dsa, we are fine with a DSA'd buildd, if DSA is happy to maintain it, they will however probably have to learn a few Hurd things? We don't know to what extend DSA have to tinker with the machine, but we would be happy to help. I think the prevailing view recently has been that having DSAed buildds and porter boxes is generally preferable; this might be something to cover under the above discussion with DSA. For security updates (i.e. after release), we need two DSAed buildds. Having DSAed buildds allows also to do autosigning, which shortens the time span for getting builds into the archive. This isn't strictly required, but not doing so will sometimes lead to annoying delays for testing transitions (when the architecture is in testing, and the mark this arch is too slow removed). (Please also note that as Adam pointed out any new arch will start to live with arch is too slow and packages might break in testing, because otherwise next to all testing transitions will be broken (until more or less all packages are moved to testing).) Andi -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519182013.ge2...@mails.so.argh.org
Re: hurd-i386 qualification for Wheezy
Hello, Cyril Brulebois, le Sat 19 May 2012 19:41:56 +0200, a écrit : (Ewww, long lines) Oops, sorry, I forgot to reindent after import from the pad. Samuel Thibault sthiba...@debian.org (19/05/2012): - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. Starting a testing distribution for an arch less than a month before a freeze doesn't smell too good to me. Well, doing it before might have meant more work for everybody. - It is fine to us to see problematic binary builds (e.g. blocking testing migrations eventually) be removed, even if they have a couple of rev-deps. Including big packages like say webkit or kde4libs or anything similar? I guess we have to say yes. Concerning the archive coverage, the 76% figure should be accurate for the current state. The freeze period should allow us to continue increasing it more easily (no new upstream releases). If you look at the current buildd figures, we are rather at 75%, this is due to current transitions, the gcc-4.7 FTBFSes, and webkit FTBFS (about to be fixed). I wouldn't be very happy to see unblock requests just to get hurd-i386 fixes in testing, if that's what you're suggesting. Even when they are just e.g. #include or configure.ac cases? Concerning installability, it currently can not really be measured because the latest upstream webkit release is once more broken for some trivial reasons, #669059, making a big part of gnome uninstallable. The haskell transition doesn't help either :) Exactly the kind of situation that led my asking about removals of problematic binaries above. Well, the problem is that as long as hurd-i386 port is not released in any sort, people care less about it. A patch was submitted to the webkit package quite soon actually, but it wasn't applied just because it was out of the maintainer's radar, and he didn't notice it, while the exact same patch, submitted to fix kfreebsd, was quickly applied, since its severity was serious. Concerning hardware support, Linux 2.6.32 network drivers are now included and will be used by default in the coming days. That provides a fairly good coverage of not too-new hardware. We are working on integrating the linux AHCI driver to support SATA HDDs. Concerning X.org, drivers which do not require drm should be working. At worse, the vesa driver should work. There is no USB support, no sound support. On a (very) personal note, the apparent lack of HW support is making it look very bad… Which lack, more precisely? Concerning the debian-ports packages, it is probably good to provide more details. The status is tracked on our wiki page: http://wiki.debian.org/Debian_GNU/Hurd From there, basic stuff like working local sockets and select() might be missing… See more precisely below: local socket *auth*, and bug in select() in *cornercases*. These are really corner cases, which have gotten apparent only recently, and don't pose problem for the vast majority of packages. “Get Xorg + gnome/kde/xfce (xfce should work, kde is missing working dbus (due to local socket auth and bugs in select() cornercases)) + some webbrowser working (iceweasel 9 works, though not https).” Bottom line for me: - way too late in the release cycle to consider adding hurd-i386 to testing (even as a bad arch). Well, I wonder when it would have been preferrable. Before now we didn't have pulseaudio fixed, which was making a lot of packages uninstallable. Chicken and egg... - not happy with unblocking packages just to get hurd-i386 fixes in, already plenty of bugs to deal with on real architectures. Mmm, I thought the first part of the freeze was just not allowing new upstream versions or such, but would still permit fixes. I guess I'm too new to the release process to know. If not, well, then we have a figure already: 76% should be what we have now. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519215929.gs...@type.famille.thibault.fr
Re: hurd-i386 qualification for Wheezy
On 19.05.2012 23:59, Samuel Thibault wrote: Hello, Cyril Brulebois, le Sat 19 May 2012 19:41:56 +0200, a écrit : (Ewww, long lines) Oops, sorry, I forgot to reindent after import from the pad. Samuel Thibault sthiba...@debian.org (19/05/2012): - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. Starting a testing distribution for an arch less than a month before a freeze doesn't smell too good to me. Well, doing it before might have meant more work for everybody. - It is fine to us to see problematic binary builds (e.g. blocking testing migrations eventually) be removed, even if they have a couple of rev-deps. Including big packages like say webkit or kde4libs or anything similar? I guess we have to say yes. Concerning the archive coverage, the 76% figure should be accurate for the current state. The freeze period should allow us to continue increasing it more easily (no new upstream releases). If you look at the current buildd figures, we are rather at 75%, this is due to current transitions, the gcc-4.7 FTBFSes, and webkit FTBFS (about to be fixed). I wouldn't be very happy to see unblock requests just to get hurd-i386 fixes in testing, if that's what you're suggesting. Even when they are just e.g. #include or configure.ac cases? Concerning installability, it currently can not really be measured because the latest upstream webkit release is once more broken for some trivial reasons, #669059, making a big part of gnome uninstallable. The haskell transition doesn't help either :) Exactly the kind of situation that led my asking about removals of problematic binaries above. Well, the problem is that as long as hurd-i386 port is not released in any sort, people care less about it. A patch was submitted to the webkit package quite soon actually, but it wasn't applied just because it was out of the maintainer's radar, and he didn't notice it, while the exact same patch, submitted to fix kfreebsd, was quickly applied, since its severity was serious. Once an architectures is a release architecture and a package is in testing, it becomes a burden for the maintainer. We have to do all sorts of workarounds to make packages build on all available architectures. This means includes disabling test suites on problematic archs and, like kfreebsd* or e.g. ia64 (webkit, seed, ...), or just compiling dummy stubs. All we basically care for is that the package builds, not that it actually is working. I've experienced this a couple of times during the last months/years. This is a bad trend, imho I'd rather see us enable test-suites and make the failures fatal. But this would mean we suddenly get a lot of FTBFS and we are no longer able to get packages into testing. This is very unfortunate. I'd be *very* unhappy if hurd became an architecture that blocks packages from migrating to testing. We already have enough problems with kfreebsd. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: hurd-i386 qualification for Wheezy
Hi everybody, On Wed, May 16, 2012 at 01:19:46PM +0100, Adam D. Barratt wrote: With the sound of the ever approaching freeze ringing loudly in our ears, we're (somewhat belatedly) looking at finalising the list of release architectures for the Wheezy release. Comments on / additions and corrections to the content of http://release.debian.org/wheezy/arch_qualify.html would be appreciated, as would any other information you think is relevant to helping us determine hurd-i386's status for the release. We are working on a reply in the moment, please do not post uncoordinated answers or comments to debian-release. Cheers, Michael -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516123202.ge2...@nighthawk.chemicalconnection.dyndns.org
