On Tue, Jul 13, 2004 at 05:27:24PM +0200, Robert Millan wrote:
It really sucks that we reached this point. But since proper communication has
failed horribly to resolve this, I recognise there's no other way.
Seconded.
I hereby withdraw my second to this proposal.
Many developers were
Euh. This ought to be signed, IIRC..
On Wed, Jul 28, 2004 at 06:21:41PM +0200, Robert Millan wrote:
On Tue, Jul 13, 2004 at 05:27:24PM +0200, Robert Millan wrote:
It really sucks that we reached this point. But since proper communication has
failed horribly to resolve this, I
I propose an amendment to this GR proposal. The text is completely replaced
by:
===
The Debian project hereby resolves:
- That the developers in charge for adding the architecture identified by
dpkg as amd64,
On Wed, Jul 28, 2004 at 07:00:29PM +0200, Robert Millan wrote:
Rationale:
- Taking technical decisions through voting is not generaly a good
idea.
Agreed.
- We're facing a communication problem, so the solution is to ease
communication between the affected parties.
This GR
On Wed, Jul 28, 2004 at 07:00:29PM +0200, Robert Millan wrote:
===
The Debian project hereby resolves:
- That the developers in charge for adding the architecture identified by
dpkg as amd64, hereinafter amd64, to
On Wed, Jul 28, 2004 at 07:16:04PM +0100, Andrew Suffield wrote:
You cannot write a GR to order somebody to do something. That's
fundamental to the project structure, and written into the
constitution. Get used to the idea, and stop proposing GRs that don't
do anything.
Please note the use
On Wed, Jul 28, 2004 at 12:12:20PM -0500, Graham Wilson wrote:
- We're facing a communication problem, so the solution is to ease
communication between the affected parties.
This GR seems to force communication between ftpmaster and the porters.
I don't put in question the
* Andrew Suffield ([EMAIL PROTECTED]) [040728 20:25]:
On Wed, Jul 28, 2004 at 07:00:29PM +0200, Robert Millan wrote:
===
The Debian project hereby resolves:
- That the developers in charge for adding the
On Wed, Jul 28, 2004 at 08:51:14PM +0200, Robert Millan wrote:
On Wed, Jul 28, 2004 at 07:16:04PM +0100, Andrew Suffield wrote:
You cannot write a GR to order somebody to do something. That's
fundamental to the project structure, and written into the
constitution. Get used to the idea,
On Wed, Jul 28, 2004 at 09:48:24PM +0200, Andreas Barth wrote:
* Andrew Suffield ([EMAIL PROTECTED]) [040728 20:25]:
On Wed, Jul 28, 2004 at 07:00:29PM +0200, Robert Millan wrote:
===
The Debian project hereby
On Wed, Jul 28, 2004 at 09:04:02PM +0200, Robert Millan wrote:
I don't think communication will be eased by a GR forcing people to talk
to each other.
Well, since everything else has failed, I disagree.
None of these other things worked, so this one must? That's not
actually rational...
#include hallo.h
* Andrew Suffield [Wed, Jul 28 2004, 07:16:04PM]:
You cannot write a GR to order somebody to do something. That's
fundamental to the project structure, and written into the
constitution. Get used to the idea, and stop proposing GRs that don't
do anything.
You can propose
Goswin von Brederlow [EMAIL PROTECTED] writes:
Yes, very reasonable. So (after asking the DPL and him rejecting) the
GR should be amended to The Debian developers overturn the decision
of the DPL not to set a deadline for deciding the amd64 inclusion in
sid for ftp-master?
No. Ask the DPL,
Hi, Sven Luther wrote:
Even if the ftp-master promise to
handle it within a week in the NEW queue template response (well, they
maybe removed this now).
No, it's still there.
NEW processing is also reasonably fast these times, AFAIK.
--
Matthias Urlichs
--
To UNSUBSCRIBE, email to
On Sat, Jul 17, 2004 at 05:41:25PM -0400, Sam Hartman wrote:
It is not abuse of the process for the project as a whole to decide
that it disagrees with a decision that some part of the project has
made.
Except there is no decision any part of the project made, contrary to
popular believe. Some
On Fri, Jul 16, 2004 at 05:16:10AM +0200, Goswin von Brederlow wrote:
[Big snip - Raul Miller wrote]
If we release an amd64 in sarge, we're committing to supporting it.
If the current port paints us into a corner, that's a good reason to
not start supporting it yet.
[Goswin replied]
No,
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
The only thing that can belong on vote (after being put in a revised
GR) is the inclusion in sid [if it has to come to that]. That would be
a GR to overturn the ftp-master decision (by inaction)
Goswin von Brederlow [EMAIL PROTECTED] writes:
Getting that information or getting amd64 added to sid would be the
point of the revised GR. It would have to be worded in a way that
forces ftp-master to add amd64 in a reasonable timeframe unless he can
give reasons not to.
It is the Project
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Getting that information or getting amd64 added to sid would be the
point of the revised GR. It would have to be worded in a way that
forces ftp-master to add amd64 in a reasonable timeframe
On 2004-07-18 09:41:28 +0100 Thomas Bushnell, BSG [EMAIL PROTECTED]
wrote:
This is the kind of thing you need in any GR long before I am willing
to agree to it.
You have lept to the GR strategy, failing to realize that the GR
strategy should *presume* that you have done this work.
This is my
On 2004-07-17 18:37:17 +0100 David Weinehall [EMAIL PROTECTED] wrote:
On Fri, Jul 16, 2004 at 02:26:28AM +0100, MJ Ray wrote:
Is queue-jumping desirable? [...]
Yes, it's definitely desirable. For instance, a person maintaining an
important library that a lot of other packages depend on, is more
On Sat, Jul 17, 2004 at 07:00:58AM +0200, Goswin von Brederlow wrote:
Is this purely because of linking problems with shared libraries, or is
there some other kind of need to support two diferent instances of the
same application?
Its a problem with avoiding archive bloat through biarch
On Sat, Jul 17, 2004 at 05:36:59AM -0400, Raul Miller wrote:
Can you tell me why you think mixing 32bit and 64bit isn't a solvable
problem?
Because you won't get upstream to accpet patches and the same probably
goes for the Debian maintainers for binutils and gcc.
In other words,
* Raul Miller
| | It's fairly simple for the port to be built to support both 32 and 64
| | bit LSB apps, and still allow for migration to multiarch.
|
| On Fri, Jul 16, 2004 at 06:45:17PM +0200, Tollef Fog Heen wrote:
| As others have said -- it's not easy to support both 32 and 64 bit. If
On Sat, Jul 17, 2004 at 03:33:17PM +0200, Tollef Fog Heen wrote:
You're jumping through a lot of hoops to get to somewhere which is a bit
like multiarch, but not quite. And you'll end up with something less
capable, more ugly and a lot more work to support properly when
upgrading to
* Raul Miller
(Sorry for Cc-ing you on the last post; it was not my intention.)
| On Sat, Jul 17, 2004 at 03:33:17PM +0200, Tollef Fog Heen wrote:
| You're jumping through a lot of hoops to get to somewhere which is a bit
| like multiarch, but not quite. And you'll end up with something less
On Fri, Jul 16, 2004 at 02:26:28AM +0100, MJ Ray wrote:
[snip]
Is queue-jumping desirable? It really sucks to see people (with
questionable philosophies expressed on lists) getting through NM in 10
days while you're dangling there for months without being able to
detect anyone doing
Michael == Michael Banck [EMAIL PROTECTED] writes:
Michael This last one could be considered on-topic for -vote in
Michael the context of this unholy GR, but I rather think it's
Michael abuse of it, as we have a release team for this kind of
Michael issue.
It is not abuse of
Goswin von Brederlow [EMAIL PROTECTED] writes:
The only thing that can belong on vote (after being put in a revised
GR) is the inclusion in sid [if it has to come to that]. That would be
a GR to overturn the ftp-master decision (by inaction) to not include
amd64.
I'm afraid I can't even
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
D. Starner [EMAIL PROTECTED] writes:
I think that's a little unfair. I assumed that people would know the
basic plan (yes, failure to anticipate what my audience knows and
doesn't know is one of my communication failures) and intend to explain
Michael Banck [EMAIL PROTECTED] writes:
On Thu, Jul 15, 2004 at 06:45:59PM -0400, Raul Miller wrote:
If so, which part of I'm talking about 64/32 bit userland -- which
is something other distributions already offer. or That's not vapor
are you having problems with?
The part about 'other
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
D. Starner [EMAIL PROTECTED] writes:
I don't agree with the GR as it stands. The release manager should
decide whether or not to release AMD64 with Sarge. I prefer that
we could get AMD64 added to Sid by peaceful discussion and not a
GR.
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Stephen Frost [EMAIL PROTECTED] writes:
Well, there aren't any 32bit apps in Debian, so it'd have to be
something you got from somewhere else. Funny enough, the error would
probably be something like 'file not found' because it can't find the
Raul Miller [EMAIL PROTECTED] writes:
On Thu, Jul 15, 2004 at 06:25:31PM -0400, Stephen Frost wrote:
Well, there aren't any 32bit apps in Debian, so it'd have to be
something you got from somewhere else.
Does this mean you've a valgrind package for amd64?
valgrind is Architecture: i386. Its
Raul Miller [EMAIL PROTECTED] writes:
We're going to be dealing with the i386
to multiarch transistion, at least this way it'll look reasonably the
same on all the platforms as opposted to special on amd64 because you
also have to change the base architecture type from amd64 to i386. It's
Raul Miller [EMAIL PROTECTED] writes:
On Thu, Jul 15, 2004 at 09:45:19PM -0400, Stephen Frost wrote:
sarge isn't supported/released, therefore this is not an issue when
discussing if amd64 should be released with sarge.
You've confused the configuration of my machine with the issues
I'm
Raul Miller [EMAIL PROTECTED] writes:
* Thomas Bushnell, BSG ([EMAIL PROTECTED]) wrote:
Details would be: which parts of LSB is the port not compliant with?
On Thu, Jul 15, 2004 at 05:20:19PM -0400, Stephen Frost wrote:
It doesn't have the i386 loader in the right place, it doesn't have
Raul Miller [EMAIL PROTECTED] writes:
On Thu, Jul 15, 2004 at 09:22:01PM -0400, Stephen Frost wrote:
I fail to understand how you still don't get it. multiarch *is*
64/32bit userland. Is there something you don't understand about that?
What I really want is LSB compliant 64 bit user land
Le mer, 14/07/2004 à 13:50 -0600, Joel Baker a écrit :
Correct, a resolution that says Foo must perform action A, instead of
not performing action A is explicitly a no-op under the constitution,
and is also obviously silly.
Correct. The appropriate GR is Foo shall be removed for failure
* Raul Miller
| Everyone knows that. If it was, we'd be doing it and sarge would be
| released in 2006 at best. That does NOT provide justification to not
| support AMD64 at *all*.
|
| The question is, what's the upgrade path to an amd64 system which supports
| 32 bit code? Is that going
On Fri, Jul 16, 2004 at 05:16:10AM +0200, Goswin von Brederlow wrote:
The only thing special for amd64 is that at some point the /lib64 -
/lib link might (or might not) be turned back into a real
directoy. But that can/will only happen if it can happen silently
without disturbance.
Which
If you don't provide a dual 32/64 bit amd64, your transition strategy
is going to be install it on a different partition or backup, wipe
and reinstall.
On Fri, Jul 16, 2004 at 09:14:25AM +0200, Goswin von Brederlow wrote:
That is the plan and the current implementation. As such pure64 has
On Fri, Jul 16, 2004 at 09:25:22AM +0200, Goswin von Brederlow wrote:
No. You obviously never tried or read the mails about it. If you don't
have lib64 - lib linked you get lots and lots of random breakages and
misbuilds. In effect you have to touch and fix all 2000+ library
packages. There is
On Fri, Jul 16, 2004 at 09:31:39AM +0200, Goswin von Brederlow wrote:
apt-get install dchroot cdebootstrap
read FAQ
I've already raised this in another message, but how do I make 32 bit
userland able to use 64 bit programs?
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Fri, Jul 16, 2004 at 10:53:02AM +0200, Tollef Fog Heen wrote:
| Last time I checked [two days ago], the trivial change to dpkg to support
| amd64 hadn't happened. I think making sure that the debian package tools
| work right for the architecture should be considered pre-requisites for
|
* Raul Miller ([EMAIL PROTECTED]) wrote:
On Fri, Jul 16, 2004 at 09:31:39AM +0200, Goswin von Brederlow wrote:
apt-get install dchroot cdebootstrap
read FAQ
I've already raised this in another message, but how do I make 32 bit
userland able to use 64 bit programs?
At the moment, you
* Raul Miller ([EMAIL PROTECTED]) wrote:
On Thu, Jul 15, 2004 at 09:45:19PM -0400, Stephen Frost wrote:
Do you have some issue that's relevent to the GR to discuss then? Or to
pure64's inclusion in sarge? If not, then let's move this to
debian-amd64 where it'd be at least closer to
* Goswin von Brederlow ([EMAIL PROTECTED]) wrote:
There is no and never will be a transition plan from i386 to
amd64. That is just not possible. You can't replace dpkg since then it
lacks its libc and you can't replace libc since then dpkg lacks the
old one. And so on for every other essential
Raul Miller [EMAIL PROTECTED] writes:
On Fri, Jul 16, 2004 at 05:16:10AM +0200, Goswin von Brederlow wrote:
The only thing special for amd64 is that at some point the /lib64 -
/lib link might (or might not) be turned back into a real
directoy. But that can/will only happen if it can happen
Raul Miller [EMAIL PROTECTED] writes:
If you don't provide a dual 32/64 bit amd64, your transition strategy
is going to be install it on a different partition or backup, wipe
and reinstall.
On Fri, Jul 16, 2004 at 09:14:25AM +0200, Goswin von Brederlow wrote:
That is the plan and the
Raul Miller [EMAIL PROTECTED] writes:
On Fri, Jul 16, 2004 at 09:25:22AM +0200, Goswin von Brederlow wrote:
No. You obviously never tried or read the mails about it. If you don't
have lib64 - lib linked you get lots and lots of random breakages and
misbuilds. In effect you have to touch and
Raul Miller [EMAIL PROTECTED] writes:
On Fri, Jul 16, 2004 at 09:31:39AM +0200, Goswin von Brederlow wrote:
apt-get install dchroot cdebootstrap
read FAQ
I've already raised this in another message, but how do I make 32 bit
userland able to use 64 bit programs?
man mount
mount --bind /
On Fri, Jul 16, 2004 at 09:15:47AM -0400, Stephen Frost wrote:
And get every package in the archive changed and updated for it ..
This (every package changed) doesn't have to happen until multiarch
is ready.
[Before you explained about multiarch, my only objection was the lack
of 32 bit LSB
You could install a biarch glibc which supports both 32 and 64 bit
dpkg.
On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote:
Which would be a completly new glibc package adding extra bloat to the
already streesed mirrors.
We're talking about something several orders of
* Raul Miller ([EMAIL PROTECTED]) wrote:
Which means it's probably not going to change. This is an easy choice
up through system install time, but a tough one upgrade time.
It's not all that hard to handle such an upgrade path.
No, the only thing referencing lib or lib64 is the ld.so.
I
Stephen Frost [EMAIL PROTECTED] writes:
* Raul Miller ([EMAIL PROTECTED]) wrote:
On Fri, Jul 16, 2004 at 09:31:39AM +0200, Goswin von Brederlow wrote:
apt-get install dchroot cdebootstrap
read FAQ
I've already raised this in another message, but how do I make 32 bit
userland able to
Stephen Frost [EMAIL PROTECTED] writes:
* Goswin von Brederlow ([EMAIL PROTECTED]) wrote:
There is no and never will be a transition plan from i386 to
amd64. That is just not possible. You can't replace dpkg since then it
lacks its libc and you can't replace libc since then dpkg lacks the
On Fri, Jul 16, 2004 at 11:10:20AM -0400, Raul Miller wrote:
you mount the 64bit / inside the 32bit chroot (thus creating a circle)
and then configure the mime.type to use dchroot to change back into
64bit.
Doesn't this blow efficiency out of the water? Doesn't this mean
that VFS has to
On Fri, Jul 16, 2004 at 11:33:46AM -0400, Raul Miller wrote:
On Fri, Jul 16, 2004 at 03:28:06PM +0200, Goswin von Brederlow wrote:
mount --bind / /chroot/i366/chroot/amd64
I may be wrong, but I think that means VFS is going to have to manage
memory as if there are two independent copies of
| It's fairly simple for the port to be built to support both 32 and 64
| bit LSB apps, and still allow for migration to multiarch.
On Fri, Jul 16, 2004 at 06:45:17PM +0200, Tollef Fog Heen wrote:
As others have said -- it's not easy to support both 32 and 64 bit. If
you want to do that
You could install a biarch glibc which supports both 32 and 64 bit
dpkg.
On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote:
Which would be a completly new glibc package adding extra bloat to the
already streesed mirrors.
Raul Miller [EMAIL PROTECTED] writes:
Raul Miller [EMAIL PROTECTED] writes:
You could install a biarch glibc which supports both 32 and 64 bit
dpkg.
On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote:
Which would be a completly new glibc package adding extra bloat to the
already streesed mirrors.
We're
Anibal Monsalve Salazar [EMAIL PROTECTED] writes:
On Wed, Jul 14, 2004 at 12:36:35AM +0100, Scott James Remnant wrote:
I strongly suspect there are many others in Debian who also have no
problems communicating with James.
During debconf4, I didn't have any problem communicating with him
* Raul Miller ([EMAIL PROTECTED]) wrote:
On Fri, Jul 16, 2004 at 11:32:22AM -0400, Stephen Frost wrote:
Do you have an example of this case? I havn't heard of one yet, not
even with Oracle.
K
They're going to charge you huge amounts to use their 64bit version
instead of their 32bit
* Raul Miller ([EMAIL PROTECTED]) wrote:
On Fri, Jul 16, 2004 at 11:32:22AM -0400, Stephen Frost wrote:
Do you have an example of this case? I havn't heard of one yet, not
even with Oracle.
On Fri, Jul 16, 2004 at 04:51:05PM -0400, Stephen Frost wrote:
They're going to charge you huge
On Fri, Jul 16, 2004 at 08:34:09PM +0200, Goswin von Brederlow wrote:
It was also suggested that people that met James personally have way
less problems talking to him via mail later since then he already
knows you.
I have never met James in person, yet have no problem whatsoever
communicating
Goswin von Brederlow [EMAIL PROTECTED] writes:
3) Should the existing pure64 be added to sid?
I think that is the only thing on-topic for vote.
There is no GR relevant to that question which has been proposed.
Therefore, it is not on topic.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Stephen Frost [EMAIL PROTECTED] writes:
Do you have some issue that's relevent to the GR to discuss then? Or to
pure64's inclusion in sarge? If not, then let's move this to
debian-amd64 where it'd be at least closer to on-topic.
pure64 is not in sid or testing. It therefore is
Josselin Mouette [EMAIL PROTECTED] writes:
Currently, the destiny of amd64 is in the hands of the release manager
and FTP masters, but that's not in their duties to add it. However,
should the GR pass, I hope the DPL would have the honesty to remove the
delegates who would fail to comply with
On Fri, Jul 16, 2004 at 06:19:20PM -0700, Thomas Bushnell, BSG wrote:
Now there is a *different* question: should the current amd64 be in
sid? I can see no reason why not, but then, I wonder why you all
didn't get it in sid *long* ago. We put hurd-i386 in sid almost from
the very first day.
Raul Miller [EMAIL PROTECTED] writes:
| It's fairly simple for the port to be built to support both 32 and 64
| bit LSB apps, and still allow for migration to multiarch.
On Fri, Jul 16, 2004 at 06:45:17PM +0200, Tollef Fog Heen wrote:
As others have said -- it's not easy to support both 32
Is it just me or are these two paragraphs contradictory?
On Sat, Jul 17, 2004 at 04:28:32AM +0200, Goswin von Brederlow wrote:
Yes, its just you. Multiarch will not be an issue for sid for a long
time to come. If you want it work on it but it just confuses in the
GR.
Why?
Is this
Raul Miller [EMAIL PROTECTED] writes:
To be fair, bug #248043 was filed some time ago.
It seems to me, after reading that bug, that getting the port into sid
has been stalled on questions about the treatment of biarch [actually,
probably more from the lack of an adequate statement of the
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
That's not an adequate error--but it should be simple to write a
trivial loader which provides a more useful error.
Thomas
You get the same error as with any binary with unfullfillable
Goswin von Brederlow [EMAIL PROTECTED] writes:
That would mean patching the kernel and porting the binfmt-elf ia32 to
be a binfmt misc extention and only loading that if ia32-libs is
installed.
No way.
It's rapidly becoming obvious why you folks are not succeeding; you
can't keep track of
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Raul Miller [EMAIL PROTECTED] writes:
To be fair, bug #248043 was filed some time ago.
It seems to me, after reading that bug, that getting the port into sid
has been stalled on questions about the treatment of biarch [actually,
probably
Raul Miller [EMAIL PROTECTED] writes:
Is it just me or are these two paragraphs contradictory?
On Sat, Jul 17, 2004 at 04:28:32AM +0200, Goswin von Brederlow wrote:
Yes, its just you. Multiarch will not be an issue for sid for a long
time to come. If you want it work on it but it just
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
That would mean patching the kernel and porting the binfmt-elf ia32 to
be a binfmt misc extention and only loading that if ia32-libs is
installed.
No way.
It's rapidly becoming obvious why
On Wed, Jul 14, 2004 at 11:55:14PM +0100, Colin Watson wrote:
On Thu, Jul 15, 2004 at 12:46:16AM +0200, Ingo Juergensmann wrote:
On Wed, Jul 14, 2004 at 11:15:16PM +0100, Colin Watson wrote:
Obviously, flaming people whose cooperation you need doesn't
necessarily speak volumes for your
On Wed, Jul 14, 2004 at 11:08:19AM -0400, Joey Hess wrote:
Sven Luther wrote:
I personally trust the ftp-masters, and believe they are working for the
best of the project, but it is hard when one has questions only they can
answer or act to solve, to wait apparently forever in the dark. And
[Colin Watson]
I doubt that, because there are plenty of people who have no trouble
communicating with ftpmaster, and they're generally the people who
are less flamy about *everything*, not just any particular person.
Well, there are some of us less flamy people that also have problems
getting
On Thu, Jul 15, 2004 at 04:01:36AM +0200, Robert Millan wrote:
On Thu, Jul 15, 2004 at 12:54:26AM +0200, Wouter Verhelst wrote:
On Thu, Jul 15, 2004 at 12:48:07AM +0200, Robert Millan wrote:
On Wed, Jul 14, 2004 at 10:19:19PM +0200, Ingo Juergensmann wrote:
Even a fresh DD, who has been
On Wed, Jul 14, 2004 at 06:13:38AM +0200, Josselin Mouette wrote:
Indeed, this is a way to force a result. However, I wouldn't qualify it
a pet issue. The results of the vote will tell whether this is a pet
issue for all developers. The purpose of the GR is to ensure everyone is
working
On Thu, Jul 15, 2004 at 09:19:55AM +0200, Sven Luther wrote:
Well, no, but i believe that new kernel release handling deserve it too,
and not this almost a month if not more wait from upload to NEW queue
handling we are currently seing. And i have sent a non-flame mail to
ftp-masters,
On Wed, Jul 14, 2004 at 10:17:14PM -0800, D. Starner wrote:
To become LSB compliant would involve changing half the packages in
Debian to achieve a result to many AMD64 developers consider inelegant;
furthermore, a multiarch design is being created that would allow
us to install Linux binaries
On Thu, Jul 15, 2004 at 12:33:03PM +0200, Michael Banck wrote:
On Thu, Jul 15, 2004 at 09:19:55AM +0200, Sven Luther wrote:
Well, no, but i believe that new kernel release handling deserve it too,
and not this almost a month if not more wait from upload to NEW queue
handling we are
* Raul Miller ([EMAIL PROTECTED]) wrote:
The most likely reason someone would pick the AMD64 architecture over
the PowerPC architecture is that AMD64 can natively run I386 binaries.
That's quite an assumption you're making there. One that I, personally,
seriously doubt is accurate considering
On Thu, Jul 15, 2004 at 08:17:55AM -0400, Stephen Frost wrote:
* Raul Miller ([EMAIL PROTECTED]) wrote:
In other words, that the only thing we're talking about is distribution
of binaries built from sarge sources?
Make it a release architecture which will move those bugs to RC and give
us
On Thu, Jul 15, 2004 at 07:18:45AM -0400, Raul Miller wrote:
The most likely reason someone would pick the AMD64 architecture over
the PowerPC architecture is that AMD64 can natively run I386 binaries.
Oh, really? Let's see - ~5 months ago I'd put together an
amd64 box (athlon64/3400,
* Michael Banck ([EMAIL PROTECTED]) wrote:
On Thu, Jul 15, 2004 at 08:17:55AM -0400, Stephen Frost wrote:
* Raul Miller ([EMAIL PROTECTED]) wrote:
In other words, that the only thing we're talking about is distribution
of binaries built from sarge sources?
Make it a release
On Thu, Jul 15, 2004 at 10:46:12AM +0200, Wouter Verhelst wrote:
As you can guess by the context, I was referring to the DAM approval part.
That doesn't change anything about what I said (except that the example
is no longer valid). The DAM approval state is not simply an
administrative
Michael Banck wrote:
On Thu, Jul 15, 2004 at 09:19:55AM +0200, Sven Luther wrote:
Well, no, but i believe that new kernel release handling deserve it too,
and not this almost a month if not more wait from upload to NEW queue
handling we are currently seing. And i have sent a non-flame mail to
On Thu, Jul 15, 2004 at 03:54:29PM +0200, Robert Millan wrote:
Really nice, but I already knew that. Now can you tell me what
prevents FIFO processing?
Are you processing all of your bugs in a FIFO fashion?
I don't.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Thu, Jul 15, 2004 at 02:04:54PM +0200, Andreas Metzler wrote:
People choose ix86 (or amd64) over PowerPC because
a) bang/buck ratio.
b) runs windows (games.)
Those are two reasons.
Unfortunately, the current debian amd64 port doesn't look like it supports
cedega (forinstance).
More
* Raul Miller ([EMAIL PROTECTED]) wrote:
The most likely reason someone would pick the AMD64 architecture over
the PowerPC architecture is that AMD64 can natively run I386 binaries.
On Thu, Jul 15, 2004 at 08:33:23AM -0400, Stephen Frost wrote:
That's quite an assumption you're making
* Raul Miller ([EMAIL PROTECTED]) wrote:
Those are two reasons.
Unfortunately, the current debian amd64 port doesn't look like it supports
cedega (forinstance).
It does support a number of commercial binaries though already, for
those that need them. Many of us don't.
More generally, by
On Thu, Jul 15, 2004 at 03:24:07PM -0400, Raul Miller wrote:
On Thu, Jul 15, 2004 at 02:04:54PM +0200, Andreas Metzler wrote:
People choose ix86 (or amd64) over PowerPC because
a) bang/buck ratio.
b) runs windows (games.)
Those are two reasons.
Unfortunately, the current debian amd64
Unfortunately, the current debian amd64 port doesn't look like it supports
cedega (forinstance).
On Thu, Jul 15, 2004 at 04:16:48PM -0400, Stephen Frost wrote:
It does support a number of commercial binaries though already, for
those that need them. Many of us don't.
I don't know what you
D. Starner [EMAIL PROTECTED] writes:
To become LSB compliant would involve changing half the packages in
Debian to achieve a result to many AMD64 developers consider inelegant;
furthermore, a multiarch design is being created that would allow
us to install Linux binaries on NetBSD or Hurd, or
Those are two reasons.
Unfortunately, the current debian amd64 port doesn't look like it supports
cedega (forinstance).
More generally, by not providing 32 bit support, we're reducing the
bang/buck ratio.
On Thu, Jul 15, 2004 at 09:18:39PM +0100, [EMAIL PROTECTED] wrote:
Let me
1 - 100 of 282 matches
Mail list logo
