Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Mar 01, 2005 at 01:28:58AM +0100, Goswin von Brederlow wrote:
It does? How does that work for packages with only a minimal control
file that generate a full contol file during build?
Such packages need to make sure their initial control file
[Goswin von Brederlow]
Which also avoids that packages will be unavailable on every new
architecture debian introduces because the maintainer has to adjust
the Architecture: line.
I suppose it'd be nice to be able to use !foo in the Architecture: line
for cases where something is known not to
On Sun, Feb 27, 2005 at 11:08:14AM -0500, Rudy Godoy wrote:
On 22/02/2005 at 10:11 Wouter Verhelst wrote...
snip
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
On Mon, Feb 28, 2005 at 04:42:54AM -0600, Peter Samuelson wrote:
[Goswin von Brederlow]
Which also avoids that packages will be unavailable on every new
architecture debian introduces because the maintainer has to adjust
the Architecture: line.
I suppose it'd be nice to be able to use
Peter Samuelson [EMAIL PROTECTED] writes:
[Goswin von Brederlow]
Which also avoids that packages will be unavailable on every new
architecture debian introduces because the maintainer has to adjust
the Architecture: line.
I suppose it'd be nice to be able to use !foo in the Architecture:
On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
[Goswin von Brederlow]
Which also avoids that packages will be unavailable on every new
architecture debian introduces because the maintainer has to adjust
the Architecture:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
[Goswin von Brederlow]
Which also avoids that packages will be unavailable on every new
architecture debian introduces because the
On Tue, Mar 01, 2005 at 01:28:58AM +0100, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
[Goswin von Brederlow]
Which also avoids that packages
On 22/02/2005 at 10:11 Wouter Verhelst wrote...
snip
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
Rudy Godoy [EMAIL PROTECTED] writes:
Regarding this issue I was thinking about it since I've faced in a
situation where a package[0] I maintain does have high hardware
requirements, which led me to think if it is really wise to have it
with arch: any since probably in some arches it would not
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Rudy Godoy [EMAIL PROTECTED] writes:
Regarding this issue I was thinking about it since I've faced in a
situation where a package[0] I maintain does have high hardware
requirements, which led me to think if it is really wise to have it
with
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
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
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
[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,
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
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
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.
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
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, 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
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 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
* 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
* 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.
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
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
On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote:
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Why do the build servers install all the dependencies only to find out
that some installed versions are insufficient for the build?
Because the current buildd
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
On Mon, Feb 21, 2005 at 11:46:37PM -0500, Kevin Mark wrote:
On Mon, Feb 21, 2005 at 04:30:27PM +0100, Wouter Verhelst wrote:
There are small KDE applications that require most of the KDE dependency
chain to be installed, while on the other hand XFree86's build
dependency list is
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Is the problem that you use apt-get to install the current version, and
then check what you got? Because you can't tell apt-get to install
at least version X else fail?
Yes, that's how it works currently.
Since this also makes
On Tue, Feb 22, 2005 at 10:44:42PM +1100, Hamish Moffatt wrote:
Bastian Blank worked on a database that handles all these build-deps on the
central wanna-build replacement. The idea is to give out just those packages
Even that sounds too complicated. Really, each buildd can work this out
on
Marc Haber [EMAIL PROTECTED] writes:
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
Dirk Eddelbuettel [EMAIL PROTECTED] writes:
For your convenience, I quote the numbers here again along with a quick
percentage calculation:
files.downloaded percent
i386 1285422 70.5079
all 504789 27.6886
powerpc17754 0.9738
ia64
Steve McIntyre [EMAIL PROTECTED] writes:
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
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 ].
Kevin Mark [EMAIL PROTECTED] writes:
would it make sense to examine the queue to see if any packages have
similar build dependencies and then move them to the top of the queue so
they build immediately after the current one?
or to re-sequence the queue to group package with similar build
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
On Tue, Feb 22, 2005 at 12:51:16PM +0100, Ingo Juergensmann wrote:
On Tue, Feb 22, 2005 at 10:44:42PM +1100, Hamish Moffatt wrote:
Bastian Blank worked on a database that handles all these build-deps on
the
central wanna-build replacement. The idea is to give out just those
On Tue, Feb 22, 2005 at 12:50:02PM +0100, Wouter Verhelst wrote:
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Is the problem that you use apt-get to install the current version, and
then check what you got? Because you can't tell apt-get to install
at least version X
On Tue, Feb 22, 2005 at 11:23:51PM +1100, Hamish Moffatt wrote:
Thanks for the explanation Wouter. That sounds like a big improvement.
By the way, does this duplicate the functionality of 'apt-get build-dep'?
Possibly. Sbuild, however, predates the implementation of 'apt-get
build-dep', so
On Tue, Feb 22, 2005 at 11:22:37PM +1100, Hamish Moffatt wrote:
Can and should are different stories.
When there's a missing build-dep on one arch, it might make sense to stop
that package from being distributed for other archs, so they don't waste
their time on that.
You can't do
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
Hamish Moffatt [EMAIL PROTECTED] writes:
On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote:
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Why do the build servers install all the dependencies only to find out
that some installed versions are insufficient
Hamish Moffatt [EMAIL PROTECTED] writes:
On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote:
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Why do the build servers install all the dependencies only to find out
that some installed versions are insufficient
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,
Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Is the problem that you use apt-get to install the current version, and
then check what you got? Because you can't tell apt-get to install
at least version X else fail?
Yes, that's how
* Goswin von Brederlow ([EMAIL PROTECTED]) [050222 15:15]:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
Is the problem that you use apt-get to install the current version, and
then check what you got? Because you can't tell
On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Since this also makes autobuilding experimental harder, work is being
done to use ``apt-cache policy'' output to determine whether the right
version of a package is available and
Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Since this also makes autobuilding experimental harder, work is being
done to use ``apt-cache policy'' output to determine whether the
On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote:
I can always tell you how to do things and you never have to
listen. But my opinion stands that improving apt-get is the right
thing to do, not having two divergent systems.
sbuild includes some centralized build-dependency
* Wouter Verhelst ([EMAIL PROTECTED]) [050222 18:00]:
On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote:
I can always tell you how to do things and you never have to
listen. But my opinion stands that improving apt-get is the right
thing to do, not having two divergent
* Wouter Verhelst ([EMAIL PROTECTED]) [050222 18:00]:
On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote:
I can always tell you how to do things and you never have to
listen. But my opinion stands that improving apt-get is the right
thing to do, not having two divergent
[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
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
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?
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
Thaddeus H. Black [EMAIL PROTECTED] writes:
[Not private. Reply on-list if you wish.]
However, I do think that not including amd64 (while keeping mips and
friends) in the sarge release due to mirroring problems is ridiculous.
Amen, brother.
... packages are uploaded too frequently, ...
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
Em Ter, 2005-02-22 s 15:28 +0100, Wouter Verhelst escreveu:
On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote:
Wouter Verhelst [EMAIL PROTECTED] writes:
Since this also makes autobuilding experimental harder, work is being
done to use ``apt-cache policy'' output to
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
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
alpha
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
Adam Heath doogie at debian.org writes:
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
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
s390
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
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:
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
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?
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
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
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
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
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.
[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
In article [EMAIL PROTECTED] you wrote:
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.
Perhaps it helps, if the buildds for slow systems introduce
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
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
* 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. :)
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
[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
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
On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
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
On Mon, 2005-02-21 at 13:36 +0100, Wouter Verhelst wrote:
On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
[snip]
The problem with s390 is that you can't just go to eBay and buy yourself
an s390; or even if you could, that you would
On Mon, Feb 21, 2005 at 12:33:24AM +0100, Goswin von Brederlow wrote:
Dropping some archs would only have one benefit. There would be mirror
space to include amd64.
Well, that's quite a compelling reason. It's embarassing that amd64 won't
be official in sarge.
Hamish
--
Hamish Moffatt VK3SB
[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
[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
[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
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]
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
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
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
Petter Reinholdtsen [EMAIL PROTECTED] writes:
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
Wouter Verhelst [EMAIL PROTECTED] writes:
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
Peter Samuelson [EMAIL PROTECTED] writes:
[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
Robert Lemmen [EMAIL PROTECTED] writes:
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
Thiemo Seufer [EMAIL PROTECTED] writes:
Those would need to go into experimental, where no buildd problem
exists by definition.
Thiemo
Except for the 11 archs with experimental buildds.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Bernd Eckenfels [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED] you wrote:
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.
Perhaps it
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.
On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote:
Bernd Eckenfels [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED] you wrote:
Hypothetical daily KDE builds would also insanely increase the amount of
network traffic being used by the mirror pulse and people
1 - 100 of 142 matches
Mail list logo
