On 14 March 2011 10:47, Jonathan Nieder wrote:
> Konstantinos Margaritis wrote:
>
>> To cut the long story short, I agree with Steve's proposal on this:
>>
>> arm-linux-gnueabi_hf
>
> What is the purpose of the underscore? In other words, what is the
> advantage over arm-linux-gnueabihf? I worry
After a short discussion with Steve and later with Guillem on IRC,
I think it's time to make a final decision about this issue.
To cut the long story short, I agree with Steve's proposal on this:
arm-linux-gnueabi_hf
If we all agree on this, let's please have a dpkg release with the final armhf
Konstantinos Margaritis wrote:
> To cut the long story short, I agree with Steve's proposal on this:
>
> arm-linux-gnueabi_hf
What is the purpose of the underscore? In other words, what is the
advantage over arm-linux-gnueabihf? I worry that some tools may not
like it --- for example, package n
On Mon, Feb 21, 2011 at 09:43:41AM +0100, Guillem Jover wrote:
> On Sun, 2011-02-20 at 23:38:36 -0800, Steve Langasek wrote:
> > On Mon, Feb 21, 2011 at 07:32:19AM +0100, Guillem Jover wrote:
> > > Given the above we'd need to either switch to i586-linux-gnu or
> > > i386-linux-gnu, it seems to me
On Mon, 2011-02-21 at 07:32:19 +0100, Guillem Jover wrote:
> The gcc-4.4:i386 package seems to be compiled on Debian to target i586
> as the base instruction set, as can be seen in its debian/rules2:388,
> which implies changing the triplet would not affect this (barring the
> small change I'm atta
On Sun, 2011-02-20 at 23:38:36 -0800, Steve Langasek wrote:
> On Mon, Feb 21, 2011 at 07:32:19AM +0100, Guillem Jover wrote:
> > Given the above we'd need to either switch to i586-linux-gnu or
> > i386-linux-gnu, it seems to me both will imply the same amount of
> > changes? And thus going for the
On Mon, Feb 21, 2011 at 07:32:19AM +0100, Guillem Jover wrote:
> Given the above we'd need to either switch to i586-linux-gnu or
> i386-linux-gnu, it seems to me both will imply the same amount of
> changes? And thus going for the latter seems the correct solution,
> it matches with the other arch
On Mon, Feb 21, 2011 at 02:22:44AM +, Wookey wrote:
> > The challenge, as Matthias points out, is that these triplets are already so
> > entrenched and there is so much software that handles x86 specially - even
> > if incorrectly! - that it's prohibitive to switch back to i386-linux-gnu as
>
[ Sorry for entangling the armhf bug with the i386 stuff, subsequent
replies should probably remove debian-arm and the bug report from
them. ]
On Fri, 2011-02-18 at 13:30:19 +0100, Matthias Klose wrote:
> On 18.02.2011 11:13, Guillem Jover wrote:
> >[ CCing Matthias, as I'd like your opinion o
+++ Steve Langasek [2011-02-18 17:36 -0800]:
> > * The remaining problem at least for multiarch is the use of more
> > specialized cpu names for the i386 triplets, i486-linux-gnu on Debian,
> > which might change depending on the base instruction set to support,
> > for example i686-linux-gnu
+++ Guillem Jover [2011-02-18 11:13 +0100]:
Guillem makes some good points about how GNU triplets should (and once
did) represent ABIs, and that if they still did, dpkg (and everything
else) could use them as the definitive ABI-indicator. He's quite
right.
_Something_ has to stand as nomenclatur
Hi Guillem,
Thanks for letting us know your thoughts.
On Fri, Feb 18, 2011 at 11:13:11AM +0100, Guillem Jover wrote:
> * The assumption that each GNU triplet denotes a different ABI is so
> entrenched in the GNU build system, that we have things like the
> following all over the place to prop
On Fri, Feb 18, 2011 at 01:30:19PM +0100, Matthias Klose wrote:
> On 18.02.2011 11:13, Guillem Jover wrote:
> >[ CCing Matthias, as I'd like your opinion on my proposed solution
> > involving some Debian gcc changes. ]
> The armhf patch for gcc looks ok, however I would like to see this
> better
On 18.02.2011 11:13, Guillem Jover wrote:
[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
The armhf patch for gcc looks ok, however I would like to see this better
addressed in Linaro and/or upstream.
Yes but x86 goes to the other
[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
Hi!
On Thu, 2011-02-17 at 12:27:30 +0100, Loïc Minier wrote:
> Trying to kick the dust a bit as having the triplet "in the air" is
> kind of an unhappy situation for armhf :-)
I think it
On Fri, Feb 18, 2011 at 04:27:52AM +, Luke Kenneth Casson Leighton wrote:
> precisely. this is another, (clearer or at least different) way of
> stating what i've been advocating. by having such a delta-maintaining
> tool, complex sets of deltas can be maintained indefinitely, or in
> fact c
On Fri, Feb 18, 2011 at 12:25 AM, Steve Langasek wrote:
> Hi Luke,
allo steve.
> I think you are working from a buggy assumption here.
i'm pleased - and relieved - to see the word "think".
> The problem is not
> that infrastructure is lacking to let Konstantinos et al. get on with making
>
Hi Luke,
On Fri, Feb 18, 2011 at 12:06:27AM +, Luke Kenneth Casson Leighton wrote:
> sorry, markos - and again, apologies to all, but i am actually now
> getting deeply concerned.
> allow me to ask you this, markos. why, if someone says, "i have an
> idea that could help you, and could help
sorry, markos - and again, apologies to all, but i am actually now
getting deeply concerned.
allow me to ask you this, markos. why, if someone says, "i have an
idea that could help you, and could help the debian project in
general, it's complex, it's been misunderstood frequently in the past
(not
On Thu, Feb 17, 2011 at 9:43 PM, Konstantinos Margaritis
wrote:
> Luke,
>
> 1. My name is Konstantinos, or Kostas, or if you prefer, just call me
> markos. It's not konstantinos, and it's not konstantinous.
sorry! :) i have always spotted such auto-finger-typing errors in
the past: i apologise
+++ Steve Langasek [2011-02-17 12:03 -0800]:
> Loïc's latest post drew my attention back to this thread, where I see I had
> this message flagged for follow-up:
>
> On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote:
>
> > > I realize this is ideal, but:
>
> > > - there's been
Luke,
1. My name is Konstantinos, or Kostas, or if you prefer, just call me
markos. It's not konstantinos, and it's not konstantinous.
2. My workload is big even without considering "crazy" solutions of
distro-wide bitbake-integrations. If you so strongly believe that this
method works so great, f
On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis
wrote:
> Hi all,
>
> I really would like to know the stance of the dpkg maintainers regarding the
> armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as
> bug reports, but without the dpkg patch, those patches would b
Loïc's latest post drew my attention back to this thread, where I see I had
this message flagged for follow-up:
On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote:
> > I realize this is ideal, but:
> > - there's been very strong upstream pushback on this, asserting that this
>
Hey
Trying to kick the dust a bit as having the triplet "in the air" is
kind of an unhappy situation for armhf :-)
On Wed, Sep 08, 2010, Guillem Jover wrote:
> We currently need something like this in dpkg-dev because the mappings
> need to be bidirectional, as dpkg-dev needs to be ab
On Wed, Sep 08, 2010, Guillem Jover wrote:
> Steve wondered why this is the case, and that's because for
> cross-compiling purposes dpkg-architecture infers the host architecture
> from the CC environment variable through the -dumpmachine option.
> Chaning this is possible but, would break a curren
Steve Langasek writes:
> On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote:
>> This also causes issue with not being able to have installed two
>> cross-toolchains for say armel and armhf as they share triplet,
>> although you can use the armel toolchain with few options to build for
On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote:
> This also causes issue with not being able to have installed two
> cross-toolchains for say armel and armhf as they share triplet,
> although you can use the armel toolchain with few options to build for
> armhf, but then you'd need t
Hi!
[ I'm leaving for two days, and running out the door just right now, so
this mail is a bit rushed, and might contain inaccuracies and
repetition due to lack of proper review, sorry about that, I'll try
to clarify anything unclear once I get back. ]
On Tue, 2010-09-07 at 14:01:37 +0300,
Hi all,
I really would like to know the stance of the dpkg maintainers regarding the
armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as
bug reports, but without the dpkg patch, those patches would be useless, so
I'm holding back, but that in the meantime increases the
30 matches
Mail list logo
