Dnia 2014-06-18, o godz. 17:24:03
Peter Stuge napisał(a):
> Alexandre Rostovtsev wrote:
> > current crossdev versions blindly install their
> > /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting
> > the binary belonging to pkgconfig[abi_x86_32].
>
> Thanks for getting to the point
Alexandre Rostovtsev wrote:
> current crossdev versions blindly install their
> /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting
> the binary belonging to pkgconfig[abi_x86_32].
Thanks for getting to the point.
It seems silly for two toolchains (abi_x86_32 and a crossdev i686 too
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18/06/14 02:24 AM, Joshua Kinard wrote:
> IOW, it looks like less than 1.5% of the tree contains multilib
> packages that rely on pkgconfig that could be affected by crossdev
> installing the ${CHOST}-pkg-config link into PATH.
>
> We all have di
On 06/18/2014 01:08, Alexandre Rostovtsev wrote:
> eix --depend -z virtual/pkgconfig -a --use -z abi_x86_32 -a --use -z
> abi_x86_64 --only-names | wc -l
Interesting, I got 294 (probably from my local dev tree). Close enough, thanks!
So, taking this count-packages script here:
http://dev.gent
On Tue, 2014-06-17 at 11:20 -0400, Joshua Kinard wrote:
> On 06/17/2014 10:56, Alexandre Rostovtsev wrote:
> > On Tue, 2014-06-17 at 10:17 -0400, Joshua Kinard wrote:
> >> What I'd like to see is a list of all affected packages so we all can get a
> >> sense of just how big the actual problem reall
Joshua Kinard:
> Provide a technical counter-argument to that or propose a solution that
> people can agree on and you're going to find people are a LOT more willing
> to stand with you on fixing the perceived problem.
>
I start to think here is some confusion going on. We already proposed
soluti
On 06/17/2014 10:56, Alexandre Rostovtsev wrote:
> On Tue, 2014-06-17 at 10:17 -0400, Joshua Kinard wrote:
>> What I'd like to see is a list of all affected packages so we all can get a
>> sense of just how big the actual problem really is. All I am hearing so far
>> are unsubstantiated claims of
Joshua Kinard:
>> I have proposed numerous ways to communicate this problem to the user
>> without touching any of the precious toolchain/embedded packages. If no
>> one responds there, I'll just pick one and apply it.
>
> And what I am trying to tell you is that making hardmask threats don't solv
Dnia 2014-06-17, o godz. 10:56:41
Alexandre Rostovtsev napisał(a):
> On Tue, 2014-06-17 at 10:17 -0400, Joshua Kinard wrote:
> > What I'd like to see is a list of all affected packages so we all can get a
> > sense of just how big the actual problem really is. All I am hearing so far
> > are uns
On 06/17/2014 10:38, hasufell wrote:
> Joshua Kinard:
>>
>> "upstream" didn't say anywhere in that bug that they weren't interested.
>> They countered your reasoning with a technical argument. QA even states
>> that you need to file separate bugs for the various build failures. You
>> could set u
On Tue, 2014-06-17 at 10:17 -0400, Joshua Kinard wrote:
> What I'd like to see is a list of all affected packages so we all can get a
> sense of just how big the actual problem really is. All I am hearing so far
> are unsubstantiated claims of tree-wide breakage. Knowing which packages
> are brok
Joshua Kinard:
>
> "upstream" didn't say anywhere in that bug that they weren't interested.
> They countered your reasoning with a technical argument. QA even states
> that you need to file separate bugs for the various build failures. You
> could set up a master TRACKER bug for these crossdev-r
On 06/17/2014 10:22, Michał Górny wrote:
> Dnia 2014-06-17, o godz. 09:25:32
> Ian Stakenvicius napisał(a):
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 16/06/14 07:38 PM, Joshua Kinard wrote:
>>> Can $PATH be configured via our existing eselect tool to
>>> enable/disable the
On 06/17/2014 08:48, hasufell wrote:
> Joshua Kinard:
>>
>> Equally using the Council as a hammer all the time doesn't work in the
>> long-term, either.
>
> This is exactly the case where the council has to step in to solve
> global issues and those between projects (here it is embedded gentoo
>
Dnia 2014-06-17, o godz. 09:25:32
Ian Stakenvicius napisał(a):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 16/06/14 07:38 PM, Joshua Kinard wrote:
> > Can $PATH be configured via our existing eselect tool to
> > enable/disable the crossdev paths when needed?
> >
>
> Technically
On 06/17/2014 08:49, Rich Freeman wrote:
>
> Is there a list/etc for crossdev? I'd think that the users and
> maintainers of crossdev collectively have the biggest vested interest
> in addressing these issues. They're also the ones who can vouch for
> how big of a problem this is.
toolchain is
On 06/17/2014 08:30, hasufell wrote:
> Joshua Kinard:
>> On 06/16/2014 21:47, hasufell wrote:
>>> Joshua Kinard:
How big of a patch would this change require to the existing crossdev
ebuild?
>>>
>>> Probably quite trivial, but since vapier said "bs" to that proposal
>>> (transl
Rich Freeman:
> On Tue, Jun 17, 2014 at 8:30 AM, hasufell wrote:
>> No, that's not how opensource works. You don't work on things after
>> "upstream" said "not interested".
>
> That is hardly true though - which is why we have 47 different
> implementations of everything to debate the merits of.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/06/14 07:38 PM, Joshua Kinard wrote:
> Can $PATH be configured via our existing eselect tool to
> enable/disable the crossdev paths when needed?
>
Technically it could but not really ; PATH is an environment thing,
AFAIK all eselect could do
On Tue, Jun 17, 2014 at 8:30 AM, hasufell wrote:
> No, that's not how opensource works. You don't work on things after
> "upstream" said "not interested".
That is hardly true though - which is why we have 47 different
implementations of everything to debate the merits of. :)
Besides, if this we
Joshua Kinard:
>
> Equally using the Council as a hammer all the time doesn't work in the
> long-term, either.
This is exactly the case where the council has to step in to solve
global issues and those between projects (here it is embedded gentoo
project and multilib project).
Joshua Kinard:
> On 06/16/2014 21:47, hasufell wrote:
>> Joshua Kinard:
>>>
>>> How big of a patch would this change require to the existing crossdev
>>> ebuild?
>>>
>>
>> Probably quite trivial, but since vapier said "bs" to that proposal
>> (translates to "bullshit" I guess) I'll not put any wor
On 06/16/2014 21:47, hasufell wrote:
> Joshua Kinard:
>>
>> How big of a patch would this change require to the existing crossdev ebuild?
>>
>
> Probably quite trivial, but since vapier said "bs" to that proposal
> (translates to "bullshit" I guess) I'll not put any work into that.
>
> So there w
Joshua Kinard:
>
> How big of a patch would this change require to the existing crossdev ebuild?
>
Probably quite trivial, but since vapier said "bs" to that proposal
(translates to "bullshit" I guess) I'll not put any work into that.
So there we go. If you are cool, you can just say "bs", vani
On 06/16/2014 18:10, hasufell wrote:
> Joshua Kinard:
>>
>> Then, can crossdev be augmented to work around the invalid behavior?
>
> Yes, by installing it into prefixes and requiring people to add it to
> PATH on their own if they need it outside of cross-emerge.
How big of a patch would this cha
On 06/17/2014 04:24 AM, hasufell wrote:
>> What about those of us who have been using crossdev to generate
>> cross-compilers for years w/o issue, because we run non-multilib?
>> Hardmasking crossdev to solve multilib problems doesn't accomplish anything,
>> other than just irk us. Why not hardma
Joshua Kinard:
>
> Then, can crossdev be augmented to work around the invalid behavior?
Yes, by installing it into prefixes and requiring people to add it to
PATH on their own if they need it outside of cross-emerge.
On 06/16/2014 16:24, hasufell wrote:
> Joshua Kinard:
>> On 06/16/2014 15:47, hasufell wrote:
>>> Jeroen Roovers:
On Mon, 16 Jun 2014 19:31:58 +
hasufell wrote:
> Also check the history of this thread for a few proposed solutions.
The history of this thread and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/06/14 04:05 PM, Joshua Kinard wrote:
> On 06/16/2014 15:47, hasufell wrote:
>> So I don't see what else we can do here other than taking more
>> radical steps to INFORM users of these possible breakages... and
>> that's exactly what a hardmask
Steev Klimaszewski:
>
> while I agree that temporarily adding the cross
> compiler(s) to the PATH is easy, for some of us, it's easier to allow
> Gentoo to do so.
I'm not sure if that is reason enough to cause the current breakage
crossdev and multilib are in.
Joshua Kinard:
> On 06/16/2014 15:47, hasufell wrote:
>> Jeroen Roovers:
>>> On Mon, 16 Jun 2014 19:31:58 +
>>> hasufell wrote:
>>>
Also check the history of this thread for a few proposed solutions.
>>>
>>> The history of this thread and the history of gx86-multilib and
>>> crossdev deve
On 06/16/2014 15:47, hasufell wrote:
> Jeroen Roovers:
>> On Mon, 16 Jun 2014 19:31:58 +
>> hasufell wrote:
>>
>>> Also check the history of this thread for a few proposed solutions.
>>
>> The history of this thread and the history of gx86-multilib and
>> crossdev development suggest that cros
Jeroen Roovers:
> On Mon, 16 Jun 2014 19:31:58 +
> hasufell wrote:
>
>> Also check the history of this thread for a few proposed solutions.
>
> The history of this thread and the history of gx86-multilib and
> crossdev development suggest that crossdev was doing nothing wrong until
> gx86-mu
On Mon, 16 Jun 2014 19:31:58 +
hasufell wrote:
> Also check the history of this thread for a few proposed solutions.
The history of this thread and the history of gx86-multilib and
crossdev development suggest that crossdev was doing nothing wrong until
gx86-multilib came around and a proble
Steev Klimaszewski:
>
> I'm someone who uses crossdev (and the cross compilers) quite heavily -
> can you point me to a bug that you're talking about? I'm not in the
> toolchain, and while I agree that temporarily adding the cross
> compiler(s) to the PATH is easy, for some of us, it's easier to a
On Mon, 2014-06-16 at 13:37 +, hasufell wrote:
> Chí-Thanh Christopher Nguyễn:
> > hasufell schrieb:
> >> No improvements so far. I am going to hardmask sys-devel/crossdev,
> >> unless someone can explain why we are still in broken stage.
> >>
> >> More packages are popping up that randomly bre
Chí-Thanh Christopher Nguyễn:
> hasufell schrieb:
>> No improvements so far. I am going to hardmask sys-devel/crossdev,
>> unless someone can explain why we are still in broken stage.
>>
>> More packages are popping up that randomly break. Recent failures were
>> related to tc-getBUILD_CC.
>>
>> Th
hasufell schrieb:
> No improvements so far. I am going to hardmask sys-devel/crossdev,
> unless someone can explain why we are still in broken stage.
>
> More packages are popping up that randomly break. Recent failures were
> related to tc-getBUILD_CC.
>
> This isn't stable in any way. I'm not b
Steven J. Long:
>
> "I'll see you when you get there, if you ever get there.."
>
No improvements so far. I am going to hardmask sys-devel/crossdev,
unless someone can explain why we are still in broken stage.
More packages are popping up that randomly break. Recent failures were
related to tc-g
Mike Frysinger wrote:
> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > Steven J. Long wrote:
> > > > The cross tools should NOT pollute the default PATH, simply because the
> > > > user happened to run crossdev at some point.
> > >
> > > that's bs. people install crossdev to get a cross-co
40 matches
Mail list logo
