On Sat, 16 Nov 2013 11:57:23 +0100
Thomas Sachau wrote:
> >>> 2: multilib-portage
> >
> > I think this has been discussed multiple times, if I don't
> > misremember, PMS team is not willing to accept it until the
> > specification is done... and we are waiting for that for years
> > probably beca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 17 Nov 2013 17:09:10 +0100
hasufell wrote:
> multilib eclasses as a whole were a big failure, both for users
> (enough examples given here)
You mean those failures where they mix branches and thus cause blockers
between the old and new appro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/2013 11:57 AM, Thomas Sachau wrote:
> Pacho Ramos schrieb:
>> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
>>> Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot
>>> napisał(a):
>>>
As I see it now, with respect to multilib,
Pacho Ramos schrieb:
> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
>> Dnia 2013-11-15, o godz. 14:53:00
>> Ben de Groot napisał(a):
>>
>>> As I see it now, with respect to multilib, we have three competing
>>> solutions, but not a clear direction which way we want to go as a
>>> d
El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió:
> Dnia 2013-11-15, o godz. 14:53:00
> Ben de Groot napisał(a):
>
> > As I see it now, with respect to multilib, we have three competing
> > solutions, but not a clear direction which way we want to go as a
> > distro:
> >
> > 1: emul-*
On Fri, 15 Nov 2013 23:39:34 +0100
Michał Górny wrote:
> Dnia 2013-11-15, o godz. 14:53:00
> Ben de Groot napisał(a):
>
> > As I see it now, with respect to multilib, we have three competing
> > solutions, but not a clear direction which way we want to go as a
> > distro:
> >
> > 1: emul-* pac
On Fri, 15 Nov 2013 23:26:57 +0100
Peter Stuge wrote:
> Tom Wijsman wrote:
> > > portage should say, with as similar wording as possible:
> > >
> > > "If you want to emerge libXt with those USE flags then you'll also
> > > have to set those same USE flags for libYt and libZt because libXt
> > >
Dnia 2013-11-15, o godz. 14:53:00
Ben de Groot napisał(a):
> As I see it now, with respect to multilib, we have three competing
> solutions, but not a clear direction which way we want to go as a
> distro:
>
> 1: emul-* packages
> 2: multilib-portage
> 3: multilib.eclass
>
> I would like to vot
Tom Wijsman wrote:
> > portage should say, with as similar wording as possible:
> >
> > "If you want to emerge libXt with those USE flags then you'll also
> > have to set those same USE flags for libYt and libZt because libXt
> > DEPENDs on them."
> >
> > Bonus points:
> >
> > "Would you like me
On Fri, 15 Nov 2013 22:57:06 +0100
Peter Stuge wrote:
> Tom Wijsman wrote:
> > I'm not sure if making broken (or experimental) things more easily
> > available or a suggestion would be a good idea; people already have
> > enough trouble as it is, adding more doesn't seem to be the right
> > way.
On Fri, 15 Nov 2013 13:45:29 -0800
Matt Turner wrote:
> On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman
> wrote:
> > On Fri, 15 Nov 2013 13:21:53 -0800
> > Matt Turner wrote:
> >
> >> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman
> >> wrote:
> >> > On Fri, 15 Nov 2013 12:25:47 -0800
> >> > Matt T
Tom Wijsman wrote:
> I'm not sure if making broken (or experimental) things more easily
> available or a suggestion would be a good idea; people already have
> enough trouble as it is, adding more doesn't seem to be the right way.
It's not about broken/experimental, it's about the logical
conseque
On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman wrote:
> On Fri, 15 Nov 2013 13:21:53 -0800
> Matt Turner wrote:
>
>> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman
>> wrote:
>> > On Fri, 15 Nov 2013 12:25:47 -0800
>> > Matt Turner wrote:
>> >
>> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
>>
On Fri, 15 Nov 2013 13:21:53 -0800
Matt Turner wrote:
> On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman
> wrote:
> > On Fri, 15 Nov 2013 12:25:47 -0800
> > Matt Turner wrote:
> >
> >> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
> >> wrote:
> >> Imagine I had simply forgotten to unmask the abi_
On Fri, 15 Nov 2013 22:09:04 +0100
Peter Stuge wrote:
> Tom Wijsman wrote:
> > Does replacing this "explicit behavior" by "implicit behavior" make
> > sense for the users in general?
>
> Please don't warp the words. Maybe I misunderstand, but it seems like
> that's what you're doing.
>
> I'll t
On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman wrote:
> On Fri, 15 Nov 2013 12:25:47 -0800
> Matt Turner wrote:
>
>> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
>> wrote:
>> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
>> kbproto but was attempting to emerge unstable (or
Tom Wijsman wrote:
> Does replacing this "explicit behavior" by "implicit behavior" make
> sense for the users in general?
Please don't warp the words. Maybe I misunderstand, but it seems like
that's what you're doing.
I'll try to clarify:
With explicit I was refering to allowing manual setting
On Fri, 15 Nov 2013 12:25:47 -0800
Matt Turner wrote:
> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman
> wrote:
> Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
> kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
> libXt. In fact, if I un-unmask kbproto
On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800
> Matt Turner wrote:
>
>> There's a single problem. It can't enable abi_x86_32. Why didn't it
>> just say that?
>
> As per the full output, it does:
>
> !!! Enabling --newuse and --update might solve this co
On Fri, 15 Nov 2013 21:10:41 +0100
Peter Stuge wrote:
> Tom Wijsman wrote:
> > !!! Enabling --newuse and --update might solve this conflict.
> > !!! If not, it might help emerge to give a more specific suggestion.
> >
> > That together with ABI_X86="(64) (-32*) (-x32)" from the package
> > line
Tom Wijsman wrote:
> !!! Enabling --newuse and --update might solve this conflict.
> !!! If not, it might help emerge to give a more specific suggestion.
>
> That together with ABI_X86="(64) (-32*) (-x32)" from the package line
> makes it clear that it is trying to change that USE flag.
I disagre
On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner wrote:
> There's a single problem. It can't enable abi_x86_32. Why didn't it
> just say that?
As per the full output, it does:
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific su
On Fri, Nov 15, 2013 at 11:24 AM, Tom Wijsman wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800
> Matt Turner wrote:
>
>> Attempting to merge =x11-proto/kbproto-1.0.6-r1
>> results in:
>>
>> x11-proto/kbproto:0
>>
>> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge)
>> pulled in by (no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/11/13 02:24 PM, Tom Wijsman wrote:
> On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner
> wrote:
>
>> Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in:
>>
>> x11-proto/kbproto:0
>>
>> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild schedu
On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner wrote:
> Attempting to merge =x11-proto/kbproto-1.0.6-r1
> results in:
>
> x11-proto/kbproto:0
>
> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge)
> pulled in by (no parents that aren't satisfied by other packages in
> this slot)
On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner wrote:
> Attempting to merge =x11-proto/kbproto-1.0.6-r1
> results in:
>
> x11-proto/kbproto:0
>
> (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge)
> pulled in by (no parents that aren't satisfied by other packages in
> this slot)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/11/13 10:54 AM, Peter Stuge wrote:
> Matt Turner wrote:
>> I think in large part recently it's because of use.stable.mask
>> and package.use.stable.mask. These really are a nightmare for
>> users.
> ..
>> I think most of the confusion is caused
Matt Turner wrote:
> I think in large part recently it's because of use.stable.mask and
> package.use.stable.mask. These really are a nightmare for users.
..
> I think most of the confusion is caused by the necessity to put a
> *stable* package atom into package.keywords to unmask a *USE* flag.
A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/11/13 02:13 AM, Ulrich Mueller wrote:
>> On Fri, 15 Nov 2013, Ben de Groot wrote:
>
>> As I see it now, with respect to multilib, we have three
>> competing solutions, but not a clear direction which way we want
>> to go as a distro:
>
>>
On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot wrote:
>
> I don't really want to bring up this episode again, but it is a
> telling example, which you asked for.
I appreciate that. I did ask for an example. I'll also limit my
comments just to things that I think are more helpful moving forward.
On 11/15/2013 03:13 PM, Ulrich Mueller wrote:
>> On Fri, 15 Nov 2013, Ben de Groot wrote:
>
>> As I see it now, with respect to multilib, we have three competing
>> solutions, but not a clear direction which way we want to go as a
>> distro:
>
>> 1: emul-* packages
>> 2: multilib-portage
>> 3
> On Fri, 15 Nov 2013, Ben de Groot wrote:
> As I see it now, with respect to multilib, we have three competing
> solutions, but not a clear direction which way we want to go as a
> distro:
> 1: emul-* packages
> 2: multilib-portage
> 3: multilib.eclass
> I would like to vote for option 1, a
On 15 November 2013 01:32, Rich Freeman wrote:
> On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot wrote:
>> I was particularly hit by this as maintainer of freetype, see bugs
>> 455070 and 459352 for some of the mess that could have been avoided.
>
> Looks like 455070 was the source of problems the
On 15 November 2013 17:56, Matt Turner wrote:
> After using it for a month, he's now convinced that
> Gentoo is clearly the most difficult to use.
>
> I'm inclined to agree,
I'd have to disagree there slightly, arch is more easy to use if you
stick to the core set, the binary packages ... as is
On Wed, Nov 13, 2013 at 2:28 AM, Martin Vaeth
wrote:
> The new "features" use.stable.mask and package.use.stable.mask
> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> into a nightmare:
I agree. I have helped two friends convert to Gentoo recently (one
used it a few years ago
On 11/15/2013 03:35 AM, Ciaran McCreesh wrote:
> On Thu, 14 Nov 2013 20:07:39 +0100
> Thomas Sachau wrote:
>> - multilib-portage was planned to add features with a future EAPI
>> version, so in the end needs agreement from maintainers of package
>> managers, the pms team and the council. If anyone
On 11/15/2013 01:51 AM, Michał Górny wrote:
>>> So tell me, what you exactly want or need? Or is it just bare
>>> complaining for the sake of complaining?
>>
>> Well, you accidentally cut out all references to TommyD's work again.
>> Almost as if you don't even want to discuss a working proper sol
On Thu, 14 Nov 2013 20:07:39 +0100
Thomas Sachau wrote:
> - multilib-portage was planned to add features with a future EAPI
> version, so in the end needs agreement from maintainers of package
> managers, the pms team and the council. If anyone from those groups
> only claims "you wrote so much, b
Rich Freeman schrieb:
> On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote:
>>
>> So just "fix it as problems appear and/or we have some spare time" ...
>
> Have any problems appeared that impact anybody who hasn't tried to
> take advantage of the new multilib features (ie modified their config
Dnia 2013-11-14, o godz. 20:03:36
Patrick Lauer napisał(a):
> On 11/14/2013 01:13 PM, Michał Górny wrote:
> > https://wiki.gentoo.org/wiki/Multilib_porting_status
> >
> > That's the closest thing to a roadmap.
>
> So just "fix it as problems appear and/or we have some spare time" ...
You could
On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot wrote:
> I was particularly hit by this as maintainer of freetype, see bugs
> 455070 and 459352 for some of the mess that could have been avoided.
Looks like 455070 was the source of problems there (the other is just
a tracker with the aftermath). T
On 14 November 2013 23:12, Rich Freeman wrote:
> On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot wrote:
>>> I said
>> As it is always happy to point out, Council doesn't see itself as
>> leadership, just as a supreme court of appeal, when everything else
>> seems to have failed. It likes to get in
On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot wrote:
>> I said
> As it is always happy to point out, Council doesn't see itself as
> leadership, just as a supreme court of appeal, when everything else
> seems to have failed. It likes to get involved as little as possible.
The last time I talked
On 14 November 2013 20:32, Rich Freeman wrote:
> On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote:
>> On 14 November 2013 13:13, Michał Górny wrote:
>>>
>>> And how is it possible to discuss anything properly in Gentoo?
>>
>> That's because we have no proper leadership. We're an anarchistic
>
On Thu, Nov 14, 2013 at 7:30 AM, Patrick Lauer wrote:
>
> Apart from me masking a few things because portage couldn't figure out a
> way to a consistent state, and all that ...
That is vague. It may be true, but it does nothing to help anybody
understand what is going on. I haven't had to mask
On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote:
> On 14 November 2013 13:13, Michał Górny wrote:
>>
>> And how is it possible to discuss anything properly in Gentoo?
>
> That's because we have no proper leadership. We're an anarchistic
> collection of people working at cross-purposes at the
On 11/14/2013 08:13 PM, Rich Freeman wrote:
> On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote:
>>
>> So just "fix it as problems appear and/or we have some spare time" ...
>
> Have any problems appeared that impact anybody who hasn't tried to
> take advantage of the new multilib features (ie
On 14 November 2013 13:13, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>> > It's also worth pointing out that the whole reason why abi_x86_32 is
>> > {package.,}use.stable.masked is because trying to m
On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote:
>
> So just "fix it as problems appear and/or we have some spare time" ...
Have any problems appeared that impact anybody who hasn't tried to
take advantage of the new multilib features (ie modified their config
files/etc)?
>
> Well, you acci
On 11/14/2013 01:13 PM, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>>> It's also worth pointing out that the whole reason why abi_x86_32 is
>>> {package.,}use.stable.masked is because trying to manage
Dnia 2013-11-14, o godz. 07:49:55
Patrick Lauer napisał(a):
> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>
> > It's also worth pointing out that the whole reason why abi_x86_32 is
> > {package.,}use.stable.masked is because trying to manage the partial
> > transisition between emul-* and mu
On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies
^^
Why is there a partial random transition
On Wed, Nov 13, 2013 at 10:02 AM, Ian Stakenvicius wrote:
> It's also worth pointing out that the whole reason why abi_x86_32 is
> {package.,}use.stable.masked is because trying to manage the partial
> transisition between emul-* and multilib-build dependencies on stable
> or mixed-keyworded syste
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/13 09:10 AM, Michał Górny wrote:
>>
>> 1. For several reasons I always want the most current
>> emul-linux-x86* libraries, so they are in
>> package.accept_keywords. Due to global ABI_X86=32 (which I also
>> want), this forced me of course
Dnia 2013-11-13, o godz. 10:28:02
Martin Vaeth napisał(a):
> As I understand, it tries to solve a "social" issue
> (that an ARCH user might set a USE-flag which eventually
> pulls in an ~ARCH package) on a technical level
> (by forcibly disabling the USE-flag for the user).
> Solving social probl
On Wed, 13 Nov 2013 08:37:51 -0500
Rich Freeman wrote:
> That said, your original email contained a few separate issues and
> they're probably best dealt with individually.
Just to set things straight: Note that these were different authors.
> We're not going to have a common solution for multi
On Wed, 13 Nov 2013 14:25:11 +0100
Thomas Kahle wrote:
> Hi,
>
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> > On Wed, 13 Nov 2013 10:28:02 + (UTC)
> > Martin Vaeth wrote:
> >
> >> Hello.
> >>
> >> The new "features" use.stable.mask and package.use.stable.mask
> >> have turned maintaining
On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle wrote:
> On 11/13/2013 12:39 PM, Tom Wijsman wrote:
>> On Wed, 13 Nov 2013 10:28:02 + (UTC)
>> Martin Vaeth wrote:
>>
>>> Hello.
>>>
>>> The new "features" use.stable.mask and package.use.stable.mask
>>> have turned maintaining systems with mixed
Hi,
On 11/13/2013 12:39 PM, Tom Wijsman wrote:
> On Wed, 13 Nov 2013 10:28:02 + (UTC)
> Martin Vaeth wrote:
>
>> Hello.
>>
>> The new "features" use.stable.mask and package.use.stable.mask
>> have turned maintaining systems with mixed ARCH and ~ARCH keywords
>> into a nightmare:
>
> They ar
On Wed, 13 Nov 2013 10:28:02 + (UTC)
Martin Vaeth wrote:
> Hello.
>
> The new "features" use.stable.mask and package.use.stable.mask
> have turned maintaining systems with mixed ARCH and ~ARCH keywords
> into a nightmare:
They are considered unsupported by many; so, going down that path you
Hello.
The new "features" use.stable.mask and package.use.stable.mask
have turned maintaining systems with mixed ARCH and ~ARCH keywords
into a nightmare:
Similarly to the (fortunately dropped) concept of forcing
useflags if certain packages are installed this forces a
magic on the user which can
61 matches
Mail list logo
