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 yng...@gentoo.org 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:
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
unnecessarily
On Sat, 16 Nov 2013 10:11:47 +0100
Ulrich Mueller u...@gentoo.org 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
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 yng...@gentoo.org 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
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
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 :
On Sat, 16 Nov 2013 11:29:20 +
Markos Chandras hwoar...@gentoo.org 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 Changes
2013/11/16 Tom Wijsman tom...@gentoo.org
On Sat, 16 Nov 2013 11:29:20 +
Markos Chandras hwoar...@gentoo.org 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
Pacho Ramos pa...@gentoo.org 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
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 good
Dnia 2013-11-16, o godz. 12:39:37
Martin Vaeth va...@mathematik.uni-wuerzburg.de napisał(a):
Pacho Ramos pa...@gentoo.org 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
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. 13:50:11
Andreas K. Huettel dilfri...@gentoo.org 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
On Sat, 16 Nov 2013, Tom Wijsman wrote:
On Sat, 16 Nov 2013 11:29:20 +
Markos Chandras hwoar...@gentoo.org 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
On Sat, 16 Nov 2013 14:40:34 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Sat, 16 Nov 2013, Tom Wijsman wrote:
On Sat, 16 Nov 2013 11:29:20 +
Markos Chandras hwoar...@gentoo.org wrote:
I think this is unnecessary. Infra requested all new projects to
be in the Wiki so I don't
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
+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
On 17 November 2013 01:39, Martin Vaeth
va...@mathematik.uni-wuerzburg.de 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
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-portage
Dnia 2013-11-17, o godz. 09:24:26
Kent Fredric kentfred...@gmail.com napisał(a):
On 17 November 2013 01:39, Martin Vaeth
va...@mathematik.uni-wuerzburg.de wrote:
This is really a severe restriction since the motivation
for installation can be very different for these variants.
For
On 17 November 2013 10:52, Michał Górny mgo...@gentoo.org 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 ? (
21 matches
Mail list logo
