Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:54:36PM -0800, Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: I was quoting a post with actual download numbers that actually demonstrate that the vast majority of users are on i386: see http://blog.bofh.it/id_66. But that doesn't show what you said you believe, which is that supporting other archs slows the release. It's not actually all that difficult to show that there's a positive, roughly linear correlation between the number of release archs and the magnitude of certain problems that are potential release delays: - new versions of packages are not promoted to testing until they're in sync on all archs - all release-critical bugs in packages are resolved by either removing the package from testing (not always an option) or by getting a new version of the package into testing - a buildd for a single arch that is broken with respect to the package in question can therefore cause a delay in fixing a single release-critical bug in testing - the chance of a bug fix being held out of testing because of a buildd bug on some arch is roughly equal to the chance of it being held out because of a bug on a particular arch, times the number of archs[1] - when the delays cause our bug closure rate to be lower than the rate at which new release-critical bug reports are opened, we have a problem. That said, however, there is not much evidence to support the idea that dropping architectures from the list of release candidates is going to get us to the release any faster. Not only is there the possibility that the responsiveness of individual buildd maintainers should outweigh popularity as a factor in deciding which architectures to support, there's also the issue that the biggest blocker for sarge currently, the lack of testing-security buildd support, affects all but *two* architectures. Somehow, I don't think the idea of releasing with only i386 and sparc would be very popular, even if I was inclined to do so. Easy to say. How many RC bugs have you fixed recently, and if we dropped the other archs, how many would you have fixed? ahem do we get to count on his behalf CAN-2005-0011, a security bug in kdeedu which is currently blocked from reaching testing because the quantlib package he maintains needs for someone to manually adjust the buildd timeout on mips and mipsel? - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. Prior to release, security bugs are RC bugs that are handled by the testing security team and the release team. While we would not delay the release on account of security bugs alone (since they can be fixed post-release), they are bugs that get tracked by the release team. - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Hmm, no; I've only said that dropping archs because of build problems affecting individual, arbitrary packages is a stupid strategy for getting us to release. -- Steve Langasek postmodern programmer [1] With other minor factors that probably balance each other out, such as identical simultaneous breakage on multiple buildds that reduce the impact by allowing fixes in parallel or as a batch, vs. some buildd maintainers running multiple buildds who may have less time to tend an individual arch because of the total number of archs being supported signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:09:55PM -0500, Joey Hess wrote: - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. DSAs are occasionally delayed waiting on builds. The priveliged nature of much of the information surrounding DSAs makes it impossible for me to give a list, but I've seen it happen repeatedly. The most glaring example in recent memory is the 6 or so months it took for us to get updated kernels in stable for last spring's set of very bad kernel security holes. Security bugs which are currently not fixed in testing, and which either would be fixed there or would not be a concern if it wasn't for the need to support all architectures include: Just so we're clear on *which* architectures are at issue here, and why they are: bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1 arm, sparc builds waiting on the xfree86 chroot cleanup bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 arm waits on cleanup of yacc alternative mess in buildd chroot emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1 m68k, mips builds missing due to a timestamp skew problem in the package that constitutes a sourceful bug in emacs21 which affects slow architectures *and all archs running 2.6 kernels* (hence amd64 fails, and after release any buildds that switch to 2.6 kernels in sarge would fail) kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011 mips, mipsel build of quantlib needed, requires adjusting buildd timeouts kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 not actually an architecture stall problem anymore; this was a missing mipsel build, but now it's that kdelibs is hung up waiting for aspell, which is the sort of bad timing that can affect us at any moment (but is certainly more likely when uploads to unstable for all archs are spread across a longer period) kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465 alpha, obviously kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, CAN-2004-1235 and sparc, of course kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 powerpc... xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1 since resolved xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1 not actually an arch buildd problem, the issue here is that we have known-broken binaries on one arch that need to be removed from the archive; but if we count it, it counts for ia64. So supposing we had some sort of requirement for release archs such as within 10 days of any source upload, there must be either a binary upload or a FTBFS report for the build, we would presently have to kick out alpha amd64 arm ia64 m68k mips mipsel powerpc sparc and keep hppa i386 s390; and if we relax this to only require within 10 days of any source upload, assuming the source isn't buggy, there must be a binary upload for this security bug, we would be kicking out alpha arm mips mipsel powerpc sparc and keeping amd64 hppa ia64 i386 m68k s390, which I hope amply demonstrates the point to people that railing against slow or unpopular architectures is not actually going to bring about the desired outcome. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sat, Feb 26, 2005 at 05:27:48PM -0800, Steve Langasek wrote: and if we relax this to only require within 10 days of any source upload, assuming the source isn't buggy, there must be a binary upload for this security bug, we would be kicking out alpha arm mips mipsel powerpc sparc I think those have one thing in common... and keeping amd64 hppa ia64 i386 m68k s390, ... and those archs has something in common as well. Who spots the point? ;) -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Dirk Eddelbuettel] [1] I removed the entry unknown -- this corresponds to assuming that unknown as population corresponds to the distribution of all known dists shown here. Lacking knowledge of what drives unknown, this appears fair. If someone has a breakdown of unknown, I will gladly use it. 'unknown' are the submissions without arch info, most likely machines running debian/woody. It might be fair to assume that the unknown population have the same arch distribution, and it might not. I suspect some archs are over-represented in debian/sid and debian/sarge, and others are over-represented in debian/woody. But I have nothing to back up my suspicion. :) As for the accuracy with such small population, I believe the relative distribution accuracy is very high. It haven't changed much the last few years, while the number of submissions have more than doubled. Not too long ago, the i386 count was split it two, i386 and amd64, but the sum of those two are very close to the value previously used by i386. Another minor piece of information to consider, is that slightly less than 200 amd64 machines are from one cluster in Sweden. If we ignore this cluster, the amd64 population count would end up somewhere between powerpc and sparc. (I know this because I could see the steep growth, and was approached by the cluster maintainer asking if it was ok for 200 identical machines to report to popcon. My answer was that this was ok, as long as the machines were real machines and not just for example chroots. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: stuff and numbers Just because an arch is fairly unused doesn't mean we should drop it. We should drop an arch just like we would drop a package - if it doesn't work, no one wants to maintain it, and if keeping it would delay release. -- Petri Latvala signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Feb 23, Adam Heath [EMAIL PROTECTED] wrote: These numbers show a cross-section of users who use this particular mirror. It is not represenative of the world as a whole. Far from it. Agreed. But I have not seen any other reports so far. -- ciao, Marco signature.asc Description: Digital signature
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 10:57:06PM -0600, Ron Johnson wrote: On Tue, 2005-02-22 at 22:25 -0500, Glenn Maynard wrote: On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: [snip] Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. NetBSD? 'sensible' ducks That said, NetBSD often is not a good option, because they are mainly a source-based operating system whereas Debian is not. This is not to say that Debian is better than NetBSD, but both source-based and binary-based operating systems have their merits. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 10:57:06PM -0600, Ron Johnson wrote: On Tue, 2005-02-22 at 22:25 -0500, Glenn Maynard wrote: On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: [snip] Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. NetBSD? Debian + NetBSD! Okay, so Nienna is going to be lucky to be a candidate for etch, even at the current release rate; there's simply a huge amount of work to do and much of it is still core work that isn't easy for Joe Random Developer to do. But it was too good a shot to pass up. :) Seriously, though: anyone who argues that keeping amd64 out while keeping some of our architectures with pitiable download/popcon stats in, when an arch-for-arch swap would prevent mirror growth, is utterly missing the point of the question Yes, it's in the interest of our users, but *we have to choose* for Sarge - and which one is *more* in the interest of our users? But that's OK. Our amd64 users just use the Alioth site instead of our wonderful mirror network, and track it as unstable. I mean, it's so much more effective to have it all hitting alioth for download, right? Thought so. People will (often) do it the right way if it's convenient, but if it serves a use to them, they *will* do it, right way or not. We support amd64 officially, or we support it unofficially and in a thoroughly half-assed manner, but it's what some number of developers and users care about, so we WILL end up supporting it (or rather, we ARE supporting it). The question is only 'how well?'. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Joel Aelwyn wrote: [snip] But that's OK. Our amd64 users just use the Alioth site instead of our wonderful mirror network, and track it as unstable. I mean, it's so much more effective to have it all hitting alioth for download, right? Thought so. You probably should inform yourself before talking. The amd64 port has also a sarge distribution, and alioth isn't the only site carrying it. Thiemo signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 2005-02-22 at 04:39 +, Dirk Eddelbuettel wrote: For your convenience, I quote the numbers here again along with a quick percentage calculation: md - read.table(/tmp/md.txt, header=TRUE, row.names=1) md - cbind(md, percent=round(100*md[,1]/md[total,1], 4)) md files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. The problem with these numbers is the architecture all. over 27% of files downloaded don't count since you don't know what systems they are running on. -- Patrick Ouellette [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Wed, Feb 23, 2005 at 08:38:21PM -0500, Patrick Ouellette wrote: The problem with these numbers is the architecture all. over 27% of files downloaded don't count since you don't know what systems they are running on. All of these people having the time to comment this statistical sample. Yes, it is a bit inaccurate. Thanks for everyone for their feedback. But it's not like this isn't moderately close to the truth. It's not like there's some 10-box mips installation cluster hiding somewhere. Yes, there are arches that have less use than i386 or amd64. No statistical inaccuracy or error in this sample is going to change that. (Patrick, no offence meant for you, I replied to your message but I'm speaking to all people who gave out similar info, not just you. Sorry. And now back to the original topic.) The thing is, the actual numbers don't matter, as long as there is _some_ use. And there is. In programming in general, it is best to identify the bottleneck by profiling and optimize on that, and only that. Let's do the same with releasing. What is the bottleneck of the release now? Testing-security infrastructure? Focus on that if you want a release happening. Or the ~100 RC bugs still left. gtk+ build failing because lack of disk space makes some things go slower, but it's not like Sarge is released the moment gtk+ is built. It's not the bottleneck. -- Petri Latvala signature.asc Description: Digital signature
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Wed, Feb 23, 2005 at 10:25:04PM +0100, Thiemo Seufer wrote: Joel Aelwyn wrote: [snip] But that's OK. Our amd64 users just use the Alioth site instead of our wonderful mirror network, and track it as unstable. I mean, it's so much more effective to have it all hitting alioth for download, right? Thought so. You probably should inform yourself before talking. The amd64 port has also a sarge distribution, and alioth isn't the only site carrying it. Wonderful way to miss the point - which is that we aren't using the actual, existing infrastructure that exists for these things, but rather, cobbling together a kludge that may, or may not, work in the long term, certainly takes more resources than it otherwise would (which is to say, a few incremental resources time/developer-wise, and one arch worth of space mirror-wise, which is the kicker), and is just, in general, a big middle finger to anyone needing current top-end hardware. I mean, it's one thing to say You know, the not-expected-to-be-large number of users for a NetBSD port just doesn't warrant a lot of time invested right this second for making it possible. I agree with that. But failing to support the only arch big enough to actually cause the other distributions, who are mostly infamous for NOT supporting architectures, bother? It just makes us look like idiots. I think the lesser-known architectures are great, and there isn't one of them I'd want to see dropped unless folks simply stop working on them, but if you put on the table in front of me We have room for 11 architectures, and no more. If you want amd64 in, one of them has to go, I'm not going to flinch much at dropping one of the ones at the low end of the spectrum until post-sarge. However, it's not my choice to make, so we'll just stumble along, continue to duplicate effort and waste resources, and look like idiots, because the second-or-third-most-used arch out of 12 releaseable ones (that got that way in, what, well under a year?), depending on how you count it, isn't even an official one. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Dirk Eddelbuettel ([EMAIL PROTECTED]) [050222 05:45]: It delays our releases in the sense that it affects our resources: - available maintainer and developer time, You mean, we have some great people working as porters and also giving a general helping hand, and we would loose them if we throw most arches out? :) - cpu cycles (witness Wouter's request to compile big packages rarely), It is _definitly_ a bad idea to just upload packages every few days. This has nothing to do with buildds, but just with general good or bad preparations. - security response time (more builds to do) that is not an issue. and that it - increases the load on infrastructure (t-p-u, security) There's no real difference between 2 and 11 archs - scarce resource such as release managers, ftp admins, ... no. Frankly speaking, the most costly point with other arches is that there are too often these useless discussions. _That_ is beyond all the most expansive of them. 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: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Matthew Palmer ([EMAIL PROTECTED]) [050222 06:20]: Security autobuilders are on their way. You could make the argument that if we only had a couple of architectures we wouldn't really need security autobuilders, but I think that automating everything that can be automated is a Good Thing. We have security autobuilders since woody. 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: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. Nor could this possibly slow release. One of the biggest reasons provided so far against accepting amd64 is we don't have enough mirror space. Dropping a less-used port for a new commonly-used one seems an easy fix here. Most of the large mirrors currently carry all arches, hence the efforts on billie to make it easier for people to drop the less common arches. - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Into the distance, a ribbon of black Stretched to the point of no turning back -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 10:42:15AM +, Steve McIntyre wrote: Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. But the CD set build would take hours rather than weeks, right? I can't imagine it'd hold up the release by any appreciable amount, and building CD sets is a nicely parallelizable task. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: Maybe we should pick up on Petter's suggestion of stricter buildd requirements. Maybe we should only build base and essential packages for the minor architectures [ after, apt-source is there for everybody to go further ]. Debian is not a source-based distribution. If people want to compile their own packages, they usually go to one of the BSD's or Gentoo. In the mean time, our users expect to be able to run 'apt-get install' and be done with it. We should not break that expectation, because that would not be in the interest of our users; we should ensure that all software our users would want to run is available. I agree that we should not continue to provide software for outdated hardware platforms just for the sake of it; but as it is, there are still people interested in m68k (some hobbyists, some embedded developers, some who just use their old trusty hardware as their home firewall, etc) and, I'm sure, other currently less-used hardware, so as long as a port doesn't continually stall the release (which none currently does; there are occasionally problems, but that happens in every major undertaking), I see no reason to drop any port. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:54:36PM -0800, Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - cpu cycles (witness Wouter's request to compile big packages rarely), So you're saying that if we dropped the mips buildd's we'd have more cycles for other archs? No, he's saying that if we dropped the slower architectures we'd be able to do more frequent updates of large packages, such as KDE. However, this is false. You'd get * Angry mirror administrators that don't like the fact that users now have to download a *much* larger amount of data every day for their daily updates, thus eating a larger part of their bandwidth, * Angry users who, like me, have a traffic quota on their Internet connection and who'd get problems staying within the quota if they want to keep up with unstable, * Problems keeping track of all those versions, and the relation to when bugs were fixed (there are always users who do not have the latest version of a package installed and still file bugs). * Problems with your own development pace, because you'd be spending more time on performing package builds and making sure they get updated correctly than you'd be spending on the improvement of those packages. As I said before, this is not just a buildd problem, it's a sensible approach to maintaining large packages in general; and if you as the maintainer of a large package really made a stupid mistake and need to upload a package within two hours after the previous one, then so be it. We only request that you try to avoid it as much as possible. - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. In fairness, this is not just a fairy tale. DSA's are sent out for all architectures at once; if a package requires two days to build on the slower architectures (there are packages for which this is true), then the DSA will take two days to be prepared. I should note that security builds are given priority, however, and are done on the fastest machines in the architecture's buildd pool. That said, your statement that it could not slow release is, of course, true. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote: On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... Why not? Is there something non-deterministic in the compilation process? Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? (I'm actually quite fond of the idea of dist-cc sending pre-processed C code to remote (faster) machines and getting unlinked object code back. I haven't got a good use for it yet, but the _idea_ is neat.) -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
Paul Hampson wrote: On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote: On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... Why not? Is there something non-deterministic in the compilation process? Yes. Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? gcc -fno-guess-branch-probability Thiemo signature.asc Description: Digital signature
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
[EMAIL PROTECTED] (Paul Hampson) writes: Or have I missed something important? Yes. There are a jillion different machine code programs that do the same thing and a compiler could generate any one of them in response to the same source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Steve McIntyre [EMAIL PROTECTED] writes: Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. Does this delay release? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
On Wed, Feb 23, 2005 at 12:38:46AM +1100, Paul Hampson wrote: Why not? Is there something non-deterministic in the compilation process? Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? -frandom-seed=string This option provides a seed that GCC uses when it would otherwise use random numbers. At present, this is used to generate certain symbol names that have to be different in every compiled file. The string should be different for every file you compile. -fno-guess-branch-probability Do not guess branch probabilities using a randomized model. Sometimes gcc will opt to use a randomized model to guess branch probabilities, when none are available from either profiling feedback (-fprofile-arcs) or __builtin_expect. This means that different runs of the compiler on the same program may produce different object code. Also, the first 16 bytes will differ in an ELF format .o, see http://lists.debian.org/debian-devel/2004/09/msg00201.html -- Petri Latvala signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG wrote: - network bandwith (witness the discussion on mirror efficiency), Mirrors don't have to (and don't need to) copy all the archs. They can support whichever ones they want. Nor could this possibly slow release. - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. That's predicated on the assumption that mirrors can easily or feasibly do such a partial mirror. The small number of mirrors that have, the smaller number of important mirrors (push-primary, top-level country code mirrors, etc) that have, and the fact that the ftp-masters have this upcoming SCC project to make it easier, belies that. - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. DSAs are occasionally delayed waiting on builds. The priveliged nature of much of the information surrounding DSAs makes it impossible for me to give a list, but I've seen it happen repeatedly. The most glaring example in recent memory is the 6 or so months it took for us to get updated kernels in stable for last spring's set of very bad kernel security holes. Security bugs which are currently not fixed in testing, and which either would be fixed there or would not be a concern if it wasn't for the need to support all architectures include: bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1 bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1 kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011 kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465 kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, CAN-2004-1235 kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1 xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1 - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. To the contrary, I've publically said before that the need to support all our architectures (in d-i) has prevented me from doing other work that I could have done to advance the release. The release of d-i RC3 has been delayed for several months now because that's how long it takes to update the debian kernel packages for all arches. I've spent at least one man-week of full-time work during that time period in tracking what work still needed to be done and working with the debian-kernel team, ftp-masters, d-i team, and others to get the updated kernels in place. I've spent approximatly one man-month of time in the past year on setting up and running an automated test lab for the debian-installer on 6 or 7 architectures. For some lesser-used architectures, the install tests from this lab are the only way we have to know if the installer is generally working on a day-to-day basis, since we get only rare installation reports from users of those arches. The above is just the tip of the iceberg WRT architecture specific d-i work that I have to do. If I hadn't needed to work on that stuff due to the requirement that d-i release on all arches, then I would have certianly been able to devote more time to other things, including testing security work, other release-critical areas of d-i, and so on. I'm not particularly advocating dropping any architectures at this point, but I do think that people who shrug off the impact of our supporting so many architectures are not arguing from a very strong position. -- see shy jo signature.asc Description: Digital signature
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
Petri Latvala wrote: [snip] Also, the first 16 bytes will differ in an ELF format .o, see http://lists.debian.org/debian-devel/2004/09/msg00201.html That's incorrect, strictly speaking. The first (magic) bytes have to be identical, only the padding bytes could be different (but are usually zeroed). Thiemo signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 10:17:39AM -0800, Thomas Bushnell BSG wrote: Steve McIntyre [EMAIL PROTECTED] writes: Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. Does this delay release? It delays the release of the CDs and DVDs, yes. I don't know if you care about that. It also adds significantly to the amount of work needed regularly for the weekly sarge CD and DVD builds. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. These numbers show a cross-section of users who use this particular mirror. It is not represenative of the world as a whole. Far from it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Don Armstrong don at debian.org writes: On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. You used package download results from one (1!) debian mirror to demonstrate the supposed lack of usage. However, those download stats only point to who is actually downloading packages with that architecture from only that mirror in a single month. These were the only public usage numbers, broken out by arch, from a primary mirror, that I am aware of. Which is why I used them. If you suspect that they are unrepresentative, you would greatly enhance the debate by providing additional data from the US, UK, DE, FR, JP, ... mirrors and actually proving me wrong -- rather than just calling the Earth flat. In any event, I found a way to complement these numbers -- using the upload reports from popcon.debian.org, taken earlier today. With a little emacs editing, we get the data file below, which is used by the few R commands include below as well. [1] reports percent hurd-i386 1 0.0175 kfreebsd-i386 1 0.0175 ppc64 1 0.0175 arm 2 0.0351 mipsel 2 0.0351 m68k3 0.0526 s3904 0.0702 mips5 0.0877 ia649 0.1579 hppa 12 0.2106 alpha 33 0.5790 sparc 47 0.8247 powerpc87 1.5266 amd64 257 4.5096 i386 5235 91.8582 total5699 100. Now this shows that *amd64 is already the second most important arch*. We are so busy looking after the arches used by basically nobody that we are not getting around to releasing with what is becoming *the* main alternative to i386. Oh boy. Dirk [1] I removed the entry unknown -- this corresponds to assuming that unknown as population corresponds to the distribution of all known dists shown here. Lacking knowledge of what drives unknown, this appears fair. If someone has a breakdown of unknown, I will gladly use it. [2] Raw data, stored in /tmp/popcon.txt reports alpha 33 amd64 257 arm 2 hppa 12 hurd-i386 1 i386 5235 ia64 9 kfreebsd-i386 1 m68k 3 mips 5 mipsel2 powerpc 87 ppc64 1 s390 4 sparc 47 unknown 1116 [3] Simple transformation script popcon.R Raw - read.table(/tmp/popcon.txt, header=TRUE, row.names=1) ind - which(Raw==Raw[unknown,1]) ## find row with unknown Dat - Raw[-ind,,drop=FALSE]## create new data.frame without it Dat - Dat[order(Dat[,1]),1,drop=FALSE] ## order by downloads Dat - rbind(Dat, total=sum(Dat[,1])) ## add a new row for totals Dat - cbind(Dat, ## add a percentage column percent=round(100*Dat[,1]/Dat[total,1], 4)) print(Dat) ## show result -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: reports percent hurd-i386 1 0.0175 kfreebsd-i386 1 0.0175 ppc64 1 0.0175 arm 2 0.0351 mipsel 2 0.0351 m68k3 0.0526 s3904 0.0702 mips5 0.0877 ia649 0.1579 hppa 12 0.2106 alpha 33 0.5790 sparc 47 0.8247 powerpc87 1.5266 amd64 257 4.5096 i386 5235 91.8582 total5699 100. Now this shows that *amd64 is already the second most important arch*. We are so busy looking after the arches used by basically nobody that we are not getting around to releasing with what is becoming *the* main alternative to i386. Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 22 Feb 2005 22:25:25 -0500 Glenn Maynard [EMAIL PROTECTED] wrote: On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: reports percent hurd-i386 1 0.0175 kfreebsd-i386 1 0.0175 ppc64 1 0.0175 arm 2 0.0351 mipsel 2 0.0351 m68k3 0.0526 s3904 0.0702 mips5 0.0877 ia649 0.1579 hppa 12 0.2106 alpha 33 0.5790 sparc 47 0.8247 powerpc87 1.5266 amd64 257 4.5096 i386 5235 91.8582 total5699 100. Now this shows that *amd64 is already the second most important arch*. We are so busy looking after the arches used by basically nobody that we are not getting around to releasing with what is becoming *the* main alternative to i386. Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. Or you can debate whether something like a sparc and alpha will be used for more important projects than the average amd64. In that case, one sparc or alpha could carry more weight than one amd64. Important can be a totally different twist that's very open to definition. Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 2005-02-22 at 22:25 -0500, Glenn Maynard wrote: On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: [snip] Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. NetBSD? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. Since when do business goals (profit) come before values, ethics, and decency? Dr. Laura Schlessinger Since the time of the writing of the Old Testament... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sunday 20 February 2005 23:57, Dirk Eddelbuettel wrote: Clint Byrum cbyrum at spamaps.org writes: But then it doesn't matter anymore. These days, Debian is infrastructure. We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. em. at least for CDD's this is false, CDD-releases build on Debian releases as the only differences between a CDD and Debian are: - the initial set of installed packages - the default configuration of those packages (- some additions/changes not _yet_ added/merged back into Debian proper) CDD's are currently based on Debian-stable (which is the reason Skoleinux, for example. is still using kde 2.2), and eagerly anticipating the release of Sarge -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpaHE3oNI8da.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: Clint Byrum cbyrum at spamaps.org writes: Now, can someone please tell me how messages like the one below, and others, aren't indicative that debian should drop s390, mipsel, and maybe hppa from the list of architectures? How about we release for i386, sparc, and powerpc, and let the others release on their own schedule? This business of supporting 11 architectures and making sure they're all 100% right before releasing is just about the worst idea ever. Couldn't agree more. Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. I'll believe that when you can point me to an actual occasion where something not being built on /only/ one of those less mattering architectures you want to drop (as opposed to the three latter ones) effectively stalled the release. As it is, architecture-specific problems occur on all architectures, not just the less important ones. Claiming the contrary only proves you don't know what you're talking about. The problem being talked about (not enough disk space on the buildd host) is serious, but can be fixed; and /nothing/ prevents it from happening to other architectures in the future. But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. It also ensures that GNU/Linux still actually runs on the platforms we support, which is often of great importance of embedded developers. It also ensures that gcc remains working (what better way to test a compiler than to compile 10G worth of software with it?), and so on. [...] Still, the hours we maste on fixing, building, maintaining, ... code on unused platforms is hysterical waste of resources. The only resource that is being wasted, is one of disk space (well, and network traffic for mirror updates). How is that a major problem, considering that mirrors will be allowed to pick their architecture in the future? Resources we don't really have. On porting, we usually have all the resources we really need. It would be better to concentrate on a core of packages, and platforms, and then get on with it. One day it will break the infrastructure provision, at which point someone will fork our high-priority core packages. You're welcome to do so, if you really must. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. Hypothetical daily KDE builds would also insanely increase the amount of network traffic being used by the mirror pulse and people upgrading their home boxes, so it isn't just a buildd problem. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 12:09:16AM -0300, Henrique de Moraes Holschuh wrote: On Sun, 20 Feb 2005, Brian Nelson wrote: Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. The answer to that is to setup a dist-cc cluster for these archs, where only the master node is in the slow arch, and everything else is a fast arch. That would require cross-compilers on the other hosts in the distcc cluster, and (unless I don't understand how dist-cc works; never had a look at it) a mechanism to install build-dependencies on those hosts in addition to the one on the 'slow' node. There are a few reasons why we usually avoid cross-compilers for buildd purposes. For one, as one cannot as easily test a cross-compiler by running a test suite, it may have been miscompiled -- but you wouldn't notice; this would result in strange, hard to debug behaviour by the resulting cross-compiled packages. For another, satisfying build-dependencies for cross-compiling is pretty hard, as anyone using dpkg-cross can tell you. Our answer simply is (or at least, should be) to increase the number of buildd hosts if we can't keep up, and to request the maintainers of large packages that they don't do daily updates, which is a bad idea anyway. If maintainers insist on doing daily updates, we stop building their package. See mozilla-snapshot (even though it's no longer in the archive these days). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Le Lun 21 Février 2005 11:38, Wouter Verhelst a écrit : On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. Hypothetical daily KDE builds would also insanely increase the amount of network traffic being used by the mirror pulse and people upgrading their home boxes, so it isn't just a buildd problem. that's true, though this is because partial uploads are not possible I mean that you have no way to say for huge source packages : you only need to build this , this, this and this pacakge. since the changes I've made won't affect the others. I know this raises practical problems (the worst of it not beeing able to construct the same packages that are on the archive when starting from source+diff). But if one day BW is critical, there is a path to explore here. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpXPKHIGiGGX.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. Hypothetical daily KDE builds would also insanely increase the amount of network traffic being used by the mirror pulse and people upgrading their home boxes, so it isn't just a buildd problem. Those would need to go into experimental, where no buildd problem exists by definition. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 12:04:37PM +0100, Pierre Habouzit wrote: I know this raises practical problems (the worst of it not beeing able to construct the same packages that are on the archive when starting from source+diff). But if one day BW is critical, there is a path to explore here. Oh, absolutely; but let's not forget that we can't even correctly specify how we only want to build arch-dep vs arch-indep packages currently... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Thiemo Seufer] Those would need to go into experimental, where no buildd problem exists by definition. I'm told there are some autobuilders for experimental, and believe your definition of experimental need some adjustment. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 21 Feb 2005, Wouter Verhelst wrote: That would require cross-compilers on the other hosts in the distcc Not from what I know of dist-cc. You just need dist-cc, and nothing else. dist-cc just offloads the number-crunching, so it uses no data from the non-master node. AFAIK anyway (which is NOT much on dist-cc matters). There are a few reasons why we usually avoid cross-compilers for buildd I know. But dist-cc is not a cross-compiler. And unlike a buildd farm like m68k has, it will cut down the ammount of time it takes for a BIG package to be compiled. -- 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: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Petter Reinholdtsen wrote: [Thiemo Seufer] Those would need to go into experimental, where no buildd problem exists by definition. I'm told there are some autobuilders for experimental, And how would missing builds there be a problem? and believe your definition of experimental need some adjustment. :) Daily build+upload of a package prevents it from migrating ever to testing. IMHO uploading daily builds to unstable is inappropriate, especially since packages in unstable are supposed to be in a generally releasable state, and daily changes in a package are unlikely to meet that standard. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Petter Reinholdtsen ([EMAIL PROTECTED]) [050221 12:30]: [Thiemo Seufer] Those would need to go into experimental, where no buildd problem exists by definition. I'm told there are some autobuilders for experimental, and believe your definition of experimental need some adjustment. :) Thiemo knows that pretty well :) However, if they are overloaded/broken/whatever, the real implications are quite limited, and it doesn't matter for purposes like preparation of the next stable release. 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: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
There are a few reasons why we usually avoid cross-compilers for buildd purposes. For one, as one cannot as easily test a cross-compiler by running a test suite, it may have been miscompiled -- but you wouldn't notice; this would result in strange, hard to debug behaviour by the resulting cross-compiled packages. For another, satisfying This can be solved by using emulation tools (like qemu). Unfortunately qemu doesn't support m68k as a target yet. It would not only help for cross buildd's, but also allow maintainers to debug arch specific problems in their package on their laptop :) build-dependencies for cross-compiling is pretty hard, as anyone using dpkg-cross can tell you. Yes, this is not solved yet, although emdebian and scratchbox are making progress in this area. Someday this problem will be mastered, at least for archs which have qemu support. The critical part is executing target code in maintainer and build scripts. This can be done using qemu user emulation. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Peter 'p2' De Schrijver] This can be solved by using emulation tools (like qemu). Unfortunately qemu doesn't support m68k as a target yet. It would not only help for cross buildd's, but also allow maintainers to debug arch specific problems in their package on their laptop :) For m68k, there is uae, URL:http://www.freiburg.linux.de/~uae/ which is claimed to run Linux when the MMU patch is applied. I was once able to boot the kernel but unable to mount the root directory. Unfortunately, uae lack a working network interface, and has limited use here. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 11:49:46AM +0100, Thiemo Seufer wrote: Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. Hypothetical daily KDE builds would also insanely increase the amount of network traffic being used by the mirror pulse and people upgrading their home boxes, so it isn't just a buildd problem. Those would need to go into experimental, where no buildd problem exists by definition. http://experimental.ftbfs.de/ (but I agree that the problem is much less important there; and I personally don't really care about it as much as I do about unstable -- the latter contains packages that should at one point try to get released, while the former does not) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Steve Langasek] The four most common porting problems for software are endianness (differs between i386/amd64 and powerpc), word size (differs between i386/powerpc and amd64), char signedness (differs between i386/amd64 and powerpc), and use of non-PIC code in shared libs (which is a problem on *all* non-i386 platforms). I'd add unaligned data access (broken or at least problematic on most non-i386). Again, though, it's not something s390 or mipsel have special problems with. Peter signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Henrique de Moraes Holschuh] Not from what I know of dist-cc. You just need dist-cc, and nothing else. dist-cc just offloads the number-crunching, so it uses no data from the non-master node. AFAIK anyway (which is NOT much on dist-cc matters). Right. distcc runs the C preprocessor on the master and just sends preprocessed source and compiled code across the network. So the slave nodes could just as well be using a cross-arch gcc/gas, no external dependencies. The main problem with distcc across architectures is the FUD surrounding whether gcc-as-cross-compiler spits out the same code as gcc-as-native-compiler. The gcc team seem to be very hesitant to make any guarantees about that, as it's not something they test much. Without better information than guesswork, I'd say you might minimise your chances of cross-gcc bugs by using a host with the same endianness and bit width. signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Pierre Habouzit] I mean that you have no way to say for huge source packages : you only need to build this , this, this and this pacakge. since the changes I've made won't affect the others. As far as mirror bandwidth goes (including end user bandwidth *from* the mirrors), that's a problem for rsync/zsync to solve. Of course, that doesn't help with buildd time, which is still a bottleneck in certain cases. Peter signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Le Lun 21 Février 2005 14:13, Peter Samuelson a écrit : [Pierre Habouzit] I mean that you have no way to say for huge source packages : you only need to build this , this, this and this pacakge. since the changes I've made won't affect the others. As far as mirror bandwidth goes (including end user bandwidth *from* the mirrors), that's a problem for rsync/zsync to solve. yes and no because when you build a new package : 1- binary backages do not have the same name (so rsync/apt-get are lost) 2- if you build them for real, they won't be exactly the same (think of /usr/share/doc/your-package/changelog.Debian.gz e.g.) anyway, I'm not sure we really want to do such things ... -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpMUWItfsl2T.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Pierre Habouzit] As far as mirror bandwidth goes (including end user bandwidth *from* the mirrors), that's a problem for rsync/zsync to solve. 1- binary backages do not have the same name (so rsync/apt-get are lost) It's still a problem for rsync/zsync to solve. I didn't mean to say they had already solved it. zsync already seems to be moving in the direction of application-specific hacks - I don't see why call an external script to produce a list of files to check the checksums against should not be one such hack. Since zsync (unlike rsync) does all the heavy lifting on the receiving side, this seems very feasible. 2- if you build them for real, they won't be exactly the same (think of /usr/share/doc/your-package/changelog.Debian.gz e.g.) zsync already reaches inside a gzip file and effectively rsyncs the uncompressed version. No reason it couldn't be made a bit smarter so as to look inside the components of a .deb ar file. This being a fairly interesting use case for zsync, I expect it's already being considered, if not implemented. Peter signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
The main problem with distcc across architectures is the FUD surrounding whether gcc-as-cross-compiler spits out the same code as gcc-as-native-compiler. The gcc team seem to be very hesitant to make any guarantees about that, as it's not something they test much. Without better information than guesswork, I'd say you might minimise your chances of cross-gcc bugs by using a host with the same endianness and bit width. I guess differences in floating point implementations might be an issue too for expressions containing floats which can be evaluated at compile time. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 07:25:02AM -0600, Peter Samuelson wrote: zsync already reaches inside a gzip file and effectively rsyncs the uncompressed version. No reason it couldn't be made a bit smarter so as to look inside the components of a .deb ar file. This being a fairly interesting use case for zsync, I expect it's already being considered, if not implemented. at least considered ;) seriously, if zsync stabilizes (which will take a while) it would provide us with a way (together with some other stuff) to sync our mirrors while taking only a fraction of the bandwidth currently needed. this can't be bad. but it would mean we have to store .zsync files besides the debs (+ ~1% size) and talk the mirror admins into running an update script that is way more complex than two-phase rsync and needs a wee bit more processing power on their side. anyway, it's too early to speculate about stuff like that... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Petter Reinholdtsen wrote: [snip] But at the moment, there are very few problems with the autobuilders, it seem. The packages with missing builds on some archs are listedon URL:http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz, and it is not bad compared to earlier. Missing archiectures blocking packages: arm(86) mips(84) ia64(74) alpha(65) mipsel(64) m68k(61) sparc(60) powerpc(59) s390(51) hppa(46) i386(5) This looks worse than it is, btw., because of erraneous builds for some architectures which aren't removed from the archive, despite removal requests being filed. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. And for the more obscure architectures, virtually all of the testing comes from the build of the package. How many people out there are actually using e.g. KDE on mips enough to actually find any portability bugs? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. Actually, my long experience is that it takes more than 2; but at, say, 4 systems (both byte orders, both 32 and 64 bits) you get most of them. More important at that point is getting better compiler coverage; gcc and friends is *not* the only compiler suite in the world, and different compilers uncover a different spectrum of bugs. - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Brian Nelson wrote: On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. And for the more obscure architectures, virtually all of the testing comes from the build of the package. That's incorrect, at least from my experience. How many people out there are actually using e.g. KDE on mips enough to actually find any portability bugs? I use some kde programs on mips and haven't found portability bugs so far. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. False. Unaligned data access is a portability problem, and I've never seen a bus error on any of my PPCs or i386s[0], but I have on UltraSparc. [0] Actually, I did have my current machine (an i686) have a problem with a bus error, but that was because *somebody* (who shall remain nameless) accidentally unplugged the hard disk while the computer was running. Needless to say, the kernel did not take kindly to this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Brian Nelson pyro at debian.org writes: On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. Fair point. But you'll get shouted down just for raising this ... And for the more obscure architectures, virtually all of the testing comes from the build of the package. How many people out there are actually using e.g. KDE on mips enough to actually find any portability bugs? That is an important point, and nobody else really picked it up. Almost all other contributors to this thread engaged in attempts to stifle the debate and claim that the parrot wasn't dead, but resting. But to the best of my knowledge, Marco's (blog) post from a few months ago which showed download from ftp.it.debian.org by architecture stands undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there are no KDE users on mips. So guys, we need a new framework. Maybe we should pick up on Petter's suggestion of stricter buildd requirements. Maybe we should only build base and essential packages for the minor architectures [ after, apt-source is there for everybody to go further ]. We can still provide the debian-installer for everything with a power cord provided we have the resources to code, maintain, debug, document, improve, ... and all those platforms. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: But to the best of my knowledge, Marco's (blog) post from a few months ago which showed download from ftp.it.debian.org by architecture stands undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there are no KDE users on mips. So guys, we need a new framework. Maybe we should pick up on Petter's suggestion of stricter buildd requirements. Maybe we should only build base and essential packages for the minor architectures [ after, apt-source is there for everybody to go further ]. We can still provide the debian-installer for everything with a power cord provided we have the resources to code, maintain, debug, document, improve, ... and all those platforms. IMHO, we are in an awkward position. There are *some* users in the other architectures. Not, many but some. If we drop those architectures then we will have *no* users in other architectures. This debate reminds me of the way that large corporations go for the largest market segment and leave the small fry without anyone catering to their needs. Debian is not a desktop architecture for some of these other architectures, but that doesn't mean it isn't valuable. It is clear that there is a problem with buildd resource efficiency and the fact that large packages delay our release undesirably because of the high buildd latency. I would hate to see Debian throw out the baby. The problem with apt-source is that, if I understand it correctly, it only performs native builds. This isn't necessarily possible for some people. Speaking as an ARM user on embedded systems, there is no chance I'm going to build natively on the targets I support. It does seem prudent to find a way to permit a release on x86 and ppc before all architectures are complete. Especially if this tactic will give Debian the ability to release more often. Is it so bad to allow the smaller architectures to lag as long as problems are fixed? Cheers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there You can believe in the tooth fairy, too, but it doesn't make it true. Since you're trying to convince others to join your tooth fairy worshipping religion, it might be useful to provide some evidence to back your belief. I believe we haven't seen any evidence that all our architectures has delayed any release. DI was a potential sticking point, but it's already sorted due to the hard work by the relevant porters while we're still waiting for other technical issues to work themselves out. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Matthew Palmer mpalmer at debian.org writes: On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there You can believe in the tooth fairy, too, but it doesn't make it true. Since you're trying to convince others to join your tooth fairy worshipping religion, it might be useful to provide some evidence to back your belief. Sorry, you just scored against your own team. I was quoting a post with actual download numbers that actually demonstrate that the vast majority of users are on i386: see http://blog.bofh.it/id_66. For your convenience, I quote the numbers here again along with a quick percentage calculation: md - read.table(/tmp/md.txt, header=TRUE, row.names=1) md - cbind(md, percent=round(100*md[,1]/md[total,1], 4)) md files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. I believe we haven't seen any evidence that all our architectures has delayed any release. DI was a potential sticking point, but it's already sorted due to the hard work by the relevant porters while we're still waiting for other technical issues to work themselves out. It delays our releases in the sense that it affects our resources: - available maintainer and developer time, - cpu cycles (witness Wouter's request to compile big packages rarely), - network bandwith (witness the discussion on mirror efficiency), - mirrror capacity (witness the sad state of amd64), - security response time (more builds to do) and that it - increases the load on infrastructure (t-p-u, security) - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. As you say so cogently: it might be useful to provide some evidence to back your belief. Consider the ball in your court, and please prove with tangible numbers how the approximate benefit from the minor arches is roughly equivalent to that of arches being used. Hand-waving (find more bugs) won't do. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel [EMAIL PROTECTED] writes: But to the best of my knowledge, Marco's (blog) post from a few months ago which showed download from ftp.it.debian.org by architecture stands undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there are no KDE users on mips. So guys, we need a new framework. But the point is, who cares? These things don't slow the release. You believe it does, but without a shred of actual evidence, and no agreement from the people whose job it is to get the releases done. I think what slows releases is that you aren't fixing RC bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel [EMAIL PROTECTED] writes: I was quoting a post with actual download numbers that actually demonstrate that the vast majority of users are on i386: see http://blog.bofh.it/id_66. But that doesn't show what you said you believe, which is that supporting other archs slows the release. - available maintainer and developer time, Easy to say. How many RC bugs have you fixed recently, and if we dropped the other archs, how many would you have fixed? - cpu cycles (witness Wouter's request to compile big packages rarely), So you're saying that if we dropped the mips buildd's we'd have more cycles for other archs? - network bandwith (witness the discussion on mirror efficiency), Mirrors don't have to (and don't need to) copy all the archs. They can support whichever ones they want. Nor could this possibly slow release. - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. Nor could this possibly slow release. - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. and that it - increases the load on infrastructure (t-p-u, security) How much does it? Do we have an infrastructure which is short on capacity for these things? - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Marc Singer [EMAIL PROTECTED] writes: It does seem prudent to find a way to permit a release on x86 and ppc before all architectures are complete. Especially if this tactic will give Debian the ability to release more often. Is it so bad to allow the smaller architectures to lag as long as problems are fixed? This would only make sense if we had a complete x86 and ppc release, but not a complete mips release. In practical terms, this doesn't happen. It's not like we do all the x86 work, and then the rest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:56:27PM -0800, Thomas Bushnell BSG wrote: Marc Singer [EMAIL PROTECTED] writes: It does seem prudent to find a way to permit a release on x86 and ppc before all architectures are complete. Especially if this tactic will give Debian the ability to release more often. Is it so bad to allow the smaller architectures to lag as long as problems are fixed? This would only make sense if we had a complete x86 and ppc release, but not a complete mips release. In practical terms, this doesn't happen. It's not like we do all the x86 work, and then the rest. I agree completely. This makes sense iff the lesser used arches affect release. As I posted in another message, this discussion about removing arch's seems to me to be a red herring. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 04:39:22AM +, Dirk Eddelbuettel wrote: Matthew Palmer mpalmer at debian.org writes: On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there You can believe in the tooth fairy, too, but it doesn't make it true. Since you're trying to convince others to join your tooth fairy worshipping religion, it might be useful to provide some evidence to back your belief. Sorry, you just scored against your own team. Why, by asking for evidence that multiple architectures delays releases? You have a really oddball scoring system. I believe we haven't seen any evidence that all our architectures has delayed any release. DI was a potential sticking point, but it's already sorted due to the hard work by the relevant porters while we're still waiting for other technical issues to work themselves out. It delays our releases in the sense that it affects our resources: - available maintainer and developer time, What's to say that someone who spends time on a minority architecture would spend it on Debian proper if that architecture wasn't in Debian? I would say that the inverse is the case: developers with an interest in minority architecture come to Debian and help out with non-arch-specific things as well as their pet arch, while if Debian didn't support that arch they'd probably go elsewhere. - cpu cycles (witness Wouter's request to compile big packages rarely), More computers wastes CPU cycles? - network bandwith (witness the discussion on mirror efficiency), Do you have any actual evidence that lower bandwidth would benefit Debian in any material way? - mirrror capacity (witness the sad state of amd64), So you're saying that we need to reduce our architecture count to increase our architecture count? - security response time (more builds to do) Security autobuilders are on their way. You could make the argument that if we only had a couple of architectures we wouldn't really need security autobuilders, but I think that automating everything that can be automated is a Good Thing. and that it - increases the load on infrastructure (t-p-u, security) WTF? t-p-u would be needed if we had one arch. - scarce resource such as release managers, ftp admins, ... RMs and ftpmasters aren't arch-specific, apart from the odd occasion when an ftpmaster needs to remove out-of-date binaries for unbuilt architectures. Note, however, that two ftpmasters are presidios of their own niche architecture. If we dropped them, they'd probably go off and do their own (non-Debian) thing. As you say so cogently: it might be useful to provide some evidence to back your belief. Consider the ball in your court, and please prove with tangible numbers You'll need to go and collect the ball from behind you where it landed after you missed it before you send it back to me. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Matthew Palmer mpalmer at debian.org writes: [ a lot of stuff but omitting one critical argument of mine ] Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. I rest my case. These arches have little benefit, but as everybody shouts at me that they have exactly zero cost, we're still winning with a net benefit. If only I could believe in Santa like the rest of us. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. You used package download results from one (1!) debian mirror to demonstrate the supposed lack of usage. However, those download stats only point to who is actually downloading packages with that architecture from only that mirror in a single month. The very fact that people are willing to maintain buildds and make appropriate patches for the architectures indicates that people actually are using them. When (and if) an arch fails to have a critical mass of people who care about it enough to actually take care of it, then it should be jettisoned. However, that appears not to have happened yet. This is almost exactly like an argument for ejecting packages that don't appear to be very popular but are being actively maintained by a maintainer who supposedly uses the package in question.[1] Don Armstrong 1: Hell, I use and maintain a few packages that aren't too terribly popular. -- I don't care how poor and inefficient a little country is; they like to run their own business. I know men that would make my wife a better husband than I am; but, darn it, I'm not going to give her to 'em. -- The Best of Will Rogers http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: But to the best of my knowledge, Marco's (blog) post from a few months ago which showed download from ftp.it.debian.org by architecture stands undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- I've written back then something about that. Maybe you could dig the archives for my comment on this. For example, Italy was never a strong country for m68ks (Amigas) as f.e. Germany was. Of course you'll find that after a decade there would be virtually no users left. Picking out just one country mirror gives a wrong image. Anyway, with statistics you can usually prove whatever you like. It's just a matter of interpretation. and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. Then give facts and prove your believing. As you say, there are no KDE users on mips. So guys, we need a new framework. Wasn't there someone in this thread that is actually using KDE on mips? So, your statement is simply wrong. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On 21 Feb 2005 20:54:36 -0800, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. There are rumours that the noticeable multi-week gap last fall when no DSAs were released at all were caused by some buildd failure on one of the lesser-userd arches and the security team decided to defer advisories until security builds could be released for all arches. I have a dedicated opinion about this time of service the major arches received during this time, but I do not want to voice it here as I am only talking about a rumour and I do not want to start yet another flame war. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 05:24:28AM +, Dirk Eddelbuettel wrote: Matthew Palmer mpalmer at debian.org writes: [ a lot of stuff but omitting one critical argument of mine ] Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. So, when you're such a great fan of i386, why don't you just drop all other archs from your arch: line then? Et voila... problem solved for you. Oh, maybe that could violate the SC, but who cares about other socials anyway. It's only you who counts. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel [EMAIL PROTECTED] writes: Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. lack of usage here means much rarer usage of course. .001 is not zero. And your point was supposedly that supporting these archs delays the release. Proving they are used by absolutely nobody still doesn't prove that it delays the release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 07:10:36AM -0600, Peter Samuelson wrote: The main problem with distcc across architectures is the FUD surrounding whether gcc-as-cross-compiler spits out the same code as gcc-as-native-compiler. The gcc team seem to be very hesitant to make any guarantees about that, as it's not something they test much. Without better information than guesswork, I'd say you might minimise your chances of cross-gcc bugs by using a host with the same endianness and bit width. Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... Just a thought. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Clint Byrum cbyrum at spamaps.org writes: Now, can someone please tell me how messages like the one below, and others, aren't indicative that debian should drop s390, mipsel, and maybe hppa from the list of architectures? How about we release for i386, sparc, and powerpc, and let the others release on their own schedule? This business of supporting 11 architectures and making sure they're all 100% right before releasing is just about the worst idea ever. Couldn't agree more. Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a total of eleven is insane. But then it doesn't matter anymore. These days, Debian is infrastructure. We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. Still, the hours we maste on fixing, building, maintaining, ... code on unused platforms is hysterical waste of resources. Resources we don't really have. It would be better to concentrate on a core of packages, and platforms, and then get on with it. One day it will break the infrastructure provision, at which point someone will fork our high-priority core packages. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: Clint Byrum cbyrum at spamaps.org writes: Now, can someone please tell me how messages like the one below, and others, aren't indicative that debian should drop s390, mipsel, and maybe hppa from the list of architectures? How about we release for i386, sparc, and powerpc, and let the others release on their own schedule? This business of supporting 11 architectures and making sure they're all 100% right before releasing is just about the worst idea ever. Still, the hours we maste on fixing, building, maintaining, ... code on unused platforms is hysterical waste of resources. Resources we don't really have. I'd like to see your numbers on how many manhours have been wasted in the past, say, 6 months on fixing code on unused platforms which would have gone into other things had those architectures not been in Debian. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: Clint Byrum cbyrum at spamaps.org writes: Now, can someone please tell me how messages like the one below, and others, aren't indicative that debian should drop s390, mipsel, and maybe hppa from the list of architectures? How about we release for i386, sparc, and powerpc, and let the others release on their own schedule? This business of supporting 11 architectures and making sure they're all 100% right before releasing is just about the worst idea ever. Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a total of eleven is insane. But then it doesn't matter anymore. These days, Debian is infrastructure. We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. Any maintainer who believes that trying to release doesn't matter is invited to file serious bugs against all his optional/extra packages so that the release team can remove them from testing outright rather than worrying about whether they're in a releasable state. The more people believe that releasing does not matter, the longer it takes the rest of us to pull off a release. Still, the hours we maste on fixing, building, maintaining, ... code on unused platforms is hysterical waste of resources. Resources we don't really have. It would be better to concentrate on a core of packages, and platforms, and then get on with it. One day it will break the infrastructure provision, at which point someone will fork our high-priority core packages. The four most common porting problems for software are endianness (differs between i386/amd64 and powerpc), word size (differs between i386/powerpc and amd64), char signedness (differs between i386/amd64 and powerpc), and use of non-PIC code in shared libs (which is a problem on *all* non-i386 platforms). A fifth, less significant portability issue involves arm-specific weirdness with floating point handling, which affects only a handful of packages that try to do their own direct manipulation of floats. So which portability problems are the ones that we waste time fixing code for? I certainly don't think that maintainers/packages should be penalized for failures of porters to provide viable build infrastructure for their architectures, and I think that we should have stricter standards in this area for etch; but the actual amount of work that maintainers have to do to their packages that's only of benefit to a single, little-used architecture is negligible. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Feb 21, Steve Langasek [EMAIL PROTECTED] wrote: So which portability problems are the ones that we waste time fixing code for? You are right, close to none. The usual sources of problems are slow or broken buillds, broken toolchains and buggy kernels. -- ciao, Marco signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel [EMAIL PROTECTED] writes: Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a total of eleven is insane. There isn't any evidence I've seen that these arch's actually slow down the release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Dirk Eddelbuettel [EMAIL PROTECTED] writes: Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a total of eleven is insane. There isn't any evidence I've seen that these arch's actually slow down the release. Getting debian-installer working across all architectures was certainly an issue at one time, though that time passed a few months ago. Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, 20 Feb 2005, Brian Nelson wrote: There isn't any evidence I've seen that these arch's actually slow down the release. Getting debian-installer working across all architectures was certainly an issue at one time, though that time passed a few months ago. Well, if the installer ever holds etch, we can think about it. Right now, the installer is not even semi-close to being the worst problem. Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. The answer to that is to setup a dist-cc cluster for these archs, where only the master node is in the slow arch, and everything else is a fast arch. i.e. far stricter buildd requirements would fix it. Even mirror space problems can be fixed without dropping an arch. -- 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: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a total of eleven is insane. Ah, are the 6 months over and it's time for your regularly drop those archs!-rant again? Linux is about freedom - freedom of whatever software you want to use and even what arch you want to use to run your chosen software. And even it's freedom of you to support an arch or not - but keep in mind that dropping support for some archs might trigger the freedom of release managers to not include your packages because of missing arch support. Isn't freedom a great thing? Yet you haven't come up with proofs to support your call to remove those archs. I think you're just annoyed to deal with more than (let's say) 3 archs. But hey, that's your personal problem then. I do see some structural problems (or say management problems) for some archs, but not problems with those archs itself. While m68k has solved those problems long time ago and still continuing to work on those problems, other archs don't want to take over the way of m68k to prevent problems. But again, that's a managing problem. Remove the responsible porters if they are not successful in doing their duties, but not the arch. But then it doesn't matter anymore. These days, Debian is infrastructure. We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. That's true in some regards, but hasn't to do anything with the number of archs. Still, the hours we maste on fixing, building, maintaining, ... code on unused platforms is hysterical waste of resources. Resources we don't really have. It would be better to concentrate on a core of packages, and platforms, and then get on with it. One day it will break the infrastructure provision, at which point someone will fork our high-priority core packages. Concentrating on a core set of packages for release was one of the aspects I already proposed last year, well, 2 years ago in the meantime. The problem is quite simple: Debian is too huge for the current structure. It worked fine so far, but that's easy. You can easily release 2000 packages for 3 archs with that grown structure, but you will get real problems with 1 packages and 10 archs. Change the structure how Debian works and you'll be able to deal again with those problems easily. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Henrique de Moraes Holschuh] The answer to that is to setup a dist-cc cluster for these archs, where only the master node is in the slow arch, and everything else is a fast arch. i.e. far stricter buildd requirements would fix it. Even mirror space problems can be fixed without dropping an arch. Stricter buildd requirements might do it. Perhaps an upper limit on the number of days allowed to pass from a package is upload until the autobuilder did its first build, and an upper limit on the number of days allowed to pass with a broken toolchain before the arch is removed would work. But at the moment, there are very few problems with the autobuilders, it seem. The packages with missing builds on some archs are listedon URL:http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz, and it is not bad compared to earlier. Missing archiectures blocking packages: arm(86) mips(84) ia64(74) alpha(65) mipsel(64) m68k(61) sparc(60) powerpc(59) s390(51) hppa(46) i386(5) Of course, the relative order and package count in this list varies a lot over time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 21 Feb 2005, Ingo Juergensmann wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: ... But then it doesn't matter anymore. These days, Debian is infrastructure. We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. That's true in some regards, but hasn't to do anything with the number of archs. Especially it is wrong regarding the fact about Custom Debian Distributions (if you mean this special term) because they reside inside Debian and in consequence do also cope with all architectures. There are reasons that people use such CDDs for only a single architecture and do some further adaptations to a CDD but this is a different issue. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
