Re: Status of 'sarge' for the amd64 architecture
Adrian Bunk [EMAIL PROTECTED] writes: On Sat, Apr 30, 2005 at 11:50:30AM +0200, Goswin von Brederlow wrote: 1. release team Another arch to sync. And, as with every arch, there would be some packages that fail just there. There are still a lot of amd64 specific FTBFS bugs (lots of them with patches) that would all become RC. The RC count would double overnight at least for a few weeks. (yeah, it would be back down if this had happened weeks ago) Besides the fact that I think the RC bug count metric isn't a good metric for measuring the quality (it's a good example for the known fact that in such cases only the metric is improved, but other things that aren't measured by this metric tend to be ignored), FTBFS bugs on architectures a package was never built on are not considered RC. Are there any FTBFS issues on amd64 in important packages that aren't easily solvable? Some very few package broke with newer uploads. So those would be counted as did build before by us. Esspecially if the old version is still in sarge. For the rest you are right, they would still only be important and not RC. Then there are the packages with bugs in sarge but not in sid. Again you can keep them all non RC (except util-linux and syslinux which are needed for a release) and . But all of those can easily be fixed by a weekend of aggressive NMUing. 2. security ream Who knows about amd64? Who is able to debug code to see if security problems also exist there? Who will maintain the amd64 security buildd What kind of amd64 specific security problems do you expect (except for kernel issues)? I guess kernel problems. But always expect the unexpected. At a minimum they need a system meeting their security secrecy requirements. (since us Non-DDs are not allowed)? Who will get the wanna-build admins to add the amd64 buildd? Seeing as after over 6 month there are still 2 of the old archs without a security buildd for testing this seems to be a realy big problem. What is the real problem? Getting hardware? Getting money for hardware? Finding administratores for the machines? Beats me. 3. britney One more arch, 15K more packages to consider. Britney needs more ram, more time, gets slower overall and probably fails more often. More hints needed costing more manual time. Why are more hints needed? And if the problem is Britney being resource hungry, adding more RAM to the computer it's running on might be an option? Might be, might not be. I think the britney algorithm needs rewriting. There is something seriously wrong with the current one. Getting killed by out-of-memory after using over 1.2Gb ram doesn't sound correct. 4. D-I docs and CDs There are no docs covering amd64 yet as nobody has done any work in that regard. Since amd64 is basicaly just a i386 on steroids adapting those docs should be easy. But it has to be done. There are also some (hopefully minor) quircks left in debian-cd to investigate. Might be caused by the missing docs. And you have to do this work for your separate amd64 release. I do however feel that the need of Debians users to have amd64 over the next 2 years till etch is out far outweights the inconvenience of adding it. That's why the amd64 team, recently with much entusiasm from other parts of the debian foodchain, is doing the inofficial release in parallel with sarge. Which creates extra work... At least it will be a test for what the SCC/Vancouver proposal will mean. LOTS OF PAIN. Sources are the same, cdimages will be on cdimage.d.o, security updates will follow debian closely. All that differs for users is that ftp.debian.org is amd64.debian.net for the main archive and /debian becomes /debian-amd64 for mirros. Maybe at some point someone up there will decide to embrace amd64, move the files over to ftp-master and call it official post datum. And security fixes will be provided at which location? amd64.debian.net:/debian/dists/stable-security/ probably. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 30, 2005 at 11:50:30AM +0200, Goswin von Brederlow wrote: Adrian Bunk [EMAIL PROTECTED] writes: Sorry, but I still don't understand it: You could continue to offer the complete archive as it is today, and it shouldn't be a big amount of work to offer one or more partial archives (e.g. only stable or only i386) from different locations - and a mirror with bandwith problems could simply switch to using a partial archive. This wouldn't be as complicated as the SCC proposal, would have exactly zero impact on release management and should be implemantable within a few days. Yes it absolutely would be trivial. All it needs is a script to make a linkfarm and sync that daily. I can even give you a script for it. And noone has said _why_ this isn't simply done... Considering that this might make it possible to ship amd64 with sarge which would have a positive effect on the reputation of Debian, could you please explain which technical problems I do oversee when thinking that the technical problems of such a solution were small? If such a solution would e.g. take two weeks and would have been implemented at the day of the SCC announcement, it was running for one month today... Could someone please enlighten me? Back when we asked for amd64 inclusion more than a year ago some people just ignored it, hiding the (non) problem in the process for many month. Then the same people don't want to do anything to fix the problem easy and quickly but rather design a grand scheme to solve a million problems at once with the Vancouver proposal. And through all those delays we are now at the Now it is too late to add amd64 stage. There were also not so nice things like ftpmasters ignoring emails and amd64 porters calling them names for doing this. This was wrong in both directions, and was one more negative result of communication problems inside Debian. So, after letting off some steam, please consider some other things adding amd64 would affect: 1. release team Another arch to sync. And, as with every arch, there would be some packages that fail just there. There are still a lot of amd64 specific FTBFS bugs (lots of them with patches) that would all become RC. The RC count would double overnight at least for a few weeks. (yeah, it would be back down if this had happened weeks ago) Besides the fact that I think the RC bug count metric isn't a good metric for measuring the quality (it's a good example for the known fact that in such cases only the metric is improved, but other things that aren't measured by this metric tend to be ignored), FTBFS bugs on architectures a package was never built on are not considered RC. Are there any FTBFS issues on amd64 in important packages that aren't easily solvable? 2. security ream Who knows about amd64? Who is able to debug code to see if security problems also exist there? Who will maintain the amd64 security buildd What kind of amd64 specific security problems do you expect (except for kernel issues)? (since us Non-DDs are not allowed)? Who will get the wanna-build admins to add the amd64 buildd? Seeing as after over 6 month there are still 2 of the old archs without a security buildd for testing this seems to be a realy big problem. What is the real problem? Getting hardware? Getting money for hardware? Finding administratores for the machines? 3. britney One more arch, 15K more packages to consider. Britney needs more ram, more time, gets slower overall and probably fails more often. More hints needed costing more manual time. Why are more hints needed? And if the problem is Britney being resource hungry, adding more RAM to the computer it's running on might be an option? 4. D-I docs and CDs There are no docs covering amd64 yet as nobody has done any work in that regard. Since amd64 is basicaly just a i386 on steroids adapting those docs should be easy. But it has to be done. There are also some (hopefully minor) quircks left in debian-cd to investigate. Might be caused by the missing docs. And you have to do this work for your separate amd64 release. I do however feel that the need of Debians users to have amd64 over the next 2 years till etch is out far outweights the inconvenience of adding it. That's why the amd64 team, recently with much entusiasm from other parts of the debian foodchain, is doing the inofficial release in parallel with sarge. Which creates extra work... Sources are the same, cdimages will be on cdimage.d.o, security updates will follow debian closely. All that differs for users is that ftp.debian.org is amd64.debian.net for the main archive and /debian becomes /debian-amd64 for mirros. Maybe at some point someone up there will decide to embrace amd64, move the files over to ftp-master and call it official post datum. And security fixes will be provided at which location? MfG Goswin cu Adrian --
Re: Status of 'sarge' for the amd64 architecture
Adrian Bunk [EMAIL PROTECTED] writes: Sorry, but I still don't understand it: You could continue to offer the complete archive as it is today, and it shouldn't be a big amount of work to offer one or more partial archives (e.g. only stable or only i386) from different locations - and a mirror with bandwith problems could simply switch to using a partial archive. This wouldn't be as complicated as the SCC proposal, would have exactly zero impact on release management and should be implemantable within a few days. Yes it absolutely would be trivial. All it needs is a script to make a linkfarm and sync that daily. I can even give you a script for it. Considering that this might make it possible to ship amd64 with sarge which would have a positive effect on the reputation of Debian, could you please explain which technical problems I do oversee when thinking that the technical problems of such a solution were small? If such a solution would e.g. take two weeks and would have been implemented at the day of the SCC announcement, it was running for one month today... Could someone please enlighten me? Back when we asked for amd64 inclusion more than a year ago some people just ignored it, hiding the (non) problem in the process for many month. Then the same people don't want to do anything to fix the problem easy and quickly but rather design a grand scheme to solve a million problems at once with the Vancouver proposal. And through all those delays we are now at the Now it is too late to add amd64 stage. So, after letting off some steam, please consider some other things adding amd64 would affect: 1. release team Another arch to sync. And, as with every arch, there would be some packages that fail just there. There are still a lot of amd64 specific FTBFS bugs (lots of them with patches) that would all become RC. The RC count would double overnight at least for a few weeks. (yeah, it would be back down if this had happened weeks ago) 2. security ream Who knows about amd64? Who is able to debug code to see if security problems also exist there? Who will maintain the amd64 security buildd (since us Non-DDs are not allowed)? Who will get the wanna-build admins to add the amd64 buildd? Seeing as after over 6 month there are still 2 of the old archs without a security buildd for testing this seems to be a realy big problem. 3. britney One more arch, 15K more packages to consider. Britney needs more ram, more time, gets slower overall and probably fails more often. More hints needed costing more manual time. 4. D-I docs and CDs There are no docs covering amd64 yet as nobody has done any work in that regard. Since amd64 is basicaly just a i386 on steroids adapting those docs should be easy. But it has to be done. There are also some (hopefully minor) quircks left in debian-cd to investigate. Might be caused by the missing docs. I do however feel that the need of Debians users to have amd64 over the next 2 years till etch is out far outweights the inconvenience of adding it. That's why the amd64 team, recently with much entusiasm from other parts of the debian foodchain, is doing the inofficial release in parallel with sarge. Sources are the same, cdimages will be on cdimage.d.o, security updates will follow debian closely. All that differs for users is that ftp.debian.org is amd64.debian.net for the main archive and /debian becomes /debian-amd64 for mirros. Maybe at some point someone up there will decide to embrace amd64, move the files over to ftp-master and call it official post datum. Cheers, Andi cu Adrian MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
hoi :) On Mon, Apr 25, 2005 at 05:22:53PM +0200, Andreas Barth wrote: Why not? removing arm from testing does not change at all the number of binary arm packages being pushed each day, as the packages between testing and unstable are shared (and only few packages go in via t-p-u). So, the only win is that packages are faster removed - but as unstable and testing are quite in sync, even this is not so much difference. Adding a new arch however adds a lot of new binary packages to be pushed each day well, those should be about as much as are saved by removing another arch -- once the new architecture is uptodate in testing and unstable. so it seems we have two problems: * too much bandwith needed to update all mirrors. do all mirrors sync with ftp-master? would it help to establish a mirror hierarchy where only a few selected mirrors are allowed to connect to our master server? * the initial peek that is needed to fill the archive of the new architecture. As Andreas already noted, this could be solved by slowly filling the archive. other problems? other solutions? I don't think postponing the problem will help in any way. -- Martin Waitz signature.asc Description: Digital signature
Re: Status of 'sarge' for the amd64 architecture
* Martin Waitz ([EMAIL PROTECTED]) [050429 15:40]: On Mon, Apr 25, 2005 at 05:22:53PM +0200, Andreas Barth wrote: Why not? removing arm from testing does not change at all the number of binary arm packages being pushed each day, as the packages between testing and unstable are shared (and only few packages go in via t-p-u). So, the only win is that packages are faster removed - but as unstable and testing are quite in sync, even this is not so much difference. Adding a new arch however adds a lot of new binary packages to be pushed each day well, those should be about as much as are saved by removing another arch -- once the new architecture is uptodate in testing and unstable. Actually, that is exactly what is planned post-sarge (well, not removing an arch, but splitting the archive so that mirrors are only required to carry some of our current architectures). There is a simple reason why we don't do it now: We prefer to use the ftp-masters time for resolving issues we need to release sarge. (And, BTW, of course an architecture won't be considered for inclusion in sarge unless we have tested it for a decent time in unstable, so even adding amd64 to sid today won't make it an sarge architecture, except if we want to delay sarge even more.) * too much bandwith needed to update all mirrors. do all mirrors sync with ftp-master? would it help to establish a mirror hierarchy where only a few selected mirrors are allowed to connect to our master server? This is already the case. But there are places where our _mirrors_ bandwith is too expansive to make the daily pushes even larger. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Martin Waitz [EMAIL PROTECTED] writes: hoi :) On Mon, Apr 25, 2005 at 05:22:53PM +0200, Andreas Barth wrote: Why not? removing arm from testing does not change at all the number of binary arm packages being pushed each day, as the packages between testing and unstable are shared (and only few packages go in via t-p-u). So, the only win is that packages are faster removed - but as unstable and testing are quite in sync, even this is not so much difference. Adding a new arch however adds a lot of new binary packages to be pushed each day well, those should be about as much as are saved by removing another arch -- once the new architecture is uptodate in testing and unstable. No it doesn't. As Andreas said testing does not produce any traffic (noticeable), it only takes up space. Adding an arch to sid on the other hand does add another arch to the daily pulse. Only removing an arch from _sid_ would gain as much as adding one and surely you don't suggest that? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Fri, Apr 29, 2005 at 03:50:37PM +0200, Andreas Barth wrote: * Martin Waitz ([EMAIL PROTECTED]) [050429 15:40]: On Mon, Apr 25, 2005 at 05:22:53PM +0200, Andreas Barth wrote: Why not? removing arm from testing does not change at all the number of binary arm packages being pushed each day, as the packages between testing and unstable are shared (and only few packages go in via t-p-u). So, the only win is that packages are faster removed - but as unstable and testing are quite in sync, even this is not so much difference. Adding a new arch however adds a lot of new binary packages to be pushed each day well, those should be about as much as are saved by removing another arch -- once the new architecture is uptodate in testing and unstable. Actually, that is exactly what is planned post-sarge (well, not removing an arch, but splitting the archive so that mirrors are only required to carry some of our current architectures). There is a simple reason why we don't do it now: We prefer to use the ftp-masters time for resolving issues we need to release sarge. (And, BTW, of course an architecture won't be considered for inclusion in sarge unless we have tested it for a decent time in unstable, so even adding amd64 to sid today won't make it an sarge architecture, except if we want to delay sarge even more.) * too much bandwith needed to update all mirrors. do all mirrors sync with ftp-master? would it help to establish a mirror hierarchy where only a few selected mirrors are allowed to connect to our master server? This is already the case. But there are places where our _mirrors_ bandwith is too expansive to make the daily pushes even larger. Sorry, but I still don't understand it: You could continue to offer the complete archive as it is today, and it shouldn't be a big amount of work to offer one or more partial archives (e.g. only stable or only i386) from different locations - and a mirror with bandwith problems could simply switch to using a partial archive. This wouldn't be as complicated as the SCC proposal, would have exactly zero impact on release management and should be implemantable within a few days. Considering that this might make it possible to ship amd64 with sarge which would have a positive effect on the reputation of Debian, could you please explain which technical problems I do oversee when thinking that the technical problems of such a solution were small? If such a solution would e.g. take two weeks and would have been implemented at the day of the SCC announcement, it was running for one month today... Could someone please enlighten me? Cheers, Andi 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On 23-Apr-05, 17:24 (CDT), Andreas Barth [EMAIL PROTECTED] wrote: Beyond the fact that it is too late to add another architecture for sarge, removing arm from sarge does not make the mirror pulses much smaller - and AFAIK the size of the mirror pulses is the main problem. See, that just makes no sense whatsover. You can claim either: 1) Adding AMD64 would increase the mirror load unacceptably OR 2) Removing ARM would not have a significant effect on the mirror load but not both at the same time. (Yes, I realize that two different people made these claims, but which one am I supposed to believe?) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Mon, Apr 25, 2005 at 09:24:28AM -0500, Steve Greenland wrote: On 23-Apr-05, 17:24 (CDT), Andreas Barth [EMAIL PROTECTED] wrote: Beyond the fact that it is too late to add another architecture for sarge, removing arm from sarge does not make the mirror pulses much smaller - and AFAIK the size of the mirror pulses is the main problem. See, that just makes no sense whatsover. You can claim either: 1) Adding AMD64 would increase the mirror load unacceptably OR 2) Removing ARM would not have a significant effect on the mirror load but not both at the same time. (Yes, I realize that two different people made these claims, but which one am I supposed to believe?) Sure one can: removing arm would be removing arm from testing, not from unstable. Currently around 800 (of the 8000) source packages in testing have a different version compared to unstable, even less so different arm packages (think big arch:all packages, or arch:i386 specific packages). This means that removing arm from testing would only save about 1GB of space. That's only half of what today's mirror pulse will be, for example. Adding amd64 would however require all the amd64 .deb's to be added, I don't know *how* many it is, but probably about 10 times as much, certainly more than the space saving by removing arm. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
* Steve Greenland ([EMAIL PROTECTED]) [050425 16:45]: On 23-Apr-05, 17:24 (CDT), Andreas Barth [EMAIL PROTECTED] wrote: Beyond the fact that it is too late to add another architecture for sarge, removing arm from sarge does not make the mirror pulses much smaller - and AFAIK the size of the mirror pulses is the main problem. See, that just makes no sense whatsover. You can claim either: 1) Adding AMD64 would increase the mirror load unacceptably OR 2) Removing ARM would not have a significant effect on the mirror load but not both at the same time. (Yes, I realize that two different people made these claims, but which one am I supposed to believe?) Why not? removing arm from testing does not change at all the number of binary arm packages being pushed each day, as the packages between testing and unstable are shared (and only few packages go in via t-p-u). So, the only win is that packages are faster removed - but as unstable and testing are quite in sync, even this is not so much difference. Adding a new arch however adds a lot of new binary packages to be pushed each day (and, for the sanity of the mirrors, we should probably take 20-30 days [just as guess, I didn't start calculate the number] for the initial pushing in of any new arch to restrict the maximum new binary packages on each day). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Le lundi 25 avril 2005 à 16:54 +0200, Jeroen van Wolffelaar a écrit : See, that just makes no sense whatsover. You can claim either: 1) Adding AMD64 would increase the mirror load unacceptably OR 2) Removing ARM would not have a significant effect on the mirror load but not both at the same time. (Yes, I realize that two different people made these claims, but which one am I supposed to believe?) Sure one can: removing arm would be removing arm from testing, not from unstable. Currently around 800 (of the 8000) source packages in testing have a different version compared to unstable, even less so different arm packages (think big arch:all packages, or arch:i386 specific packages). This means that removing arm from testing would only save about 1GB of space. This is true today. Will it still be true in a few months for the differences between stable and unstable? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: Status of 'sarge' for the amd64 architecture
* Josselin Mouette ([EMAIL PROTECTED]) [050425 18:20]: Le lundi 25 avril 2005 à 16:54 +0200, Jeroen van Wolffelaar a écrit : See, that just makes no sense whatsover. You can claim either: 1) Adding AMD64 would increase the mirror load unacceptably OR 2) Removing ARM would not have a significant effect on the mirror load but not both at the same time. (Yes, I realize that two different people made these claims, but which one am I supposed to believe?) Sure one can: removing arm would be removing arm from testing, not from unstable. Currently around 800 (of the 8000) source packages in testing have a different version compared to unstable, even less so different arm packages (think big arch:all packages, or arch:i386 specific packages). This means that removing arm from testing would only save about 1GB of space. This is true today. Will it still be true in a few months for the differences between stable and unstable? The size of the mirror pushes is not really changed by keeping some random packages (aka stable) or not. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Adrian Bunk schrieb: On Sat, Apr 23, 2005 at 01:20:42PM -0700, Steve Langasek wrote: On Sat, Apr 23, 2005 at 04:24:28PM +0200, Adrian Bunk wrote: A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Some of our mirrors have had to choose between distributing Debian and distributing other stuff -- some pick one, some pick the other, but in either case it's bad for the users. The ftpmasters believe it is not in our interest to exacerbate this situation by adding another arch before a sensible per-arch partial mirroring solution is in place. Hm is that a problem with the master archive structure? We mirror against ftp.de.debian.org via rsync and it's very easy to tell rsync just what you want[1] [1] At least that's what we did 'till 3 weeks ago sice then wh have a full debian mirror + amd64 + marillat debs + blackdown.org java debs (amd64 as well) and Ubuntu stuff. Thats 183 GB of files right now. We use a couple of partial mirrors as well that carry only i386 or sparc or amd64 debs without source. greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 07:55:52AM +0200, Andreas Jochens wrote: Steve Langasek wrote: Andreas Jochens wrote: It will only be necessary to describe the current situation in the official release documents and include pointers to the separate amd64 archive, which will be provided by the amd64 porting team anyway. Have you discussed this with the security team, and have they agreed to provide stable security support for amd64 in sync with the other architectures? Or have they agreed to coordinate with someone on the amd64 team for security support? I don't think we can consider it an official stable port without this key feature. This is still an open issue, yes. Security support for amd64 sarge will be one of the main topics for the amd64 porters irc meeting today. An autobuilder has been prepared which will build amd64 security updates for sarge as soon as the sources become available. However, as far as I know, this has not yet been officially coordinated with the security team and I do not know the position of the security team on this. But I am confident that a solution can be found for this issue. The amd64 is certainly willing to do the necessary work. Besides security support, do you have any other concerns which should be addressed to make a sarge release for the amd64 architecture possible? Well, the other big ones would be the installer, being synced up on sources, and the ability to do point releases. It seems the first two are addressed, and the third seems to be more or less the same question as that of security support -- whether the people involved are willing to coordinate with an externally-hosted repo when doing updates. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 12:26:45AM -0700, Steve Langasek wrote: Well, the other big ones would be the installer, being synced up on sources, and the ability to do point releases. It seems the first two are addressed, and the third seems to be more or less the same question as that of security support -- whether the people involved are willing to coordinate with an externally-hosted repo when doing updates. A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? This wouldn't require any extra work. Steve Langasek 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, 23 Apr 2005, Adrian Bunk wrote: A silly question to you as release manager: Silly indeed. Use the list archives. You cannot miss the monstruous threads about it. What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? Mirror space. Instead of replying and beating a dead, burried, and already decomposed horse, just go read the archives. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 11:40:03AM -0300, Henrique de Moraes Holschuh wrote: On Sat, 23 Apr 2005, Adrian Bunk wrote: A silly question to you as release manager: Silly indeed. Use the list archives. You cannot miss the monstruous threads about it. I didn't miss the threads, but much of it looked mostly like the amd64 developers using non-friendly words because the ftp admins didn't respond to them. What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? Mirror space. Instead of replying and beating a dead, burried, and already decomposed horse, just go read the archives. I might have missed this email in the huge threads, but could you point me to an email explaining why increasing the archive space by less than 10% exacly hits a hard limit in mirror space? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, 23 Apr 2005, Adrian Bunk wrote: I might have missed this email in the huge threads, but could you point me to an email explaining why increasing the archive space by less than 10% exacly hits a hard limit in mirror space? No, I cannot. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Hello Steve, thank you for your reply to my status report. Steve Langasek wrote: Andreas Jochens wrote: It will only be necessary to describe the current situation in the official release documents and include pointers to the separate amd64 archive, which will be provided by the amd64 porting team anyway. Have you discussed this with the security team, and have they agreed to provide stable security support for amd64 in sync with the other architectures? Or have they agreed to coordinate with someone on the amd64 team for security support? I don't think we can consider it an official stable port without this key feature. This is still an open issue, yes. Security support for amd64 sarge will be one of the main topics for the amd64 porters irc meeting today. An autobuilder has been prepared which will build amd64 security updates for sarge as soon as the sources become available. However, as far as I know, this has not yet been officially coordinated with the security team and I do not know the position of the security team on this. But I am confident that a solution can be found for this issue. The amd64 is certainly willing to do the necessary work. Besides security support, do you have any other concerns which should be addressed to make a sarge release for the amd64 architecture possible? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 04:24:28PM +0200, Adrian Bunk wrote: On Sat, Apr 23, 2005 at 12:26:45AM -0700, Steve Langasek wrote: Well, the other big ones would be the installer, being synced up on sources, and the ability to do point releases. It seems the first two are addressed, and the third seems to be more or less the same question as that of security support -- whether the people involved are willing to coordinate with an externally-hosted repo when doing updates. A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Some of our mirrors have had to choose between distributing Debian and distributing other stuff -- some pick one, some pick the other, but in either case it's bad for the users. The ftpmasters believe it is not in our interest to exacerbate this situation by adding another arch before a sensible per-arch partial mirroring solution is in place. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 01:20:42PM -0700, Steve Langasek wrote: On Sat, Apr 23, 2005 at 04:24:28PM +0200, Adrian Bunk wrote: A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Some of our mirrors have had to choose between distributing Debian and distributing other stuff -- some pick one, some pick the other, but in either case it's bad for the users. The ftpmasters believe it is not in our interest to exacerbate this situation by adding another arch before a sensible per-arch partial mirroring solution is in place. What are the technical problems with such a solution? To be honest, I still do not understand why such an overly complicated solution like in your SCC proposal was required. Why can't a mirror who has a problem with the size of the Debian archive use a tool like debmirror to create the subset it needs? And if this was a problem for some mirrors, Debian could itself create a few such subsets and offer them for mirrors from a different location. Where is the technical problem behind the whole mirror issue that can't be reasonable solved within a pretty short amount of time? Perhaps I'm dumb, but as far as I understand it, there's no release management reason against shipping amd64 with sarge, and it would both be good for the reputation of Debian and prevent the required extra work of maintaining amd64 for sarge externally if amd64 was included in sarge. That's why I'm trying to understand the technical problems behind solving the mirror issue - and have failed to understand them. Steve Langasek 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
In article [EMAIL PROTECTED], Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Sat, 23 Apr 2005, Adrian Bunk wrote: A silly question to you as release manager: Silly indeed. Use the list archives. You cannot miss the monstruous threads about it. What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? Mirror space. Instead of replying and beating a dead, burried, and already decomposed horse, just go read the archives. Well, there's several mirrors like ftp.nl.debian.org and ftp.debian.nl that now mirror _both_ official debian and debian-amd64. Which means the source is mirrored twice already. On those mirrors, including amd64 would mean less mirror space, not more. Because of the popularity of amd64/em64t I expect a lot of mirrors to follow suit, anyway. So in the end it doesn't really matter if sarge includes amd64 or not - the mirrors will carry it regardless. It would be simpler though to include amd64 with sarge. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
In article [EMAIL PROTECTED] you wrote: We are already running into size constraints (on an ongoing basis) with our mirrors We dont need to have all architectures on all mirrors. And for the less-often used architectures we event dont need to care, since one or two mirrors can easyly hold a stable archive and serve it. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? [1] http://lists.debian.org/debian-x/2005/04/msg00183.html -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Status of 'sarge' for the amd64 architecture
On Sun, Apr 24, 2005 at 12:12:42AM +0200, Josselin Mouette wrote: Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? If we dropped arm, it would be to drop arm, not to trade it for something -- it's way too late to be talking about adding amd64 to the main archive for sarge. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Status of 'sarge' for the amd64 architecture
Le samedi 23 avril 2005 à 15:18 -0700, Steve Langasek a écrit : If we dropped arm, it would be to drop arm, not to trade it for something -- it's way too late to be talking about adding amd64 to the main archive for sarge. Why? If the amd64 archive already uses the same sources as the main archive, and if the security team agrees to support it, it's just a matter of moving it in. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Status of 'sarge' for the amd64 architecture
* Josselin Mouette ([EMAIL PROTECTED]) [050424 00:15]: Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? Beyond the fact that it is too late to add another architecture for sarge, removing arm from sarge does not make the mirror pulses much smaller - and AFAIK the size of the mirror pulses is the main problem. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sun, Apr 24, 2005 at 12:12:42AM +0200, Josselin Mouette wrote: Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? [1] http://lists.debian.org/debian-x/2005/04/msg00183.html Could anyone explain the story behind this? Why exactly is there no longer an ARM autobuilder? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sun, Apr 24, 2005 at 12:24:44AM +0200, Andreas Barth wrote: * Josselin Mouette ([EMAIL PROTECTED]) [050424 00:15]: Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? Beyond the fact that it is too late to add another architecture for sarge, removing arm from sarge does not make the mirror pulses much AFAIK, a freeze date for sarge isn't even announed. Is there any planned date, or will there be a freeze starts tommorow surprise a few weeks or months from now? smaller - and AFAIK the size of the mirror pulses is the main problem. You signed the announcement that the Debian archive would have to be splitted, but even you don't know what exactly the problem is you support the solution for??? Cheers, Andi 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
* Adrian Bunk ([EMAIL PROTECTED]) [050424 00:30]: On Sun, Apr 24, 2005 at 12:12:42AM +0200, Josselin Mouette wrote: Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? [1] http://lists.debian.org/debian-x/2005/04/msg00183.html Could anyone explain the story behind this? Why exactly is there no longer an ARM autobuilder? Because the previous autobuilders had hardware crashes (as in don't boot anymore). We have already new autobuilders up and running, and hopefully stable-security is added soon. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
I demand that Bernd Eckenfels may or may not have written... In article [EMAIL PROTECTED] you wrote: We are already running into size constraints (on an ongoing basis) with our mirrors We dont need to have all architectures on all mirrors. And for the less-often used architectures we event dont need to care, since one or two mirrors can easyly hold a stable archive and serve it. Two or three, with sufficient geographical separation? -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | We've got Shearer, you haven't Quantised Revision of Murphy's Law: Everything goes wrong all at once. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 23 Apr 2005, Steve Langasek wrote: On Sat, Apr 23, 2005 at 04:24:28PM +0200, Adrian Bunk wrote: On Sat, Apr 23, 2005 at 12:26:45AM -0700, Steve Langasek wrote: A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Some of our mirrors have had to choose between distributing Debian and distributing other stuff -- some pick one, some pick the other, but in either case it's bad for the users. The ftpmasters believe it is not in our interest to exacerbate this situation by adding another arch before a sensible per-arch partial mirroring solution is in place. Speaking as a second-level mirror maintainer, I can vouch that the size of the Debian archive is not all *that* large, as compared to other distributions. These are the numbers from a dh -h on the mirror I admin: Debian: 111GB Debian-cd: 51GB Fedora: 152GB Gentoo: 112GB Mandrake: 240GB RedHat: 71GB While others mirrors may very well be suffering from space constraints (where are these messages coming from? [EMAIL PROTECTED] doesn't appear to be active at all), they do have the ability to use proper --exclude lines in rsync to avoid mirroring the debs from the archs that they don't want. I know it's not the best solution, as their Packages.gz file becomes bad, but it works. I'd mirror the AMD64 right now, but I'd have to take portions of my mirror down to reallocate space to a new logical volume. If AMD64 were to go into the main mirror, I know I've got the space for it already allocated. Just my $0.02 - -- Branden J. Moore [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFCas+e0HulGszUTxERAriBAKCK1eLbgd8a0GOorbJSEb8JoBTtFACgxX/X qT5VasHlL1ZFSRYeFoq9JB0= =LJkb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
In article [EMAIL PROTECTED], Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Apr 24, 2005 at 12:12:42AM +0200, Josselin Mouette wrote: Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Given that - if I believe the security team [1] - we are not able to provide security updates for arm, even in woody, is there any point in including it in sarge when we could include an architecture with working autobuilders just in place? If we dropped arm, it would be to drop arm, not to trade it for something -- it's way too late to be talking about adding amd64 to the main archive for sarge. True, we don't want to miss the release date of September 2004. Oh, wait ... Mike. -- One suspects that Chaucer would feel right at home on Usenet -- The Jargon File, flame. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status of 'sarge' for the amd64 architecture
As a preparation for the amd64 porters irc meeting tomorrow, I tried to build the complete Debian sarge archive for the amd64 architecture from the unpatched Debian sarge sources. It took about a week to build all 8800+ source packages on a standard single processor EM64T-P4 box (Every package was built in a newly created clean chroot environment. By relaxing this requirement, the build time for the archive could probably be reduced to less than four days.) The result was very encouraging. Almost all packages build now on amd64 without problems using the pristine Debian sarge sources. There are very few remaining cases where a patch has been submitted to the BTS a long time ago and for some reason that patch has not yet been applied. These cases could either be solved by a porting NMU or by just dropping that package from the amd64 version of sarge. For some reason, the amd64 architecture has not been added to the official Debian archive. There is a plan to change this when sarge is released, but as I understand it, there is no plan to provide amd64 binaries for sarge in the official Debian archive. This means that Debian sarge will be released with source packages that can be used to build a complete and fully usable Debian sarge distribution for the amd64 architecture, but there will be no binaries available in the main Debian archive. This is not necessarily as bad as it may look at a first glance. First of all, everybody can build its own Debian amd64 sarge archive from the official Debian sarge sources. It will take only a few days to build the complete archive on cheap commodity hardware. This archive build process, including later updates, can easily be automated by a small script. To build packages from sources instead of downloading binary packages from a Debian archive may be a good idea from a security point of view. For critical applications it seems to be problematic to trust a binary archive which depends on the integrity of the machines of 1000 Debian developers. But of course, there _is_ a binary Debian amd64 sarge archive. The debian-pure64 amd64 archive on alioth is maintained by members of the amd64 porting team. It tracks the current Debian 'unstable' and 'testing' distributions. In the current situation, the amd64 porting team is responsible for providing and maintaining the amd64 binary archive and the amd64 buildd infrastructure, while the sources are taken from the normal Debian source archive. I consider this a good way to split up responsibilities. This way of handling things could serve as a good example of how other ports may be organized after sarge is released. As a conclusion, I think that it may still be possible to release the amd64 port with sarge. Nothing in the current setup has to be changed for that. It is just a matter of recognizing the current state of affairs officially. It will only be necessary to describe the current situation in the official release documents and include pointers to the separate amd64 archive, which will be provided by the amd64 porting team anyway. Regards Andreas Jochens P.S.: The above statements represent my personal view only. Other members of the amd64 porting team may view things differently, of course. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
Hi Andreas, On Fri, Apr 22, 2005 at 08:05:17PM +0200, Andreas Jochens wrote: I consider this a good way to split up responsibilities. This way of handling things could serve as a good example of how other ports may be organized after sarge is released. I certainly agree with that; unfortunately, history seems to suggest that this method of organization tends to fall away once an architecture is integrated into the archive. :) As a conclusion, I think that it may still be possible to release the amd64 port with sarge. Nothing in the current setup has to be changed for that. It is just a matter of recognizing the current state of affairs officially. It will only be necessary to describe the current situation in the official release documents and include pointers to the separate amd64 archive, which will be provided by the amd64 porting team anyway. Have you discussed this with the security team, and have they agreed to provide stable security support for amd64 in sync with the other architectures? Or have they agreed to coordinate with someone on the amd64 team for security support? I don't think we can consider it an official stable port without this key feature. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Status of 'sarge' for the amd64 architecture
Hello, On Fri, Apr 22, 2005 at 08:05:17PM +0200, Andreas Jochens wrote: As a preparation for the amd64 porters irc meeting tomorrow, I tried to build the complete Debian sarge archive for the amd64 architecture from the unpatched Debian sarge sources. The result was very encouraging. Almost all packages build now on amd64 without problems using the pristine Debian sarge sources. Thats great news, thanks for doing the proof of concept =) For some reason, the amd64 architecture has not been added to the official Debian archive. There is a plan to change this when sarge is released, but as I understand it, there is no plan to provide amd64 binaries for sarge in the official Debian archive. Really a sad thing, considering we already demanded addition to the archive exactly a year ago in a couple of weeks. I look forward discussing the other topics on the meeting tomorrow :) Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
