On Tue, 2005-03-08 at 16:22 -0800, Steve Langasek wrote:
> Hi Gergely,
>
> On Wed, Mar 09, 2005 at 12:56:10AM +0100, Gergely Nagy wrote:
> > Just to chime in, not saying that maintaining a consistent state between
> > architectures is an easy thing and presents no problems, but Debian is
> > the o
Wouter Verhelst wrote:
> I very well remember that mail. The key word in Clint's mail that
> prompted my reply was 'current' (problems). d-i has been ported to all
> our architectures now, which required a lot of work, and doing a d-i
> release still requires quite some work to synchronise that amo
Op di, 08-03-2005 te 17:58 -0500, schreef Joey Hess:
> Wouter Verhelst wrote:
> > This argument has been brought up so many times by now that I'm amazed
> > people /still/ try it.
> >
> > The answer is, simply, 'not'. Go learn to use google if you want to know
> > why.
>
> You're ignoring people
Op di, 08-03-2005 te 14:36 -0800, schreef Clint Byrum:
> On Tue, 2005-03-08 at 22:22 +0100, Wouter Verhelst wrote:
> > Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> > > How much would it help with the current problems if we just picked 3
> > > arches(mipsel, s390, ???)
> >
> > This arg
Hi Gergely,
On Wed, Mar 09, 2005 at 12:56:10AM +0100, Gergely Nagy wrote:
> Just to chime in, not saying that maintaining a consistent state between
> architectures is an easy thing and presents no problems, but Debian is
> the only distribution that supports all these many architectures. This
> h
On Tue, 2005-03-08 at 14:36 -0800, Clint Byrum wrote:
> On Tue, 2005-03-08 at 22:22 +0100, Wouter Verhelst wrote:
> > Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> > > How much would it help with the current problems if we just picked 3
> > > arches(mipsel, s390, ???)
> >
> > This argu
On Tue, Mar 08, 2005 at 10:33:05AM -0800, Clint Byrum wrote:
> How much would it help with the current problems if we just picked 3
> arches(mipsel, s390, ???) and said "these are not going to release with
> the rest of sarge"? Would it reduce the time to test the installer? Any
> RC bugs that were
Wouter Verhelst wrote:
> This argument has been brought up so many times by now that I'm amazed
> people /still/ try it.
>
> The answer is, simply, 'not'. Go learn to use google if you want to know
> why.
You're ignoring people arguing the other side of the issue. For example,
in <[EMAIL PROTECTE
On Tue, 2005-03-08 at 22:22 +0100, Wouter Verhelst wrote:
> Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> > How much would it help with the current problems if we just picked 3
> > arches(mipsel, s390, ???)
>
> This argument has been brought up so many times by now that I'm amazed
> pe
On Tue, Mar 08, 2005 at 10:22:33PM +0100, Wouter Verhelst wrote:
> Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> > How much would it help with the current problems if we just picked 3
> > arches(mipsel, s390, ???)
> This argument has been brought up so many times by now that I'm amazed
Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> How much would it help with the current problems if we just picked 3
> arches(mipsel, s390, ???)
This argument has been brought up so many times by now that I'm amazed
people /still/ try it.
The answer is, simply, 'not'. Go learn to use go
On Mon, 2005-03-07 at 20:33 +0100, Florian Lohoff wrote:
> On Mon, Mar 07, 2005 at 09:13:20AM -0800, Clint Byrum wrote:
> > I feel your pain. Its hard to keep all these buildd's for different
> > architectures up. That goes to the very heart of my point.
> >
> > I'm not saying Debian should totall
On Tue, 2005-03-08 at 15:01 +0100, Andreas Barth wrote:
> * Clint Byrum ([EMAIL PROTECTED]) [050307 18:15]:
> > Please understand.. I want Debian to be great. I want it to "release
> > when it is ready." Under the current system, being ready means achieving
> > an enormous number of goals that bene
* Clint Byrum ([EMAIL PROTECTED]) [050307 18:15]:
> Please understand.. I want Debian to be great. I want it to "release
> when it is ready." Under the current system, being ready means achieving
> an enormous number of goals that benefit a very small number of users.
For sarge, the number of arch
On Mon, Mar 07, 2005 at 09:13:20AM -0800, Clint Byrum wrote:
> I feel your pain. Its hard to keep all these buildd's for different
> architectures up. That goes to the very heart of my point.
>
> I'm not saying Debian should totally abandon all the work done by the
> various architecture teams. Bu
Florian Lohoff <[EMAIL PROTECTED]> writes:
> mipsel is a little wrong in this list. We had some hardware problems on
> the 2 mipsel buildds (Same Machine, Same Manuf. Date, Same time PSU
> defect) and it took a while to get at least one up. The short-after
> death of one of the machines went past
Clint Byrum <[EMAIL PROTECTED]> schrieb:
> On Mon, 2005-03-07 at 16:35 +0100, Florian Lohoff wrote:
>> On Fri, Feb 18, 2005 at 07:20:42PM +0100, Frank Küster wrote:
>> >
>> > If the build fails on sparc, arm, and s390, how should this be
>> > indicative that we should drop s390, mipsel, and hppa?
On Mon, 2005-03-07 at 16:35 +0100, Florian Lohoff wrote:
> On Fri, Feb 18, 2005 at 07:20:42PM +0100, Frank Küster wrote:
> >
> > If the build fails on sparc, arm, and s390, how should this be
> > indicative that we should drop s390, mipsel, and hppa?
> >
>
Wow what a flurry of discussion that
On Fri, Feb 18, 2005 at 07:20:42PM +0100, Frank Küster wrote:
>
> If the build fails on sparc, arm, and s390, how should this be
> indicative that we should drop s390, mipsel, and hppa?
>
mipsel is a little wrong in this list. We had some hardware problems on
the 2 mipsel buildds (Same Machine,
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
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 prive
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
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 d
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
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
>
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
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 synonym
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 synony
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: Digita
On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote:
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
[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 o
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 de
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
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
>
Don Armstrong 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 mirr
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
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
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 zer
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
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-s
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?
--
[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 s
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
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
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?
N
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 ]
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 a
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 sai
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
* 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
* 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 thro
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 tha
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
On Tue, Feb 22, 2005 at 05:24:28AM +, Dirk Eddelbuettel wrote:
> Matthew Palmer 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
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.
Th
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
> a
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. H
Matthew Palmer 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
On Tue, Feb 22, 2005 at 04:39:22AM +, Dirk Eddelbuettel wrote:
> Matthew Palmer 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
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 relea
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 lon
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 th
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 fractio
Matthew Palmer 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
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 n
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
> ar
Brian Nelson 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 incr
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 al
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 qual
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.
> >
>
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
>
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
> http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>,
> and it is not bad compared to earlier.
>
> Mi
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
> 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 inform
[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 sa
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
[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
[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 o
[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
> pr
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
[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, th
> 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
* 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. :
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 n
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
[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
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.
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 a
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.
>
> Hypo
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
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 o
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> Clint Byrum 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
On Sunday 20 February 2005 23:57, Dirk Eddelbuettel wrote:
> Clint Byrum 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 debi
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, Knopp
[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 a
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.
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 installe
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 -- an
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
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
Desc
1 - 100 of 105 matches
Mail list logo
