[I am not subscribed to debian-amd64, please Cc: me if you feel your reply deserves my attention.]
Hi all, you'll mostly be pleased to know that dpkg in unstable now supports your architecture; hopefully this is the first step towards consideration for archive addition.
The archive name that has been chosen is "x86-64", which I understand might upset a few people who like the other name.
As I've been at DebConf 4, it provided the ideal place to discuss the architecture name in person with many people from the different Debian teams including some of your own porters.
The advantages of this name are:
* it matches the GNU arch string
* it matches the name chosen by RedHat, Fedora and SuSE
* it doesn't include unnecessary marketing connotations, and avoids the issue whether we even *can* use AMD's name in vain
The disadvantages are:
* it isn't what you have been using to-date
* it doesn't *quite* match the others "x86-64" vs. "x86_64"
The first issue is simply a matter of rebuilding, which shouldn't take too long relatively. Your patches and fixes will still all work, hopefully.
The second is due to "_" being used as a filename separator; I'd like to investigate what actually *relies* on this and potentially change the architecture at a later date (still before archive addition) to x86_64 to totally match the others -- we'll see how that plays out.
Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
On Wed, Jun 02, 2004 at 05:51:26PM -0300, Scott James Remnant wrote: > The archive name that has been chosen is "x86-64", which I understand > might upset a few people who like the other name.
> As I've been at DebConf 4, it provided the ideal place to discuss the > architecture name in person with many people from the different Debian > teams including some of your own porters.
This, I think, is a really poor substitute for discussion on the proper mailing lists. I think it is deeply wrong to exclude people's input in such a major change simply because they are not at Debconf. To many here, this appears as a dictum foisted on us from someone that has not been ever charged with determining architecture naming. I believe the choice lies with ftpmaster, not a dpkg committer.
Not only that, but why force this change on us now? The patches have been out there for months, and could have been integrated before we had such a substantial package base that will be broken. Why is there this almost maniacal aversion to working together? Why could you not have opened a discussion on debian-amd64 a month ago, or even last week?
> The advantages of this name are:
> * it matches the GNU arch string
> * it matches the name chosen by RedHat, Fedora and SuSE
Though not Gentoo, NetBSD, FreeBSD, Mandrake, Shark, etc.
> * it doesn't include unnecessary marketing connotations, and avoids > the issue whether we even *can* use AMD's name in vain
I fail to see how mentioning the name of an architecture is using unnecessary marketing connotations. Perhaps we ought to make these changes:
> * it doesn't *quite* match the others "x86-64" vs. "x86_64"
Which is also a serious problem that is going to lead to endless confusion.
> The first issue is simply a matter of rebuilding, which shouldn't take > too long relatively. Your patches and fixes will still all work, > hopefully.
*simply* is somewhat of an overstatement. Are you aware of the effort required to bootstrap a new Debian arch?
Plenty of packages rely on dpkg architecture information, and this almost certainly wil break packages.
> The second is due to "_" being used as a filename separator; I'd like to > investigate what actually *relies* on this and potentially change the > architecture at a later date (still before archive addition) to x86_64 > to totally match the others -- we'll see how that plays out.
Pick something and stick with it. Don't make us change twice.
What I'm really upset about here is that this is a major decision that was taken without even attempting to gather input on the lists. If the consensus was to rename it, fine, but no attempt at gathering info was made on your part. You should immediately s/x86-64/amd64/ in the dpkg tree and only change it back after discussion here.
-- John
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Hi all, you'll mostly be pleased to know that dpkg in unstable now > supports your architecture; hopefully this is the first step towards > consideration for archive addition.
Thank you for including the amd64/x86_64 port into dpkg.
> The archive name that has been chosen is "x86-64", which I understand > might upset a few people who like the other name.
My impression is that most people working on the Debian amd64 port do not like the name 'amd64' very much. I never understood why the name was changed from x86-64 to amd64 last year.
> * it doesn't include unnecessary marketing connotations, and avoids > the issue whether we even *can* use AMD's name in vain
To use a more neutral name is really a good thing IMHO.
> The disadvantages are:
> * it isn't what you have been using to-date
Obviously, there will be complaints about the work that the name change will cause.
> The second is due to "_" being used as a filename separator; I'd like to > investigate what actually *relies* on this and potentially change the > architecture at a later date (still before archive addition) to x86_64 > to totally match the others -- we'll see how that plays out.
I created a small test archive using x86_64 (not x86-64) and at least dpkg and apt seemed to work with that name.
I believe that x86_64 should be used as the Debian arch name to avoid confusions between the name that is used by the toolchain and the kernel (x86_64) and a slightly different Debian arch name (x86-64).
Please consider to change the arch name to 'x86_64'. Some tools and scripts will have to be adapted to work with the '_' in the name but I think it will be possible to fix them without too many problems. (The '-' in 'x86-64' might also cause some trouble).
Regards Andreas Jochens
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> almost maniacal aversion to working together? Why could you not have > opened a discussion on debian-amd64 a month ago, or even last week?
True. This should have been discussed on the lists. But it is not too late for a discussion now. At the moment the current amd64 port uses a patched dpkg anyway so no real harm has been done.
> > The first issue is simply a matter of rebuilding, which shouldn't take > > too long relatively. Your patches and fixes will still all work, > > hopefully.
> *simply* is somewhat of an overstatement. Are you aware of the effort > required to bootstrap a new Debian arch?
It will _not_ be necessary to bootstrap amd64/x86_64 again because of the name change. The existing packages can be used to build new ones with a different architecture name (I tried that and created a small test archive with 'x86_64' as the arch name and it worked so far).
> Plenty of packages rely on dpkg architecture information, and this > almost certainly wil break packages.
Of coures, some things will break. But in most cases maintainers will only have to replace amd64 with x86_64 in some places.
This should not be too difficult. It will require much more work to port the remaining ~5% of the source packages to amd64/x86_64 :)
Regards Andreas Jochens
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> This, I think, is a really poor substitute for discussion on the proper > mailing lists. I think it is deeply wrong to exclude people's input in > such a major change simply because they are not at Debconf.
I completely agree.
>> * it matches the name chosen by RedHat, Fedora and SuSE
> Though not Gentoo, NetBSD, FreeBSD, Mandrake, Shark, etc.
As was pointed out earlier, RedHat, Fedora and SuSE use x86_64. In fact, it seems that amd64 and x86_64 are the most popular names, respectively. FWIW, though, all the names listed on the ports page have hyphens, not underscores (http://www.debian.org/ports/). I really don't care, but I think the name should be reached through logic and concensus.
I'm pretty new to all of this, but logically I think that amd64 should be used only if different packages will be required for chips from different 64 bit x86 manufacturers. If all 64 bit x86 systems will use the same packages, though, then it makes sense to use the more generic x86[-|_]64.
Another thing to consider is the fact that the stated goal (on the ports page, again) of a biarch userland for AMD64 is different than the pure 64 setup of IA64. This in and of itself may provide sufficient reason to differentiate the two architectures.
Chris Horn.
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
It does not, the GNU arch string uses an underscore. And btw, the reason why this wasn't changed to amd64 in the toolchain is that it already was in use by too many people at that time.
> > * it matches the name chosen by RedHat, Fedora and SuSE
> Though not Gentoo, NetBSD, FreeBSD, Mandrake, Shark, etc.
I think RH and SuSE merely stayed with what they already had. x86_64 is not a lucky choice for a user-visible name.
Thiemo
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Are all these three entries really necessary? I made some tests and it seems that dpkg works fine when there is only the third of those entries
x86_64-linux-gnu x86-64 x86_64
I think the other two entries should be removed. This would match the i386 case which has only
i386-linux-gnu i386 i486
(Yes, I know that I requested three entries for amd64 myself in my bug report (#241938). When I filed that bug report, I had just copied those entries from the dpkg package that the amd64 port used at that time. I had verified that this configuration worked but not checked if it also works with fewer lines.)
Besides that, I would still prefer the line
x86_64-linux-gnu x86_64 x86_64
(s/x86-64/x86_64/, see my other mail).
Regards Andreas Jochens
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Wed, Jun 02, 2004 at 05:54:13PM -0400, Chris Horn wrote: > Another thing to consider is the fact that the stated goal (on the ports > page, again) of a biarch userland for AMD64 is different than the pure 64 > setup of IA64. This in and of itself may provide sufficient reason to > differentiate the two architectures.
The port page needs to be rewritten.
Actually, the goals of the port have changed:
1. we HAVE a pure64 port, almost ready. it runs in 64 mode but can still execute 32bit binaries either statically linked or in a chroot. This port is not "academical and of little use", but it is actually availeable and it will be the only one port availeable for an extended period of time (until multiarch matures).
2. Biarch was abandoned, mainly because every library package would have had to be modified to support lib/lib32, not lib/lib64, the 64bit mode being the default one on x86_64 (and not the 32bit one as on the other biarch ports like sparc).
3. Multiarch will render biarch obsolete on all architectures. This will indeed include modifying all library packages, but it is not limited to two supported architectures, it supports all possible ones which can be run or emulated on a given host.
Greetings Frederik Schueler
-- ENOSIG
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> My impression is that most people working on the Debian amd64 port > do not like the name 'amd64' very much. I never understood > why the name was changed from x86-64 to amd64 last year.
How about because your impression is wrong and that most people working on the Debian amd64 port prefer the 'amd64' name? That would seem like a very logical conclusion.
> > * it doesn't include unnecessary marketing connotations, and avoids > > the issue whether we even *can* use AMD's name in vain
> To use a more neutral name is really a good thing IMHO.
This doesn't make a damn bit of sense, sorry. There's no such thing as a 'neutral' name when you're talking about an architecture. They're developed by companies, companies put their names in them and on them. Quit trying to bring this up as a valid point, it's not, deal with it.
> On 04-Jun-02, Andreas Jochens wrote: > > On 04-Jun-02, Scott James Remnant wrote: > > > * it doesn't include unnecessary marketing connotations, and avoids > > > the issue whether we even *can* use AMD's name in vain
> > To use a more neutral name is really a good thing IMHO.
> ... There's no such thing as > a 'neutral' name when you're talking about an architecture. They're > developed by companies, companies put their names in them and on them.
This is certainly true.
However, please note that my main reason for preferring 'x86_64' instead of 'amd64' is that both the toolchain and the kernel use 'x86_64'.
But I can also live with 'amd64', if that will be the decision. I am not a DD and I don't know who can decide this issue.
Regards Andreas Jochens
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Wed, Jun 02, 2004 at 04:24:52PM -0500, John Goerzen wrote: > > * it doesn't include unnecessary marketing connotations, and avoids > > the issue whether we even *can* use AMD's name in vain
> I fail to see how mentioning the name of an architecture is using > unnecessary marketing connotations. Perhaps we ought to make these > changes:
It is also called ia32e so which should we call it x86-64, amd64, or ia32e... ;)
> > * it doesn't *quite* match the others "x86-64" vs. "x86_64"
> Which is also a serious problem that is going to lead to endless > confusion.
I don't remember all the reasons given but both _ and - can cause problems in various ways. One reason not to use _ is that it is used to split on in Debian. A reason not to use - is that is used to separate arch-os triplets. I think there were some other reasons given as well.
> > The second is due to "_" being used as a filename separator; I'd like to > > investigate what actually *relies* on this and potentially change the > > architecture at a later date (still before archive addition) to x86_64 > > to totally match the others -- we'll see how that plays out.
> Pick something and stick with it. Don't make us change twice.
> What I'm really upset about here is that this is a major decision that > was taken without even attempting to gather input on the lists. If the > consensus was to rename it, fine, but no attempt at gathering info was > made on your part. You should immediately s/x86-64/amd64/ in the dpkg > tree and only change it back after discussion here.
For what its worth the archtable entry was incorrect in any case since dpkg --print-gnu-build-architecture was printing out incorrect information. What is up for discussion appears to be whether it should be:
x86_64-linux-gnu x86-64 x86_64
x86_64-linux-gnu amd64 x86_64
Chris Cheney
BTW - Scott you still forgot to fix the header doc on what the three fields are supposed to mean. Recall you told me field 3 was for --print-gnu-build-architecture not --print-architecture...
Hi everybody! Following the official definition of the architecture name as "x86-64", there has been a lot of talk about the ethics of one name over another, practicality, and so on. What I want to know, is this: What does this mean for the users? I am currently setting up a future high-availability bridge/packet filter, and I could really do without dpkg-breakage due to partial name changes. Should I just not update in the next fortnight, or need I have no fear? If a bit of both, which packages might be particularly affected?
Thanks! Andreas Steffen
- -- Trotz unserer besten Bemühungen ist das Leben nach wie vor 100% tödlich. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
* Andreas Steffen (reign...@kawo1.rwth-aachen.de) wrote:
> Following the official definition of the architecture name as "x86-64", there
That's not the official arch name, I expect it'll get fixed in dpkg shortly. I *certainly* would discourage jumping the gun on changing everything (most things *again* since we already moved from x86-64 to amd64).
> has been a lot of talk about the ethics of one name over another, > practicality, and so on. What I want to know, is this: What does this mean > for the users? I am currently setting up a future high-availability
It doesn't mean much for the users, one way or the other.
> bridge/packet filter, and I could really do without dpkg-breakage due to > partial name changes. Should I just not update in the next fortnight, or need > I have no fear? If a bit of both, which packages might be particularly > affected?
What are you setting it up using? Pure64? That's got the correct patch to dpkg included in it and we'll probably work to avoid breaking it in any case.
Andreas Jochens <a...@andaco.de> writes: > On 04-Jun-02, Stephen Frost wrote: >> On 04-Jun-02, Andreas Jochens wrote: >> > On 04-Jun-02, Scott James Remnant wrote: >> > > * it doesn't include unnecessary marketing connotations, and avoids >> > > the issue whether we even *can* use AMD's name in vain
>> > To use a more neutral name is really a good thing IMHO.
>> ... There's no such thing as >> a 'neutral' name when you're talking about an architecture. They're >> developed by companies, companies put their names in them and on them.
> This is certainly true.
> However, please note that my main reason for preferring 'x86_64' instead > of 'amd64' is that both the toolchain and the kernel use 'x86_64'.
mrvn@dual:~/failed% gcc -mcpu=x86_64 -c foo.c cc1: error: bad value (x86_64) for -mcpu= switch
mrvn@dual:~/failed% gcc -march=x86_64 -c foo.c cc1: error: bad value (x86_64) for -march= switch cc1: error: bad value (x86_64) for -mcpu= switch
The tool chain doesn't exactly use x86_64 everywhere.
> But I can also live with 'amd64', if that will be the decision. > I am not a DD and I don't know who can decide this issue.
> Regards > Andreas Jochens
MfG Goswin
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Andreas Jochens <a...@andaco.de> writes: > On 04-Jun-02 16:24, John Goerzen wrote: >> almost maniacal aversion to working together? Why could you not have >> opened a discussion on debian-amd64 a month ago, or even last week?
> True. This should have been discussed on the lists. But it is not too > late for a discussion now. At the moment the current amd64 port > uses a patched dpkg anyway so no real harm has been done.
>> > The first issue is simply a matter of rebuilding, which shouldn't take >> > too long relatively. Your patches and fixes will still all work, >> > hopefully.
>> *simply* is somewhat of an overstatement. Are you aware of the effort >> required to bootstrap a new Debian arch?
> It will _not_ be necessary to bootstrap amd64/x86_64 again because of > the name change. The existing packages can be used to build new ones > with a different architecture name (I tried that and created a small test > archive with 'x86_64' as the arch name and it worked so far).
No they can not be used. The wanna-build and archive scripts break down. If the old packages are to be used every single package has to be patched to a higher version to avoid conflicts.
Next the buildd script breaks down because none of the build-depends are installable without extra force flags.
Third all amd64 adding patches have to be rewritten again for x86-64 which is over 50 package I believe. We just got a bunch of them added to sid and now we would have to bug the maintainers again.
All of that means extra work hacking around in things for the benefit of changing to a probably harmfull name.
You haven't been around long enough to see the work we have done and what it entails. Those of us who have know exactly what is involved in rebuilding the complete archive since we already did a partial rebuild on alioth and that took several man month already just to upload stuff.
>> Plenty of packages rely on dpkg architecture information, and this >> almost certainly wil break packages.
> Of coures, some things will break. But in most cases maintainers will only > have to replace amd64 with x86_64 in some places.
> This should not be too difficult. It will require much more work to > port the remaining ~5% of the source packages to amd64/x86_64 :)
It adds 5% extra work to the 5% work that is still there. Don't make it sound likeusing x86-64 would magically make those 5% compile.
> Regards > Andreas Jochens
MfG Goswin
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> To use a more neutral name is really a good thing IMHO.
I'm just a lowly user so I can't comment on the technical aspects of the name decision, but IMHO the 'AMD64' name is a much better public face to the project - it is immediately obvious what it means: faced with the ports page, someone who has just bought an AMD Athlon64 processor is going to be much happier with this than x86[-/_]64 which is more of a history lesson than a name, and doesn't square with the existing naming scheme, as has already been mentioned. Plus I thought the Intel 64-bit Prescott extensions weren't going to be entirely compatible? In this case, company-specific extensions are essential.
Matt
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> [I am not subscribed to debian-amd64, please Cc: me if you feel your > reply deserves my attention.]
> Hi all, you'll mostly be pleased to know that dpkg in unstable now > supports your architecture; hopefully this is the first step towards > consideration for archive addition.
> The archive name that has been chosen is "x86-64", which I understand > might upset a few people who like the other name.
> As I've been at DebConf 4, it provided the ideal place to discuss the > architecture name in person with many people from the different Debian > teams including some of your own porters.
I fail to see why any Debian team should have a say in this apart from the technical and legal side. Naming the port is the ports decision. But maybe thats just me.
Currently only the following are actively working on the pure64 port (from the keyring that governs who may upload):
pub 1024D/32951F5D 2003-06-03 TJ Vanderpoel (GCIA,GCIH) <t...@defendem.com> pub 1024D/41954920 2003-10-29 Frederik Schüler <fschue...@gmx.net> pub 1024D/5264C70D 2004-05-12 Stephen Frost <sfrost+am...@snowman.net> pub 1024D/8E384AF2 2000-05-15 Christopher L Cheney <cche...@acm.org> pub 1024D/E2CD1763 2004-05-11 Kurt Roeckx (debian-amd64 sign) <Q...@ping.be> pub 1024D/ED0D7CFA 2000-06-14 Goswin von Brederlow (inactive) <goswin.breder...@student.uni-tuebingen.de>
I know you talked to Christopher but he was very sick with a fever the last week and not quite thinking straight (due to being sick).
> The advantages of this name are:
> * it matches the GNU arch string
It does not match the GNU arch string. Thats it actually looks very similar, - instead of _, will be far more confusing than the obvious difference between amd64 and x86_64.
> * it matches the name chosen by RedHat, Fedora and SuSE
It doesn't match the name chosen by gentoo and others and it is only confusingly close to Rh, Fedora and SuSe. For comparison others use AXP instead of Alpha and Debian doesn't care. So either way is a mood point.
What others do has as yet never stoped Debian from doing the right (or wrong :) thing.
> * it doesn't include unnecessary marketing connotations, and avoids > the issue whether we even *can* use AMD's name in vain
Most other archs used in debian are trademarks. Someone even checked a Windows manual if i386 had a trademark and according to Microsoft it has (thats not authorative but it was lying around). Using _i_386 or _i_a64 or alpha or mips or sparc or .... has the same marketing connotations as amd64. Actually amd64 is more like MIPS32, an industry standard, and not like i386, an intel tradename.
I haven't seen a single amd64[tm] on the amd.com webpages but you imediatly notice Athlon[tm] and similar. It doesn't look like amd has tradenamed amd64 and it doesn't sound like they will (or can).
> The disadvantages are:
> * it isn't what you have been using to-date
> * it doesn't *quite* match the others "x86-64" vs. "x86_64"
Which nullifies your first and second argument and your third argument is void too. So only disadvantages are left.
Further disadvantages:
* It is not the official name of the architecture. The official name for amd64 (x86_64) is amd64 as you can see on:
Its Amd's product so they have the right to name it.
Users will be looking for amd64. Thats whats written on the logos, bumpers, stickers, commercials,.... Having the old obsolete name x86_64 (actualy not even that but x86-64) will be confusing.
* A long time ago the project changed from the obsolete x86_64 name to the new amd64 name following the renaming by Amd. The alioth project debian-x86-64 was deprecated and a new debian-amd64 project was created:
The debian-amd64 (not debian-x86-64) mailinglist exists since May 2003. The port is named debian-amd64 and never debian-x86-64.
* Using x86_64 is a problem because _ is the seperator between package name, version and arch in the filename. As you said on irc the DAK scripts will have problems with that name. Debpool for one will also break. x86_64 can't be used without breaking tools.
Using x86-64 avoids the _ problem but it creates the - problem. We suspect that a handfull of sources will break with - in the architecture.
Both would be no argument if the change was needed but its not. The chnage just creates extra work with no benefits.
> The first issue is simply a matter of rebuilding, which shouldn't take > too long relatively. Your patches and fixes will still all work, > hopefully.
Half the patches (not counting FTBFS on all archs, which is the majority of patches) are about adding amd64 and most of those have been accepted into sid already.
Rebuilding means that we have to hack the wanna-build, the archive scripts, the build script, apt-get, dpkg, debootstrap, cdebootstrap, debian-installer to allow some kind of transition or we have to start from scratch again. All the essential tools we have set in place for the port.
It also takes several man month to compile and upload all of sid again at the bandwiths we have, not counting the countless man hours to fix the build and Build-Depends problems such a task has.
> The second is due to "_" being used as a filename separator; I'd like to > investigate what actually *relies* on this and potentially change the > architecture at a later date (still before archive addition) to x86_64 > to totally match the others -- we'll see how that plays out.
Which means all the work you expect us to do now to change amd64 to x86-64 is completly wasted. All patched packages have to be patched and uploaded to sid yet again for x86_64. A flood of packages has to be pushed into sarge or sarge will have sources with a broken architecture lists (and that probably close or while in freeze). Decide the arch name _NOW_ and stick with it. Please, no x86-funny-arch-name-of-the-week-64 games.
Changing the name with the intention to change it again is out of the question and we have patched dpkg for amd64 to stay amd64 and will do so till this is decided.
_If_ an archive renaming is decided upon the only good time to implement it would be when adding amd64 to ftp-master. All (or all patched packages as a minimum) packages will be recompiled and reuploaded for that. The debian-amd64 port is ready to be added so this could be done any day now.
The debian-amd64 port has decided to use amd64 instead of x86-64 even before I joined up last year and I have seen no reasonable argument to revert that decision now. Please follow the wishes of the port and keep it amd64.
MfG Goswin
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Thu, Jun 03, 2004 at 03:15:28PM +0200, Andreas Steffen wrote: > Should I just not update in the next fortnight, or need > I have no fear? If a bit of both, which packages might be particularly > affected?
We will not do anything without the consent of this list, and the architecture name of the alioth archive will remain "amd64" until we have decided in consensus on this list.
If we really are going to re-rename the port, we surely will keep the existing pool availeable as something like pure64-old, until the new one has reached some reasonable state of completeness.
Greetings Frederik Schueler -- ENOSIG
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Thu, Jun 03, 2004 at 05:36:41PM +0200, Goswin von Brederlow wrote: > Currently only the following are actively working on the pure64 port > (from the keyring that governs who may upload):
> pub 1024D/32951F5D 2003-06-03 TJ Vanderpoel (GCIA,GCIH) <t...@defendem.com> > pub 1024D/41954920 2003-10-29 Frederik Schüler <fschue...@gmx.net> > pub 1024D/5264C70D 2004-05-12 Stephen Frost <sfrost+am...@snowman.net> > pub 1024D/8E384AF2 2000-05-15 Christopher L Cheney <cche...@acm.org> > pub 1024D/E2CD1763 2004-05-11 Kurt Roeckx (debian-amd64 sign) <Q...@ping.be> > pub 1024D/ED0D7CFA 2000-06-14 Goswin von Brederlow (inactive) <goswin.breder...@student.uni-tuebingen.de>
This list is misleading at best. Would you say that I am not actively working on the pure64 port, despite having created an installer specifically for it and the first dual-purpose i386/amd64 installation images?
What about those posting tarballs for installation purposes?
I dare say that others are probably preparing patches or helping out in other ways even if they are not uploading to alioth.
On Thu, Jun 03, 2004 at 03:57:02PM +0100, Matt Kay wrote: > Plus I thought the Intel 64-bit Prescott extensions weren't going to > be entirely compatible?
Are the differences worth taking into account? As announced, the instruction sets are ``identical'' enough that a single binary can run on both. Does anyone envision a path forward where Debian differentiated between the two architectures, i.e., have separate ports for each?
> In this case, company-specific extensions are essential.
Not to mention, AMD has fallen under i386 for years. Why not have the tables turned now?
dd -- David Dooling
-- To UNSUBSCRIBE, email to debian-amd64-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
* David (ba...@users.sourceforge.net) wrote: > On Thu, Jun 03, 2004 at 03:57:02PM +0100, Matt Kay wrote: > > Plus I thought the Intel 64-bit Prescott extensions weren't going to > > be entirely compatible?
> Are the differences worth taking into account? As announced, the > instruction sets are ``identical'' enough that a single binary can run > on both. Does anyone envision a path forward where Debian > differentiated between the two architectures, i.e., have separate ports > for each?
Multiarch could potentially allow for such situations where they make sense. Similar to pentium or pentium-mmx things for x86.
On Thu, Jun 03, 2004 at 11:03:42AM -0500, John Goerzen wrote: > This list is misleading at best. Would you say that I am not actively > working on the pure64 port, despite having created an installer > specifically for it and the first dual-purpose i386/amd64 installation > images?
> What about those posting tarballs for installation purposes?
> I dare say that others are probably preparing patches or helping out in > other ways even if they are not uploading to alioth.
Yes, there are at least several others that are helping out, some of which may be primarily working on multiarch. And of course the people helping out via answering questions on the list, etc.
The others I know of are:
John Goerzen Tollef Fog Heen Hugo Mills Mattias Wadenstein
