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
On Fri, Nov 15, 2013 at 11:27:33PM +0100, Tom Wijsman wrote:
> > If there are no objections, I'd like to do this to the affected
> > ebuilds in a few hours.
> It is an improvement and it has been tested on a few systems; I don't
> think this is something that would hurt or be irreversible, it rever
On Fri, 15 Nov 2013 22:06:45 +
"Robin H. Johnson" wrote:
> On Wed, Nov 06, 2013 at 04:12:47PM +0100, Michał Górny wrote:
> > Please review the following news item. I would prefer committing it
> > as soon as I get an ACK from all the relevant parties since the
> > issue is hitting users prett
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
On Wed, Nov 06, 2013 at 04:12:47PM +0100, Michał Górny wrote:
> Please review the following news item. I would prefer committing it
> as soon as I get an ACK from all the relevant parties since the issue
> is hitting users pretty hard.
I don't know why nobody looked at a better automatic solution
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
Martin Vaeth wrote:
> Probably a lot of the confusion could be avoided if
> /etc/portage/package.accept_keywords would not implicitly
> unmask useflags.
I think so too.
Anything that happens implicitly where explicit knobs exist is really
counter-intuitive.
//Peter
Ian Stakenvicius wrote:
> On 15/11/13 10:54 AM, Peter Stuge wrote:
>> ..
>>> 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 lot can be learned just from the filenames:
>> [...]
>> The latter indi
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 15.11.2013 20:12, yac wrote:
> Hi
>
> What does Gentoo Linux provide for $SUBJ?
>
> I know there are mailing lists like gentoo-user-. Is there
> anything else?
-project is where you wanted to post this
>
> ---
> Jan Matějka| Gentoo Developer
> https://gentoo.org | Gentoo Linux
> GPG
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
El jue, 14-11-2013 a las 22:22 +0100, Pacho Ramos escribió:
> New try:
>
> Title: Upgrade to GNOME 3.8
> Author: Pacho Ramos
> Content-Type: text/plain
> Posted: 2013-11-14
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: Display-If-Installed: Display-If-Installed:
> We are pleas
-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)
Hi
What does Gentoo Linux provide for $SUBJ?
I know there are mailing lists like gentoo-user-. Is there
anything else?
---
Jan Matějka| Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B
signature.asc
Description: PGP signature
-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
Duncan wrote:
> 3a) Accompany binaries/object code with complete source-code.
..
> What that means is this: Every time and place gentoo distributes
> binaries, we must make available sources as well.
"accompany" !== "make available"
> If we're giving away install-CDs at a conference, we better
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
Ian Stakenvicius posted on Fri, 15 Nov 2013 09:30:56 -0500 as excerpted:
> On 15/11/13 06:08 AM, Duncan wrote:
>> [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or
>> either one for x86-32, or some other combination for other archs.
>
> Well, not really -- an x86 toolchain can't
Rich Freeman posted on Fri, 15 Nov 2013 08:38:20 -0500 as excerpted:
> That's what I'm getting at. The actual changes themselves aren't a
> derivative work - it is the result of applying them that is.
I can (cautiously) agree with that, tho I'm sure there are those who
would take an opposing po
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/11/13 06:08 AM, Duncan wrote:
> [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or
> either one for x86-32, or some other combination for other archs.
Well, not really -- an x86 toolchain can't build for amd64 or x32 ,
you need
-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 8:17 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> To the extent patches are larger than the rather blurry "trivial" level,
> I believe there's no question that they ARE derivative. In the case of
> literal patches, literally and provably so, due to the context-diff which
> li
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.
Rich Freeman posted on Wed, 13 Nov 2013 16:18:51 -0500 as excerpted:
> On Wed, Nov 13, 2013 at 3:49 PM, Roy Bamford
> wrote:
>> The GPL obliges us to keep such patches around for three years, iirc.
>> Don't we do that ?
>
> Why? We own the copyright on the patches (to whatever degree that
> the
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
Ulrich Mueller posted on Fri, 15 Nov 2013 08:13:47 +0100 as excerpted:
>> 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
On 11/13/2013 10:14 AM, Michael Haubenwallner wrote:
> Hi all,
>
> as you might or might not be aware of, elibtoolize() originally was for
> applying
> patches to ltmain.sh, but now also applies patches to configure scripts.
> Attached patch drops that wild guesses, explicitly applying configure
42 matches
Mail list logo
