#include
* 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 what yo
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 rationa
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 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
* 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 ar
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 ftp-m
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
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 "amd
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
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", hereina
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
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 w
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 th
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 [EM
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. So
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 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
[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 timefr
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 Proj
[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 in
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]
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
> "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 no
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 any
* 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 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 multia
* 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. I
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
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 b
[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
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
[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,
>
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 tra
[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
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
> > 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 compl
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
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 da
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 comp
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 inappro
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
> libraries.
No, it's what you get when
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 PROTEC
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
communicati
> * 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
* 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
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
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
> >> > 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 PROTECTE
> | 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 p
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 copie
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 VF
* 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.
As others have said -- it's not easy to support both 32 and 64 bit. If
you want to do that properly, you should implement multiarch.
Please keep migr
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
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
>
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
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 the amd64 stuff.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL P
* 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.
>
> > 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
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
On Fri, Jul 16, 2004 at 02:43:46PM +0200, Goswin von Brederlow wrote:
> No. There never will be a biarch amd64 unless you pick up the pices
> and make one.
My concern is that it be possible for me to pick up the pieces and
make one.
> >> > [*] amd64 binaries can't be built from the sources in mai
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
moun
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 to
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 th
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
* 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 essent
* 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
* 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 mome
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
>
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 s
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. Ther
> > 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 p
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
* 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
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
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 use
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'
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
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.
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:
[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
[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
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 ab
[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
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Please reread my statement and tell me if it is unreasonable or rude?
> Its not asking ftp-master to do more than write a short status report
> that has been promised "soon" or "next week" by all other means of
> communication for a long time.
>
>
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Wed, Jul 14, 2004 at 12:51:51AM +0200, Goswin von Brederlow wrote:
>
>> So what technical issues are there? And please reply with your ftp-master
>> hat on. All we hear is "there are issues and ftp-master will post
>> something soon" but you never sa
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell, BSG ([EMAIL PROTECTED]) wrote:
>> Stephen Frost <[EMAIL PROTECTED]> writes:
>> > > No, if you do it right, then you can install the libraries with a
>> > > configuration variable, so that the packages only have to be changed
>> > > onc
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell, BSG ([EMAIL PROTECTED]) wrote:
>> Sure, and I am happy to have dpkg, the RM, the technical committee,
>> etc., make the decision, which is why I haven't given it thought. But
>> when it becomes a GR, you have the necessity to start ov
Mike Beattie <[EMAIL PROTECTED]> writes:
> 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 o
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell, BSG ([EMAIL PROTECTED]) wrote:
>> I'd be happy to think through it, but only if you give me details.
>
> http://raw.no/debian/amd64-multiarch-2
>
> I'm not 100% sure that's the latest, hopefully others will correct me if
> it isn't. I
Raul Miller <[EMAIL PROTECTED]> writes:
>> * 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 wro
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 discussing.
> > That's not my concern. I c
Raul Miller <[EMAIL PROTECTED]> writes:
> On Thu, Jul 15, 2004 at 09:18:39PM +0100, [EMAIL PROTECTED] wrote:
>> Fact of life: amd64 boxen are going to be very common.
>> Fact of life: for very large subset of debian userland, pure64 works and
>> on these boxen it works better than debian/i386.
>
>
Raul Miller <[EMAIL PROTECTED]> writes:
> 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 lo
Raul Miller <[EMAIL PROTECTED]> writes:
> 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 create
* Michael Banck ([EMAIL PROTECTED]) wrote:
> On Thu, Jul 15, 2004 at 09:24:26PM -0400, Raul Miller wrote:
> > On Thu, Jul 15, 2004 at 09:09:46PM -0400, Stephen Frost wrote:
> > > Those funcs may be available through ia32-libs... I was actually
> > > wondering more about specific programs.
> >
> >
Raul Miller <[EMAIL PROTECTED]> writes:
> On Tue, Jul 13, 2004 at 02:43:59PM +0200, Josselin Mouette wrote:
>> The only valid reasons for not including it are lack of LSB compliance
>> (which can still be easily achieved with a i386 chroot) and mirror space
>> (which will be saved using partial mi
* Raul Miller ([EMAIL PROTECTED]) wrote:
> 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
On 2004-07-16 02:35:50 +0100 Michael Banck <[EMAIL PROTECTED]> wrote:
Feel free to subscribe to -newmaint (it's quite low-traffic) and
comment
on the AM reports of those applicants if you think they are not ready.
The full AM reports are not posted to -newmaint, if I recall
correctly, so it's har
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
>
>> The only valid reasons for not including it are lack of LSB compliance
>> (which can still be easily achieved with a i386 chroot) ...
The LSB needs to be changed to sanely implement compliance to
* Michael Banck ([EMAIL PROTECTED]) wrote:
> This second one is the only open question, and I agree it is off-topic
> for -vote. I guess constructive feedback on the multiarch proposal (the
> URL of which has been cited in this thread) is welcome on -devel.
Either -devel or perhaps -amd64.. There
1 - 100 of 319 matches
Mail list logo
