Re: question on hurd-i386 Debian architecture
Em Sáb, 2006-03-18 às 23:17 +0100, Pjotr Kourzanov escreveu: Yes. However, I think that 'setting up buildd' is the least difficult of those tasks. It is by far more difficult to produce patches for all 'standard debian packages' that make them first of all, cross-compile correctly, and (only) then make them uClibc-friendly. Sorry, I don't get it. Debian has support for several architectures, why a sub-arch would be harder? Many packages will just work. Remember that in such sub-arch, we can have uclibc-dev replacing libc6-dev, solving the builddeps... Have you ever seen uwoody[1]? there are not so many patches as you're claiming to be necessary... I'm really lost about what are you talking about... [1] http://people.debian.org/~andersee/uwoody/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 20, 2006 at 05:41:26PM -0300, Daniel Ruoso wrote: Em S?b, 2006-03-18 ?s 23:17 +0100, Pjotr Kourzanov escreveu: Yes. However, I think that 'setting up buildd' is the least difficult of those tasks. It is by far more difficult to produce patches for all 'standard debian packages' that make them first of all, cross-compile correctly, and (only) then make them uClibc-friendly. Sorry, I don't get it. Debian has support for several architectures, why Supported architectures, yes. But what about un-supported ones, such as i386-uclibc? a sub-arch would be harder? Many packages will just work. Remember that in such sub-arch, we can have uclibc-dev replacing libc6-dev, solving the builddeps... Yeah, hopefully this will just work. From my experience, however, some minimal but still significant amount of patching will be needed. Have you ever seen uwoody[1]? there are not so many patches as you're claiming to be necessary... I'm really lost about what are you talking about... [1] http://people.debian.org/~andersee/uwoody/ I've heard that uwoody is abandoned by its originator... which is the reason I stopped looking at that. Is there BTW any comparable effort for sarge/etch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: question on hurd-i386 Debian architecture
Daniel Ruoso wrote: Em Qui, 2006-03-16 às 15:09 +0100, [EMAIL PROTECTED] escreveu: On Mon, Mar 13, 2006 at 01:46:59PM -0300, Daniel Ruoso wrote: Em Seg, 2006-03-13 ?s 17:30 +0100, Pjotr Kourzanov escreveu: Daniel Ruoso wrote: This is a call for help :). If you want to help, just take over the task of setting a uclibc-i386 buildd up. What is the need for buildd? Basically, what is described in http://www.debian.org/devel/buildd/setting-up The only difference is that you'll need to cross-compile all the packages used by debootstrap when setting up the chroot. After that, it's just a matter of time (a long time, I would say). Read it. OK, I think it is worth a try on a rainy weekend. I would really like, however, to focus on standard Debian packages, and not start/participate in a totally different effort in parallel with Debian. I don't think you understood... I do think i386-uclibc could turn into an official debian arch some day... Setting up a buildd and having standard debian packages ported to this architecture should be the first step, shouldn't it? Yes. However, I think that 'setting up buildd' is the least difficult of those tasks. It is by far more difficult to produce patches for all 'standard debian packages' that make them first of all, cross-compile correctly, and (only) then make them uClibc-friendly. That is the reason I think we should focus on producing these patches and make them be merged into Debian mainline. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 03:39:41PM +0200, Riku Voipio wrote: [2] http://www.emdebian.org/slind.html This one looks dead. I understand we live in a gentoo-driven 0-day bleeding edge culture, but this is quite spectacular deducment. SLIND was published exactly two weeks ago in FOSDEM and it is already dead? The website was unavailable. It's Ok now. I see though that they patched gcc and glibc also. In my case, I needed to patch only dpkg, dpkg-cross and uclibc. These patches I hope will be taken by dpkg, dpkg-cross and uclibc maintainers... ...and i386-uclibc[3] alioth project, which is quite staganant ATM and hasn't selected arch name yet. [3] http://alioth.debian.org/projects/i386-uclibc/ There were no updates to this one since october. Is it still alive? I already said it was stagnant, please pay attention. I brought it into attention since it makes more sense to revive a old project than to start a completly new one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 01:46:59PM -0300, Daniel Ruoso wrote: Em Seg, 2006-03-13 ?s 17:30 +0100, Pjotr Kourzanov escreveu: Daniel Ruoso wrote: This is a call for help :). If you want to help, just take over the task of setting a uclibc-i386 buildd up. What is the need for buildd? Basically, what is described in http://www.debian.org/devel/buildd/setting-up The only difference is that you'll need to cross-compile all the packages used by debootstrap when setting up the chroot. After that, it's just a matter of time (a long time, I would say). Read it. OK, I think it is worth a try on a rainy weekend. I would really like, however, to focus on standard Debian packages, and not start/participate in a totally different effort in parallel with Debian. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Re: question on hurd-i386 Debian architecture
Em Qui, 2006-03-16 às 15:09 +0100, [EMAIL PROTECTED] escreveu: On Mon, Mar 13, 2006 at 01:46:59PM -0300, Daniel Ruoso wrote: Em Seg, 2006-03-13 ?s 17:30 +0100, Pjotr Kourzanov escreveu: Daniel Ruoso wrote: This is a call for help :). If you want to help, just take over the task of setting a uclibc-i386 buildd up. What is the need for buildd? Basically, what is described in http://www.debian.org/devel/buildd/setting-up The only difference is that you'll need to cross-compile all the packages used by debootstrap when setting up the chroot. After that, it's just a matter of time (a long time, I would say). Read it. OK, I think it is worth a try on a rainy weekend. I would really like, however, to focus on standard Debian packages, and not start/participate in a totally different effort in parallel with Debian. I don't think you understood... I do think i386-uclibc could turn into an official debian arch some day... Setting up a buildd and having standard debian packages ported to this architecture should be the first step, shouldn't it? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Wouter Verhelst wrote: On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote: Dpkg maintainer(s), what do you think is the correct procedure for additing these things i.e., extra -vendor and -libc fields? I already have a patch for dpkg package which adds-in uclibc variants... Not being a dpkg maintainer, I find this to be a gratuitous change for no good reason (other than it looks a bit better). I don't see what point it would serve. Maybe the ability to run Debian on embedded or old systems? AFAIK, there is currently no support for running Debian with uclibc... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Pjotr Kourzanov [EMAIL PROTECTED] writes: Riku Voipio wrote: On Sun, Mar 12, 2006 at 03:49:01PM +0100, Peter Kourzanov wrote: Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? because dpkg-architecture has a line like this: return $os-$cpu; older dpkg (of sarge age) was more flexible, so likely the hurd naming decission was not done because of dpkg-architecture, but rather the other way around. That's weird, naming a architecure because of a seemingly random choice made in a script. But OK, that's fair enough... I am adding some additional archs to my local installation like i386-uclibc, which makes hurd-i386 an exception to the rule of having the CPU arch first and the OS name the next. Which is linux-i386-uclibc. Fits perfectly with os-arch. You could argue to use the gnu tripplet style though: arch-os-libc. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 10:38:52AM +0100, Pjotr Kourzanov wrote: Wouter Verhelst wrote: Not being a dpkg maintainer, I find this to be a gratuitous change for no good reason (other than it looks a bit better). I don't see what point it would serve. Maybe the ability to run Debian on embedded or old systems? AFAIK, there is currently no support for running Debian with uclibc... Wouter is referring to the naming change. Indeed I agree, changing naming conventions is troublesome, and discussions about what naming convention looks good are endless. Essentially it's a color of the bikeshed [1] issue. As for debian with uClibc, there is SLIND[2] which uses uclibc-i386 / uclibc-arm/ uclibc-powerpc and i386-uclibc[3] alioth project, which is quite staganant ATM and hasn't selected arch name yet. [1] http://www.unixguide.net/freebsd/faq/16.19.shtml [2] http://www.emdebian.org/slind.html [3] http://alioth.debian.org/projects/i386-uclibc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Riku Voipio wrote: On Mon, Mar 13, 2006 at 10:38:52AM +0100, Pjotr Kourzanov wrote: Wouter Verhelst wrote: Not being a dpkg maintainer, I find this to be a gratuitous change for no good reason (other than it looks a bit better). I don't see what point it would serve. Maybe the ability to run Debian on embedded or old systems? AFAIK, there is currently no support for running Debian with uclibc... Wouter is referring to the naming change. Indeed I agree, changing naming conventions is troublesome, and discussions about what naming convention looks good are endless. Essentially it's a color of the bikeshed [1] issue. Yes, we whould not change names of existing archs. However, for new ones, we better choose suitable names. As for debian with uClibc, there is SLIND[2] which uses uclibc-i386 / uclibc-arm/ uclibc-powerpc and i386-uclibc[3] alioth project, which is quite staganant ATM and hasn't selected arch name yet. [1] http://www.unixguide.net/freebsd/faq/16.19.shtml [2] http://www.emdebian.org/slind.html This one looks dead. [3] http://alioth.debian.org/projects/i386-uclibc/ There were no updates to this one since october. Is it still alive? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Goswin von Brederlow wrote: Pjotr Kourzanov [EMAIL PROTECTED] writes: Riku Voipio wrote: On Sun, Mar 12, 2006 at 03:49:01PM +0100, Peter Kourzanov wrote: Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? because dpkg-architecture has a line like this: return $os-$cpu; older dpkg (of sarge age) was more flexible, so likely the hurd naming decission was not done because of dpkg-architecture, but rather the other way around. That's weird, naming a architecure because of a seemingly random choice made in a script. But OK, that's fair enough... I am adding some additional archs to my local installation like i386-uclibc, which makes hurd-i386 an exception to the rule of having the CPU arch first and the OS name the next. Which is linux-i386-uclibc. Fits perfectly with os-arch. os-arch-libc. OK. You could argue to use the gnu tripplet style though: arch-os-libc. No, that does not matter much, and would require changing e.g., hurd-i386. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote:
[snip]
There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
Actually, I disagree. To me it makes perfect sense the way it
currently is, namely:
kernel-arch-libc
kernel and libc can be empty when they're the default (Linux and
glibc respectively).
The uclibc port uses Linux so I think i386-uclibc is fine. There
could be kfreebsd-i386-uclibc in the future, I suppose, or something
like that.
Makes sense. I would prefer however to stick with gcc's convention
of having arch(-vendor)-kernel-libc, however, kernel-arch(-vendor)-libc
is also
suitable.
Note that for Debian the arch part implies also the ABI, so we won't
have a 1:1 mapping to GNU-style arch-vendor-os-libc+abi anyway.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
[2] http://www.emdebian.org/slind.html This one looks dead. I understand we live in a gentoo-driven 0-day bleeding edge culture, but this is quite spectacular deducment. SLIND was published exactly two weeks ago in FOSDEM and it is already dead? ...and i386-uclibc[3] alioth project, which is quite staganant ATM and hasn't selected arch name yet. [3] http://alioth.debian.org/projects/i386-uclibc/ There were no updates to this one since october. Is it still alive? I already said it was stagnant, please pay attention. I brought it into attention since it makes more sense to revive a old project than to start a completly new one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Riku Voipio wrote: [2] http://www.emdebian.org/slind.html This one looks dead. I understand we live in a gentoo-driven 0-day bleeding edge culture, but this is quite spectacular deducment. SLIND was published exactly two weeks ago in FOSDEM and it is already dead? ...and i386-uclibc[3] alioth project, which is quite staganant ATM and hasn't selected arch name yet. [3] http://alioth.debian.org/projects/i386-uclibc/ There were no updates to this one since october. Is it still alive? I already said it was stagnant, please pay attention. I brought it into attention since it makes more sense to revive a old project than to start a completly new one. I am not starting a new project. I want to see support for i386-uclibc in standard Debian packages. So far, I have patches to a fair amount of essential packages, most of which are trivial. This gives me some confidence that we can just add i386-uclibc as a supported architecture, along with arm-uclibc, mipsel-uclibc etc. Also, looking at http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/?cvsroot=i386-uclibc I see only binutils and gcc. In the other thread cross-compiling Debian packages I already mentioned that binutils and gcc are trivial to retarget nowadays. The tricky bit is patching all those 25411 packages... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Em Seg, 2006-03-13 às 15:04 +0100, Pjotr Kourzanov escreveu: Also, looking at http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/?cvsroot=i386-uclibc I see only binutils and gcc. In the other thread cross-compiling Debian packages I already mentioned that binutils and gcc are trivial to retarget nowadays. Most of the work was made outside everything in irc. I'm too busy in the last months, so not much thing happened here. But... The cross-toolchain task was just one of them. The tricky bit is patching all those 25411 packages... The idea now is to use SLIND packages to setup a buildd for uclibc-i386 (this is the arch name they use, it seems easier to dpkg to handle it), I'm still too busy, and enerv (who was working with me in this project) got a new job and is quite busy also. So, we're in a deadlock in the moment. This is a call for help :). If you want to help, just take over the task of setting a uclibc-i386 buildd up. daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Daniel Ruoso wrote: Em Seg, 2006-03-13 às 15:04 +0100, Pjotr Kourzanov escreveu: Also, looking at http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/?cvsroot=i386-uclibc I see only binutils and gcc. In the other thread cross-compiling Debian packages I already mentioned that binutils and gcc are trivial to retarget nowadays. Most of the work was made outside everything in irc. I'm too busy in the last months, so not much thing happened here. But... The cross-toolchain task was just one of them. The tricky bit is patching all those 25411 packages... The idea now is to use SLIND packages to setup a buildd for uclibc-i386 (this is the arch name they use, it seems easier to dpkg to handle it), This is similar to what I've done, too. See http://www.xs4all.nl/~kurzanov/debian/. One difference is that I use i386-uclibc (which seems more logical to me). The other is that I would prefer to contribute all changes back to Debian so that separate development effort is not required. I'm still too busy, and enerv (who was working with me in this project) got a new job and is quite busy also. So, we're in a deadlock in the moment. This is a call for help :). If you want to help, just take over the task of setting a uclibc-i386 buildd up. What is the need for buildd? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote: Dpkg maintainer(s), what do you think is the correct procedure for additing these things i.e., extra -vendor and -libc fields? I already have a patch for dpkg package which adds-in uclibc variants... I hope toolchain-source maintainer(s) will also join the party. -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Em Seg, 2006-03-13 às 17:30 +0100, Pjotr Kourzanov escreveu: Daniel Ruoso wrote: This is a call for help :). If you want to help, just take over the task of setting a uclibc-i386 buildd up. What is the need for buildd? Basically, what is described in http://www.debian.org/devel/buildd/setting-up The only difference is that you'll need to cross-compile all the packages used by debootstrap when setting up the chroot. After that, it's just a matter of time (a long time, I would say). daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 10:38:52AM +0100, Pjotr Kourzanov wrote: Wouter Verhelst wrote: On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote: Dpkg maintainer(s), what do you think is the correct procedure for additing these things i.e., extra -vendor and -libc fields? I already have a patch for dpkg package which adds-in uclibc variants... Not being a dpkg maintainer, I find this to be a gratuitous change for no good reason (other than it looks a bit better). I don't see what point it would serve. Maybe the ability to run Debian on embedded or old systems? You're misunderstanding me. I do understand the need for the -uclibc suffix; however, I fail to see the need to restructure the hurd-i386 name. It's there, it works, and heck, it's only a name; changing that name because it looks wrong sounds like fixing a non-problem to me. The structure of kernel-processor-libc is clear enough for whatever you want. AFAIK, there is currently no support for running Debian with uclibc... SLIND? http://wiki.debian.org/EmdebianSlind -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 07:02:18PM +0100, Wouter Verhelst wrote: On Mon, Mar 13, 2006 at 10:38:52AM +0100, Pjotr Kourzanov wrote: Wouter Verhelst wrote: On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote: Dpkg maintainer(s), what do you think is the correct procedure for additing these things i.e., extra -vendor and -libc fields? I already have a patch for dpkg package which adds-in uclibc variants... Not being a dpkg maintainer, I find this to be a gratuitous change for no good reason (other than it looks a bit better). I don't see what point it would serve. Maybe the ability to run Debian on embedded or old systems? You're misunderstanding me. I do understand the need for the -uclibc suffix; however, I fail to see the need to restructure the hurd-i386 name. It's there, it works, and heck, it's only a name; changing that name because it looks wrong sounds like fixing a non-problem to me. OTOH, now (before it's a release-candidate architecture) would be the time to change it -- *if* it warrants changing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
question on hurd-i386 Debian architecture
Dear DDs, Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? Is there any rule that says that the OS name should come before CPU name? Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Peter Kourzanov wrote: Dear DDs, Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? Is there any rule that says that the OS name should come before CPU name? Is there any rule that says that the architecture should came before the OS name? Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
su, 2006-03-12 kello 15:49 +0100, Peter Kourzanov kirjoitti: Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? I guess it just happened to seem like a good name at the time. Why, is there a problem with the name? Does it matter? Debian architecture names are, after all, pretty much atomic and unparseable. -- I am an artist. Source code is my canvas, a programming language is my paint. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Sun, Mar 12, 2006 at 03:49:01PM +0100, Peter Kourzanov wrote: Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? because dpkg-architecture has a line like this: return $os-$cpu; older dpkg (of sarge age) was more flexible, so likely the hurd naming decission was not done because of dpkg-architecture, but rather the other way around. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Florian Ludwig wrote: Peter Kourzanov wrote: Dear DDs, Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? Is there any rule that says that the OS name should come before CPU name? Is there any rule that says that the architecture should came before the OS name? Probably not. Logics however, dictate that the architecture denotes a set much larger than that of the OS names... Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Lars Wirzenius wrote: su, 2006-03-12 kello 15:49 +0100, Peter Kourzanov kirjoitti: Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? I guess it just happened to seem like a good name at the time. Why, is there a problem with the name? Does it matter? Debian architecture names are, after all, pretty much atomic and unparseable. Well, I am in the process of adding more architectures like i386-uclibc, and this order (CPU-OS) seems more logical to me that the reverse (hurd-i386). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Riku Voipio wrote: On Sun, Mar 12, 2006 at 03:49:01PM +0100, Peter Kourzanov wrote: Can anyone please explain why this architecture is named hurd-i386 rather that i386-hurd? because dpkg-architecture has a line like this: return $os-$cpu; older dpkg (of sarge age) was more flexible, so likely the hurd naming decission was not done because of dpkg-architecture, but rather the other way around. That's weird, naming a architecure because of a seemingly random choice made in a script. But OK, that's fair enough... I am adding some additional archs to my local installation like i386-uclibc, which makes hurd-i386 an exception to the rule of having the CPU arch first and the OS name the next. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Pjotr Kourzanov [EMAIL PROTECTED] writes:
I am adding some additional archs to my local installation like i386-uclibc,
which makes hurd-i386 an exception to the rule of having the CPU arch first
and the OS name the next.
There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
Marc
--
Cabal theories right: https://launchpad.net/distros/debian/+members
Security is for whimps: https://launchpad.net/distros/ubuntu/+bug/34606/
Film at 11!
pgp1mPQmfy3qF.pgp
Description: PGP signature
Re: question on hurd-i386 Debian architecture
* Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2006-03-13 00:04]:
I am adding some additional archs to my local installation like
i386-uclibc, which makes hurd-i386 an exception to the rule of
having the CPU arch first and the OS name the next.
There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
Actually, I disagree. To me it makes perfect sense the way it
currently is, namely:
kernel-arch-libc
kernel and libc can be empty when they're the default (Linux and
glibc respectively).
The uclibc port uses Linux so I think i386-uclibc is fine. There
could be kfreebsd-i386-uclibc in the future, I suppose, or something
like that.
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
Martin Michlmayr wrote:
* Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2006-03-13 00:04]:
I am adding some additional archs to my local installation like
i386-uclibc, which makes hurd-i386 an exception to the rule of
having the CPU arch first and the OS name the next.
There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
Actually, I disagree. To me it makes perfect sense the way it
currently is, namely:
kernel-arch-libc
kernel and libc can be empty when they're the default (Linux and
glibc respectively).
The uclibc port uses Linux so I think i386-uclibc is fine. There
could be kfreebsd-i386-uclibc in the future, I suppose, or something
like that.
Makes sense. I would prefer however to stick with gcc's convention
of having arch(-vendor)-kernel-libc, however, kernel-arch(-vendor)-libc
is also
suitable.
Dpkg maintainer(s), what do you think is the correct procedure for
additing these things i.e., extra -vendor and -libc fields? I already
have a patch for dpkg package which adds-in uclibc variants...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote: Dpkg maintainer(s), what do you think is the correct procedure for additing these things i.e., extra -vendor and -libc fields? I already have a patch for dpkg package which adds-in uclibc variants... Not being a dpkg maintainer, I find this to be a gratuitous change for no good reason (other than it looks a bit better). I don't see what point it would serve. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Not i386 Debian
What about Digital Alpha and Sun Sparc debian version? Marco. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Not i386 Debian
On Sat, Jan 03, 1998 at 12:42:36PM +0100, Marco Bellini wrote: What about Digital Alpha and Sun Sparc debian version? Both ports exist but are not quite complete. They are usable though. There are two mailing lists debian-sparc and debian-alpha@lists.debian.org where you should get further information. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / pgpoPDquvIo1t.pgp Description: PGP signature
