waltd...@waltdnes.org writes:
> Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?
Yes. X/xorg could be needed to incorporate the X Client libraries so
On Wed, 1 Jun 2016 22:13:24 -0400
waltd...@waltdnes.org wrote:
> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
>
> > waltd...@waltdnes.org wrote:
> >
> > > I see this as at least a redundancy, if not a problem. First, let's
> > > look at the general case. An optional "UI" (
On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> waltd...@waltdnes.org wrote:
>
> > I see this as at least a redundancy, if not a problem. First, let's
> > look at the general case. An optional "UI" (User Interface) is also
> > selected...
> > * via the "tools" useflag 78 times
Due to a lack of time and the fact I don't use any of these packages anymore,
they are all up for grabs.
- media-gfx/openmesh [no project]
- sys-cluster/ganglia [cluster]
- sys-cluster/ganglia-web [cluster]
- sys-cluster/torque [cluster]
- sys-cluster/munge [cluster] dependency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On June 1, 2016 6:46:28 AM PDT, Mart Raudsepp wrote:
>Ühel kenal päeval, K, 01.06.2016 kell 15:18, kirjutas Dirkjan Ochtman:
>> On Wed, Jun 1, 2016 at 3:09 PM, Michał Górny
>> wrote:
>> > Excuse me but are you really serious? We are in this swamp b
I'll start with the easy one first. A new version is attached.
On 06/01/2016 01:53 PM, Michał Górny wrote:
>> +
>> +[[ -z ${MY_PV} ]] && MY_PV=${PV}
>
> Is MY_PV part of the API? If yes, document it, and preferably rename
> into something more collision-proof. If not, you shouldn't be doing
> [[
Ühel kenal päeval, K, 01.06.2016 kell 20:24, kirjutas Martin Vaeth:
> Gentoo has chosen this name so that as a side effect of setting
> USE=linguas_* you also get a correct LINGUAS variable exported
> (according to the USE-settings and your settings and according
> to the ebuild's IUSE.)
> These ar
Kent Fredric wrote:
> On 2 June 2016 at 07:33, Martin Vaeth wrote:
>>
>> I prefer to have at least 5% of the ebuilds working and the other
>> being fixable (if their maintainers want to spend the effort)
>> than to remove a concept which breaks also these 5% and turns
>> all ebuilds non-fixable,
Raymond Jennings wrote:
>
> I'd honestly as a minor issue like ot know why we called it linguas in the
> first place.
> [...]
> I think though I should also point out...don't we already have existing
> ebuilds that expose LINGUAS options in their USE flags?
>From this posting, it is obvious that
On 2 June 2016 at 07:33, Martin Vaeth wrote:
>
> I prefer to have at least 5% of the ebuilds working and the other
> being fixable (if their maintainers want to spend the effort)
> than to remove a concept which breaks also these 5% and turns
> all ebuilds non-fixable, in principle.
Changing the
Michał Górny wrote:
>
> If more than 95% of ebuilds are broken, this proves that a concept is
> broken.
>
> Well, feel free to live in your fairy land.
I prefer to have at least 5% of the ebuilds working and the other
being fixable (if their maintainers want to spend the effort)
than to remove a
On Wed, 1 Jun 2016 18:18:53 + (UTC)
Martin Vaeth wrote:
> Michał Górny wrote:
> >
> > Do you have any numbers on how many ebuilds were exactly being fixed?
> > And how many were broken in the process because someone failed to
> > update linguas_*?
>
> Broken ebuilds are a reason to fix th
Michał Górny wrote:
> Dnia 31 maja 2016 23:34:07 CEST, "Jörg Schaible"
> napisał(a):
>>How can I select different linguas for individual packages with this
>>approach?
>
> Using the currently available mechanisms you could use package.env to
> alter INSTALL_MASK, e.g.:
>
> /etc/portage/env/germ
Michał Górny wrote:
>
> Do you have any numbers on how many ebuilds were exactly being fixed?
> And how many were broken in the process because someone failed to
> update linguas_*?
Broken ebuilds are a reason to fix the ebuilds, but not a reason
to replace a working concept by a hack which only
On Wed, 1 Jun 2016 13:53:31 -0400
waltd...@waltdnes.org wrote:
> On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote
>
> > It is meant as a feature based USE flag, as opposed to the "extra dep"
> > based USE flags we've been using for this.
> > There are a lot of those with USE=gtk righ
On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote
> It is meant as a feature based USE flag, as opposed to the "extra dep"
> based USE flags we've been using for this.
> There are a lot of those with USE=gtk right now. In many cases it's
> some little add-on graphical utility for a lib
On Wed, 1 Jun 2016 12:53:38 -0400
Michael Orlitzky wrote:
> The php-ext-pecl eclasses are based mainly on the php-ext-source
> eclasses. Now that we have a new revision php-ext-source-r3.eclass,
> this new revision of php-ext-pecl inherits that. As a result, all of
> the changes affecting that r
What about a global "default gui" somewhere in make.conf that says what GUI
to use if a package provides multiple?
Relatedly, I also like having a general "qt" USE flag to select any/the
best version of qt, and then having "qtX' for each version of qt...ditto
for gtk and gtkX
On Wed, Jun 1, 2016
On Wed, 1 Jun 2016 12:53:37 -0400
Michael Orlitzky wrote:
> This is a new revision of the php-ext-source eclass that supports
> EAPI=6 (only) and cleans up some of the existing code. The list of
> user-facing changes is,
>
> * Support only EAPI=6.
>
> * PATCHES array/variable support.
>
>
# Michael Palimaka (1 Jun 2016)
# Ancient. Unused. Dead upstream. Masked for removal in 30 days.
# Bug 584374.
sys-libs/libfreevec
# Michael Palimaka (1 Jun 2016)
# Obsolete package. Masked for removal in 30 days. Bug 584454.
app-admin/sulfur
# Michael Palimaka (1 Jun 2016)
# Depends on vulnerable slot of net-libs/webkit-gtk. Dead upstream.
# Masked for removal in 30 days. Bug 584164.
net-print/foomatic-gui
On Wed, 1 Jun 2016 16:27:16 + (UTC)
Martin Vaeth wrote:
> Michał Górny wrote:
> >>
> >>Therefore, I suggest to put this line in l10n.eclass
> >>(perhaps with a mechanism to avoid it for some exceptional packages
> >>which have to treat LINGUAS differently.)
> >>This way, none of these ebuild
On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:
> On 01/06/16 11:19 AM, NP-Hardass wrote:
>> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>>> Hello,
>>>
>>> So here's something more simple wrt GUI USE flags.
>>>
>>> Global USE=gui for
>>> gui - enable an optional graphics user interface or extra GU
On 06/01/2016 09:21 AM, Michał Górny wrote:
> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp wrote:
>
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements w
The php-ext-pecl eclasses are based mainly on the php-ext-source
eclasses. Now that we have a new revision php-ext-source-r3.eclass,
this new revision of php-ext-pecl inherits that. As a result, all of
the changes affecting that revision also affect this one. A migration
guide for users can be foun
This is a new revision of the php-ext-source eclass that supports
EAPI=6 (only) and cleans up some of the existing code. The list of
user-facing changes is,
* Support only EAPI=6.
* PATCHES array/variable support.
* DOCS array support (bug 512184).
* Renamed my_conf and PHPSAPILIST vari
I've tried to keep these two new revisions mostly compatible with the
old ones. I performed some code cleanup, but nothing that should
affect users too badly (all updates should be trivial and make your
ebuilds smaller).
Most of the meat is in php-ext-source-r3.eclass. The other eclass simply
inhe
On 01/06/16 11:19 AM, NP-Hardass wrote:
> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> Essentially, if it's an optional GUI, it'd b
On 06/01/2016 12:21 PM, Michał Górny wrote:
> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp wrote:
>
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements w
Michał Górny wrote:
>>
>>Therefore, I suggest to put this line in l10n.eclass
>>(perhaps with a mechanism to avoid it for some exceptional packages
>>which have to treat LINGUAS differently.)
>>This way, none of these ebuilds inheriting l10n needs to be patched.
>
> This eclass should be killed wi
On Wed, 01 Jun 2016 17:29:55 +0300
Mart Raudsepp wrote:
> Hello,
>
> So here's something more simple wrt GUI USE flags.
>
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
>
> (wording improvements welcome, once it's in principle agreed; but no
> point i
On June 1, 2016 7:29:55 AM PDT, Mart Raudsepp wrote:
>Hello,
>
>So here's something more simple wrt GUI USE flags.
>
>Global USE=gui for
>gui - enable an optional graphics user interface or extra GUI tool
>
>(wording improvements welcome, once it's in principle agreed; but no
>point in bikeshed pa
I'd honestly as a minor issue like ot know why we called it linguas in the
first place. Linguas itself is latin/romance based in name, so gentoo at
least has been showing a bit of a bias.
Personally I think its a bad name on neutrality grounds alone.
I think though I should also point out...don'
On 2016-06-01 11:19 AM, NP-Hardass wrote:
On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
Hello,
So here's something more simple wrt GUI USE flags.
Global USE=gui for
gui - enable an optional graphics user interface or extra GUI tool
Essentially, if it's an optional GUI, it'd be behind a USE=gu
On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
> Hello,
>
> So here's something more simple wrt GUI USE flags.
>
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
>
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X
Hello,
So here's something more simple wrt GUI USE flags.
Global USE=gui for
gui - enable an optional graphics user interface or extra GUI tool
(wording improvements welcome, once it's in principle agreed; but no
point in bikeshed painting description wording till it is)
Local USE flag descript
Dnia 1 czerwca 2016 16:03:40 CEST, Mart Raudsepp napisał(a):
>Ühel kenal päeval, K, 01.06.2016 kell 15:19, kirjutas Michał Górny:
>> As for LINGUAS, it should be left as a toy for advanced users and not
>> presented as a recommended solution.
>
>There is nothing advanced in it for the user, only t
Ühel kenal päeval, K, 01.06.2016 kell 15:19, kirjutas Michał Górny:
> As for LINGUAS, it should be left as a toy for advanced users and not
> presented as a recommended solution.
There is nothing advanced in it for the user, only the mess we have
created with package manager behaviour and mis-use
Ühel kenal päeval, K, 01.06.2016 kell 15:18, kirjutas Dirkjan Ochtman:
> On Wed, Jun 1, 2016 at 3:09 PM, Michał Górny
> wrote:
> > Excuse me but are you really serious? We are in this swamp because
> > someone tried to be too smart. And what solution do you propose?
> > Let's add another layer of
Dnia 1 czerwca 2016 11:23:09 CEST, Martin Vaeth napisał(a):
>Michał Górny wrote:
>>
>> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
>> in Portage.
>
>As already mentioned by some, INSTALL_MASK is something else than
>LINGUAS, because LINGUAS involves also files which are ge
On Wed, Jun 1, 2016 at 3:09 PM, Michał Górny wrote:
> Excuse me but are you really serious? We are in this swamp because someone
> tried to be too smart. And what solution do you propose? Let's add another
> layer of complexity and smartness, for a single variable. Obviously nothing
> can go wr
Dnia 1 czerwca 2016 11:18:30 CEST, Mart Raudsepp napisał(a):
>Ühel kenal päeval, T, 31.05.2016 kell 14:49, kirjutas Michał Górny:
>> Since the previous thread doesn't seem to have brought any good
>> solution to the problem other than stopping to (ab)use LINGUAS
>> as USE_EXPAND, I would like to s
Dnia 31 maja 2016 23:34:07 CEST, "Jörg Schaible"
napisał(a):
>How can I select different linguas for individual packages with this
>approach?
Using the currently available mechanisms you could use package.env to alter
INSTALL_MASK, e.g.:
/etc/portage/env/german:
INSTALL_MASK="@l10n -@l10n-d
# Aaron Bauman (1 Jun 2016)
# Masked for removal in 30 days. Unpatched security
# vulnerabilities per bug #453308.
net-irc/atheme-services
Ühel kenal päeval, K, 01.06.2016 kell 12:18, kirjutas Mart Raudsepp:
> Ühel kenal päeval, T, 31.05.2016 kell 14:49, kirjutas Michał Górny:
> > Since the previous thread doesn't seem to have brought any good
> > solution to the problem other than stopping to (ab)use LINGUAS
> > as USE_EXPAND, I woul
Michał Górny wrote:
>
> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
> in Portage.
As already mentioned by some, INSTALL_MASK is something else than
LINGUAS, because LINGUAS involves also files which are generated
by the build system. Although I appreciate a more configurab
Ühel kenal päeval, T, 31.05.2016 kell 14:49, kirjutas Michał Górny:
> Since the previous thread doesn't seem to have brought any good
> solution to the problem other than stopping to (ab)use LINGUAS
> as USE_EXPAND, I would like to start a RFC on a draft solution that
> I'd like afterwards to propo
48 matches
Mail list logo
