Re: architecture qualification season
On Sat, May 02, 2020 at 09:53:49PM +0200, Paul Gevers wrote: >... > 3) In the current state, I think it boils down to the question if armel > and mipsel should be dropped for bullseye or not. What do we think > ourselves? Myself, I've been regularly cursing mipsel for it being so > much slower to build packages than most architectures, but I don't think > that's enough ;). Also, the limited address space of 32 bit > architectures is lowest on mipsel and it is starting to count. I've seen > several issues due to it (e.g. rustc), meaning that maintainers of some > large packages need to spend serious effort to build their package on > mipsel. I feel that several maintainers seriously doubt that effort is > well spent. s390x is the last big endian release architecture. Most address space problems can be workarounded with a few basic tricks, endian porting is always manual work. Usually upstream does not have access to big endian hardware. Additionally the server-only nature of the port is a problem, I could e.g. imagine that the GNOME maintainers might not miss s390x. s390x does not have (m)any users who would report bugs early. If something is broken on armel in unstable plenty of users report bugs, I don't see bugs in the BTS from normal s390x users. Any discussion about dropping architectures for bullseye would be incomplete if dropping s390x is not on the agenda. > Paul >... cu Adrian
Re: architecture qualification season
On 2020-05-15 08:23, YunQiang Su wrote: > Matthias Klose 于2020年5月14日周四 下午11:45写道： > > > > On 5/7/20 9:41 PM, Paul Gevers wrote: > > > Hi > > > > > > On 02-05-2020 21:53, Paul Gevers wrote: > > >> I don't think anybody likes to do it, but we have to discuss the > > >> architectures that will be part of bullseye. In the before last IRC > > >> meeting I promised I would send this mail, so here we go. Let's see what > > >> items we consider a must. Anybody else that wants to step in, feel free > > >> to take any action. > > >> > > >> 1) I haven't heard of new architectures that want to be on board for > > >> bullseye. > > >> > > >> 2) I think we have to ask several parties if they are OK with supporting > > >> the existing architectures: porters, DSA and security. I recall [1] DSA > > >> had issues with armel, but I believe that has been resolved by building > > >> on some other arm boxes, right? Do we already know of other issues? > > > > > > I found this mail from Niels from the buster release cycle [2]. Going > > > through it, it looks like it could be reused nearly completely. > > > > > >> 3) In the current state, I think it boils down to the question if armel > > >> and mipsel should be dropped for bullseye or not. What do we think > > >> ourselves? Myself, I've been regularly cursing mipsel for it being so > > >> much slower to build packages than most architectures, but I don't think > > >> that's enough ;). Also, the limited address space of 32 bit > > >> architectures is lowest on mipsel and it is starting to count. I've seen > > >> several issues due to it (e.g. rustc), meaning that maintainers of some > > >> large packages need to spend serious effort to build their package on > > >> mipsel. I feel that several maintainers seriously doubt that effort is > > >> well spent. > > > > > > The 32 bit issue was discussed for buster quite extensively. > > > > There are now also attempts to package binutils64 and gcc-N-64 to build a > > 64bit > > toolchain on at least mipsel and i386. As a maintainer I'm not keen to add > > these builds to the binutils and gcc-N packages. > > bintuils64 is in our repo now. > > > > > In additions to the concerns in [2], there are also a bunch of mips* patches > > which are not yet integrated upstream in binutils and GCC. > > For gcc, there are 2 patch for ffi. It is strange that gcc upstream > hasn't sync libffi for long. I have sent a patch sometimes ago to sync the mips part from upstream libffi [1]. It has been rejected as the solution is to sync the full libffi from upstream. However there have been many commits from other architectures that have been accepted contrary to the mips one, and both trees have now diverged, with some patches applied on the GCC side but not propagated to the libffi side. In short it's a huge work touching many architectures. Aurelien [1] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00304.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: architecture qualification season
Matthias Klose 于2020年5月14日周四 下午11:45写道： > > On 5/7/20 9:41 PM, Paul Gevers wrote: > > Hi > > > > On 02-05-2020 21:53, Paul Gevers wrote: > >> I don't think anybody likes to do it, but we have to discuss the > >> architectures that will be part of bullseye. In the before last IRC > >> meeting I promised I would send this mail, so here we go. Let's see what > >> items we consider a must. Anybody else that wants to step in, feel free > >> to take any action. > >> > >> 1) I haven't heard of new architectures that want to be on board for > >> bullseye. > >> > >> 2) I think we have to ask several parties if they are OK with supporting > >> the existing architectures: porters, DSA and security. I recall [1] DSA > >> had issues with armel, but I believe that has been resolved by building > >> on some other arm boxes, right? Do we already know of other issues? > > > > I found this mail from Niels from the buster release cycle [2]. Going > > through it, it looks like it could be reused nearly completely. > > > >> 3) In the current state, I think it boils down to the question if armel > >> and mipsel should be dropped for bullseye or not. What do we think > >> ourselves? Myself, I've been regularly cursing mipsel for it being so > >> much slower to build packages than most architectures, but I don't think > >> that's enough ;). Also, the limited address space of 32 bit > >> architectures is lowest on mipsel and it is starting to count. I've seen > >> several issues due to it (e.g. rustc), meaning that maintainers of some > >> large packages need to spend serious effort to build their package on > >> mipsel. I feel that several maintainers seriously doubt that effort is > >> well spent. > > > > The 32 bit issue was discussed for buster quite extensively. > > There are now also attempts to package binutils64 and gcc-N-64 to build a > 64bit > toolchain on at least mipsel and i386. As a maintainer I'm not keen to add > these builds to the binutils and gcc-N packages. bintuils64 is in our repo now. > > In additions to the concerns in [2], there are also a bunch of mips* patches > which are not yet integrated upstream in binutils and GCC. For gcc, there are 2 patch for ffi. It is strange that gcc upstream hasn't sync libffi for long. For binutils: there are mips64-default-n64.diff and gold-mips.diff. I will try to feedback them. > > mipsel buildds also seem to be the slowest buildds among the buildds for > release > architectures. > I get some new machines, and we will replace some old ones wit them. They are much faster than the current ones. > Matthias > > >> [1] https://release.debian.org/bullseye/arch_qualify.html > > > > Paul > > > > [2] https://lists.debian.org/debian-release/2018/06/msg00644.html > > > -- YunQiang Su
Re: architecture qualification season
On 5/7/20 9:41 PM, Paul Gevers wrote: > Hi > > On 02-05-2020 21:53, Paul Gevers wrote: >> I don't think anybody likes to do it, but we have to discuss the >> architectures that will be part of bullseye. In the before last IRC >> meeting I promised I would send this mail, so here we go. Let's see what >> items we consider a must. Anybody else that wants to step in, feel free >> to take any action. >> >> 1) I haven't heard of new architectures that want to be on board for >> bullseye. >> >> 2) I think we have to ask several parties if they are OK with supporting >> the existing architectures: porters, DSA and security. I recall [1] DSA >> had issues with armel, but I believe that has been resolved by building >> on some other arm boxes, right? Do we already know of other issues? > > I found this mail from Niels from the buster release cycle [2]. Going > through it, it looks like it could be reused nearly completely. > >> 3) In the current state, I think it boils down to the question if armel >> and mipsel should be dropped for bullseye or not. What do we think >> ourselves? Myself, I've been regularly cursing mipsel for it being so >> much slower to build packages than most architectures, but I don't think >> that's enough ;). Also, the limited address space of 32 bit >> architectures is lowest on mipsel and it is starting to count. I've seen >> several issues due to it (e.g. rustc), meaning that maintainers of some >> large packages need to spend serious effort to build their package on >> mipsel. I feel that several maintainers seriously doubt that effort is >> well spent. > > The 32 bit issue was discussed for buster quite extensively. There are now also attempts to package binutils64 and gcc-N-64 to build a 64bit toolchain on at least mipsel and i386. As a maintainer I'm not keen to add these builds to the binutils and gcc-N packages. In additions to the concerns in [2], there are also a bunch of mips* patches which are not yet integrated upstream in binutils and GCC. mipsel buildds also seem to be the slowest buildds among the buildds for release architectures. Matthias >> [1] https://release.debian.org/bullseye/arch_qualify.html > > Paul > > [2] https://lists.debian.org/debian-release/2018/06/msg00644.html >
Re: architecture qualification season
Hi On 02-05-2020 21:53, Paul Gevers wrote: > I don't think anybody likes to do it, but we have to discuss the > architectures that will be part of bullseye. In the before last IRC > meeting I promised I would send this mail, so here we go. Let's see what > items we consider a must. Anybody else that wants to step in, feel free > to take any action. > > 1) I haven't heard of new architectures that want to be on board for > bullseye. > > 2) I think we have to ask several parties if they are OK with supporting > the existing architectures: porters, DSA and security. I recall [1] DSA > had issues with armel, but I believe that has been resolved by building > on some other arm boxes, right? Do we already know of other issues? I found this mail from Niels from the buster release cycle [2]. Going through it, it looks like it could be reused nearly completely. > 3) In the current state, I think it boils down to the question if armel > and mipsel should be dropped for bullseye or not. What do we think > ourselves? Myself, I've been regularly cursing mipsel for it being so > much slower to build packages than most architectures, but I don't think > that's enough ;). Also, the limited address space of 32 bit > architectures is lowest on mipsel and it is starting to count. I've seen > several issues due to it (e.g. rustc), meaning that maintainers of some > large packages need to spend serious effort to build their package on > mipsel. I feel that several maintainers seriously doubt that effort is > well spent. The 32 bit issue was discussed for buster quite extensively. > Paul > > [1] https://release.debian.org/bullseye/arch_qualify.html Paul [2] https://lists.debian.org/debian-release/2018/06/msg00644.html signature.asc Description: OpenPGP digital signature
Re: Architecture qualification meeting
On 2016-10-30 12:23 +, Jonathan Wiltshire wrote: > Architecture qualification for Debian 9 'Stretch' will take place in > oftc/#debian-release on Sun Oct 30 20:00:00 UTC 2016. > > (With apologies for the short notice.) Too short for me, sorry. Missed it. Hopefully that didn't matter. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Architecture qualification meeting
On Sun, 2016-10-30 at 22:08 +0900, John Paul Adrian Glaubitz wrote: > In case you're going to axe powerpc - which I assume you will - please let > it at least exist in Debian Ports. The Release Team don't manage the Ports archive. It's not in our gift to decide which architectures it contains. Regards, Adam
Re: Architecture qualification meeting
On Sun, Oct 30, 2016 at 12:23:32PM +, Jonathan Wiltshire wrote: >Architecture qualification for Debian 9 'Stretch' will take place in >oftc/#debian-release on Sun Oct 30 20:00:00 UTC 2016. > >The meeting is primarily a discussion amongst the release team. We will >evaluate each port on the most up-to-date information available to us, >and determine if it will be a release architecture for Stretch (taking >input from other teams with an interest, such as DSA). > >Other participants are welcome, but we ask that you are read-only unless >we need information from you. > >(With apologies for the short notice.) Crap. I know I said I could make it, but at short notice a family thing has just come up and I probably won't be around today. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Re: Architecture qualification meeting
On 10/30/2016 09:23 PM, Jonathan Wiltshire wrote: > Architecture qualification for Debian 9 'Stretch' will take place in > oftc/#debian-release on Sun Oct 30 20:00:00 UTC 2016. Ugh, that would be 4 AM here in Hong Kong where I currently am. Had hoped this discussion could have been held in November when I'm back in Europe. In case you're going to axe powerpc - which I assume you will - please let it at least exist in Debian Ports. It's far too popular that we can just kill it and it would leave a very bad impression on Debian's reputation of being universal when we drop support for something lots of people are still using. I would again be happy to volunteer as a porter. Already fixed firebird3.0 on powerpc, for example. In any case, I'm very curious of the outcome of the meeting. Thanks, Adrian -- .''`. 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
Re: Architecture qualification meeting, scheduling
Adrian Bunk:
> [ fullquote adding -ports, for people not following -release or -devel ]
>
> [...]
>
> Is https://release.debian.org/stretch/arch_qualify.html the up-to-date
> information available to you, and the "candidate" line how a decision
> would look like based on the current information?
>
> cu
> Adrian
>
It reflects all the issues we are aware of at the present time (except
for archive-{coverage,uptodate}, which can be seen from
https://buildd.debian.org/stats/).
If you believe we have overlooked an issue or an update, please do not
hesitate to let us know. :)
Thanks,
~Niels
Re: Architecture qualification meeting, scheduling
[ fullquote adding -ports, for people not following -release or -devel ]
On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
>
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also take
> input from porters.
>
> As the schedule is currently wide open, please express your availability in
> the linked Doodle poll. There are 56 slots available, mostly in the European
> evening but a handful are daytime coinciding with the Cambridge
> mini-Debconf.
>
> Porters, please note your architecture in your response ("name (arch)").
>
> About the format of the meeting:
> Much like the Jessie meeting, it will be held via IRC in
> oftc.net/#debian-release and will be primarily a discussion amongst the
> release team. We will evaluate each port on the most up-to-date information
> available to us, and determine if it will be a release architecture for
> Stretch. We may ask for clarification from porters who are present if there
> are points at issue, but we ask that you are read-only otherwise.
>
> http://doodle.com/poll/362qvb89cvu43d4z
Is https://release.debian.org/stretch/arch_qualify.html the up-to-date
information available to you, and the "candidate" line how a decision
would look like based on the current information?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Re: Architecture qualification
On Mon, 4 Jun 2012 15:37:14 +0200 Holger Levsen wrote: > > No, this time the work is based on the DDE framework, recently > > successfully implemented for network drivers. Ask Samuel Thibault > > for more details if interested, he is the person in charge. BTW: > > USB support might also be possible within the DDE framework. > > show me the code in unstable aka sid, please... (or exp. is fine as > well...) DDE for network drivers has been in sid for a while now: http://packages.debian.org/sid/netdde http://packages.qa.debian.org/n/netdde.html SATA support isn't yet as far as I know, if that's what you were asking about. But as Svante said, that will use the same DDE framework. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120605000709.71864...@vader.steven-mcdonald.id.au
Re: Architecture qualification
On Montag, 4. Juni 2012, Svante Signell wrote: > Do you mean gnome3 and KDE4/5 here, or maybe DRM? DRM > No, this time the work is based on the DDE framework, recently > successfully implemented for network drivers. Ask Samuel Thibault for > more details if interested, he is the person in charge. BTW: USB support > might also be possible within the DDE framework. show me the code in unstable aka sid, please... (or exp. is fine as well...) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206041537.15479.hol...@layer-acht.org
Re: Architecture qualification
On Mon, 2012-06-04 at 13:23 +0200, Holger Levsen wrote: > Hi, > > On Montag, 4. Juni 2012, Svante Signell wrote: > > One issue is how to encourage more people trying Hurd out, when it is > > not in testing. > > I honestly don't think that's the main blocker trying out hurd. Lack of SATA, > and USB support are the blocker, I think. Might be so, yes. > And probably also missing meaningful > graphics output puts many people off. Do you mean gnome3 and KDE4/5 here, or maybe DRM? > Having SATA (or whatever feature) "in > the works" is also meaningless, as hurd is "in the works" for years. No, this time the work is based on the DDE framework, recently successfully implemented for network drivers. Ask Samuel Thibault for more details if interested, he is the person in charge. BTW: USB support might also be possible within the DDE framework. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338816345.8802.500.ca...@s1499.it.kth.se
Re: Re: Architecture qualification
On Sat, Jun 02, 2012 at 12:22:14AM +0200, Svante Signell wrote: > On Thu, 2012-05-31 at 16:18 +0200, Svante Signell wrote: > > From the one of the porters side, this would be a _very_ good solution > > indeed! If GNU/Hurd enters som kind of testing status, the number of > > users and contributors will increase (hopefully). Can it be part of > > testing and then when the release happens, be treated specially? And > > most packages will be located in the main repo, only the packages having > > patches, not yet handled by the DMs, being there. Is that possible? > > > > BTW: Are builds reported to buildd.debian.org already, it is > > visible ate least in the table on https://buildd.debian.org/, or maybe > > Samuel meant something else > > In my world it is considered polite to answer questions asked. Even if > you don't have the time to reply properly, just say so. I'm still > waiting for some kind of feedback, especially the questions. > > I assume this is not a regular mail correspondence, is it? > I generally consider it polite to give people an opportunity to respond before assuming that you're being ignored, especially if it's part of a longer thread. As per my previous mail, I will not be adding hurd to testing for this release. It would affect the release as a whole, and I'm not happy doing that. Neil -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120604095624.gu5...@camblue.cbg.collabora.co.uk
Re: Architecture qualification
Hi, On Montag, 4. Juni 2012, Svante Signell wrote: > One issue is how to encourage more people trying Hurd out, when it is > not in testing. I honestly don't think that's the main blocker trying out hurd. Lack of SATA, and USB support are the blocker, I think. And probably also missing meaningful graphics output puts many people off. Having SATA (or whatever feature) "in the works" is also meaningless, as hurd is "in the works" for years. cheers, Holger -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206041323.08900.hol...@layer-acht.org
Re: Re: Architecture qualification
On Mon, 2012-06-04 at 10:56 +0100, Neil McGovern wrote: > > I assume this is not a regular mail correspondence, is it? > > > > I generally consider it polite to give people an opportunity to respond > before assuming that you're being ignored, especially if it's part of a > longer thread. Maybe three days is a little short for a mailing list correspondence. > As per my previous mail, I will not be adding hurd to testing for this > release. It would affect the release as a whole, and I'm not happy doing > that. Ok, understood. So getting into testing after the release of Wheezy is a more resonable target. Just a small remark, two (three) of the four reasons for not adding Hurd to testing was shown false. D-I OK, ifupdown OK, SATA support in the works, the major obstacle seems to be the still too low package count. One issue is how to encourage more people trying Hurd out, when it is not in testing. It is very easy to install, e.g. in a VM, and there are a number of public Hurd boxen for DMs, DDs, upstream and everybody interested as well, http://www.gnu.org/software/hurd/public_hurd_boxen.html -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338805550.5450.192.ca...@hp.my.own.domain
Re: Re: Architecture qualification
On 6/1/12, Michael Banck wrote: > Hi, > > On Thu, May 31, 2012 at 04:18:30PM +0200, Svante Signell wrote: >> On 28/05/12 01:52, Steven Chamberlain wrote: >> > On 29/05/12 19:57, Andreas Barth wrote: >> > > [...] we add hurd-i386 to testing with >> > > break/fucked, but we don't expect it to make the release. I.e. bugs >> > > for hurd-i386 are not RC. >> > >> > Maybe that's all that's needed? >> > >> > The recent enthusiasm sounds to me like an opportunity. An official >> > testing suite in the archive, from which usable installer images can be >> > built, could be what encourages hurd-i386 to progress into something >> > really releasable. If this doesn't happen now while there's some >> > momentum, it might never happen again and that would be a shame. >> >> >From the one of the porters side, this would be a _very_ good solution >> indeed! If GNU/Hurd enters som kind of testing status, the number of >> users and contributors will increase (hopefully). Can it be part of >> testing and then when the release happens, be treated specially? > > As I understand it, this has been discussed but deemed not > possible/worthwhile. > >> And most packages will be located in the main repo, only the packages >> having patches, not yet handled by the DMs, being there. Is that >> possible? > > What do you mean with "there"? Either there is a testing distribution, > or there is not, as far as Debian is concerned. > > > 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/20120601235418.gr10...@nighthawk.chemicalconnection.dyndns.org > > -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae219abue+uz-54frdcoaclcog4pyu3b5oe9shi5z7drhqe...@mail.gmail.com
Re: Re: Architecture qualification
Hi, On Thu, May 31, 2012 at 04:18:30PM +0200, Svante Signell wrote: > On 28/05/12 01:52, Steven Chamberlain wrote: > > On 29/05/12 19:57, Andreas Barth wrote: > > > [...] we add hurd-i386 to testing with > > > break/fucked, but we don't expect it to make the release. I.e. bugs > > > for hurd-i386 are not RC. > > > > Maybe that's all that's needed? > > > > The recent enthusiasm sounds to me like an opportunity. An official > > testing suite in the archive, from which usable installer images can be > > built, could be what encourages hurd-i386 to progress into something > > really releasable. If this doesn't happen now while there's some > > momentum, it might never happen again and that would be a shame. > > >From the one of the porters side, this would be a _very_ good solution > indeed! If GNU/Hurd enters som kind of testing status, the number of > users and contributors will increase (hopefully). Can it be part of > testing and then when the release happens, be treated specially? As I understand it, this has been discussed but deemed not possible/worthwhile. > And most packages will be located in the main repo, only the packages > having patches, not yet handled by the DMs, being there. Is that > possible? What do you mean with "there"? Either there is a testing distribution, or there is not, as far as Debian is concerned. Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120601235418.gr10...@nighthawk.chemicalconnection.dyndns.org
Re: Re: Architecture qualification
On Thu, 2012-05-31 at 16:18 +0200, Svante Signell wrote: > On 28/05/12 01:52, Steven Chamberlain wrote: > > On 29/05/12 19:57, Andreas Barth wrote: > > > [...] we add hurd-i386 to testing with > > > break/fucked, but we don't expect it to make the release. I.e. bugs > > > for hurd-i386 are not RC. > > > > Maybe that's all that's needed? > > > > The recent enthusiasm sounds to me like an opportunity. An official > > testing suite in the archive, from which usable installer images can be > > built, could be what encourages hurd-i386 to progress into something > > really releasable. If this doesn't happen now while there's some > > momentum, it might never happen again and that would be a shame. > > From the one of the porters side, this would be a _very_ good solution > indeed! If GNU/Hurd enters som kind of testing status, the number of > users and contributors will increase (hopefully). Can it be part of > testing and then when the release happens, be treated specially? And > most packages will be located in the main repo, only the packages having > patches, not yet handled by the DMs, being there. Is that possible? > > BTW: Are builds reported to buildd.debian.org already, it is > visible ate least in the table on https://buildd.debian.org/, or maybe > Samuel meant something else In my world it is considered polite to answer questions asked. Even if you don't have the time to reply properly, just say so. I'm still waiting for some kind of feedback, especially the questions. I assume this is not a regular mail correspondence, is it? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338589334.5450.165.ca...@hp.my.own.domain
Re: Re: Architecture qualification
On 28/05/12 01:52, Steven Chamberlain wrote: > On 29/05/12 19:57, Andreas Barth wrote: > > [...] we add hurd-i386 to testing with > > break/fucked, but we don't expect it to make the release. I.e. bugs > > for hurd-i386 are not RC. > > Maybe that's all that's needed? > > The recent enthusiasm sounds to me like an opportunity. An official > testing suite in the archive, from which usable installer images can be > built, could be what encourages hurd-i386 to progress into something > really releasable. If this doesn't happen now while there's some > momentum, it might never happen again and that would be a shame. >From the one of the porters side, this would be a _very_ good solution indeed! If GNU/Hurd enters som kind of testing status, the number of users and contributors will increase (hopefully). Can it be part of testing and then when the release happens, be treated specially? And most packages will be located in the main repo, only the packages having patches, not yet handled by the DMs, being there. Is that possible? BTW: Are builds reported to buildd.debian.org already, it is visible ate least in the table on https://buildd.debian.org/, or maybe Samuel meant something else. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338473910.8802.453.ca...@s1499.it.kth.se
Re: Architecture qualification
Cyril Brulebois (28/05/2012): > Thanks for the clarification. I suggest we wait a few days until > somebody gets a grip on the current situation (newly-added graphs may > help figure out what would suffer from that), and we take action soon. > I should be able to look into that in the next few days. Current armel vs. armhf, and s390 vs. s390x situation, as far as installability is concerned: | $ grep -c ^+ diff.armel-armhf; grep -c ^+ diff.s390-s390x | 107 | 741 The s390 vs. s390x diff is huge, mainly because of qt/kde (an upload fixing that should happen soon). Looking at ood binaries for s390x, we have stuff like: amarok, kdenetwork, kdepim, kdemultimedia, libarchive, krusader, pykde4, zlib, kdevelop, xxdiff, digikam, and many others. → Mostly qt/kde, which should be fixed by the above-mentioned upload. I guess it makes sense not to block migration to testing until that is sorted out. Some parts of qt/kde that need migration would suffer from that. As far as I can see from a quick look, ood binaries for armhf are almost always coming with ood binaries for armel, so they need fixing anyway. I'm not sure whether promoting armhf first, and s390x only after would be nice; maybe just promote them both at the same time, as soon as qt/kde gets in a better shape as far as s390x is concerned? Mraw, KiBi. signature.asc Description: Digital signature
Re: Architecture qualification
On 30/05/12 13:10, Philipp Kern wrote: > I wonder how that makes a difference, even psychologically. We don't mail > failed builds for hurd-i386 to maintainers for example. Actually, when looking into kfreebsd-* issues, I find it very helpful to see hurd-i386 on buildd.d.o, along with log excerpts of build failures and past build attempts. As it is the only other non-Linux arch, info from hurd-i386 buildds is often relevant. And if I submit a patch for something, I have a habit of checking back on those pages for 'all green' even though I'm not a maintainer. Without a hurd-i386 box to test on it may be the only source of feedback. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc6585f.9030...@pyro.eu.org
Re: Architecture qualification
Philipp Kern, le Wed 30 May 2012 14:10:02 +0200, a écrit : > On Wed, May 30, 2012 at 12:01:21PM +0200, Samuel Thibault wrote: > > What is a problem is not appearing on buildd.debian.org. That makes > > maintainers way less receptive to patches or even fix their package > > themselves. > > I wonder how that makes a difference, even psychologically. We *have* seen quite a few people notice the failure in their package's buildd.debian.org page and then fix it. It's both a matter of getting the array fully green, and being aware that there is a hurd-i386 port at all. Also, grub2 was again uploaded without applying the hurd patches we proposed, which are either already applied upstream, or trivial packaging changes... Not being in the buildd.debian.org reports will not help at all there. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530122612.gh3...@type.bordeaux.inria.fr
Re: Architecture qualification
On Wed, May 30, 2012 at 12:01:21PM +0200, Samuel Thibault wrote: > What is a problem is not appearing on buildd.debian.org. That makes > maintainers way less receptive to patches or even fix their package > themselves. I wonder how that makes a difference, even psychologically. We don't mail failed builds for hurd-i386 to maintainers for example. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Architecture qualification
Joerg Jaspert, le Tue 29 May 2012 09:02:32 +0200, a écrit : > There is only one thing I would agree on: If the RT decides to not > include them in wheezy but add them to wheezy+1 right after wheezy is > released (so we would be doing it during the process) and keep them > there for the next release, then fine. Thats not exactly what we agreed > on, but would be a workable compromise. I believe that'd be fine from the Hurd part. I personnally don't want to add work on people by hurrying hurd-i386 into wheezy. > - hurd is no longer on the main mirrors. But "only" on those carrying > debian-ports. I don't think it's a problem indeed. What is a problem is not appearing on buildd.debian.org. That makes maintainers way less receptive to patches or even fix their package themselves. Samuel -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530100121.gr3...@type.bordeaux.inria.fr
Re: Architecture qualification
On Tue, May 29, 2012 at 09:02:32 +0200, Joerg Jaspert wrote: > - hurd can come back into the main archive following the usual archive > qualification every other new addition has to follow. Clean, simple, > straight forward. Not completely sure about the "simple, straight forward" part, if it needs a re-bootstrap. Cheers, Julien signature.asc Description: Digital signature
Re: Architecture qualification
On 12861 March 1977, Steve McIntyre wrote: >>There's a related question, which I just realised wasn't actually >>explicit - does it make sense to add an architecture to testing at this >>stage of the process which we don't think is releasable? My memory of >>previous discussions is that the general answer was "no", although this >>possibly depends on how one views the purpose of the testing suite. > Definitely not, IMHO. > How hard are the RT / ftpteam going to stick to the "ship with Wheezy > or you're out" agreement as written in http://wiki.debian.org/Debian_GNU/Hurd > ? > Is Hurd at the point where we could *reasonably* ship it as (at least) a > technology preview? I am pretty set on that. There isn't much point in coming to an agreement just to kick that out the door only because the time has come to actually do something about it. (And why didn't inclusion of hurd got a topic like, half a year or more ago?) There is only one thing I would agree on: If the RT decides to not include them in wheezy but add them to wheezy+1 right after wheezy is released (so we would be doing it during the process) and keep them there for the next release, then fine. Thats not exactly what we agreed on, but would be a workable compromise. > I'm unconvinced that it is, being brutally honest. Ack. I also think it is way to late before the freeze to add something like a whole architecture (and hurd is more than just a plain architecture) *now*, where we already kick maintainers for uncoordinated package transitions, prepare to kick people putting (uncoordinated) SONAME changes into NEW and generally want to have a freeze RSN. Also, what is really changed when we do this? - hurd is no longer on the main mirrors. But "only" on those carrying debian-ports. * So what? Yay, we suddenly stop mirroring something to thousands of places which is used by less than anything else. Don't tell me there are so many users of hurd that it really warrants the wide spread mirroring. Especially with it being very limited on desktops and probably serious servers[fn:1] too? (Reading from http://wiki.debian.org/Debian_GNU/Hurd and links) - hurd can come back into the main archive following the usual archive qualification every other new addition has to follow. Clean, simple, straight forward. - We are rid of a special case of an unstable/experimental only architecture that often keeps pretty outdated packages in the archive. Less general maintenance work. Of course the above is my personal opinion and ftpmaster is a team. It might happen the rest disagrees with me and tells me to sod off, but I think thats highly unlikely, from what I know. Footnotes: [fn:1] That is, not just "yeah, here, look, there is a server", but "there is a server that actually has a production used application on it. Is HA and whatnot, and $company does $lotsathingswithit, relies on it" -- bye, Joerg Ich will ein anderes Telefon, das hier klingelt immer! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762bfcvw7@gkar.ganneff.de
Re: Architecture qualification
On Mon, May 28, 2012 at 09:04:18PM +0100, Adam Barratt wrote: >On Mon, 2012-05-28 at 20:24 +0200, Philipp Kern wrote: >> > hurd-i386 >> >> No, not at all. It wouldn't be released at all at that point. (I.e. not >> copied >> into stable.) I'm very uncomfortable having such a thing alongside our >> regular architectures (even kfreebsd, which generally works for server >> stuff). > >There's a related question, which I just realised wasn't actually >explicit - does it make sense to add an architecture to testing at this >stage of the process which we don't think is releasable? My memory of >previous discussions is that the general answer was "no", although this >possibly depends on how one views the purpose of the testing suite. Definitely not, IMHO. How hard are the RT / ftpteam going to stick to the "ship with Wheezy or you're out" agreement as written in http://wiki.debian.org/Debian_GNU/Hurd ? Is Hurd at the point where we could *reasonably* ship it as (at least) a technology preview? I'm unconvinced that it is, being brutally honest. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529044118.gc3...@einval.com
Re: Architecture qualification
On Mon, May 28, 2012 at 01:21:38PM +0100, Adam Barratt wrote: > >armhf >- > >Seems okay. Still in fucked_arches currently - should we remove it >from there and promote it to a full release architecture? Yes please! :-) At this point, I'm happy that we can support armhf at least as well as most of the other architectures. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529043049.gb3...@einval.com
Re: Architecture qualification
On 28/05/12 19:57, Andreas Barth wrote: > [...] we add hurd-i386 to testing with > break/fucked, but we don't expect it to make the release. I.e. bugs > for hurd-i386 are not RC. Maybe that's all that's needed? The recent enthusiasm sounds to me like an opportunity. An official testing suite in the archive, from which usable installer images can be built, could be what encourages hurd-i386 to progress into something really releasable. If this doesn't happen now while there's some momentum, it might never happen again and that would be a shame. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc41de1.9090...@pyro.eu.org
Re: Architecture qualification
On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote: > > sparc > - > > Need to clarify whether the 32-bit code generation issue noted for > Squeeze is still relevant. Which issue is that? The fact that gcc is going to drop support for configurations which generate 32-bit code on 64-bit sparc? I guess that chances of this happening in wheeze lifetime are pretty slim, doko should be able to confirm. Post-wheezy we should make a directed effort towards switching to 64-bit userspace. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529000943.GA17821@womb
Re: Architecture qualification
On Mon, May 28, 2012 at 09:08:15PM +0200, Julien Cristau wrote: >On Mon, May 28, 2012 at 20:44:20 +0200, Andreas Barth wrote: > >> Also, for ia64 we *could* consider (as long as there is no serious >> hickup - #638068 is serious) that we release with ia64 but given to >> the lack of real porters left we already decide now to drop ia64 >> directly after the release of wheezy. Actually that is what I would >> expect unless someone is clearly willing (and ready) to work on it >> from here on. >> >I think it's pretty clear ia64 is going away post wheezy anyway. If it's that clear that it doesn't make sense after wheezy, is it clear enough that it still makes sense *in* wheezy? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528221002.ga3...@einval.com
Re: Architecture qualification
On 05/28/2012 08:57 PM, Andreas Barth wrote:
> * Adam D. Barratt (a...@adam-barratt.org.uk) [120528 14:22]:
>> hurd-i386
>> -
>>
>> Is there time to add it to testing and get it out of
>> {break,fucked}_arches? Would it make sense to release if it was still
>> in break_ and/or fucked_arches?
>
> Depending on the number of issues that pop up, it might still be
> technical possible. However, as a non-linux arch, I have my doubts.
> Also, as soon as we consider it a full release architecture, any bugs
> relevant to only hurd-i386 are considered RC.
>
> I don't think there is any (technical) harm in adding it to testing as
> long as it's in both break and fuck archs - however, from the feedback
> I got from different people, it might be felt different, so if we add
> it, we need to deliver a very clear message.
>
> We can't release if it still is in any of break/fucked arches (at
> least that would be my recommendation, due to technical and legal
> issues, e.g. we might need to preserve multiple source code versions
> if we have different binary versions within a stable release).
>
> All in all, my recommendation for hurd-i386 would be that (as long as
> this is agreed by all involved, and communicated clearly to the
> developers at large before doing it) we add hurd-i386 to testing with
> break/fucked, but we don't expect it to make the release. I.e. bugs
> for hurd-i386 are not RC. We don't do unblocks for hurd-i386. Etc. But
> also I think keeping at as part of proper Debian would be good for the
> open source community at large, so we keep it even after the next
> stable release in testing and unstable.
I don't think it's good to add an architecture to testing now when it's
not going to be released in wheezy. Technically you not only have to
consider the binary packages that will have to filtered out, but also
some source packages that are hurd only. It would also be very confusing
to users and developers and will give them false hope or possibly
distract them of what matters for the upcoming release. I would rather
recommend adding hurd to testing right after the release.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc3e76f.4060...@debian.org
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120528 22:05]:
> On Mon, 2012-05-28 at 20:24 +0200, Philipp Kern wrote:
> > On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote:
> > > hurd-i386
> > > -
> > >
> > > Is there time to add it to testing and get it out of
> > > {break,fucked}_arches?
> >
> > I think it's not. If anything that would be for the beginning of the next
> > cycle, but not for this one. As KiBi said it would massively increase our
> > load with unblock requests while it's unlikely that everything's fixed up
> > in time.
> [...]
> > > Would it make sense to release if it was still in break_ and/or
> > > fucked_arches?
> >
> > No, not at all. It wouldn't be released at all at that point. (I.e. not
> > copied
> > into stable.) I'm very uncomfortable having such a thing alongside our
> > regular architectures (even kfreebsd, which generally works for server
> > stuff).
>
> There's a related question, which I just realised wasn't actually
> explicit - does it make sense to add an architecture to testing at this
> stage of the process which we don't think is releasable? My memory of
> previous discussions is that the general answer was "no", although this
> possibly depends on how one views the purpose of the testing suite.
Useful for whom?
For preparation of the next stable release: between nil and not really
much, as it isn't part of it.
For preparation of the second next stable release: maybe, if the port
might be part of it.
For stabilization of the port: potentially, depending on the status of
the port and open topic. It's always way more easy to use testing as
target than unstable, e.g. for installation media (remember the issues
DSA had when armel wasn't in testing yet).
For the open source community at large: pick your favourite answer
above.
Andi
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120528202541.go2...@mails.so.argh.org
Re: Architecture qualification
On Mon, 2012-05-28 at 20:24 +0200, Philipp Kern wrote:
> On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote:
> > hurd-i386
> > -
> >
> > Is there time to add it to testing and get it out of
> > {break,fucked}_arches?
>
> I think it's not. If anything that would be for the beginning of the next
> cycle, but not for this one. As KiBi said it would massively increase our
> load with unblock requests while it's unlikely that everything's fixed up
> in time.
[...]
> > Would it make sense to release if it was still in break_ and/or
> > fucked_arches?
>
> No, not at all. It wouldn't be released at all at that point. (I.e. not copied
> into stable.) I'm very uncomfortable having such a thing alongside our
> regular architectures (even kfreebsd, which generally works for server stuff).
There's a related question, which I just realised wasn't actually
explicit - does it make sense to add an architecture to testing at this
stage of the process which we don't think is releasable? My memory of
previous discussions is that the general answer was "no", although this
possibly depends on how one views the purpose of the testing suite.
> > s390x
> > -
> >
> > Seems okay. Still in fucked_arches currently - should we remove it
> > from there and promote it to a full release architecture?
>
> My general feeling is yes, if we want it in the release. Do you feel that it's
> in the same shape as armhf?
Kibi mentioned wanting to look at the state of the Qt multi-arch
transition on s390x, but otherwise I don't think it looks too bad. 26
uninstallables in testing is a little higher than I remembered, but
hopefully they're (mostly) easily fixable. I didn't immediately spot a
trend amongst the packages involved, but did only have a quick look.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1338235458.21672.8.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On Mon, May 28, 2012 at 20:44:20 +0200, Andreas Barth wrote: > Also, for ia64 we *could* consider (as long as there is no serious > hickup - #638068 is serious) that we release with ia64 but given to > the lack of real porters left we already decide now to drop ia64 > directly after the release of wheezy. Actually that is what I would > expect unless someone is clearly willing (and ready) to work on it > from here on. > I think it's pretty clear ia64 is going away post wheezy anyway. Cheers, Julien signature.asc Description: Digital signature
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120528 14:22]:
> hurd-i386
> -
>
> Is there time to add it to testing and get it out of
> {break,fucked}_arches? Would it make sense to release if it was still
> in break_ and/or fucked_arches?
Depending on the number of issues that pop up, it might still be
technical possible. However, as a non-linux arch, I have my doubts.
Also, as soon as we consider it a full release architecture, any bugs
relevant to only hurd-i386 are considered RC.
I don't think there is any (technical) harm in adding it to testing as
long as it's in both break and fuck archs - however, from the feedback
I got from different people, it might be felt different, so if we add
it, we need to deliver a very clear message.
We can't release if it still is in any of break/fucked arches (at
least that would be my recommendation, due to technical and legal
issues, e.g. we might need to preserve multiple source code versions
if we have different binary versions within a stable release).
All in all, my recommendation for hurd-i386 would be that (as long as
this is agreed by all involved, and communicated clearly to the
developers at large before doing it) we add hurd-i386 to testing with
break/fucked, but we don't expect it to make the release. I.e. bugs
for hurd-i386 are not RC. We don't do unblocks for hurd-i386. Etc. But
also I think keeping at as part of proper Debian would be good for the
open source community at large, so we keep it even after the next
stable release in testing and unstable.
Andi
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120528185718.gn2...@mails.so.argh.org
Re: Architecture qualification
* Philipp Kern (pk...@debian.org) [120528 20:24]: > On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote: > > ia64 > > > > > > No real follow-up from porters. #638068 in initramfs-tools may be > > an issue. > > Still feels very much on the fringe. We could look how good it works out with > some people waking up on the list. (OTOH "I can test it" is not that helpful.) #638068 sounds to me like an RC bug (adjusted severity now). Also, for ia64 we *could* consider (as long as there is no serious hickup - #638068 is serious) that we release with ia64 but given to the lack of real porters left we already decide now to drop ia64 directly after the release of wheezy. Actually that is what I would expect unless someone is clearly willing (and ready) to work on it from here on. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528184419.gm2...@mails.so.argh.org
Re: Architecture qualification
On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote:
> armhf
> -
>
> Seems okay. Still in fucked_arches currently - should we remove it
> from there and promote it to a full release architecture?
Yes.
> hurd-i386
> -
>
> Is there time to add it to testing and get it out of
> {break,fucked}_arches?
I think it's not. If anything that would be for the beginning of the next
cycle, but not for this one. As KiBi said it would massively increase our
load with unblock requests while it's unlikely that everything's fixed up
in time.
I know that freezes drag on for a fair while, and I presume that several
patches for hurd might be applied to the package set in unstable by that time.
So we might have to deal with them either way.
> Would it make sense to release if it was still in break_ and/or
> fucked_arches?
No, not at all. It wouldn't be released at all at that point. (I.e. not copied
into stable.) I'm very uncomfortable having such a thing alongside our
regular architectures (even kfreebsd, which generally works for server stuff).
> ia64
>
>
> No real follow-up from porters. #638068 in initramfs-tools may be
> an issue.
Still feels very much on the fringe. We could look how good it works out with
some people waking up on the list. (OTOH "I can test it" is not that helpful.)
> mips
>
>
> Currently no porter box; being worked on. Some concern over
> stability of some buildds.
>
> mipsel
> --
>
> Currently suffering from the loss of a buildd. Machine replacement
> is in progress, so hopefully won't be an issue for much longer.
Aye, I think the two will make it.
> s390
>
>
> No issues; may be last release in favour of s390x.
>
> s390x
> -
>
> Seems okay. Still in fucked_arches currently - should we remove it
> from there and promote it to a full release architecture?
My general feeling is yes, if we want it in the release. Do you feel that it's
in the same shape as armhf?
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: Architecture qualification
On Mon, 2012-05-28 at 19:57 +0200, Andreas Barth wrote: > * Adam D. Barratt (a...@adam-barratt.org.uk) [120528 14:22]: > > mips > > > > > > Currently no porter box; being worked on. Some concern over stability > > of some buildds. > > eh. The porter box is online again after that was brought to our > attention. Still the box has an hardware issue (hard disk might fail > in the near future), but a replacement is being worked on. However, > the log shows that the porter box is not only online, but also is > being used again. I clearly missed that; apologies for the inaccuracy. > The stability concern is exactly about one buildd (or rather: there is > only one buildd with flaky hardware), and we are working on getting > that one replaced as well. That's good news. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338228909.21672.0.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120528 14:22]: > mips > > > Currently no porter box; being worked on. Some concern over stability > of some buildds. eh. The porter box is online again after that was brought to our attention. Still the box has an hardware issue (hard disk might fail in the near future), but a replacement is being worked on. However, the log shows that the porter box is not only online, but also is being used again. Not optimal, but "no porterbox" is wrong as well. Also, if most porting cases, the mipsel box can be used equally (as mips and mipsel tend to fail on the same issues). The stability concern is exactly about one buildd (or rather: there is only one buildd with flaky hardware), and we are working on getting that one replaced as well. > mipsel > -- > > Currently suffering from the loss of a buildd. Machine replacement is > in progress, so hopefully won't be an issue for much longer. Replacement is currently on its way to the data center. If we need even one more machine, please say so - we have hardware for it (except a larger ram module needs to be bought, but that's < 50 Euro, so no issue as well). Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528175749.gl2...@mails.so.argh.org
Re: Architecture qualification
Adam D. Barratt (28/05/2012): > The practical implication of dropping the architectures from > fucked_arches would be that out-of-date binaries would become > blockers for migration. > > We already dropped the architectures from break_arches, which means > that new installability problems are already blockers. Thanks for the clarification. I suggest we wait a few days until somebody gets a grip on the current situation (newly-added graphs may help figure out what would suffer from that), and we take action soon. I should be able to look into that in the next few days. Mraw, KiBi. signature.asc Description: Digital signature
Re: Architecture qualification
On 28.05.2012 13:43, Cyril Brulebois wrote: Adam D. Barratt (28/05/2012): armhf - Seems okay. Still in fucked_arches currently - should we remove it from there and promote it to a full release architecture? s390x - Seems okay. Still in fucked_arches currently - should we remove it from there and promote it to a full release architecture? I guess we would like to get a fixed qt/kde stack on s390x first (which should only need a few uploads, hello Pino). But I'm not sure of the practical implications if we were to flip the switch right now? The practical implication of dropping the architectures from fucked_arches would be that out-of-date binaries would become blockers for migration. We already dropped the architectures from break_arches, which means that new installability problems are already blockers. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9351a5cef6ce77fadc42eb6eae8a7...@mail.adsl.funky-badger.org
Re: Architecture qualification
Thanks for the summary.
Adam D. Barratt (28/05/2012):
> armhf
> -
>
> Seems okay. Still in fucked_arches currently - should we remove it
> from there and promote it to a full release architecture?
> s390x
> -
>
> Seems okay. Still in fucked_arches currently - should we remove it
> from there and promote it to a full release architecture?
I guess we would like to get a fixed qt/kde stack on s390x first (which
should only need a few uploads, hello Pino). But I'm not sure of the
practical implications if we were to flip the switch right now?
I have some scripts to check uninstallability issues (diffing against
armel and s390x) and I guess we might need to get a few more packages
ready on those archs before we do that. But again, that depends on the
pratical implications above.
> hurd-i386
> -
>
> Is there time to add it to testing and get it out of
> {break,fucked}_arches? Would it make sense to release if it was
> still in break_ and/or fucked_arches?
I guess we need more than just my views on it (see relevant thread).
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Architecture qualification
On 15.05.2012 16:18, Adam D. Barratt wrote:
In an effort to stop this stalling any further / longer, I propose
sending [1] to each of the port lists, probably some time tomorrow.
We had replies for most architectures. To try and re-centralise this a
little more, and as my tuits seem to be disappearing even more quickly
than usual over the past couple of weeks:
amd64
-
No issues.
armel
-
Looks okay in general but can suffer if a buildd is lost, as was the
case recently. Steve McIntyre is looking at improving this by adding
capavity at York.
armhf
-
Seems okay. Still in fucked_arches currently - should we remove it
from there and promote it to a full release architecture?
hurd-i386
-
Is there time to add it to testing and get it out of
{break,fucked}_arches? Would it make sense to release if it was still
in break_ and/or fucked_arches?
i386
No issues.
ia64
No real follow-up from porters. #638068 in initramfs-tools may be an
issue.
mips
Currently no porter box; being worked on. Some concern over stability
of some buildds.
mipsel
--
Currently suffering from the loss of a buildd. Machine replacement is
in progress, so hopefully won't be an issue for much longer.
powerpc
---
Could do with clarifying active porters; a couple of people spoke up in
the thread.
s390
No issues; may be last release in favour of s390x.
s390x
-
Seems okay. Still in fucked_arches currently - should we remove it
from there and promote it to a full release architecture?
sparc
-
Need to clarify whether the 32-bit code generation issue noted for
Squeeze is still relevant.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/f9eaa8d475d3fdf9a17cf699c0369...@mail.adsl.funky-badger.org
Re: Architecture qualification
* Cyril Brulebois (k...@debian.org) [120516 11:31]: > Andreas Barth (16/05/2012): > > Anyways, if the most concering issue is that there is currently only > > one swarm-type mips buildd, we could just use the spare machine we > > have and add another one. (Normally packages can build on any > > hardware, but sometimes it's more favourable to distribute packages > > accordingly between different hardware types - nothing too bad, but > > sometimes e.g. RAM is more important than many processors). > > Whatever is done, we need packages to build, reliably and not as slowly > as these days (week, months…). The current situation is really painful. Looking at mips and its backlog of less than 10 packages, I don't know why you write "months". There is no package currently waiting for being built for more than a day on mips (or at least: hadn't been tried since less than a day - things like the mysql-hickup may make a difference here, but that's not mips specific). Of course, accidents happen as on any architecture, e.g. recently a buggy package decided to block a buildd exclusivly for two weeks until I manually kill the build (activly circumventing the buildds safety mechanismn), but that could happen on any hardware and architecture. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120520130123.gb13...@mails.so.argh.org
Re: Architecture qualification
Le 15/05/2012 22:27, Michael Banck a écrit : > On Tue, May 15, 2012 at 09:45:43PM +0200, Julien Cristau wrote: >> On Tue, May 15, 2012 at 20:42:14 +0100, Adam D. Barratt wrote: >>> On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: On Tue, May 15, 2012 at 16:18:19 +0100, Adam D. Barratt wrote: > In an effort to stop this stalling any further / longer, I propose > sending [1] to each of the port lists, probably some time tomorrow. > > Comments / changes / updates / whatever welcome. > I'd add a concern about the mips buildds to the arch qual page (not sure how to phrase it). >>> >>> Assuming it's the stability issue, then maybe re-using weasel's >>> "unstable under load" which we used for the porter box? >>> >> There's that, and there's some packages that can only be built on ball >> because lucatelli/corelli fail every time. azeem has a bunch of those. > > Those were number-crunching testsuites and they timed out - I am not > sure what the relative hardware specs are but it could be that corelli > is just too slow to run those (likely floating-point heavy) test suites > in the sbuild time limit. > > I haven't looked closer, though. > The problem with the octeons is that while they have many cores (32 in our case), they don't have an FPU. That's why heavy floating-point code is slow. I have a swarm at home doing nothing since we moved, if we can find a place to host it, it seems the best way to go. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb36947.6030...@aurel32.net
Re: Architecture qualification
Andreas Barth (16/05/2012): > Anyways, if the most concering issue is that there is currently only > one swarm-type mips buildd, we could just use the spare machine we > have and add another one. (Normally packages can build on any > hardware, but sometimes it's more favourable to distribute packages > accordingly between different hardware types - nothing too bad, but > sometimes e.g. RAM is more important than many processors). Whatever is done, we need packages to build, reliably and not as slowly as these days (week, months…). The current situation is really painful. Mraw, KiBi. signature.asc Description: Digital signature
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120515 22:26]: > On Tue, 2012-05-15 at 21:45 +0200, Julien Cristau wrote: > > On Tue, May 15, 2012 at 20:42:14 +0100, Adam D. Barratt wrote: > > > > > On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: > > > > I'd add a concern about the mips buildds to the arch qual page (not sure > > > > how to phrase it). > > > > > > Assuming it's the stability issue, then maybe re-using weasel's > > > "unstable under load" which we used for the porter box? > > > > > There's that, and there's some packages that can only be built on ball > > because lucatelli/corelli fail every time. azeem has a bunch of those. > > Hmmm, ball's lower spec than the octerons iirc? Different spec. swarm and octeons have different advantages (octeons have many but a slower processors, and less memory per used processor than swarms (because we run two buildds in parallel per hardware, each using up to 6 cpus)). Anyways, if the most concering issue is that there is currently only one swarm-type mips buildd, we could just use the spare machine we have and add another one. (Normally packages can build on any hardware, but sometimes it's more favourable to distribute packages accordingly between different hardware types - nothing too bad, but sometimes e.g. RAM is more important than many processors). Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515223403.gy2...@mails.so.argh.org
Re: Architecture qualification
On Tue, 2012-05-15 at 22:10 +0200, Mehdi Dogguy wrote: [...] > >>> On Tue, 2012-05-15 at 21:22 +0200, Mehdi Dogguy wrote: > On 15/05/12 17:18, Adam D. Barratt wrote: > > http://release.debian.org/wheezy/arch_qualify.html > > Should we add a row labeled "auto-signing" there? [...] > FWIW, I wasn't proposing to ask porters about that, but just discuss the > idea as it has already been mentioned several times. Maybe I should have > started another thread. Thanks for your answers! Yeah, I (finally) gathered that, it wasn't clear to me to begin with though; sorry for any contribution to the confusion. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337113697.21380.31.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On Tue, May 15, 2012 at 09:45:43PM +0200, Julien Cristau wrote: > On Tue, May 15, 2012 at 20:42:14 +0100, Adam D. Barratt wrote: > > On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: > > > On Tue, May 15, 2012 at 16:18:19 +0100, Adam D. Barratt wrote: > > > > In an effort to stop this stalling any further / longer, I propose > > > > sending [1] to each of the port lists, probably some time tomorrow. > > > > > > > > Comments / changes / updates / whatever welcome. > > > > > > > I'd add a concern about the mips buildds to the arch qual page (not sure > > > how to phrase it). > > > > Assuming it's the stability issue, then maybe re-using weasel's > > "unstable under load" which we used for the porter box? > > > There's that, and there's some packages that can only be built on ball > because lucatelli/corelli fail every time. azeem has a bunch of those. Those were number-crunching testsuites and they timed out - I am not sure what the relative hardware specs are but it could be that corelli is just too slow to run those (likely floating-point heavy) test suites in the sbuild time limit. I haven't looked closer, though. Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515202752.gd2...@nighthawk.chemicalconnection.dyndns.org
Re: Architecture qualification
On Tue, May 15, 2012 at 08:41:08PM +0100, Adam D. Barratt wrote: > It might be worth considering as a criterion for wheezy+1, I'm not sure > it's beneficial to enforce it as a blocker for wheezy. In any case, > it's not really something that the porters can comment on / change, > unless they also happen to be buildd admins or wb-team. I think for wheezy+1 it should be implied by the criterion DSA'ed buildds. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Architecture qualification
On Tue, 2012-05-15 at 21:45 +0200, Julien Cristau wrote: > On Tue, May 15, 2012 at 20:42:14 +0100, Adam D. Barratt wrote: > > > On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: > > > I'd add a concern about the mips buildds to the arch qual page (not sure > > > how to phrase it). > > > > Assuming it's the stability issue, then maybe re-using weasel's > > "unstable under load" which we used for the porter box? > > > There's that, and there's some packages that can only be built on ball > because lucatelli/corelli fail every time. azeem has a bunch of those. Hmmm, ball's lower spec than the octerons iirc? Maybe "some unstable under load and unable to build all packages"? That's a tad long-winded, but I don't have a better suggestion right now. :-/ Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337113495.21380.29.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On 15/05/12 21:58, Adam D. Barratt wrote: On Tue, 2012-05-15 at 21:51 +0200, Mehdi Dogguy wrote: On 15/05/12 21:41, Adam D. Barratt wrote: On Tue, 2012-05-15 at 21:22 +0200, Mehdi Dogguy wrote: On 15/05/12 17:18, Adam D. Barratt wrote: http://release.debian.org/wheezy/arch_qualify.html Should we add a row labeled "auto-signing" there? auto-signing makes things less a PITA and make transitions run (a bit) faster. It'd be very nice if we could require auto-signing for release architectures. It has been done for security already. Well, given how close we (hopefully) are to the freeze, we'd mostly be talking about supporting the architecture in stable, where transitions are obviously not an issue. It helps to prepare the release though. and I was told it was appreciated when point releases are in preparation ;) The bit you didn't quote also pointed out that it's not something the porters can generally do anything about, so isn't really relevant for the purposes of a mail sent _to porters_, which is what the current thread was primarily about. FWIW, I wasn't proposing to ask porters about that, but just discuss the idea as it has already been mentioned several times. Maybe I should have started another thread. Thanks for your answers! -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb2b823.9040...@dogguy.org
Re: Architecture qualification
On Tue, May 15, 2012 at 20:58:06 +0100, Adam D. Barratt wrote: > In any case, I'm not going to unilaterally add new criteria right now. > If there's consensus that it should be included, then we can of course > look at that. > ... for the next release. Cheers, Julien signature.asc Description: Digital signature
Re: Architecture qualification
On Tue, 2012-05-15 at 21:51 +0200, Mehdi Dogguy wrote: > On 15/05/12 21:41, Adam D. Barratt wrote: > > On Tue, 2012-05-15 at 21:22 +0200, Mehdi Dogguy wrote: > >> On 15/05/12 17:18, Adam D. Barratt wrote: > >>> http://release.debian.org/wheezy/arch_qualify.html > >> > >> Should we add a row labeled "auto-signing" there? > >> > >> auto-signing makes things less a PITA and make transitions run (a bit) > >> faster. It'd be very nice if we could require auto-signing for release > >> architectures. It has been done for security already. > > > > Well, given how close we (hopefully) are to the freeze, we'd mostly be > > talking about supporting the architecture in stable, where transitions > > are obviously not an issue. > > > It helps to prepare the release though. and I was told it was > appreciated when point releases are in preparation ;) The bit you didn't quote also pointed out that it's not something the porters can generally do anything about, so isn't really relevant for the purposes of a mail sent _to porters_, which is what the current thread was primarily about. In any case, I'm not going to unilaterally add new criteria right now. If there's consensus that it should be included, then we can of course look at that. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337111886.21380.18.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On 15/05/12 21:41, Adam D. Barratt wrote: On Tue, 2012-05-15 at 21:22 +0200, Mehdi Dogguy wrote: On 15/05/12 17:18, Adam D. Barratt wrote: http://release.debian.org/wheezy/arch_qualify.html Should we add a row labeled "auto-signing" there? auto-signing makes things less a PITA and make transitions run (a bit) faster. It'd be very nice if we could require auto-signing for release architectures. It has been done for security already. Well, given how close we (hopefully) are to the freeze, we'd mostly be talking about supporting the architecture in stable, where transitions are obviously not an issue. It helps to prepare the release though. and I was told it was appreciated when point releases are in preparation ;) -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb2b3bb.7040...@dogguy.org
Re: Architecture qualification
On Tue, May 15, 2012 at 20:42:14 +0100, Adam D. Barratt wrote: > On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: > > On Tue, May 15, 2012 at 16:18:19 +0100, Adam D. Barratt wrote: > > > In an effort to stop this stalling any further / longer, I propose > > > sending [1] to each of the port lists, probably some time tomorrow. > > > > > > Comments / changes / updates / whatever welcome. > > > > > I'd add a concern about the mips buildds to the arch qual page (not sure > > how to phrase it). > > Assuming it's the stability issue, then maybe re-using weasel's > "unstable under load" which we used for the porter box? > There's that, and there's some packages that can only be built on ball because lucatelli/corelli fail every time. azeem has a bunch of those. Cheers, Julien signature.asc Description: Digital signature
Re: Architecture qualification
On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: > On Tue, May 15, 2012 at 16:18:19 +0100, Adam D. Barratt wrote: > > In an effort to stop this stalling any further / longer, I propose > > sending [1] to each of the port lists, probably some time tomorrow. > > > > Comments / changes / updates / whatever welcome. > > > I'd add a concern about the mips buildds to the arch qual page (not sure > how to phrase it). Assuming it's the stability issue, then maybe re-using weasel's "unstable under load" which we used for the porter box? Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337110934.21380.9.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On Tue, 2012-05-15 at 21:22 +0200, Mehdi Dogguy wrote: > On 15/05/12 17:18, Adam D. Barratt wrote: > > http://release.debian.org/wheezy/arch_qualify.html > > Should we add a row labeled "auto-signing" there? > > auto-signing makes things less a PITA and make transitions run (a bit) > faster. It'd be very nice if we could require auto-signing for release > architectures. It has been done for security already. Well, given how close we (hopefully) are to the freeze, we'd mostly be talking about supporting the architecture in stable, where transitions are obviously not an issue. It might be worth considering as a criterion for wheezy+1, I'm not sure it's beneficial to enforce it as a blocker for wheezy. In any case, it's not really something that the porters can comment on / change, unless they also happen to be buildd admins or wb-team. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337110868.21380.8.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On Tue, 2012-05-15 at 20:58 +0200, Mike Hommey wrote: > On Tue, May 15, 2012 at 04:18:19PM +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 $arch's status for the release. > > Out of curiosity, why isn't hppa in there? (possibly with a "no" for > "candidate?") If an architecture's not even in the main archive at this stage of the release process, I'm not sure what the value of including it in the table would be. OthersMMV, of course. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337110231.21380.3.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification
On 15/05/12 17:18, Adam D. Barratt wrote: http://release.debian.org/wheezy/arch_qualify.html Should we add a row labeled "auto-signing" there? auto-signing makes things less a PITA and make transitions run (a bit) faster. It'd be very nice if we could require auto-signing for release architectures. It has been done for security already. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb2ace9.6070...@dogguy.org
Re: Architecture qualification
On Tue, May 15, 2012 at 04:18:19PM +0100, Adam D. Barratt wrote: > Hi, > > In an effort to stop this stalling any further / longer, I propose > sending [1] to each of the port lists, probably some time tomorrow. > > Comments / changes / updates / whatever welcome. > > Regards, > > Adam > > [1] > To: debian-$archlist@l.d.o > Cc: debian-release > Subject: $arch qualification for Wheezy > > Hi, > > 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 $arch's status for the release. Out of curiosity, why isn't hppa in there? (possibly with a "no" for "candidate?") Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515185827.gb15...@glandium.org
Re: Architecture qualification
On Tue, May 15, 2012 at 16:18:19 +0100, Adam D. Barratt wrote: > Hi, > > In an effort to stop this stalling any further / longer, I propose > sending [1] to each of the port lists, probably some time tomorrow. > > Comments / changes / updates / whatever welcome. > I'd add a concern about the mips buildds to the arch qual page (not sure how to phrase it). Draft looks good. Cheers, Julien signature.asc Description: Digital signature
Re: Architecture qualification
On 2012-05-15 17:18, Adam D. Barratt wrote: > Hi, > > In an effort to stop this stalling any further / longer, I propose > sending [1] to each of the port lists, probably some time tomorrow. > > Comments / changes / updates / whatever welcome. > > Regards, > > Adam > > [...] > > Sounds good to me - though possibly with an updated "Regards" line :P. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb284ee.6060...@thykier.net
Re: Architecture qualification meeting for Wheezy
On Wed, May 09, 2012 at 05:48:48PM +0200, Niels Thykier wrote: > Yeah, thanks for starting the wiki. Honestly I am not sure the wiki is > the optimal place for it, but I guess it will do for now (and it is less > likely to "disappear" than in the mail archive). > > I will try to see if we can keep it up to date (or find a better spot > for it). The qualification page on release.debian.org does already provide for freeform text. Obviously not everyone can write, but it's the spot that has been preserved in the past. OTOH it doesn't seem that many folks are interested in doing the work anyway. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120509210115.ga16...@spike.0x539.de
Re: Architecture qualification meeting for Wheezy
On 2012-05-05 02:53, Steven Chamberlain wrote: > Hi Niels, > Hi, > I'm not DM/DD, but, I thought the summary you gave the other week [1] > looked like a good starting point for a Wiki page of all > considerations/concerns. > > Since the outcome of the archive qualification ought to be documented > anyway, I went ahead and started off a new Wiki page [2] for this. > > [...] > > Thanks! > Regards, Yeah, thanks for starting the wiki. Honestly I am not sure the wiki is the optimal place for it, but I guess it will do for now (and it is less likely to "disappear" than in the mail archive). I will try to see if we can keep it up to date (or find a better spot for it). ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4faa91e0.9080...@thykier.net
Re: Architecture qualification for wheezy - status of Linux kernel
On Sun, May 06, 2012 at 11:24:48PM +0100, Ben Hutchings wrote: > in future. A minor concern I have is that I find it hard to get bug > fixes reviewed and applied upstream. For this part of the problem seems to be that the systems Debian chooses to support are mostly not ones that get much active attention upstream; they're very much spare time activities. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120508094925.gb21...@sirena.org.uk
Re: Architecture qualification for wheezy - status of Linux kernel
On Mon, May 07, 2012 at 02:37:56PM +0100, Ben Hutchings wrote: > > > > Debian have access to at least one Power7 machine located at OSUOSL. The > > machine list shows three LPAR running on it. > > Yes, the project has these resources. But a kernel porter will of > course need to install and test new kernels. Does the porterbox provide > nested virtualisation for any developer? (For some reason we haven't > enabled KVM_BOOK3S_64, which I think means the answer is currently 'no', > but we can fix that part, leaving the administrative issue of > permissions to use KVM.) > > How about other PowerPC hardware, in particular 32-bit machines? How, > if at all, would a new kernel porter support these? Should qemu be used to test PowerPC architecture? In a sense, Qemu can simulate ppc and ppc64. -- Thanks and Regards, -- Liang Guo http://bluestone.cublog.cn signature.asc Description: Digital signature
Re: Architecture qualification for wheezy - status of Linux kernel
On Mon, 2012-05-07 at 09:48 +0200, Bastian Blank wrote: > On Sun, May 06, 2012 at 11:24:48PM +0100, Ben Hutchings wrote: > > * s390/s390x: Actively supported upstream by IBM. > > Sometimes to actively supported. :-) > > >Only runs in virtual > > machines, > > It runs in three different environments: Bare hardware, LPAR and VM. > However the environments don't differ that much. The hardware usualy > have two hardware assisted virtualisation layers; LPAR is the first and > used on almost every machine, z/VM or kvm is the second. > > > * powerpc > > There is no Debian kernel maintainer for powerpc. I also see a problem > > of hardware availability for prospective maintainers (no new PowerPC > > Macs since 2006; PS3 'OtherOS' support removed in 2010). I am unsure > > whether this port should be included in wheezy. > > Debian have access to at least one Power7 machine located at OSUOSL. The > machine list shows three LPAR running on it. Yes, the project has these resources. But a kernel porter will of course need to install and test new kernels. Does the porterbox provide nested virtualisation for any developer? (For some reason we haven't enabled KVM_BOOK3S_64, which I think means the answer is currently 'no', but we can fix that part, leaving the administrative issue of permissions to use KVM.) How about other PowerPC hardware, in particular 32-bit machines? How, if at all, would a new kernel porter support these? Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Re: Architecture qualification for wheezy - status of Linux kernel
On Sun, May 06, 2012 at 11:24:48PM +0100, Ben Hutchings wrote: > * s390/s390x: Actively supported upstream by IBM. Sometimes to actively supported. :-) >Only runs in virtual > machines, It runs in three different environments: Bare hardware, LPAR and VM. However the environments don't differ that much. The hardware usualy have two hardware assisted virtualisation layers; LPAR is the first and used on almost every machine, z/VM or kvm is the second. > * powerpc > There is no Debian kernel maintainer for powerpc. I also see a problem > of hardware availability for prospective maintainers (no new PowerPC > Macs since 2006; PS3 'OtherOS' support removed in 2010). I am unsure > whether this port should be included in wheezy. Debian have access to at least one Power7 machine located at OSUOSL. The machine list shows three LPAR running on it. Bastian -- There's coffee in that nebula! -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud" -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507074819.ga27...@wavehammer.waldi.eu.org
Re: Architecture qualification for GNU/kFreeBSD
Steven Chamberlain (05/05/2012): > I noticed on "the table" that no porter box is listed for kfreebsd-i386: > http://release.debian.org/wheezy/arch_qualify.html > > Is that because io.debian.net is/was not working? Or is it? FWIW from a previous IRC discussion, we have no DSA-admin'd porterboxes but DSA is happy to do the setup. The release team (at least its members who voiced an opinion at the time) seemed happy with the current state of affairs (i.e. half a porterbox) for the time being, since it's going to be fixed soonish. > Apart from that, the biggest outstanding issue might be to get daily d-i > images built again? Speaking of which, I just sent: https://lists.debian.org/debian-boot/2012/05/msg00045.html Mraw, KiBi. signature.asc Description: Digital signature
Re: Re: Architecture qualification meeting for Wheezy
Hi Niels, I'm not DM/DD, but, I thought the summary you gave the other week [1] looked like a good starting point for a Wiki page of all considerations/concerns. Since the outcome of the archive qualification ought to be documented anyway, I went ahead and started off a new Wiki page [2] for this. [1] https://lists.debian.org/debian-release/2012/04/msg00304.html which I have borrowed to create: [2] http://wiki.debian.org/ArchiveQualification/Wheezy and I am still trying to add bits to it that have already been mentioned recently. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa47a0e.40...@pyro.eu.org
Re: Architecture qualification meeting for Wheezy
On May 2, 2012 23:09 "Andreas Barth" wrote: > * Adam D. Barratt (a...@adam-barratt.org.uk) [120430 20:30]: > > [...] > > > > So far there have only been two responses, one of which was from me. > > :-/ > > > > If this is due to people not liking the included dates, please > > suggest > > others. We really should decide this stuff soon though... > > As that weekend doesn't work for all, I created a new doodle a week > later. As Saturday is already busy with the .-release, I only used > Sunday as options > http://www.doodle.com/dgi23b5fgxs7vqnk > > I think it would be useful to have all involved parties present (and > give all interessted porters the chance to join us) so that we could > get an result we could work on. > > Andi > Hi, I am beginning to think that postponing the meeting (again?) will not be a good idea. Before long, people will not bother filling out "yet another doodle", as "it will only be replaced by a new doodle". I think a better alternative would be to work out "our concerns" for all ports. These concerns can then be send out to the relevant porters giving them time to address them. I believe this will be better for us, because we will get an overview of which ports need attention. But I also think it is better for the porters as they will (presumably) get more time to fix any issues we have. An important consequence of my proposed alternative is that we will *not* reject ports at this time. Though, if there are ports we believe are all okay at this time, I see no problem in approving them already now[1]. Phil suggested (over IRC) that we should be able to compile a list of concerns without doing a meeting. I am okay with that, but it implies that people are ready to take the time to write and reply to emails about it. Alternatively, we could just pick one of the slots on the doodle Adam made and use it for the above purpose. If nothing else, I hope it it would at least be a good starting point. ~Niels [1] Hopefully it would also mean it will be easier to find a meeting slot later, as porters for these archs probably do not "need" to be present. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503214419.00a78ea604...@bmail02.one.com
Re: Architecture qualification meeting for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120430 20:30]: > On Wed, 2012-04-25 at 23:09 +0100, Adam D. Barratt wrote: > > On Wed, 2012-04-25 at 13:46 +0100, Adam D. Barratt wrote: > > > fwiw, the next sensible weekends (i.e. ignoring the one in a couple of > > > days time) are May 5/6th - which is a three-day holiday weekend in the > > > UK - and 12/13th, which is the York BSP. I could do the latter but > > > would prefer the former. > > > > As mentioned on IRC, a Doodle for the former - > > http://www.doodle.com/qxr4u5xa29yk3tid > > So far there have only been two responses, one of which was from me. :-/ > > If this is due to people not liking the included dates, please suggest > others. We really should decide this stuff soon though... As that weekend doesn't work for all, I created a new doodle a week later. As Saturday is already busy with the .-release, I only used Sunday as options http://www.doodle.com/dgi23b5fgxs7vqnk I think it would be useful to have all involved parties present (and give all interessted porters the chance to join us) so that we could get an result we could work on. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502210924.gq2...@mails.so.argh.org
Re: Architecture qualification meeting for Wheezy
On Mon, 2012-04-30 at 19:03 +0100, Adam D. Barratt wrote: > On Wed, 2012-04-25 at 23:09 +0100, Adam D. Barratt wrote: > > As mentioned on IRC, a Doodle for the former - > > http://www.doodle.com/qxr4u5xa29yk3tid > > So far there have only been two responses, one of which was from me. :-/ Now up to five. > If this is due to people not liking the included dates, please suggest > others. We really should decide this stuff soon though... So far we appear to be looking at Saturday afternoon and most of Sunday as times when most of the respondents are available (one set of four people for each period). Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1335936370.15577.27.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification meeting for Wheezy
On Wed, 2012-04-25 at 23:09 +0100, Adam D. Barratt wrote: > On Wed, 2012-04-25 at 13:46 +0100, Adam D. Barratt wrote: > > fwiw, the next sensible weekends (i.e. ignoring the one in a couple of > > days time) are May 5/6th - which is a three-day holiday weekend in the > > UK - and 12/13th, which is the York BSP. I could do the latter but > > would prefer the former. > > As mentioned on IRC, a Doodle for the former - > http://www.doodle.com/qxr4u5xa29yk3tid So far there have only been two responses, one of which was from me. :-/ If this is due to people not liking the included dates, please suggest others. We really should decide this stuff soon though... Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1335809007.6289.6.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification meeting for Wheezy
Joerg Jaspert writes: > On 12824 March 1977, Niels Thykier wrote: >> """ >> The Debian GNU/Hurd port can almost completely be installed from the >> official mirrors, using the standard Debian Installer. >> """ > >> Not sure if that means "we have imported packages" (which are not >> showing up on my radar) or if it is "just" an installer issue (which >> would be covered by the table). > > They do: https://lists.debian.org/debian-hurd/2012/04/msg00110.html > and ff. You need to check the build logs what they use for building > packages. There is stuff in there thats only from d-p.o. https://lists.debian.org/debian-hurd/2012/04/msg00111.html is the thread about hurd still using debian-ports. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr5229r9@deep-thought.43-1.org
Re: Architecture qualification meeting for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120425 14:47]: > fwiw, the next sensible weekends (i.e. ignoring the one in a couple of > days time) are May 5/6th - which is a three-day holiday weekend in the > UK - and 12/13th, which is the York BSP. I could do the latter but > would prefer the former. Morning of the 12th (i.e. end prior to 11h UTC) and evening of the 13th (i.e. after 14h UTC) would work here. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120426063530.gd13...@mails.so.argh.org
Re: Architecture qualification meeting for Wheezy
On 12824 March 1977, Niels Thykier wrote: > [3] > http://raphaelhertzog.com/2012/04/19/people-behind-debian-samuel-thibault-working-on-accessibility-and-the-hurd/ > > """ > The Debian GNU/Hurd port can almost completely be installed from the > official mirrors, using the standard Debian Installer. > """ > Not sure if that means "we have imported packages" (which are not > showing up on my radar) or if it is "just" an installer issue (which > would be covered by the table). They do: https://lists.debian.org/debian-hurd/2012/04/msg00110.html and ff. You need to check the build logs what they use for building packages. There is stuff in there thats only from d-p.o. Also, see https://lists.debian.org/debian-hurd/2012/04/msg00110.html -- bye, Joerg I'm normally not a praying man, but if you're up there, please save me Superman. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5pjdoof@gkar.ganneff.de
Re: Architecture qualification meeting for Wheezy
On Wed, 2012-04-25 at 13:46 +0100, Adam D. Barratt wrote: > fwiw, the next sensible weekends (i.e. ignoring the one in a couple of > days time) are May 5/6th - which is a three-day holiday weekend in the > UK - and 12/13th, which is the York BSP. I could do the latter but > would prefer the former. As mentioned on IRC, a Doodle for the former - http://www.doodle.com/qxr4u5xa29yk3tid Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1335391795.20495.32.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification meeting for Wheezy
On Sun, 2012-04-22 at 23:19 +0200, Niels Thykier wrote: > As for meeting preps, I must admit that I found it rather difficult to > work out what needs to be prepared. I was largely hoping to avoid discussions around what people's feelings on arches were and concentrate more on technical points. If you want to suggest that archX should become a release architecture, or archY should be dropped then being able to show that more than Z% of severity >= important packages either don't build, or are buggy, or take five times longer to build than every other architecture put together, or whatever, on that architecture would be preferable. I'm not suggesting that we spend weeks analysing every little detail of every architecture's performance, it would just be good to be able to rely more on objective rather than subjective data. Not that "I think i386 sucks" isn't a useful data point still. :-) > * No imported packages (from -ports). >- s390x still have libproxy (according to projectb). I am told they > are working on it and presumbly this will be fixed before long. >- hurd-i386 /may/ have an issue here[3] libproxy/s390x is waiting for iceweasel, which was itself blocked behind a chain of other packages until the end of last month. Now it "just" fails to build, although that's being worked on. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1335387392.20495.30.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification meeting for Wheezy
On 2012-04-25 14:46, Adam D. Barratt wrote: > On 22.04.2012 22:19, Niels Thykier wrote: > [...] >> I originally wanted the length of the meeting to be an hour at most. I >> had a draft agenda that I never got around to send out[1]. Looking back >> at it now, I am not entirely sure if it is realistic (on IRC). >> However, I would rather do two meetings of 45 minutes than one meeting >> of 90 minutes. So I guess I would like to work out "How long do we >> need?" (and "Does that fit in one or two meetings?") before looking at >> dates. > > I agree that having an approximate length in mind would be a good thing, > but I'm also wary of us spending ages discussing (or failing to discuss) > that point and then having to wait again while we decide on dates. > > fwiw, the next sensible weekends (i.e. ignoring the one in a couple of > days time) are May 5/6th - which is a three-day holiday weekend in the > UK - and 12/13th, which is the York BSP. I could do the latter but > would prefer the former. > > Regards, > > ADam > > May 6th and 12/13th should work for me. Depending on the time, I /may/ be available on the 5th, but I wouldn't count on it. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9863f2.8020...@thykier.net
Re: Architecture qualification meeting for Wheezy
On 22.04.2012 22:19, Niels Thykier wrote: On 2012-04-20 22:32, Adam D. Barratt wrote: On Fri, 2012-04-06 at 12:44 +0200, Niels Thykier wrote: Per discussions on #d-release, we have decided to postpone the meeting till some time after Easter. It's now distinctly after Easter, and we need to look at rescheduling this. Do we want to start from looking at dates, or working out how much time we need for both the meeting and any pre-meeting prep so people can block out the right amount of time? Maybe both at once? :-) [...] I originally wanted the length of the meeting to be an hour at most. I had a draft agenda that I never got around to send out[1]. Looking back at it now, I am not entirely sure if it is realistic (on IRC). However, I would rather do two meetings of 45 minutes than one meeting of 90 minutes. So I guess I would like to work out "How long do we need?" (and "Does that fit in one or two meetings?") before looking at dates. I agree that having an approximate length in mind would be a good thing, but I'm also wary of us spending ages discussing (or failing to discuss) that point and then having to wait again while we decide on dates. fwiw, the next sensible weekends (i.e. ignoring the one in a couple of days time) are May 5/6th - which is a three-day holiday weekend in the UK - and 12/13th, which is the York BSP. I could do the latter but would prefer the former. Regards, ADam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8f1c24b5db7669ffb1c70ba7945cf...@mail.adsl.funky-badger.org
Re: Architecture qualification meeting for Wheezy
On 2012-04-20 22:32, Adam D. Barratt wrote:
> On Fri, 2012-04-06 at 12:44 +0200, Niels Thykier wrote:
>> Per discussions on #d-release, we have decided to postpone the meeting
>> till some time after Easter.
>
> It's now distinctly after Easter, and we need to look at rescheduling
> this.
>
> Do we want to start from looking at dates, or working out how much time
> we need for both the meeting and any pre-meeting prep so people can
> block out the right amount of time? Maybe both at once? :-)
>
> Regards,
>
> Adam
>
I originally wanted the length of the meeting to be an hour at most. I
had a draft agenda that I never got around to send out[1]. Looking back
at it now, I am not entirely sure if it is realistic (on IRC).
However, I would rather do two meetings of 45 minutes than one meeting
of 90 minutes. So I guess I would like to work out "How long do we
need?" (and "Does that fit in one or two meetings?") before looking at
dates.
As for meeting preps, I must admit that I found it rather difficult to
work out what needs to be prepared. I did manage to get some points
down (which are not on the "table"[2]):
* No imported packages (from -ports).
- s390x still have libproxy (according to projectb). I am told they
are working on it and presumbly this will be fixed before long.
- hurd-i386 /may/ have an issue here[3]
* Amount of RC bugs introduced by promoting an arch to release
candidate. We got too many RC bugs already now.
- For s390x and armhf we can probably get a reasonable estimate by
comparing their bug list with s390 and armel (respectively)[4]
plus looking at the build state stats for these architectures[5].
- I got less ideas for hurd-i386 where there are no "comparision"
arch.
Personally, I could probably also use a refresh on the status of some of
our architectures. Presumably, I/we could ask the porters for an
update, but I have to admit - I am not really sure what to ask for and
what to expect from them.
~Niels
[1] Old draft:
"""
This will be a one-hour meeting to debate the current state of all
architectures. A tentative agenda is attached. Each point has been
allocated a maximum time. Should we be unable to come to a conclusion
within that time, we will debate the issues per mail and (if needed)
follow up with a second meeting.
Agenda:
* Status of hurd (max 15 minutes)
- Hurd porters present
* Status of kfreebsd-{amd64,i386} (max 10 minutes)
- BSD porters present
* Status of armhf and s390x (max 10 minutes)
- Should we promote them to release architectures?
* Status of armel, ia64, mipsel, powerpc, sparc (max 10 minutes)
- Any improvements since last time? (yellow entries)
- Are these still "ok"?
* Status of amd64, i386, mips (max 5 minutes)
- Should be "all ok".
* Misc (max 10 minutes)
"""
[2] http://release.debian.org/wheezy/arch_qualify.html
[3]
http://raphaelhertzog.com/2012/04/19/people-behind-debian-samuel-thibault-working-on-accessibility-and-the-hurd/
"""
The Debian GNU/Hurd port can almost completely be installed from the
official mirrors, using the standard Debian Installer.
"""
Not sure if that means "we have imported packages" (which are not
showing up on my radar) or if it is "just" an installer issue (which
would be covered by the table).
[4] By "bug list" I mean the usertagged bugs for armhf and s390x. e.g.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-s...@lists.debian.org;tag=s390x
Take all non-RC bugs on that list, and if its not on
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-s...@lists.debian.org;tag=s390
then it will "possibly" be a new RC bug.
[5] Something like querying the buildd data base for "FTBFS" on armhf
that are in a "good" state for armel. This is a possibly unfiled FTBFS bug.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9475c9.4080...@thykier.net
Re: Architecture qualification meeting for Wheezy (Was: Re: Release Team meeting?)
On 2012-04-22 10:42, Moritz Muehlenhoff wrote: > On Fri, Apr 20, 2012 at 09:32:40PM +0100, Adam D. Barratt wrote: >> On Fri, 2012-04-06 at 12:44 +0200, Niels Thykier wrote: >>> Per discussions on #d-release, we have decided to postpone the meeting >>> till some time after Easter. >> >> It's now distinctly after Easter, and we need to look at rescheduling >> this. >> >> Do we want to start from looking at dates, or working out how much time >> we need for both the meeting and any pre-meeting prep so people can >> block out the right amount of time? Maybe both at once? :-) > > I can't speak for the whole security team, but I don't believe we need > to be involved. There's no architecture-specific problem with any of > the existing ports in the archive wrt security issues and the current > security buildds build fast enough. > > Cheers, > Moritz Hi, Sounds good. If we do not hear otherwise from you, we will assume you (i.e. the security) have no concerns then. I will take you off the CC then. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f946199.10...@thykier.net
Re: Architecture qualification meeting for Wheezy (Was: Re: Release Team meeting?)
On Fri, Apr 20, 2012 at 09:32:40PM +0100, Adam D. Barratt wrote: > On Fri, 2012-04-06 at 12:44 +0200, Niels Thykier wrote: > > Per discussions on #d-release, we have decided to postpone the meeting > > till some time after Easter. > > It's now distinctly after Easter, and we need to look at rescheduling > this. > > Do we want to start from looking at dates, or working out how much time > we need for both the meeting and any pre-meeting prep so people can > block out the right amount of time? Maybe both at once? :-) I can't speak for the whole security team, but I don't believe we need to be involved. There's no architecture-specific problem with any of the existing ports in the archive wrt security issues and the current security buildds build fast enough. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422084248.ga26...@inutil.org
Re: Architecture qualification meeting for Wheezy (Was: Re: Release Team meeting?)
On Fri, 2012-04-06 at 12:44 +0200, Niels Thykier wrote: > Per discussions on #d-release, we have decided to postpone the meeting > till some time after Easter. It's now distinctly after Easter, and we need to look at rescheduling this. Do we want to start from looking at dates, or working out how much time we need for both the meeting and any pre-meeting prep so people can block out the right amount of time? Maybe both at once? :-) Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1334953960.26539.11.ca...@jacala.jungle.funky-badger.org
Re: Architecture qualification meeting for Wheezy (Was: Re: Release Team meeting?)
On Mar 30, 2012 08:30 "Niels Thykier" wrote: > On 2012-03-30 00:16, Martin Zobel-Helas wrote: > > [...] > > Thanks. So one more time :). > > I propose we do an architecture qualification meeting over the Easter > holidays. I have setup a doddle for it at [1]. > > ~Niels > > [1] http://www.doodle.com/q9i8ptm8hyegam3b > > Hi, Per discussions on #d-release, we have decided to postpone the meeting till some time after Easter. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120406104415.1762e4937c...@bmail-n01.one.com
Re: Architecture qualification meeting for Wheezy (Was: Re: Release Team meeting?)
* Niels Thykier (ni...@thykier.net) [120330 08:31]: > On 2012-03-30 00:16, Martin Zobel-Helas wrote: > > Hi, > > > > On Thu Mar 29, 2012 at 23:52:02 +0200, Niels Thykier wrote: > >> [...] > > > > With my DSA hat on: > > > > It would make sense to have someone from the DSA team present during > > that IRC meeting, as architecture qualification has a direct impact on > > our hardware and resource planning. > > > > Could you set up a doodle for that, and keep us posted? > > > > Cheers, > > Martin > > Thanks. So one more time :). > > I propose we do an architecture qualification meeting over the Easter > holidays. I have setup a doddle for it at [1]. Sorry, but Easter weekend is a bit bad here because that are 4 days where one could be away. Could we move it a weekend earlier or later? That would be great, at least for me. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120330070524.gx13...@mails.so.argh.org
