On 17 November 2013 10:52, Michał Górny wrote:
> Unless I'm misunderstanding something, you are not correct.
>
> You can surely do something like:
>
> RDEPEND="abi_x86_32? ( dev-libs/c[abi_x86_32(-)] )"
It was more you cant do
IUSE="foo"
without doing
RDEPEND=" abi_x86_32? ( foo ? ( dev-lib
Dnia 2013-11-17, o godz. 09:24:26
Kent Fredric napisał(a):
> On 17 November 2013 01:39, Martin Vaeth
> wrote:
> >
> > This is really a severe restriction since the motivation
> > for installation can be very different for these variants.
> > For instance, for a native ffmpeg the user might want
Martin Vaeth posted on Sat, 16 Nov 2013 12:39:37 + as excerpted:
> A "cleaner" solution would somehow treat the 32bit and 64bit variant
> like separate packages, each having its own set of USE-Flags, and also
> the possibility to rebuild one without rebuilding the other. AFAIK
> multilib-porta
On 17 November 2013 01:39, Martin Vaeth
wrote:
>
> This is really a severe restriction since the motivation
> for installation can be very different for these variants.
> For instance, for a native ffmpeg the user might want support
> for a lot of codecs/devices while for the 32 bit variant
> the
+1
I was an user very interested by the bug day event, but the timing was
never right. A permanent effort where everyone can help whenever they
can seems more interesting. The only thing needed then is documentation
on exactly what can be done by users with varying skills.
Damien
On 11/16/2013 0
On 11/16/2013 04:11 AM, Ulrich Mueller wrote:
On Fri, 15 Nov 2013, Robin H Johnson wrote:
Add this line to the dev-lang/python-exec ebuilds:
PDEPEND=">=dev-python/python-exec-1:$SLOT"
This looks wrong to me. On a newly installed system, currrently only
dev-lang/python-exec:2 would be instal
On Sat, 16 Nov 2013 14:40:34 +0100
Ulrich Mueller wrote:
> > On Sat, 16 Nov 2013, Tom Wijsman wrote:
>
> > On Sat, 16 Nov 2013 11:29:20 +
> > Markos Chandras wrote:
> >> I think this is unnecessary. Infra requested all new projects to
> >> be in the Wiki so I don't think that you are su
> On Sat, 16 Nov 2013, Tom Wijsman wrote:
> On Sat, 16 Nov 2013 11:29:20 +
> Markos Chandras wrote:
>> I think this is unnecessary. Infra requested all new projects to be in
>> the Wiki so I don't think that you are supposed to add a proj/en page
>> anymore just so you can redirect it to
Dnia 2013-11-16, o godz. 13:50:11
"Andreas K. Huettel" napisał(a):
> Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
>
> > Probably a lot of the confusion could be avoided if
> > /etc/portage/package.accept_keywords would not implicitly
> > unmask useflags.
>
> How would you handl
Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> Probably a lot of the confusion could be avoided if
> /etc/portage/package.accept_keywords would not implicitly
> unmask useflags.
How would you handle the case if a package has only one version in portage and
that one is stable?
Dnia 2013-11-16, o godz. 12:39:37
Martin Vaeth napisał(a):
> Pacho Ramos wrote:
> >
> >> > 3: multilib.eclass
> >> >
> >
> > This is my preferred solution
>
> However, it has some serious drawbacks; most importantly:
> It implies that the same USE-flags must be used for the
> native and 32-bit
Am Freitag, 15. November 2013, 21:18:03 schrieb Martin Vaeth:
> If this is not very hard to implement in portage, I would
> strongly vote to remove this implicit connection:
Not really doable since this is explicitly defined as such in EAPI=5 PMS.
Retroactively changing PMS is probably not a goo
Pacho Ramos wrote:
>
>> > 3: multilib.eclass
>> >
>
> This is my preferred solution
However, it has some serious drawbacks; most importantly:
It implies that the same USE-flags must be used for the
native and 32-bit variant.
This is really a severe restriction since the motivation
for installati
2013/11/16 Tom Wijsman
> On Sat, 16 Nov 2013 11:29:20 +
> Markos Chandras wrote:
>
> >
> > I think this is unnecessary. Infra requested all new projects to be in
> > the Wiki so I don't think that you are supposed to add a proj/en page
> > anymore just so you can redirect it to the Wiki
>
>
On Sat, 16 Nov 2013 11:29:20 +
Markos Chandras wrote:
> On 11/16/2013 10:27 AM, Tom Wijsman (tomwij) wrote:
> > tomwij 13/11/16 10:27:43
> >
> > Added:index.xml
> > Log:
> > Initial project directory for the Bug Cleaners project.
> >
> > Revision ChangesPath
On 11/16/2013 10:27 AM, Tom Wijsman (tomwij) wrote:
> tomwij 13/11/16 10:27:43
>
> Added:index.xml
> Log:
> Initial project directory for the Bug Cleaners project.
>
> Revision ChangesPath
> 1.1 xml/htdocs/proj/en/bug-cleaners/index.xml
>
> file :
Hello
This is a request for comments on a new project:
http://wiki.gentoo.org/wiki/Project:Bug_Cleaners
The Gentoo Bug Cleaners project aims to clean up the oldest bugs in
Bugzilla. Our goal is twofold, the main purpose of this project is to
close bugs on Bugzilla that do no longer apply due to
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
On Sat, 16 Nov 2013 10:11:47 +0100
Ulrich Mueller wrote:
> > On Fri, 15 Nov 2013, Robin H Johnson wrote:
>
> > Add this line to the dev-lang/python-exec ebuilds:
> > PDEPEND=">=dev-python/python-exec-1:$SLOT"
>
> This looks wrong to me. On a newly installed system, currrently only
> dev
> On Fri, 15 Nov 2013, Robin H Johnson wrote:
> Add this line to the dev-lang/python-exec ebuilds:
> PDEPEND=">=dev-python/python-exec-1:$SLOT"
This looks wrong to me. On a newly installed system, currrently only
dev-lang/python-exec:2 would be installed. Adding above PDEPEND would
unnece
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-*
21 matches
Mail list logo
