[gentoo-dev] Non-maintainer sandbox patching

[Mart Raudsepp]

Hello,

So I provided a patch for a sandbox bug hitting bigger projects using
-export-symbols-regex with a long list of object files. 3 months ago.
Bug has been there since forever, reported 15 months ago, with some
good clues to what's up since 9 months.
It has been sitting there, collecting dust, with no action from
sandbox@ whatsoever. As such, I plan to finally non-maintainer push
this fix straight to ~arch as a sandbox-2.10 revision bump once I have
my months old GPG machine tree and system updated (this week or early
next week). And 2.11, but because that is still p.masked due to it
causing issues for XUL stuff (with analysis of what's going on also
available since a while now), that's going to be a p.masked revbump
alongside the 2.11 masks.
If I can't do my gnome-builder bumps that depends on this right away, I
might let it simmer in p.mask for some hours or days too, especially if
I see some sort of sandbox@ action appearing or some valid objections
by the time I get to it.

This is the bug I have fix for:
https://bugs.gentoo.org/show_bug.cgi?id=553092

libtool ends up running "nm -B" with the long list of object files as
arguments and saves the result in a temporary file (which it'll apply
the regex to then), but various shells in some environments (including
bash-4.3 and dash) end up trying to glob it and check if it's a dir,
calling opendir with the whole commandline as argument. If that is
longer than 8196 characters, sandbox gets confused because it
internally uses PATH_MAX*2 buffers, it gets cut and things fall over in
ways I'm not interested in finding out deeper.

At least gnome-builder-3.20+ and graphicsmagick are affected for some
(might depend on what their shell is doing).

Because of this, gnome-builder hasn't seen version bumps, while the
existing version in tree (3.18, it didn't use so many object files in
the linker line quite yet back then to trigger the bug) are completely
unusable with current stable gtksourceview and co.

So, any objections with me pushing in the sandbox revbumps?


PS: I'm sure our mozilla team would appreciate also help with sandbox
bug 580726, which is a bug in the ptrace fallback, which now gets
triggered with the p.masked sandbox 2.11 due to some inherent issues
with the default non-ptrace code that were hit in Chrome OS project
thing doing some own memory management (and so it fallbacks more often,
when it finds custom memory allocation stuff based on some heuristics).
The ptrace fallback gets now used with 2.11 for firefox and co as well
(probably due to jemalloc usage), and that fallback sandbox codepath is
apparently buggy for its more complex case. Alternatively maybe these
heuristics could be less triggerhappy to fallback to ptrace.


Mart

Re: [gentoo-dev] Re: The changes about the stabilization process

[Mart Raudsepp]

Ühel kenal päeval, N, 29.12.2016 kell 20:51, kirjutas Marc Schiffbauer:
> * Ulrich Mueller schrieb am 29.12.16 um 16:52 Uhr:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > On Thu, 29 Dec 2016, Marc Schiffbauer wrote:
> > 
> > > 
> > > I'd prefer "package versions" but the people will come up with 
> > > "sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
> > > "=sys-apps/eix-1.2.3". 
> > 
> > Why would the equals sign be needed there?
> 
> I supposed it to do because I assumed that we are not going to
> change 
> the expected values.

To my knowledge the sanity checking tool doesn't care either way.
I've been adding the = in front for now just in case it helps arch
teams to more directly copy-paste the list to their
package.accept_keywords or whatnot.
I'm sure any further tooling like "app-portage/tatt" can or will be
able to handle it either way for the arch dev too.

> But yes, propably only listing the PV would be enough.

You mean PVR, or rather $CATEGORY/$PF.


As my own worthless 2 dimes on the field naming bikeshed, I'd suggest
"Package revisions" (as opposed to just versions).


Additionally I would like such a package revision list or in this case
even ranges to be used outside stabling/keywording as well. For marking
up which package and revision fixes a given bug, as to do independent
semi-automatic tracking of bugs that still affect the stable tree. But
that's a bikeshed and discussion for next year, once the tooling that
could make good use of that gets further along and into this area of
topics. Initial thought was to have it as a separate field anyways
then, sort of like the one that shows up for RESOLVED DUPLICATE closing
of bugs, but for RESOLVED FIXED or some such. Anyways, that's for
another thread, another year :)


Mart

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Mart Raudsepp]

Ühel kenal päeval, L, 24.12.2016 kell 02:29, kirjutas Raymond Jennings:
> I hope this isn't a stupid question...but can we safely assume that
> all such google code SRC_URI's have *already* been mirrored?
> 
> If I understand the mirrors correctly, they serve as a sort of cache
> of sorts of upstream distfile sources.  Is there such a thing as a
> "cache miss" that could lead to a 404 if the mirrors themselves have
> to fetch from a dead upstream they've never fetched from before?

https://devmanual.gentoo.org/general-concepts/mirrors/

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Mart Raudsepp]

Ühel kenal päeval, K, 14.12.2016 kell 15:35, kirjutas Andrew Savchenko:
> On Wed, 14 Dec 2016 11:16:58 +0200 Mart Raudsepp wrote:
> > 
> > Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
> > > 
> > > On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> > > > 
> > > > 
> > > > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org
> > > > wrote:
> > > > > 
> > > > > 
> > > > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > > > > 
> > > > > > 
> > > > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > gpg: signing failed: Inappropriate ioctl for device
> > > > > > this might indicate a want for export GPG_TTY=$(tty)
> > > > > I don't understand what has really happened. I removed my
> > > > > last
> > > > > commit, an 
> > > > > attempt to commit it again failed with gpg: signing failed.
> > > > > Then
> > > > > I logged 
> > > > > out of the box on which I have the git tree (I log in this
> > > > > box
> > > > > via ssh), 
> > > > > and logged in again. After that the commit succeeded.
> > > > 
> > > > I was also getting some odd issues with commit signing, though
> > > > it
> > > > seemed 
> > > > to settle for me when I switched to pinentry-curses (since I
> > > > use 
> > > > awesome), so I figured it was probably a local issue. Perhaps
> > > > there's a 
> > > > wider problem here?
> > > 
> > > If anyone else is getting this, it seems to be resolved by
> > > exporting 
> > > GPG_TTY=$(tty) either immediately before attempting to sign or in
> > > your 
> > > shell ~/.*rc file.
> > 
> > I'd consider this a temporary workaround. The real issue would just
> > be
> > workarounded with this, which is nice to get something committed,
> > but
> > not so nice longterm.
> > I had similar issues, but it turned out some pinentry issues for me
> > iirc, so properly fixed by now and not needing such hackery
> > anymore.
> 
> This is not a workaround, but officially recommended practice, from
> man gpg-agent:
> 
> You should always add the following lines to your .bashrc or
> whatever initialization file is used for all shell invocations:
> 
> GPG_TTY=$(tty)
> export GPG_TTY

Then the packages or eselect pinentry or whatever should be taking care
of it, not have users have to mess with .bashrc to have stuff work.

I don't have GPG_TTY and it works fine, but I use a graphical password
asking agent.


Mart

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Mart Raudsepp]

Ühel kenal päeval, K, 14.12.2016 kell 13:08, kirjutas Sam Jorna:
> On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> > 
> > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote:
> > > 
> > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > > 
> > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > > > > 
> > > > > gpg: signing failed: Inappropriate ioctl for device
> > > > this might indicate a want for export GPG_TTY=$(tty)
> > > I don't understand what has really happened. I removed my last
> > > commit, an 
> > > attempt to commit it again failed with gpg: signing failed. Then
> > > I logged 
> > > out of the box on which I have the git tree (I log in this box
> > > via ssh), 
> > > and logged in again. After that the commit succeeded.
> > 
> > I was also getting some odd issues with commit signing, though it
> > seemed 
> > to settle for me when I switched to pinentry-curses (since I use 
> > awesome), so I figured it was probably a local issue. Perhaps
> > there's a 
> > wider problem here?
> 
> If anyone else is getting this, it seems to be resolved by exporting 
> GPG_TTY=$(tty) either immediately before attempting to sign or in
> your 
> shell ~/.*rc file.

I'd consider this a temporary workaround. The real issue would just be
workarounded with this, which is nice to get something committed, but
not so nice longterm.
I had similar issues, but it turned out some pinentry issues for me
iirc, so properly fixed by now and not needing such hackery anymore.


Mart

Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

[Mart Raudsepp]

Ühel kenal päeval, T, 06.12.2016 kell 20:59, kirjutas james:
> 
> So I just now sent email to :
> proxy-maint+subscr...@gentoo.org
> 
> 
> NO answer on this attempt. ON this page::
> https://www.gentoo.org/get-involved/mailing-lists/all-lists.html
> 
> All I see is: gentoo-proxy-maint
> 
> Am I subscribe?  Did I miss the exact syntax to get subscribed?
> 
> Perhaps proxy-ma...@gentoo.org needs to be listed with the rest of
> the mailing lists?

proxy-ma...@gentoo.org is a mail alias, not a mailing list, you can't
subscribe to that.
gentoo-proxy-ma...@gentoo.org is the mailing list.

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Mart Raudsepp]

Ühel kenal päeval, R, 02.12.2016 kell 11:26, kirjutas Matt Turner:
> On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko 
> wrote:
> > 
> > Hi all!
> > 
> > Right now we have two somewhat conflicting policies (at least up to
> > my understanding of them):
> > 
> > 1) git atomic commits [1]:
> > each logical change should be a separate commit.
> > 
> > 2) revision bump policy [2]:
> > each change sufficiently affecting application run-time or
> > installed files should have a revision bump.
> > 
> > Let's consider the following quite common scenario: package foo-1.0
> > should be updated to foo-1.1, but aside from version bump there is
> > a set of accumulated issues which maintainer is willing to handle,
> > e.g.:
> > - bump to EAPI 6;
> > - fix several runtime bugs (still present in the new version);
> > - install missing documentation;
> > - add previously omitted USE flags for some tools of controllable
> > functionalities;
> > - etc...
> > 
> > If both policies are to be followed, users will see something like:
> > foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> > a separate commit with a revision bump).
> > 
> > While such versioning change is technically correct, it is
> > confusing for our users and makes future maintainance harder,
> > because of multiple file renames (yeah, I know about git diff
> > --find-renames, but this kludge is not perfect).
> > 
> > What about the following forkflow:
> > - version bump first with minimal changes required, but without
> > pushing commit to the tree;
> > - make each logical change as a separate commit without revision
> > bumps and without pushing stuff to the tree (of course repoman
> > scan/full is required as usual for each commit);
> > - well test package after the last commit (that it builds with
> > various USE flag combinations, old and new functionality works fine
> > and so on);
> > - fix any problems found and only afterwards push changes to the
> > tree.
> > 
> > This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> > while git will still retain each logical change as a separate
> > commit, which will make future maintenance and debugging much
> > easier.
> > 
> > Of course a separate git branch may be used as well, but using
> > branches for each half-a-dozen set of commits looks like an
> > overkill to me.
> > 
> > Thoughts, comments?
> 
> Thanks for starting the discussion. I completely agree.
> 
> Though my case might have been a bit more clear-cut since I was
> working on an ebuild that initially didn't have any KEYWORDS, I think
> what I did for freeradius is the best way of handling the situation
> you describe.
> 
> See 97704b400b7^..e84dc52a816
> 
> An initial commit that copied the 3.0.12 ebuild to 3.0.12-r1 without
> making any other changes, followed by three self-contained
> fixes/commits, and finally a patch to add KEYWORDS to 3.0.12-r1.
> 

That makes me think that it might be an idea to have no KEYWORDS on the
intermediate commits. So removing them at first for the -r1 copy in tis
example, even if -r0 had them, and then after all is done add back
~arch ones.
Just an idea, not even sure I think it's a good idea myself.

Re: [gentoo-dev] Uppercase characters in package names

[Mart Raudsepp]

Ühel kenal päeval, R, 02.12.2016 kell 13:02, kirjutas Mike Gilbert:
> The devmanual states:
> 
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
> Why are uppercase characters strongly discouraged?
> 
> Wouldn't it make sense to follow upstream's naming convention?

It's much easier to just write all in lowercase for emerge, because it
is case sensitive and won't directly work (only hopefully show how it's
capitalized in the suggestions it prints if no direct match is found).
So usually lowercase means there's no guessing which happens to be
upper case to feed to emerge.
Less important for stuff people usually don't install, but are usually
only pulled in as a dependency of something.

Re: [gentoo-dev] Please retain authorship of contributed patches

[Mart Raudsepp]

Ühel kenal päeval, K, 30.11.2016 kell 21:23, kirjutas Andrey Utkin:
> My PR: https://github.com/gentoo/gentoo/pull/2765
> 
> My bugzilla ticket linked to it:
> https://bugs.gentoo.org/show_bug.cgi?id=599088
> 
> After my pull request from Nov 6, the following commit gets into
> mainline:
> 
> commit e19f46dfca967f4195eedf3f37a7882fbb37b796
> Author: Matthew Thode 
> Date:   Tue Nov 15 13:55:17 2016 -0600
> 
> dev-python/secretstorage: adding for keyring
> 
> Package-Manager: portage-2.3.0
> 
> 
> The difference between my submission and final variant by Matthew is
> big
> in number of lines, but is trivial in content as you can see below,
> so I
> don't believe that Matthew has written his variant from scratch on
> his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.

The diff posted shows almost the maximum amount of differences possible
for an ebuild of this kind imho. There literally is nothing else than
usage of eclasses and listing of depends, and all the spacing and some
order is different even there. If I go and create an ebuild from
scratch without being aware at all of any other ebuild for it being
there and never having looked at either, it would probably be either
identical to yours, or identical to Matthew's.
So I would say it is entirely possible he simply did not know of the
existing work and just created a simple ebuild from scratch.
This work itself is something I wouldn't even consider copyrightable
(as mentioned in some other threads on that topic).

That said, if the existing work was being based on, attribution should
have been done, but that's something only he knows if he looked at your
work or not. He seems to have had to add it as a keyring dep; given
it's simplicity, might have just done the ebuild from scratch in 5
minutes.
At least after (or rather before) doing the work, searching for
existing bugzilla bugs for that package would have been nice.

The first occurrence seems to have more merit for concern, as it is a
recorded fact that your work was looked upon for doing it. However it
does give credit in the commit message (even summary), just no
authorship information towards you in git metadata, as your ideas were
taken and rewritten (new authorship) on top of existing release ebuild
and credited as a link to the PR. For perfection, a Thanks tag or some
other tag towards you (Cc?) by name and e-mail would have been nice,
though.

Overall, it is very appreciated you are contributing, and it does bring
up a topic we should be more careful about in general. Maybe some
documentation and part of quizzes for push access even.
Though the individual cases here brought as example seem not a big
point of concern (in one case a credit was given, in a way; in the
other it might have been very well individual work), but I do think
there could very easily be cases of developers taking someone's work
and not thinking of proper attribution, even if just from not thinking
about it.



Thanks for your contributions!


Mart

Re: [gentoo-dev] Gentoo Staffing Needs page is out of date

[Mart Raudsepp]

Ühel kenal päeval, T, 29.11.2016 kell 19:31, kirjutas Gokturk Yuksek:
> Mart Raudsepp:
> > 
> > Ühel kenal päeval, E, 28.11.2016 kell 17:45, kirjutas Gokturk
> > Yuksek:
> > > 
> > > On 11/23/2016 12:31 AM, Gokturk Yuksek wrote:
> > > > 
> > > > 
> > > > Hi all,
> > > > 
> > > > The Staffing Needs page on the wiki [0] seems a little out of 
> > > > date, there are still mentions of "herds". I invite project
> > > > leads and members to update it. We added a reference to it in
> > > > the Mentors wiki page [1] and hoping to get more attention to
> > > > it.
> > > > 
> > > > Thanks,
> > > > 
> > > > [0] https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs
> > > > [1] https://wiki.gentoo.org/wiki/Project:Mentors
> > > > 
> > > 
> > > Given the inactivity on the page since the submission of this
> > > post, I'll clear the page entirely in two days. It's better to
> > > have no information than a misleading one. Please remember to
> > > update the page with your staffing needs after the cleanup.
> > 
> > This is not some page that is just there and edited as-is. It is 
> > generated from {{Staffing Needs}} macros placed into project pages
> > and seems like individual subpages when
> > https://wiki.gentoo.org/wiki/Projec 
> > t:Gentoo/Staffing_Needs/Maintenance is used instead. Therefore I
> > doubt you can just go and clear things on that page alone, nor does
> > it mean you should clean everything without contacting the project,
> > especially those that actually have it on their project page (so
> > relatively knowingly placed there recently).
> > 
> 
> I thought about the same thing at first. A more careful look at the
> URL shows that this is not the case:
> 
> 
> https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs/ProxyMaint
> ain
> er
> 
> The {{Staffing Need}} macro page lives under "Gentoo" in project
> namespace, not under "Proxy Maintainers". As a matter of fact, the
> link has a typo where it's missing an 's' at the end.

I guess that template then just gives an additional staffing need table
to the project page when used and not synced if you say so. Would be
nice to have this automated in the way I thought it already was. This
ensures that there is a project page that advertises the staffing need
and with that a contact in the detailed page.

> I'd like to bring it to attention that there had been no activity on
> the page in a week. We should at least clear some obvious ones like
> this
> :
> 
> --
> GMN Editor/Author
> We are looking for developers or users interested in helping us out
> with the Gentoo Monthly Newsletters.
> --
> 
> This isn't even an official GMN project at the moment, there is no
> information who is in charge and it's misleading people.

That's because there is no-one to do it, but it would be nice if
someone did. So a staffing need. But yes, there should be someone to
contact for it then; maybe PR should consider adding a new staffing
need for that under their umbrella or something.

> I'll try to contact individual projects as much as I can.

Sounds good.


Mart

Re: [gentoo-dev] Gentoo Staffing Needs page is out of date

[Mart Raudsepp]

Ühel kenal päeval, E, 28.11.2016 kell 17:45, kirjutas Gokturk Yuksek:
> On 11/23/2016 12:31 AM, Gokturk Yuksek wrote:
> > 
> > Hi all,
> > 
> > The Staffing Needs page on the wiki [0] seems a little out of
> > date, there are still mentions of "herds". I invite project leads
> > and members to update it. We added a reference to it in the Mentors
> > wiki page [1] and hoping to get more attention to it.
> > 
> > Thanks,
> > 
> > [0] https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs [1]
> > https://wiki.gentoo.org/wiki/Project:Mentors
> > 
> 
> Given the inactivity on the page since the submission of this post,
> I'll clear the page entirely in two days. It's better to have no
> information than a misleading one. Please remember to update the page
> with your staffing needs after the cleanup.

This is not some page that is just there and edited as-is. It is
generated from {{Staffing Needs}} macros placed into project pages and
seems like individual subpages when https://wiki.gentoo.org/wiki/Projec
t:Gentoo/Staffing_Needs/Maintenance is used instead.
Therefore I doubt you can just go and clear things on that page alone,
nor does it mean you should clean everything without contacting the
project, especially those that actually have it on their project page
(so relatively knowingly placed there recently).


Mart

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Mart Raudsepp]

Ühel kenal päeval, N, 27.10.2016 kell 07:21, kirjutas Rich Freeman:
> On Thu, Oct 27, 2016 at 7:00 AM, Mart Raudsepp <l...@gentoo.org>
> wrote:
> > 
> > 
> > Projects that want explicit copyright or copyright assignments or
> > CLAs
> > are those that want to be able to re-license the code without
> > getting
> > permissions from everyone (some of whom might not be possible to
> > contact at a future date) or be able to sue someone for license
> > violations without the original developers of the affected parts
> > having
> > to be involved. Are we pursuing those option, or why do we care?
> 
> These are useful options to have available.  The ability to pursue
> violators would not require 100% signing of FLAs to
> work.  Relicensing
> probably would, or close to it, so that might not ever be practical
> unless FLA acceptance is very widespread.
> 
> > 
> > We don't need bogus or
> > non-bogus copyright headers, just a "Gentoo project and
> > contributors"
> > copyright notice or optionally allowing explicit ones to those that
> > want it, together with a license notice.
> 
> Actually, that isn't allowed, and was the very issue that kicked off
> the entire matter.  You can't just take somebody else's code and
> change the copyright to "Gentoo project and contributors" if the
> Gentoo project's only contribution to the file is changing the
> copyright notice.  From my reading on the topic you generally need to
> list the largest contributor on the copyright line, which may or may
> not be the Gentoo Foundation.

"and contributors" covers that, and I didn't specify "Foundation".
The copyright headers purpose is:

"Contrary to popular belief, providing a copyright notice or
registering the work with the USCO is not necessary to obtain basic
copyright protections. But there are some steps that can be taken to
enhance the creator's ability to sue or stop others from copying:"

Place a copyright notice on a published work. (...) Placing this notice
on a published work (...) prevents others from claiming that they did
not know that the work was covered by copyright. This can be important
if the author is forced to file a lawsuit to enforce the copyright,
since it is much easier to recover significant money damages from a
deliberate (as opposed to innocent) copyright infringer."

The copyright header has NO LEGAL meaning. IANAL.

> > And yes, the headers are currently completely bogus. You can
> > consider
> > it to be as such to any file I have contributed copyrightable work
> > to,
> > and the Gentoo Foundation does not have copyright to such work of
> > mine.
> 
> If you don't think your contributions are copyrighted by the Gentoo
> Foundation, you probably shouldn't be putting that statement in the
> files you commit.  I don't see why your commits are any less legally
> binding on you than your statements in emails like the one above.

The copyright header has no meaning on who holds the copyright. The
Gentoo tooling automatically puts these lines or refuses to work. Over
half of the stuff I commit is not copyrightable work in the first
place.
Me committing something with repoman commit (especially during CVS
times even doing a separate commit for this stuff) ending up with some
header doesn't mean I have done any copyright assignment. No court in
my jurisdiction would consider this to be the case. Courts in other
jurisdictions don't even recognize copyright reassignment and some not
even work for hire copyright to the company.

The header is only a tool to lower the chances of someone taking the
work inappropriately. Stop treating it as some kind of law.

> And this is why improving the policy in this space is important.


IANAL,
Mart

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Mart Raudsepp]

Ühel kenal päeval, E, 24.10.2016 kell 19:07, kirjutas Rich Freeman:
> On Mon, Oct 24, 2016 at 6:34 PM, Matt Turner 
> wrote:
> > 
> > In order to contribute to GNU projects, one must sign a copyright
> > assignment statement.
> > 
> > Gentoo doesn't have anything similar as far as I'm aware, which
> > makes
> > me question the legitimacy of "Gentoo Foundation" copyrights.
> > 
> > What is the story?
> > 
> 
> The story of what?
> 
> Are you asking whether they're legally binding?  You'd have to sue
> somebody to find out, because as far as I'm aware the matter is
> untested in court.  I think you could make an argument that
> voluntarily placing that header on your work is an assignment of
> copyright.  You could also argue otherwise.  A court would decide who
> wins.
> 
> Personally I'd rather move to an explicit system.

Why do we care about an explicit copyright system at all?
The copyright holder having licensed the work under our GPL-2 license
or a license that allows to re-license to GPL-2 is what matter to us.
That should be explicit, not chasing some explicit copyright headers
and whatnot specifically.

Projects that want explicit copyright or copyright assignments or CLAs
are those that want to be able to re-license the code without getting
permissions from everyone (some of whom might not be possible to
contact at a future date) or be able to sue someone for license
violations without the original developers of the affected parts having
to be involved. Are we pursuing those option, or why do we care?

Having all copyrightable work explicitly licensed or possible to re-
license to our chosen license is what matter. We don't need bogus or
non-bogus copyright headers, just a "Gentoo project and contributors"
copyright notice or optionally allowing explicit ones to those that
want it, together with a license notice. That's so that people looking
at some file know what license it is, etc, and not run off copying it
into their incompatible license stuff or whatever.

And yes, the headers are currently completely bogus. You can consider
it to be as such to any file I have contributed copyrightable work to,
and the Gentoo Foundation does not have copyright to such work of mine.
It may however use it under the terms of the GPL-2 license.


IANAL,
Mart

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

[Mart Raudsepp]

Ühel kenal päeval, K, 26.10.2016 kell 14:58, kirjutas Kent Fredric:
> On Tue, 25 Oct 2016 09:25:52 +0200
> Ulrich Mueller  wrote:
> 
> > 
> > And I guess that even most ebuilds for new
> > packages aren't written from scratch, but will be based on an
> > existing
> > ebuild or on some template like skel.ebuild.
> 
> You could probably argue that subsequently, every ebuild is
> essentially
> a derived work of the first ebuild, and thus, a derived work of
> Gentoo's copyright.

Please don't confuse copyright with licensing. They are completely
different things. You don't get my copyright if I derive something on
your work you allow me to with the license you've chosen for your
copyrightable work. If you did, you could then relicense everything to
a proprietary license, including my work. But you can't, because you
don't have the copyright to the code I did, because I didn't reassign
it and didn't give you a permission to do that (e.g by licensing my
code under some BSD license or signing some sort of a copyright
assignment or CLA). You might just reasonably assume I have licensed my
code under the same license the whole codebase was in, and this is what
should be explicitly known to be the case to be safer.

With GPL (and other) licenses, copyright is what gives the power to
enforce the license. Derivative work is related to the GPL license
requirement, it has (imho) nothing to do with copyright beyond
copyright law allowing to enforce the license (and copyright law basics
being adopted by most of the world via the Berne Convention).

> The format is so regularised 2 people could independently create the
> same ebuild.

These ebuilds are probably not copyrightable work in the first place.
But it's hard to judge, so people tend to assume it is to be on the
safe side.

> Not because there's any real rules to how we order things, but
> because
> people take their advice at how to write ebuilds by copying other
> existing ones.

IANAL,
Mart

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Mart Raudsepp]

Ühel kenal päeval, E, 24.10.2016 kell 15:29, kirjutas Matt Turner:
> A former co-worker of mine is now at Google and wants to contribute
> ebuilds he wrote for ChromeOS to Gentoo. They add packages necessary
> for Vulkan (new 3D graphics API).
> 
> For instance: https://chromium.googlesource.com/chromiumos/overlays/c
> hromiumos-overlay/+/master/media-libs/vulkan-loader/vulkan-loader-
> 1.0.24.0.ebuild
> 
> The copyright header says "Copyright 2016 The Chromium OS Authors.
> All
> rights reserved." All ebuilds in gentoo.git say "Copyright 1999-20xx
> Gentoo Foundation".
> 
> Can I add ebuilds copyrighted by others to gentoo.git?

I don't see anything significantly artistic there to be copyrightable
in the first place. Just boilerplate of ebuild variables (one could say
this is derivative work on Gentoo stuff), and passing of variables to
cmake via a method whose copyrightable significant work is inside
cmake-utils.eclass, which is in main tree (probably with wrong
copyright headers, but...).

Given they only care about ICD loader, we'd want to re-do much of the
work and checking anyway, to perhaps build more stuff than the ICD
loader.


IANAL,
Mart

Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS

[Mart Raudsepp]

Ühel kenal päeval, K, 28.09.2016 kell 08:39, kirjutas Michał Górny:
> On Wed, 28 Sep 2016 08:31:06 +0200
> Marek Szuba  wrote:
> 
> > 
> > On 2016-09-27 22:51, Raymond Jennings wrote:
> > 
> > > 
> > > Doesn't VIDEO_CARDS factor in on xorg-server's video driver
> > > selection?  
> > It does. Which is why with the way things are now, and which
> > Michał's
> > proposal should improve, someone with an amdgpu-compatible card
> > will
> > still have xf86-video-ati lying around - VIDEO_CARDS=radeon will
> > pull it in.
> 
> Also note there's VIDEO_CARDS=amdgpu for newer cards, to increase
> your
> confusion. And the LLVM target is probably needed for
> VIDEO_CARDS=radeonsi and newer, not by VIDEO_CARDS=radeon. Though it
> may be needed for OpenCL.

As discussed on IRC, I think the amdgpu target should be enabled via
video_cards_radeonsi, because the only consumer of that target that
pulls it in is currently mesa[video_cards_radeonsi], so users don't
need to go fiddling with yet another USE_EXPAND when they already set
VIDEO_CARDS="radeonsi" or similar anyways in their make.conf.

I don't quite understand the rest of the LLVM_TARGETS proposed. Seems
like all the rest of them would be use.masked and unmasked in specific
arch profiles?
It seems that once you remove AMDGPU from the equation by keeping it
behind VIDEO_CARDS, all the rest are CPU specific stuff, not GPU, so
less mixing things up in a way; though with completely unhelpful
llvm_targets.desc I don't know if any of the others might not be
something else (like BPF, Hexagon, Lanai, MSP430 and more)


And yes, the existing VIDEO_CARDS=radeon* stuff is rather confusing in
mixing up GL driver names, DRM backend names and more, but a separate
issue that I'm thinking on how to clean up and working with the rest of
the x11 team towards something. Meanwhile llvm[video_cards_radeonsi]
would make sure those that need it, already have it if they enable the
thing they need to get it from mesa globally, and won't need to fiddle
with other flags too.
And yes, it's currently llvm[video_cards_radeon] in old versions of
llvm, and that's not accurate anymore since a while imho, and should be
converted to video_cards_radeonsi as well.


Mart

Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS

[Mart Raudsepp]

Ühel kenal päeval, E, 26.09.2016 kell 00:42, kirjutas Mart Raudsepp:
> > The new system will be applied to 3.9.0 and  ebuilds.
> > VIDEO_CARDS
> > flag will be removed completely because of no revdeps.
> 
> People with radeonsi graphics set VIDEO_CARDS=radeon already, I'm a
> bit
> reserved about having to force them to set some LLVM_TARGETS=radeon
> or
> LLVM_TARGETS=amdgpu on top of that to satisfy some USE depends on
> mesa[video_cards_radeon].
> 

I meant they set VIDEO_CARDS="radeon radeonsi" already. Got that wrong
from being an actual r600 mesa/evergreen user still with "radeon r600"
set instead :(

Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS

[Mart Raudsepp]

Ühel kenal päeval, P, 25.09.2016 kell 23:08, kirjutas Michał Górny:
> I'd like to introduce a new USE_EXPAND for LLVM & clang. It'd be
> named
> LLVM_TARGETS, and it's going to replace the current solution based on
> USE=multitarget & VIDEO_CARDS=radeon.
> 
> - VIDEO_CARDS=radeon enabled additional R600 target,

No. It enables AMDGPU target these days, which is for the modern stuff
and very much needed by them.
r600 stuff was in the llvm 3.3-3.6 era, which was used by old
experimental mesa[r600-llvm-compiler] as an alternative shader compiler
for r600 instead of builtin mesa stuff. This work has been ditched long
ago afaik.
Instead now VIDEO_CARDS=radeon is required on llvm for radeonsi and
later AMD GPUs for _ANY_ shader compiler support at all, plus other
things (from it adding AMDGPU to llvm targets in current ebuild).

> The new system will be applied to 3.9.0 and  ebuilds. VIDEO_CARDS
> flag will be removed completely because of no revdeps.

People with radeonsi graphics set VIDEO_CARDS=radeon already, I'm a bit
reserved about having to force them to set some LLVM_TARGETS=radeon or
LLVM_TARGETS=amdgpu on top of that to satisfy some USE depends on
mesa[video_cards_radeon].

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Mart Raudsepp]

Ühel kenal päeval, R, 16.09.2016 kell 17:20, kirjutas Ulrich Mueller:
> How does a file in FILESDIR get stale? The typical scenario is that a
> patch will no longer be needed after a version bump and pruning of
> old
> ebuild versions. I fear that with FILES the problem would simply be
> shifted: instead of forgetting to delete the stale file, people would
> forget removing the patch from the FILES list.
> 
> Ulrich

While I'm not sure I would like this feature as a whole, compared to
the status quo, the only way this would really work in a reasonable way
(and maybe not at all in some cases without the duplication) is if you
don't eapply them in a way that lists them again, but it would replace
PATCHES functionality or you'd do some bash magic to eapply everything
in $FILES that ends in .patch or something.


Mart

Re: [gentoo-dev] Looking for people willing to take care of Cinnamon

[Mart Raudsepp]

On Wed, 2016-08-24 at 11:43 +0200, Kristian Fiskerstrand wrote:
> On 08/24/2016 11:26 AM, Pacho Ramos wrote:
> > Hello
> > 
> > Most Gnome team member are not willing to keep maintaining cinnamon
> > ebuilds (specially since most of us are not even using it and,
> > also, we
> > already have enough load with Gnome ebuilds alone). 
> > 
> > We were wondering if maybe some other people would be willing to
> > maintain them under a new Cinnamon Project or similar, in that
> > case,
> > feel free to create the project and take it
> > 
> > Thanks a lot
> > 
> 
> 
> I'm using it so would certainly be willing to join a project to help
> out
> with it. At the same time I'm not sufficiently familiar with
> gnome-packages etc that I'd want to do it on my own.

I believe this is the list of packages we want to give away:

gnome-extra/cinnamon
gnome-extra/cinnamon-control-center
gnome-extra/cinnamon-desktop
gnome-extra/cinnamon-menus
gnome-extra/cinnamon-screensaver
gnome-extra/cinnamon-session
gnome-extra/cinnamon-settings-daemon
gnome-extra/cinnamon-translations
gnome-extra/cjs
gnome-extra/nemo
x11-wm/muffin

but there might be more that don't contain "cinnamon" in the name or
don't have linuxmint as remote-id.

We keep maintaining all the GNOME packages cinnamon relies on.

So please just form a project and take em. Hopefully others can help
too; in GNOME team tetromino has been most involved with them.
I think it would be fine with us if the project is on paper a
subproject of GNOME if you want that instead of a top-level project, we
just don't want to be responsible to it and have us feel guilty with
bugs of it shown up in our GNOME saved searches, or give an impression
we are overstaffed which I guess a subproject kinda might do.
Or a subproject of Desktop, which I see was already deleted with my
objections for now, so nvm...


Mart

Re: [gentoo-dev] Developers, please work on underlinking issues!

[Mart Raudsepp]

Ühel kenal päeval, N, 18.08.2016 kell 23:56, kirjutas Alexis Ballier:
> On Thu, 18 Aug 2016 14:20:41 -0700
> Daniel Campbell  wrote:
> 
> > On 08/18/2016 06:21 AM, Alexis Ballier wrote:
> > > On Thu, 18 Aug 2016 08:13:14 -0400
> > > Rich Freeman  wrote:
> > >   
> > > > If you just check your packages occassionally to make sure they
> > > > build with gold it completely achieves the goal, and it will
> > > > actually result in fewer bugs using the non-gold linker as
> > > > well.  
> > > 
> > > 
> > > That's what a tinderbox is for. The only QA problem I see here is
> > > that QA doesn't automate that kind of checks anymore since Diego
> > > left. Maybe QA should ask Toralf to run a ld.gold tinderbox and
> > > avoid asking people to randomly test random packages ?
> > >   
> > I dunno, if testing packages that one maintains is as simple as
> > reconfiguring a package, testing, and switching back then I don't
> > think it's unreasonable to ask us to test our own packages. We're
> > supposed to do that already, and for packages whose dependencies
> > aren't 100% hashed out, it can help us figure out what the real
> > deps
> > are.
> 
> 
> test against... all linkers, all compilers, all libcs, all kernels,
> all
> userlannds, all useflags, ... ? :)
> 
> 
> by all means, please do it, but there are things machines are better
> at, like ensuring all packages have been tested against gold linker
> and
> every failure has been reported

The tl;dr did say to switch to ld.gold, but the main point was to
actually fix the bugs reported against your packages about it by other
developers, users and any future tinderbox runs, instead of ignoring
them as something that isn't supposed to matter and very low priority.
I think that should be sufficient, and we don't need to all rush to
switching to it, as long as we take care of the bugs about it when
others notice and file a bug.
Though it gives some good benefits when you are able to use it, afaik,
so hey, why not use it when you can :)


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 18:00, kirjutas Mike Gilbert:
> On Thu, Aug 11, 2016 at 5:34 PM, Kent Fredric 
> wrote:
> > On Thu, 11 Aug 2016 16:07:27 -0400
> > Ian Stakenvicius  wrote:
> > 
> > > but realistically this should be
> > > installed to /usr/$(get_libdir)/debiancompat/ or similar, and if
> > > you
> > > still don't want to wrap the apps that need it then also install
> > > an
> > > /etc/env.d/ file to add this dir to the LDPATH.
> > 
> > +1 to this. I was going to suggest something similar.
> > 
> > At least, because I'm still thinking in a view other than "steam",
> > and
> > anticipating "Maybe we're going to do more of this"
> > 
> > If more than one binary application need more than one debian hack,
> > stuffing all the debian hacks in a special prefix that everyone can
> > use
> > without polluting the main gentoo stuff is an advantage.
> > 
> > ( And the separate dir makes it clear what the library is for and
> > why
> > its there if anyone is trying to weed out some library problem that
> > still manages to happen despite our attempts )
> 
> I also like the private libdir better than installing a symlink in a
> "standard" libdir.

The question is really why, still.
I only see some sort of tidyness arguments, but it's not exactly tidy
to clobber ld.so.conf either, so I don't consider this a real argument.

If you install a proprietary package from their .tar.bz2 or Loki .sh
installer or whatever, the user will not know to install some libpcre-
debian package.
Also, again, PCRE2 is there. Soon dev-libs/libpcre:3 (libpcre-8.*) is
primarily a binary package satisfier anyways, so why not just satisfy
libpcre.so.3 while at it. Funny fact - we have it in SLOT=3 too :)

Ultimately I don't care personally as a gentoo user, as I will know to
install this useless symlink package. Maybe, if I remember. And only
because of a 10+ thread. But our users are uselessly bothered when they
actually need it by something.
They ought to be able to choose to not care, and have shit working out
of the box. This is providing a very important choice, in the spirit of
Gentoo.


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 11:23, kirjutas james:
> Whilst devs are discussing the future of Valve's offerings on
> gentoo, 
> it'd be wise to consider the effects of "Vulcan" as it is FOSS where
> all 
> video card vendors can inter-operate with multiple game vendors.
> Vulcan 
> will impact  those gaming codes, as Vulcan seems to be the clear
> pathway 
> forward for Valve related to Open Source communities [1 3].

I have no idea what Vulcan is, besides the race in Star Trek or Roman
god, but Vulkan is tracked in https://bugs.gentoo.org/574886 and Intel
support in https://bugs.gentoo.org/580148

I was going to look into it as well on basis of Intel Vulkan with
dota2, but on that machine Steam doesn't even work anymore due to
https://github.com/ValveSoftware/steam-for-linux/issues/4537
so got rather demotivated. Basically a case where having a fully
working setup without steam runtime should also fix it. Current main
machine has Radeon Evergreen and so no current Vulkan implementation to
play with.


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 11:05, kirjutas Ian Stakenvicius:
> Wouldn't the most simple solution here would be to make a symlink for
> libpcre.so.3 within the local bindir for each Valve or whatever
> package that needs it?  This is a binary-package-supporting hack,
> might as well do it in the binary packages that need it.  You might
> still need to wrap the binary to set some environment stuff, not
> sure;
> either way it doesn't seem to make sense to make this a system-wide
> thing.
> 

It makes sense, IF it doesn't hurt absolutely anything as a by-product.
Also open source stuff should be gradually moving over to pcre2,
eventually ending up with libpcre.so being for binary packages
exclusively in due time anyways.


Ühel kenal päeval, N, 11.08.2016 kell 16:03, kirjutas Ciaran McCreesh:
> On Thu, 11 Aug 2016 17:57:59 +0300
> Steam isn't a use case, it's a program.

Use case is proprietary gaming and software, if that makes you happier
and avoids further useless e-mails due to feeling like nitpicking on a
perhaps very slightly wrong terminology.
Having specifically Steam hassle-free is also important on the desktop,
unless your only goal is to be a FSF endorsed distribution. But it
covers all proprietary software that targets and tests stuff working on
Debian/Ubuntu (which is the majority of cases, sadly).


Mart

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Mart Raudsepp]

Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller:
> > > > > > On Thu, 11 Aug 2016, James Le Cuirot wrote:
> 
> > > Have you asked Debian why they are doing that?
> 
> > I did find out but had since forgotten. Here it is:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10
> 
> So they are aware of the issue since 10 years, but chose not to fix
> it? Seriously, there's no good reason to dance to their tune then.

It's not to dance to Debians tune, it's to dance to Valve tunes, which
happens to create its runtimes from Ubuntu packages.
I strongly believe that it's important to have such a use case as Steam
work problem-free in Gentoo. It's currently too messy, with and without
using steam runtime.
In the former case (using steam runtime), there are incompatibilities
between libraries found in the steam runtime, and those that it doesn't
include and assumes the system provides (primarily mesa and deps); each
steam runtime version you get to hack around things by removing a small
selection of libraries from the steam runtime dir to get stuff working;
a 1-2 month old upgrade I haven't even managed to get to work yet on a
more up to date machine.
In the latter case (forcing to not use steam runtime), it's near
impossible right now to get a set of 32bit binaries to satisfy even
steam client itself without lots of trial and error, let alone some
32bit game.

> > I'm fine with putting it in libpcre-debian package as kentnl
> > suggested.
> 
> I still think that the libpcre.so.3 compatibility link shouldn't be
> installed in a generally visible location. Install it in a specific
> directory instead, and start your binary with a wrapper which will
> add that directory to LD_LIBRARY_PATH.

Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
toolchain.eclass function does, except for pointing libpcre.so.3 to
libpcre.so.1 (so can't use that eclass function, but could just pre-
create one to $FILESDIR if it works)?
The important points should be:
1) No compilation/linking done on Gentoo should possibly end up with
putting libpcre.so.3 in its DT_NEEDED
2) libpcre.so should link to libpcre.so.1

If we can satisfy these, I don't see a reason to mess around with some
extra package.
Debian reasoning of having stuck with libpcre.so.3 historically is
sound as well, especially if upstream will never use that, given
libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, and
given debians todays situation with this, I would also technically
choose not to change this, as things should migrate over to PCRE2.


Mart

Re: [gentoo-dev] Empty project: Desktop

[Mart Raudsepp]

Ühel kenal päeval, T, 09.08.2016 kell 12:02, kirjutas Jason Zaman:
> On Sun, Aug 07, 2016 at 04:37:23PM +0200, Pacho Ramos wrote:
> > El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
> > >  [...]
> > > Well, that's easily remedied with an alias for the project that
> > > contains
> > > all the subprojects, no?
> > > 
> > 
> > But I don't know if the projects will like to behave in that way...
> > because freedesktop-bugs was behaving exactly in that way and,
> > during
> > the transition, it was agreed to stop using that and simply CC the
> > right projects when needed :/
> > 
> > From my point of view we should simply kill that "Desktop" project
> > as
> > it serves no purpose and CC the relevant projects when needed, as I
> > don't recall many cases of the old freedesktop-bugs behaving in the
> > way
> > you are suggesting (involving *all* desktop related projects in the
> > bug
> > reports). On the other hand it was ending up with most people under
> > the
> > subprojects simply ignoring the bug reports assigned to
> > freedesktop-
> > bugs
> 
> Removing it is fine. I'm in the freedesktop and Xfce projects and I
> had
> no idea this Desktop project even existed.
> Pretty sure everyone would just ignore anything from/to it anyway.
> Problems with eg KDE and Xfce are mostly not really related. And the
> few
> things that are related are more core components that are under
> freedesktop (polkit/consolekit etc). In which case, that component is
> fixed without needing to bother every single other project or we just
> CC
> them all if need be.


It should be kept for the purposes of coordination between different
specific desktop projects and the grouping of them it provides as
subprojects.
However that doesn't mean it should have any packages in the tree that
the desktop projects maintains itself personally, instead of one of its
subprojects.

One of my gentoo plans, when I have time, has been in reviving such
desktop-wide coordinations, possibly under the desktop project banner.
E.g my started USE=gui and toolkit threads when I had time.

Frankly, it would be weird to not have a project that broadly manages
all the desktop stuff.
We should manage this all better under a broad desktop project that
manages documentation, some policies, etc, but doesn't necessarily have
any packages that it maintains in tree.

If we need a new lead election per GLEP 39, I'm sure we have some
volunteers from the subprojects to throw their name in, that are
interested in having a good desktop-wide organization going on. Myself
included.


Mart

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

[Mart Raudsepp]

Ühel kenal päeval, T, 02.08.2016 kell 15:25, kirjutas Michał Górny:
> On Mon, 1 Aug 2016 17:15:41 -0400
> Mike Gilbert  wrote:
> 
> > On Mon, Aug 1, 2016 at 5:08 PM, David Seifert 
> > wrote:
> > > Dear friends,
> > > while version bumping sci-libs/fftw, I've noticed our
> > > CPU_FLAGS_X86
> > > list could be expanded a bit:
> > > 
> > > avx512 - introduced with Skylake and Knights Landing
> > 
> > According to Wikipedia, "AVX-512 consists of multiple extensions
> > not
> > all meant to be supported by all processors implementing them."
> > 
> > https://en.wikipedia.org/wiki/AVX-512
> > 
> > https://en.wikipedia.org/wiki/CPUID#EAX.3D7.2C_ECX.3D0:_Extended_Fe
> > atures
> 
> Also https://bugs.gentoo.org/show_bug.cgi?id=588628.

Do we actually want to be fast in adding these things, or do we want to
wait for any actual consumers to be possible to start consuming it
right away? Like with all these different variants, will consumers
actually group the variants in the same way and will we be able to map
things cleanly in ebuilds in the future?
Though I guess there are already potential consumers out there that
people have already looked at and I've just not kept up with IRC or
something :)

Also, how are they exposed in cpuinfo, do we have first patches
for cpuid2cpuflags? Since what kernel version are they exposed in
cpuinfo, is it a flag for each CPUID capability? What variants do each
CPU implementing any expose, maybe all CPUs doing e.g avx512f all also
do avx512dq - perhaps all consumers would make such assumptions and
assume things based on real world CPUs? Or maybe all consumers of some
of the variants will always do runtime detection themselves and we
won't even use that flag in an IUSE ever?

tl;dr: Concerned about prematurely adding things without knowing of
consumer examples


Mart

Re: [gentoo-dev] Signed push & clock drift rejection

[Mart Raudsepp]

Ühel kenal päeval, E, 18.07.2016 kell 16:25, kirjutas james:
> On 07/18/2016 03:03 PM, Marc Schiffbauer wrote:
> > * Rafael Goncalves Martins schrieb am 18.07.16 um 03:12 Uhr:
> > > On Sat, Jul 16, 2016 at 11:33 AM, Andrew Savchenko  > > o.org> wrote:
> > > > Set it for a minute or two. This will protect from commits from
> > > > really out-of-sync systems (like 14 days mentioned above) and
> > > > will
> > > > keep usablity hight for others.
> > > 
> > > I second this "request" :)
> > > 
> > > remote: Your system clock is off by 6 seconds (limit 5)
> > 
> > Why not fix your system clock? No ntpd running?
> > 
> > Check 'ntpq -pn'
> > 
> > -Marc
> > 
> 
> net-misc/openntpd is simple and might do the job well enough, or is
> net-misc/ntp a hard requirement ?
> 

or just

systemctl enable systemd-timesyncd.service
systemctl start systemd-timesyncd.service

if you are fortunate enough to run systemd.
If not, well, some other ntp client indeed, no need to debate fortunes
further :)

If there's no RTC clock ticking and syncing during/after suspend,
something seems off in my experience. Disabled ACPI? :D

I didn't find any indications of why this is actually a problem in the
announcement or replies, and I couldn't read the backlog for the
explanation that I saw might have skimmed through. I think if we want
to nitpick what the actual drift allowed is, we need to know the
reasons this restriction is needed and what could be the difference to
that unspecified potential rsync issue between a seconds of drifts and
a couple minutes or an hour or so of drift.
I'm sure infra will adjust if possible and choose what's best :)


Mart

Re: [gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Mart Raudsepp]

Ühel kenal päeval, T, 07.06.2016 kell 20:28, kirjutas Michał Górny:
> 
> So here's how I would word it. I think if we combine a few different
> texts, we may end up with something good ;-).
> 
> ---
> The LINGUAS USE flag group has been renamed to L10N, in order to
> avoid
> a conceptual clash between the Gentoo use of the name, and a standard
> environment variable used by multiple gettext-based packages. 

Where "multiple" is pretty much the whole tree of autoconf based
packages (and probably cmake too?). Pretty much anything that has a
translation :)

> Therefore,
> from now on filtering localizations is supported on three independent
> levels: L10N, LINGUAS and INSTALL_MASK.
> 
> The L10N flags affect built and installed localizations of the
> packages
> listing those flags explicitly. They are fully controlled by
> the package manager, and their values are defined globally. They do
> not
> affect the packages not listing them explicitly.
> 
> The LINGUAS variable is now verbosely passed through to the build
> system.

If we have a transition phase for the USE_EXPAND, where we'll have both
for a while, then this is not strictly true immediately. It also means
we can't roll out your portage changes to stop the special casing
before we are finished with the transition and LINGUAS is removed from
the USE_EXPAND set.


> It controls the localizations built and installed by packages
> that use it, and that do not override it using L10N flags.

Packages should not be exporting some LINGUAS values based on L10N
USE_EXPAND anyways in my opinion; I'd make such approach a QA violation
maybe even, though we have some odd cases in a very limited set of
packages, iirc.

> Note that
> due to the design, the localization stripping is done implicitly
> and the package manager can not determine which localizations were
> actually provided.


> Additionally, the INSTALL_MASK improvements available in Portage
> 2.3.0
> make it possible to filter localizations at package merge stage. In
> this
> case, the filtering is done on installed directories transparently,
> and the build process and binary packages are not affected.

So I take it that these install_mask groups are in for upcoming 2.3.0.
Before that, you can still do it though, just need to list paths
manually yourself.
Info on what groups are pre-shipped or whatnot would have to be on the
wiki page then, I suppose.

> If you were using LINGUAS before, you most likely want to replace it
> with L10N. If you need to strip localizations more (e.g. for embedded
> systems), you may also want to set LINGUAS and/or INSTALL_MASK.
> However, if you intend to provide or use binary package, you will
> most

I don't like this shunning of LINGUAS feature and shunning to some sort
of embedded systems use case still.
Most of us build systems used by only ourselves, I believe, and there
is nothing wrong in getting a gettext feature applied for free, which
reduces translation lines in .desktop, .schema and other files, and
reduces the runtime mmap caches of those with it for free.
It being clear in the appropriate place that this is a build time thing
and whatnot is of course quite fine.

If we go with BCP47, then users will want to revise their values based
on the available options in the new l10n.desc I suppose.

> likely want to leave L10N and LINGUAS unset in order to build most
> portable binary packages, and use INSTALL_MASK to transparently strip
> installed localizations on the hosts using them.

L10N unset would mean no language packs at all, unless we have a wide
default set in base profile. So unless we set a default set of all of
them in profile, this would mean opposite behavior for L10N and LINGUAS
when unset.

> For more information, please see:
> https://wiki.gentoo.org/wiki/Localization/Guide
> ---
> 
> Of course, we'd need to update the guide to explain all three layers
> in detail.


This was just my random set of thoughts, so Ulrich knows them while
writing a new version of the news item tomorrow ;)


Mart

[gentoo-dev] News item: LINGUAS USE_EXPAND renamed to L10N

[Mart Raudsepp]

First draft of news item for proceeding with LINGUAS USE_EXPAND rename
to L10N independently of the INSTALL_MASK feature additions.

I hope English natives will improve the sentence flow and grammar here
:)
Perhaps there's also a better title than with the technical USE_EXPAND
mention.


Title: LINGUAS USE_EXPAND renamed to L10N
Author: Mart Raudsepp <l...@gentoo.org>
Content-Type: text/plain
Posted: 2016-06-06
Revision: 1
News-Item-Format: 1.0

The LINGUAS USE_EXPAND has been renamed to L10N, to avoid a conceptual
clash with the standard gettext LINGUAS behaviour.
L10N controls which extra localization support will be installed.
This is usually used in case of extra downloads of language packs.

If you have set LINGUAS in your make.conf, you should either copy or
rename it to L10N, depending on if you want to filter the supported
languages at build time or not via the gettext LINGUAS environment
variable behaviour as described below. Note that this filtering does not
affect only installed gettext catalog files (*.mo), but also lines of
translations in an always shipped file (e.g *.desktop).

LINGUAS maintains the standard gettext behaviour and will now work as
expected with all package managers. It controls which language
translations are built and installed. An unset value means all
available, an empty value means none, and a value can be an unordered
list of gettext language codes, with or without country codes.
Usually only two letter language codes suffice, but can be limited with
country codes with a 'll_CC' formatting, where 'll' is the language code
and 'CC' is the country code, e.g en_GB. Some rare languages also have
three letter language codes.
If you want English with a set LINGUAS, it is suggested to list it with
the desired country code, in case the default is not the usual en_US.
It is also common to list "en" then, in case a package is natively
written in a different language, but does provide an English translation
for whichever country.
A list of LINGUAS language codes is available at
http://www.gnu.org/software/gettext/manual/gettext.html#Language-Codes

Note that LINGUAS affects build time, and thus filters what ends up
in binary packages. If you are building generic binary packages that
should support all available language, you should not set LINGUAS.

If you have per-package customizations of LINGUAS USE_EXPAND, you
should also rename those from LINGUAS to L10N. This typically means
renaming linguas_* to l10n_*.

https://wiki.gentoo.org/wiki/Localization/Guide has also been updated
to reflect this change.

Re: [gentoo-dev] Choosing GUI toolkits from multiple choices

[Mart Raudsepp]

> I drafted that mentioned USE_EXPAND idea as a means to get some
> 'design from the scratch' discussion going and flesh out this way of
> potentially doing it (such a USE_EXPAND was idly mentioned at start
> by
> others as something that was deemed too crazy, but I didn't find any
> references). It is currently still as a draft over at
> http://piratepad.net/iwvgjB1P5d

For the javascript restricted and for purposes of in-line quoted
replies, here's the current state of my braindump there copied to e-
mail here:


The following draft concerns only applications.
Libraries should continue using qt4 and qt5 USE flags when they are
about libraries (linking against qt4 or qt5), where it's mostly a
matter of USE depends by consumer apps or higher level libraries, not
user choice for applications.
For gtk case, we would use IUSE="gtk2" and IUSE="gtk3" in this case,
but ideally they would be in separate slots or packages. In gtk case,
this is for things like avahi, gtk-vnc, caribou, libcanberra - things
that provide a library or module that links against given gtk SLOT or
implements a gtk module for that SLOT with the given IUSE.
The remainder concerns only applications, as we don't like to use the
same flag name for different concepts (library support vs application
toolkit version choice), and USE="gtk" might be something we could
perhaps get rid of, in favor of moving gtk2 libraries to IUSE="gtk2"
and application choice to IUSE="gui" or the proposed GUI USE_EXPAND.



use.desc:

gui - Enable an optional GUI

use.desc/gui.desc:

athena - Choose the MIT Athena widget set
gtk - Build a x11-libs/gtk+ based GUI
motif - Build a  toolkit based GUI
sdl - ...
qt4 - Build a Qt4 toolkit based GUI
qt5 - Build a Qt5 toolkit based GUI
wxwidgets - Build a wxWidgets based GUI
Xaw3d - Build a 3d athena widget set based GUI


Many of current IUSE=gtk should move to IUSE=gui when it's about
application GUIs.
Some of IUSE=gtk will move to version specific IUSE=gtk2 and IUSE=gtk3
when it's about libraries.
Not sure if anything will remain then. If it does, we'll need to think
about it then, or figure it out of the masses of IUSE=gtk users
beforehand.
An old mapping was partially conducted a while ago on https://docs.goog
le.com/spreadsheets/d/19sJuupspkY65FrU6b4U7gEWKiOgFGQwyXYdPCAvPqBo/edit
#gid=0

In no circumstance is a REQUIRED_USE or an equivalent pkg_pretend
limitation allowed when dealing with gui USE_EXPAND.

- A package has optional support for a GUI, written in any GUI toolkit
(but only one)
-- IUSE="gui" and depend and build against the toolkit it uses. No
toolkit specific USE_EXPAND should exist, as there's nothing to choose.
Example: wicd. USE="gui" shall build the gtk based GUI

- A package has optional support for a GUI, and that GUI can be chosen
to be either gtk, qt4 or qt5 based, but only one of them
-- IUSE="gui gui_gtk gui_qt4 gui_qt5". If user has USE="gui" disabled
for the package, don't build any GUI. If it's enabled, have a
maintainer chosen preferred order of toolkit to use, then choose
whichever highest priority toolkit flag is enabled by user. If no
supported toolkit flag is chosen, choose the highest priority one.
Example: ???

- A package has a required GUI, but the GUI can be chosen to be either
gtk, qt4 or qt5 based, but only one of them
-- Same as previous, but no IUSE="gui" as a GUI is not optional
Example: ???

- A package has optional GUI frontends in a way that multiple can be
built and shipped at once.
-- IUSE="gui" to have any GUI at all, if user hasn't it set, gui_*
values do not matter - no GUI will be built at all. If user has
USE="gui" set, all of the user enabled gui_* frontends will be built.
If user has no gui_* enabled at all that this package implements, but
USE="gui" is set, then a maintainer chosen first choice GUI is built.
Example: transmission with IUSE="gui gui_gtk gui_qt"

- Same case as previous, but some toolkits are exclusive, e.g one can
build both a gtk frontend and a qt frontend, but not both qt4 and qt5
frontend.
-- Same USE="gui" behaviour. If multiple exclusive flags are set, they
have an independent priority order, similar to when only one can be
built. So with GUI="gtk qt4 qt5", a gtk and a qt5 frontend would be
built when both qt4 and qt5 can't be. To choose qt4 frontend, qt5 has
to be disabled by user for this package.

- Same as prior 2 cases but a GUI is not optional (e.g lack of frontend
doesn't make sense)
-- Same, but no IUSE="gui"



Suggestions for users approach of the GUI="" setting in make.conf:

* If you don't care which toolkit is used, but rather would have the
preferred one chosen for you, don't set it at all, but keep it empty.
Do set USE="gui" if you want a GUI for where it's optional.
* If you strongly prefer a given toolkit or toolkits, set that/those in
GUI="..."; it will be then chosen whenever possible (if multiple, a
maintainer decided preference will be chosen, if only one toolkit
frontend is available; otherwise all of them will be built). 

[gentoo-dev] Choosing GUI toolkits from multiple choices

[Mart Raudsepp]

Ühel kenal päeval, R, 03.06.2016 kell 22:40, kirjutas Daniel Campbell:
> You touched on the part that I'm most concerned about: choosing. If
> the
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and
> if
> there's no preference just build whatever? Will we not be expected to
> emit an ewarn or something similar to clarify *why* the package is
> being
> built a certain way? Granted, if a user has a problem and reports a
> bug,
> their make.conf's GUI variable should be present in emerge -v output,
> easily explaining the issue.

Said 'GUI' USE_EXPAND is outside the intended scope of the USE=gui
thread, but anticipating discussion will happen regardless now, I've
cut the thread and named it something else.
Many discussions have happened on IRC on this as well, which is where
Daniel got this from.


I think it's actually a rather corner-case to have an optional GUI, and
then that GUI being buildable against a selection of toolkits. Arguably
in some of those cases it might be more ideal to have the GUI parts in
a separate package too, but usually upstream sources aren't so
accommodating to our source-based case (while binary distributions
split it up into multiple binary packages, built from one source in one
go).
In most cases when there's a choice, a GUI imho isn't usually optional.
You choose e.g qt4 or qt5, or gtk3 or qt5 and having both shipped is
not so common from the same package. Transmission is an example where
it is, because they have a multiple frontend system (arguably it would
be neat to have these in separate transmission-qt, transmission-gtk and
so on packages), and one of these can be a web service UI instead of a
dedicated graphics toolkit.

USE=gui would replace a ton of USE=gtk's at least, where it's mostly
about simple extra GUI tools added with a gtk2 dep, but I've seen it in
other toolkit cases too, but I don't know how common it is there.
Ideally USE=gui can be agreed upon while ignoring the corner-case of
multiple choices; in some of these cases it might make sense to ignore
USE=gui at the start, until the multiple choice case gets some
resolution though, e.g emacs and perhaps transmission could just keep
the current way until we agree how to express multiple choice cases
universally.

I drafted that mentioned USE_EXPAND idea as a means to get some 'design
from the scratch' discussion going and flesh out this way of
potentially doing it (such a USE_EXPAND was idly mentioned at start by
others as something that was deemed too crazy, but I didn't find any
references). It is currently still as a draft over at
http://piratepad.net/iwvgjB1P5d -  but I didn't want the original
USE=gui thread to discuss this, as it's a separate and much more
complex matter really, and would work in tandem with USE=gui when
appropriate.

> It's the implementation that gets me here, not the idea. The idea
> could
> be neat and make Gentoo management easier at the expense of some
> (hopefully) minor ebuild bloat. Another issue that hasn't been
> covered
> well yet is how are we going to select DEPENDs? I was told DEPEND
> doesn't support exactly-one-of, and we don't want extraneous
> dependencies.

The part of it being not clear (due to the intentional lack of
REQUIRED_USE usage in that design) what is getting built is probably
the main drawback of that drafted idea, and some QA members tell me
this would be outright vetoed as a QA violation.

This uncertainty also echoes in the need for these complex DEPEND atoms
as well then, based on maintainer chosen preference, combined with user
set flags.

So it isn't ideal at all indeed, and we'd need to really do the
suggested EAPI/package manager improvements first, to express this
maintainer order of preference to the user and filter the flags somehow
to what will actually be chosen then before the DEPEND atoms get
processed, which would make the *DEPENDs feasible, as you could
simplify the conditionals, because the unused (but set by user) USE
flags are already filtered out then (or one added when user didn't have
any, and one would be chosen by default).

I ruled out REQUIRED_USE because I don't like it at all when it is used
together with common global USE flags, as opposed to just some local
flags. In my opinion it tends to results in users disabling or enabling
something globally, instead of locally for the package in question. And
with that having made the choice unknowingly for a ton of future
packages to be installed as well. pkg_pretend is a bit better, because
you can customize the error message to be readable, but it's still
something that takes away my choice of not having to care.. just give
me a GUI, preferably a gtk3 one, ok? thx.

> Transmission is a good example: supports gtk3, qt4, qt5. Let's say
> the
> maintainer prefers the qt5 version. Would we do this?:
> 
> DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
> gui_gtk3? ( x11-libs/gtk+:3 )"
> 
> or this?:
> 
> DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( 

Re: [gentoo-dev] [RFC] Global USE=gui

[Mart Raudsepp]

Ühel kenal päeval, R, 03.06.2016 kell 22:40, kirjutas Daniel Campbell:
> You touched on the part that I'm most concerned about: choosing. If
> the
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and
> if
> there's no preference just build whatever?

As I don't want this thread to drown in the (imho) cornercase of
multiple choice GUIs, I will cut this into a fully new thread named
"Choosing GUI toolkits from multiple choices" and will reply there for
clean separation.


Mart

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Mart Raudsepp]

Ü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 are the package with LINGUAS options in their USE flags
> which you mentioned above.

People already set LINGUAS for autotools control; using the same for
USE_EXPAND probably seemed natural to re-use that, but the effects on
PM variable mangling wasn't thought about at the time.
This was introduced only to have a natural way to refer to them in
SRC_URI and beyond, for extra language pack downloads (like firefox
langpacks).
Things escalated badly from there.

> This had the advantage that no additional code except a correct
> IUSE is needed for these ebuilds. (That's why gentoo has chosen
> this name).

> It had the disadvantage that:
> 1. Ebuilds without handling IUSE=linguas_* explicitly (or
> with wrong values, because maintainers did not care about the
> values) had problems.

There were no problems, and there still are no problem with implicit
LINGUAS handling (by means of not listing them in IUSE), as long as the
package manager doesn't modify the variable set in make.conf.
The user has set it explicitly somewhere (make.conf most likely) and
simply gets honored in upstream build system, just like CFLAGS.
The problem is when package manager mangles it per PMS rules, for which
I'm told portage has special PMS ignoring exceptions.

> 2. Some packages which needed a different handling of LINGUAS
> (like respecting the order) also had problems.

LINGUAS does not imply any order whatsoever. Packages that assumed so
were seriously buggy and if any still remain, this needs to be fixed
ASAP. We have LC_* and LANG environment variables to choose what the
localization is at runtime, not some arbitrary choice at build time.
This is not a concern whatsoever, forget about it.

> There are at least the following solutions to these disadvantages:
> 
> a)
> One _could_ solve problem 1 simply by not touching LINGUAS if
> IUSE=linguas_* is not in the ebuild. (Main problem with this
> solution: It is not PMS compatible; one needs e.g.
> an exception for LINGUAS).

This is a problem when they are in IUSE too. For example a package
provides translations via gettext, but has extra downloads for some
languages support (lets say grammar checking support for a language in
an office application). The latter would get marked up with IUSE for
usage in SRC_URI and install. Package manager will intersect them and
remove the LINGUAS values not found in IUSE, but simple UI translation
gettext catalogs for these languages might still exist upstream. They
now get removed due to IUSE=linguas_* not including them.

Including them all in IUSE for simple translation catalogs is not
feasible to maintain. It also clutters emerge --verbose --pretend or --
ask output hard with LINGUAS="long list of 196 language codes" for
these and mixes it all up for when the information is more useful when
it implies huge extra downloads.

And yes, there are packages that have 196 different language and
dialects translations. Even core GNOME packages would have such an
amount, see https://l10n.gnome.org/languages/

> In a similar manner, one could solve problem 2 by allowing
> ebuilds to modify LINGUAS at build time (which is perhaps
> also not PMS compatible).
> 
> b)
> Or one could, for all packages with LINGUAS in their USE-flag
> simply rename IUSE=linguas_* to IUSE=l10n_* and set
> export LINGUAS=$L10N
> in these ebuilds (this would require practically no manual ebuild
> editing if one does it in the l10n.eclass).

The idea is not to export this anywhere in ebuilds. We'd have to do
that in pretty much all.
The point is that if the USE_EXPAND is renamed, then a LINGUAS as found
in make.conf will just get passed verbatim into the environment (as
parsed in via shlex - make.conf is not bash sourced), and then honored
by upstream build system.
That's because it isn't in USE_EXPAND list anymore, so it doesn't have
such PMS rules to modify it.
One can modify the environment via package.env as well, to change
things per-package if one fancies for some reason.

> I had originally understood mgorny's suggestion such that b)
> is meant, and I would complain neither against a) nor b).
> 
> But in his reply, mgorny says that, moreover, he wants to
> remove the l10n.eclass, more precisely, that he considers
> it as broken that packages use IUSE=l10n_* for setting
> LINGUAS.
> 
> This suggestion means that setting LINGUAS can be done
> *only* in a hackish way by the user, "hidden" from the
> package manager, not in the clean way as it is currently
> done by those ebuilds with LINGUAS in their use-falgs.

I don't see anything hackish in just setting L10N for extra language
support downloads and LINGUAS for UI translations.

> I agree with him that a hidden setting is a bad 

[gentoo-dev] [RFC] Global USE=gui

[Mart Raudsepp]

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 description overrides to specify exactly what extra tool
is built and installed with the flag are encouraged.


This is meant to cover the cases where a package has an optional GUI,
as a user facing graphical application, whichever the toolkit.

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 library, or some graphical
configuration GUI in addition to command line, or some bigger cases in
more modular packages that provide multiple frontends, and not all of
them are graphical, but CLI or TUI (TUI meaning ncurses-based or
similar).
Also there are various with USE=X where it's also about that, but X
isn't the only way to do GUI these days (any gtk3 app that doesn't
directly use libX11/libxcb/etc themselves natively supports wayland,
for example).

Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
available in only one toolkit version. So hence feature based flag, not
dependency-based.

http://tinyurl.com/gtk-use was an old analysis of USE=gtk usage in tree
by Gilles over a year ago. That suggests that at least 80+ USE flags
should be then USE=gui instead of USE=gtk out of that analyzed USE=gtk
subset alone, not counting USE=X and others.

There are some other things in the ideas pipeline for when there are
multiple toolkit choices, but that's something for a different thread,
a different day and more controversial.


Mart

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

[Mart Raudsepp]

Ü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 of it (the order
matters case; which I believe is long eradicated).
We are a source based distribution, and gettext/intltool upstream
LINGUAS behaviour is perfect advantage for our main use case of
customizing ones own system and almost always building things from
source, only using binary packages before an upgrade as a backup, if at
all.
So it's natural to use the way that really build only the support you
want. This is what LINGUAS gives you, when the PM doesn't happen to
munge it.

Hiding this away under some toy for advanced users is not in our spirit
of Gentoo, as far as I would judge.

But this is a matter of documentation at this point, in principle I
agree that SRC_URI extra downloads should be under a different naming.

INSTALL_MASK groups for locales is what I would consider a convenience
for binary package builders in a wide environment where language choice
to the end user preferably gets filtered on deployment in a site- or
machine-specific manner. Or a toy for advanced binary distribution
creators, if you will. A way for binary packages to provide almost as
good support for LINGUAS as source packages (but not quite).
That said, supporting our binary package ecosystem is very important,
and I applaud these efforts. The proposed INSTALL_MASK improvements are
very useful for many other cases as well. For source-based users as
well (openrc init scripts, systemd unit files, gtk-doc documentation,
etc)

Either way, the masterplan works out, I just don't think we need to
wait for INSTALL_MASK groups here in any way. The reminder is a matter
of documentation, a matter of perspective.
This l10n.eclass PLOCALES nonsense needs to go ASAP.


Mart

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Mart Raudsepp]

Ü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 complexity and smartness, for a single
> > variable. Obviously nothing can go wrong with this.
> 
> Please stop the derogatory remarks and unnecessary cynicism. If you
> think some proposed solution is a bad idea, just explain why you
> think
> it's a bad idea. Not everyone has the same perspective as you on
> these
> things; nor are they likely to be converted to your stance by your
> scolding them.


+1
Especially given the followup mail.
Really unprofessional.

So lets have users set multiple variables for the same thing, so it's
done properly because users need to care about env variable intricacies
in package management deep guts.
That said, maybe indeed better to force them to set it twice, as
discussed in my followup mail.


Mart

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Mart Raudsepp]

Ü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 would like to start a RFC on a draft solution that
> > I'd like afterwards to propose to the Council.
> > 
> > 
> > Rationale
> > -
> > 
> > The direct reason for this is that LINGUAS is treated as non-
> > standard
> > special variable by multiple build systems. This includes the
> > following
> > problems:
> > 
> > 1. no localizations are installed if it is set to an empty value
> > (which
> > happens in EAPI 5 when the ebuild does not use the flags),
> 
> Why not just add a USE_EXPAND_DONTTOUCH variable to profiles, like
> there is already a USE_EXPAND_HIDDEN, which tells the PM to not play
> with the envvar, and just use it for USE expansion when the ebuild
> does
> use it?
> Point being, it leaves it unset, when it's unset, and it leaves it
> set
> to empty value or a value when it is so.
> 
> Obviously with a better name than USE_EXPAND_DONTTOUCH, but you get
> the idea.
> 
> I suppose this doesn't solve the case of PM not knowing about what is
> inside a binary package, but if said variable also affected the
> metadata of the result, this should be possible to handled with some
> PM work, while not duplicating places to set languages to be
> compiled/installed.
> 
> The common case should be to support language x, y and z, and not
> wanting to change that, and never or rarely build binary packages
> (just as a backup before upgrade).
> This is how I believe Gentoo is used as a source based distribution.
> 

That said, I didn't like this being made a USE_EXPAND from the start,
as it does something else - control what huge language packs get
installed, as opposed to what stripping of files and file contents is
done. And LINGUAS is quite a different beast, due to dialects, having
special rules of implicit handling (e.g, you have a dialect in LINGUAS,
but no specific translations exist for that language, you still get the
main one instead; or was it vice-versa).
But I don't think we need to wait for the INSTALL_MASK bits to swap the
USE_EXPAND over to L10N or some other name (maybe something that
denotes likely extra downloads of langpacks). We still have LINGUAS,
which we might want to document better (with the binary package caveats
mentioned, etc), and localepurge that end results in the same result as
with the proposed INSTALL_MASK.

Though this shouldn't demotivate to make this group feature for
INSTALL_MASK happen regardless. The lingua groups should probably be
with wildcards like /pl/... AND /pl_*/... to cover
dialects, when you don't have dialect groups.

Additionally I don't think there's harm in filtering languages out
manually based on LINGUAS after all this is done still (LINGUAS not
being a USE_EXPAND), if the upstream build system itself doesn't. Might
want to take more care about dialects though.

`
Mart

Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[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 would like to start a RFC on a draft solution that
> I'd like afterwards to propose to the Council.
> 
> 
> Rationale
> -
> 
> The direct reason for this is that LINGUAS is treated as non-standard
> special variable by multiple build systems. This includes the
> following
> problems:
> 
> 1. no localizations are installed if it is set to an empty value
> (which
> happens in EAPI 5 when the ebuild does not use the flags),

Why not just add a USE_EXPAND_DONTTOUCH variable to profiles, like
there is already a USE_EXPAND_HIDDEN, which tells the PM to not play
with the envvar, and just use it for USE expansion when the ebuild does
use it?
Point being, it leaves it unset, when it's unset, and it leaves it set
to empty value or a value when it is so.

Obviously with a better name than USE_EXPAND_DONTTOUCH, but you get the idea.

I suppose this doesn't solve the case of PM not knowing about what is inside a 
binary package, but if said variable also affected the metadata of the result, 
this should be possible to handled with some PM work, while not duplicating 
places to set languages to be compiled/installed.

The common case should be to support language x, y and z, and not wanting to 
change that, and never or rarely build binary packages (just as a backup before 
upgrade).
This is how I believe Gentoo is used as a source based distribution.

And big roll-outs with staging and binary packages have capable overlords 
knowing what's up in this area.

As this idea is too obvious, I'm sure it has come up before and dismissed, but 
as I don't remember it mentioned in the previous thread, nor with a quick skim 
over them, here it is anyways.


Mart

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Ühel kenal päeval, R, 27.05.2016 kell 13:14, kirjutas Anthony G.
Basile:
> On 5/27/16 12:59 PM, rindeal wrote:
> > On 27 May 2016 at 18:54, landis blackwell  > m> wrote:
> > > I stopped reading after you reminded me it was 2016
> > 
> > Good to know, thanks for stopping by.
> > 
> 
> Yeah the "its  year" meme has been making its rounds of the
> internet.
> 
> anyhow, my 2017 question is about avahi.  right now i have USE=gtk
> and
> gtk3, where gtk really means gtk2.  i'm not going to change that
> because
> it fits QA's specs.  but i could remove it altogether and just drop
> gtk2
> support for the next release.  good idea?  bad idea?  i guess i'm
> asking
> whats the status of gtk2 in gentoo seeing as its dead upstream.

Instead you should have 3 packages here.

avahi that ships the non-gtk linking bits.
avahi-gtk2 that ships the gtk2 library.
avahi-gtk3 that ships the gtk3 library.

This wasn't done originally as we lacked the manpower there and hoped
that gtk2 consumers will go away soon anyway. If that isn't the case,
the work should be done long ago. I hear there have been various
dependency issues already anyways due to the splitting not having been
done.

If there are no more avahi-gtk2 consumers, you could drop the gtk2
support altogether and maybe not need the splitting.
Then the question is if you name it USE="gtk" or USE="gtk3" to build
the gtk3 component.
Either way, consumers would USE depend correctly on which they need - I
don't think it's magical, so consumers would always actually link to it
and a clear USE depend can be in place.

So in an ideal world, you wouldn't have any USE=gtk* whatsoever here
anyways.


Mart

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Ühel kenal päeval, R, 27.05.2016 kell 14:10, kirjutas
waltd...@waltdnes.org:
>   While we're at it, why are there 23 occurences of the "X" useflag
> in
> /usr/portage/profiles/use.local.desc when it exists in
> /usr/portage/profiles/use.desc ???  I'm talking about stuff like...
> 
> app-misc/vifm:X - Add support for X11
> dev-libs/m17n-lib:X - Builds the Graphical User Interface API and
> utilities for the package.
> dev-libs/wlc:X - Enable X11 backend and XWayland support.
> dev-python/PyQt4:X - Build bindings for the QtGui module
> dev-python/pyside:X - Build QtGui and QtTest modules

Because they specify in more details what the USE flag does
specifically, in the context of that package.
Such more exact local descriptions are something I at least personally
strongly advocate in favour of.
app-misc/vifm local desc seems redundant though, but the rest listed
here seem useful and necessary.


Mart

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

Ühel kenal päeval, R, 27.05.2016 kell 13:14, kirjutas Anthony G.
Basile:
> On 5/27/16 12:59 PM, rindeal wrote:
> > On 27 May 2016 at 18:54, landis blackwell  > m> wrote:
> > > I stopped reading after you reminded me it was 2016
> > 
> > Good to know, thanks for stopping by.
> > 
> 
> Yeah the "its  year" meme has been making its rounds of the
> internet.
> 
> anyhow, my 2017 question is about avahi.  right now i have USE=gtk
> and
> gtk3, where gtk really means gtk2.  i'm not going to change that
> because
> it fits QA's specs.  but i could remove it altogether and just drop
> gtk2
> support for the next release.  good idea?  bad idea?  i guess i'm
> asking
> whats the status of gtk2 in gentoo seeing as its dead upstream.

I don't see a strong reason to have gtk2 support if there are no gtk2
consumers remaining in the tree. I somehow doubt that's the case for
avahi, though?
If gtk2 support is removed though, then per gnome policy gtk3 component
should come with USE=gtk and per QA policy USE=gtk3.

The QA policy is not finalized and completely contradicts our side of
things, hence discussions are needed, but did not conclude.
This is a thread to continue this discussion, I suppose.

I wouldn't change anything till then really, especially for libraries,
where it's mostly handled by USE depends anyway.

One thing is USE flag naming for gtk2 and gtk3, another thing is if
apps should provide support on building against either.
I strongly disagree with using the same flag names for "provide gtk2
linking higher level library" and "Build this GUI application against
gtk version 2". QA proposed policy has this regression.
Also for libraries it is a "either or both" situation, for apps it's a
"one or the other" situation. This gets awful very quick if any
application maintainer decides to express it with a
REQUIRED_USE="^^ ( gtk2 gtk3 )", combined with the libraries in tree
that then would have REQUIRED_USE="|| ( gtk2 gtk3 )" + libraries in
tree where gtk component is optional, and if available both gtk2 and
gtk3 versions are available with
REQUIRED_USE="gtk? ( || ( gtk2 gtk3 ))".

This would be clean with only libraries using gtk2/gtk3 as is GNOME
teams current policy. Then the natural thing would be to have a
different USE flag to mean to prefer gtk2 for user facing applications
when possible instead of gtk3 (USE="force-gtk2" being suggested here
for that)
With this approach we can cleanly handle any upcoming gtk4 as well,
while naturally moving users who don't care into using the latest
version.

I also strongly believe that USE flags should be first and foremost
about features, not an expression of the name of an external
dependency.

Gilles did a huge start of work on mapping gtk* use flag usages in a
spreadsheet, but given the volume, got distracted before finished.
I pointed this out to the QA team to look at, but have not heard
anything back.
The point of the exercise was, that it turns out half of the tree seem
to mis-use USE=gtk in some way, and QA should really concentrate on
helping with that first. Then the situation would be much clearer, as
there wouldn't be all that many USE=gtk's remaining.
Anyhow, this is where the discussions stalled last time around.

I think we should first figure out about the USE flag usages (naming +
library only or not).
We can bikeshed if gtk2 version for applications should be provided
more liberally in addition to gtk3 as a one or the other choice later
on. I don't feel too strongly about making that hard if it doesn't step
on our library USE flag namespace.


Mart

[gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Mart Raudsepp]

k3 version is primary and we just have 1 app
remaining that needs the gtk2 version or something.
The concept of library is broad here, covering also gtk theme engines
(x11-themes/gtk-engine-*, but they shouldn't be hard to split) and
modules (e.g caribou, libcanberra)

* Applications may only use a gtk2 based stack or gtk3 based stack in a
given version/revision. gtk3 is strongly preferred when it is deemed to
not have any regressions compared to gtk2 build, but the choice is
ultimately with the maintainer. Once the application converts to using
gtk3 in our distribution, it should try hard to stay that way in
upcoming versions as well.

* Some exceptions to the above may exist under heavy consideration,
especially in cases where the toolkit usage is complex and may have
some issues for some, but in general gtk3 support is deemed good by
upstream. Most notable here would be browsers like firefox and
chromium, which are using gtk dependency more for emulating the theme
it uses, rather than using it as its real toolkit. If such exceptions
are allowed, the USE flag naming here must be consistent amongst the
exceptions. My proposal would be USE=force-gtk2 then, as I have no
better ideas without stomping on the USE=gtk{2,3} historical meaning.


When arguing in favor of supporting gtk2 builds more for apps, please
do keep in mind that gtk2 really is pretty much dead. And no, MATE,
XFCE and others are NOT continuing its support; they are just slow in
fully converting to gtk3, but they are doing so and I expect both of
those to be fully done this year, around autumn.
If the issue is political or just a general gnome3 or gtk3 hate, then I
would ask you to keep your political opinions or hate outside this
thread and go contemplate on more important life issues.
If the issue is lack of themes, then I would like you to help package
more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
themes shouldn't be breaking anymore beyond this point, theoretically.
And gtk3 theme packages should pretty much just be CSS files and some
metadata. Though we have yet to get over that bumpy thing yet (a main
reason gtk3.20 isn't in main tree yet).

Thoughts? Agreements? Suggestions?
I'm particularly interested in QA opinion here. I believe WilliamH
wanted to spearhead this from their side.


Regards,
Mart Raudsepp
Gentoo developer, GNOME team

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Mart Raudsepp]

Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas
waltd...@waltdnes.org:
> On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote
> > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds
> > have
> > a good reason to use flags for localization, we introduce a new,
> > non-colliding USE_EXPAND for that. We also ask users to replace
> > LINGUAS
> > with the new flag in their make.conf files. LINGUAS gets the
> > original
> > upstream behavior back, and we eventually discourage it in favor of
> > new
> > INSTALL_MASK features (WiP) [2].

Short of making an exception to LINGUAS in the USE_EXPAND rules, I
think this is the only way.

> 5. An reversed variant of INSTALL_MASK in make.conf, e.g.
> LOCALE_ALLOW="foo bar fubar"
> 
> 6. Integrate localepurge into Portage, and run it post install
> 
>   There are some lazy programmers out there who *DO NOT* respect the
> LINGUAS setting, and splatter files throughout /usr/share/locale/*
> and
> /usr/share/man/* regardless.  That's the reason "localepurge" was
> written in the first place.  Any proposed solution should take that
> problem into consideration, and handle it too.

For both of these cases, I have to point out that e.g
LINGUAS="en et pl"
does not mean "keep only /usr/share/locale/{en,et,pl}/*", it means have
support for only these languages. This means for example that *.desktop
files will have translations in them only for those language. Same for
dconf schema files. Same for many other things. MO Translation files
and manuals aren't the only thing here, especially with intltool (and
many of these intltool features are now part of gettext proper).
In short, LINGUAS affects the content of files too, not only the
existence of files. See any file in /usr/share/applications/ for
example.
I always put "en" as my first in LINGUAS, due to historical abuse of
the first value there, I think e.g mplayer or vlc used to do this.
LINGUAS is an unordered list, but some packages used to took the first
value as meaning the default and switch the UI to that by default,
instead of honoring LC_* variables. Another reason I put "en" there, is
because of IUSE_EXPAND and packages that might not be natively english,
but do have english translations (I think I've seen some french ones
like that :D)


And no, localepurge is not capable of stripping these translations out
of existing files. To my knowledge at least. Though it could be
improved to do so in some cases.


Mart

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Mart Raudsepp]

Ühel kenal päeval, K, 18.05.2016 kell 22:25, kirjutas
aide...@gentoo.org:
> From: Amadeusz Żołnowski 
> 
> awk doesn't have the -i option like sed and if editing file in place
> is
> desired, additional steps are required. eawk uses tmp file to make it
> look to the caller editing happens in place.
> ---
>  eclass/eutils.eclass | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index dbedffe..e331f1b 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -20,6 +20,19 @@ _EUTILS_ECLASS=1
>  
>  inherit multilib toolchain-funcs
>  
> +# @FUNCTION: eawk
> +# @USAGE:  
> +# @DESCRIPTION:
> +# Edit file  in place with awk. Pass all arguments following
>  to
> +# awk.
> 

I would like if such a function would explicitly document that calling
this function means the caller should DEPEND on an awk provider.
Similarly, I would like that all ebuild that call 'sed' actually DEPEND
on sed, not just half of them.
I would also like that no ebuild would assume packages in @system to be
present, beyond those dictated by PMS (unpackers and such).

Mart

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Mart Raudsepp]

Ühel kenal päeval, N, 19.05.2016 kell 18:51, kirjutas Amadeusz
Żołnowski:
> Ulrich Mueller  writes:
> > The EAPI 6 method would be to use "|| die -n". Then the caller can
> > either call "eawk" if the function should die automatically, or
> > "nonfatal eawk" if it should return with an error status.

Don't you possibly need a || return as well in there if it isn't the
last things in the function?
https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6

> Yes, that seems better. Hasn't it been introduced earlier than in
> EAPI 6?

die -n argument is new in EAPI 6
nonfatal was added in EAPI 4, together with the fatality defaults for
PM utilities.
See https://devmanual.gentoo.org/ebuild-writing/eapi/


Mart

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Mart Raudsepp]

Ühel kenal päeval, N, 21.04.2016 kell 15:42, kirjutas Ian Stakenvicius:
> b) -1 for making it global right now pending resolution of logistics
> for the profiles/base/use.mask entry,

I don't think it's unprecedented to just globally use.mask a USE flag
even if it's not declared a global USE flag.
Or more like it's common that architectures use.mask local flags used
in more than one place with a clear meaning it involved a dep they
don't want or can't keyword. Globally masking and unmasking in one
profile is kind of similar.
Those reading PMS or whatnot can speak up if needed, but I don't see a
problem here.
The discussion is useful, as I suspect we can get sufficient users soon
enough, especially if you look into some of the other GUI stuff that
can work there (e.g gitg/gedit), though the question is what's the real
use of having any of these if upstream isn't looking into making use of
this to build their windows binaries or whatnot.

> c) rejection for the proposed ebuild patches pending a toolkit
> refactoring to be determined later.

Not really a rejection, it's just that I haven't looked into those
patches with a review mind as of yet. It just sounds like it's worth
looking at it deeper, that maybe there's more extensive improvement
possibilities. So just not an ACK as of yet.

> 
> B and C make most of this thread pretty well moot, I guess, but
> following A, can we decide that USE="winapi" could be a good flag
> name?  If nobody objects I'll use that when leio and I work on the
> refactoring of gtk+ and likely try to use local flags somehow for
> now.

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Mart Raudsepp]

Ühel kenal päeval, K, 20.04.2016 kell 22:18, kirjutas Mart Raudsepp:
> Basically the only real point I have is that anything kernel_* to
> control this probably doesn't make sense.
> 

Oh, just to clarify and avoid misunderstanding:
I did not intend to ack the changes to gdk-pixbuf and gtk+ with my
message, even if the flag name is changed.
It sounds to me like we have some refactoring to do in those ebuilds
together with aqua in mind as well, once we have agreed on the future
global USE flag name.
I also vote 'no' to the profiles changes, because we don't have 6+
packages with the flag yet to make it global use flag quite yet (though
it would make sense once we do, and in essence it is a global one that
needs masking in other profiles, etc - fiddly with local use flag).

Once this thread has concluded on a naming, I'm sure we can have a
productive gtk/gdk-pixbuf review via IRC :)


Mart

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Mart Raudsepp]

Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent Fredric:
> On 21 April 2016 at 06:38, Ian Stakenvicius  wrote:
> > Well so far the only needs I have run into for the win32 flag has
> > been in relation to choosing UI toolkit support for cairo and gtk+
> > (and possibly others in the future), which is why I saw the
> > parallel.
> 
> 
> Given you're not using the flag to indicate "works on win32" as such,
> but instead "compile using Win32 Widgets instead of something else",
> wouldn't a better name indicate that somehow?
> 
> The simplest thing I can think of that clears this confusion is a few
> extra characters:
> 
>   "win32gui", "win32ui"
> 
> Or something along those lines.
> 
> It doesn't require us to know what the exact binding keywords in
> microsoft terminology is used, and it clearly communicates "This is
> something to do with User Interfaces" as opposed to "Just
> linking/compiling slightly differently".

win32 is what the base API seems to be called all over in the wild.
The GTK+ configure flag is also --enable-win32-backend in gtk3 and
--with-backend=win32 in gtk2 (didn't personally check the latter).
Note that gtk configure actually also tracks platform_win32 and
os_win32 in there, which are different things (and just configure.ac
internal names). Former is true when host contains mingw, latter when
host contains mingw or cygwin.
When win32 gdk backend is enabled (which the propose USE flag would
do), then it will depend on a matching cairo backend of that, to be
able to do its own drawing on Windows. There's actually some stuff
about pangowin32 as well, not sure Ian has noticed that yet.

The GDK win32 backend uses what is called the win32 API. See e.g
https://en.wikipedia.org/wiki/Windows_API#Versions
For example a GdkWindow is created via CreateWindowExW, root of that
documentation is apparently at
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx

It doesn't use the Windows API higher level UI stuff, like wxWidgets
does, but only the low-level stuff, and then emulating the themeing as
best as it can right now, like Qt does. So in that way win32gui might
be misleading. win32 or win32api or winapi or I dunno.

Theoretically you can also build this stuff for consumption with wine.
Or maybe ReactOS?
Basically the only real point I have is that anything kernel_* to
control this probably doesn't make sense.


Mart

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mart Raudsepp]

Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:
> On 16 Apr 2016 09:23, Patrick Lauer wrote:
> > So why on earth are we applying a random patch that upstream is not
> > using
> 
> not everyone uses glibc, and glibc *is* moving in this
> direction.  Gentoo
> is simply accelerating the change ... otherwise glibc will take
> longer to
> do the actual migration.

You don't need to break everyone's ~arch for dubious glibc benefits,
which could be done by a p.masked version and a tinderbox run.
I am not your tinderbox dummy having to waste time on this to maintain
my own ~arch stuff.

> packages failing to build under glibc already
> fail to build in other environments.

That is simply not true, at least not to the extent you make it sound.
We have FreeBSD prefix ourselves seemingly building just fine, X.org
stuff build everywhere UNTIL you apply this currently gentoo specific
patch, etc.

> > *and* unleashing it on ~arch without any of the usual precautions
> > like masking the package until some of the issues have been smoked
> > out?
> 
> it was masked for a while, some bugs were fixed, but no new ones were
> really being found.  so in the absence of data showing a problem,
> unmasking is normal.
> -mike

Why are all the concerns raised at e.g
https://bugs.freedesktop.org/show_bug.cgi?id=94231 not resolved then?
Over there you even told you won't be including this patch in Gentoo,
but get it trickled in from upstream once they judge it as good to go.

Instead you go ahead and unmask this without removing the gentoo
specific sysmacros header removal, knowing FULLY WELL that you break
~arch for a lot of things (just even based on that libdrm bug, merely
breaking every single ~arch gentoo GUI installation in existence), as
any simple test would show you, or a tinderbox run would blow up
immediately. This is glibc ~arch here, not some little independent tool
or not widely used library where ~arch breakage is acceptable.

If you wanted to flush out packages breaking, you could simply locally
compiled stuff and immediately see a ton of stuff, asked someone to do
a tinderbox run, or whatever. Yet it doesn't help much, because
upstreams can be resisting to changing anything, because the
documentation in man-pages tells them they are doing everything
correctly already.
Even todays git of man-pages tells that including sys/types.h is
sufficient and the correct thing to do to get makedev/major/minor. You
are breaking this with a Gentoo specific patch, this is really a NO-NO.

I really appreciate your system packages gruntwork, but please please
start to consider with others and be a little bit more conservative
about such stuff for ~arch, especially when it's Gentoo specific.


A heavily disgruntled Gentoo ~arch maintainer unable to do his job due to 
others adding breakages he shouldn't care about,
Mart Raudsepp

Re: [gentoo-dev] Re: can someone help me or give me access to planet.gentoo.org

[Mart Raudsepp]

Ühel kenal päeval, P, 03.04.2016 kell 01:55, kirjutas Duncan:
> Anthony G. Basile posted on Sat, 02 Apr 2016 05:31:44 -0400 as
> excerpted:
> 
> > I wrote a long blog post and I'd like to see it on planet
> > gentoo.  I
> > plan on blogging a lot more too and need to see this problem fixed.
> 
> In the mean time, what about a direct link to your blog?
> 
> While I follow planet gentoo, I subscribe directly to a few gentooer 
> blogs as well, in part because I'm interested in some stuff that
> doesn't 
> get tagged gentoo and thus that planet gentoo won't carry.

That stuff should get to universe then, but I'm not sure if all
developer blogs are syndicated as such.

https://planet.gentoo.org/universe/


Mart

[gentoo-dev] Re: New virtual: virtual/jack for jack protocol implementations

[Mart Raudsepp]

Ühel kenal päeval, N, 04.02.2016 kell 15:05, kirjutas Alexis Ballier:
> As its name does not imply, jack2 is not really the successor of
> jack1
> but rather another implementation of the same protocol [2]. As such,
> I
> don't think it is wise to add jack2 as an update to jack1 in
> media-sound/jack-audio-connection-kit but rather to add a new package
> (media-sound/jack2) along with a virtual that packages can depend
> onto.
> 
> Proposed ebuild for the virtual is here:
> https://github.com/suhr/gentoo/commit/1aebd8e72ff4ff2665761fc3b07f796
> 945aa0943
> 

Does it work with media-plugins/gst-plugins-jack too (as in, can
jackaudiosrc read from jack2 and jackaudiosink output to it)? :)
If yes, feel free to adjust deps there accordingly once you implement
the virtual, or maybe chat with miknix too.

However one concern with the virtual - if it is not interchangeable
(same library naming and ABI), then you have to rebuild things against
the other provider, and hopefully that can be set up to be more
automatic somehow; as the virtual will be satisfied with either of
them, so the user could exchange them without actual consumers linking
to it noticing. Some thoughts into that aspect, if even just some
warning to user, would be good.


Mart

Re: [gentoo-dev] USE=desktop-file request

[Mart Raudsepp]

Ühel kenal päeval, K, 06.01.2016 kell 16:23, kirjutas tot-to:
> I'm a user of a KISS wm, which does not provide Windows™-like menus,
> desktop icons, etc. GUI software is called just by typing the binary
> name in PATH, just like any other software. For me the desktop-files
> are
> some kind of useless junk.
> 
> Recently a lot of software were made harddep on
> dev-util/desktop-file-utils, i.e. from now on there are not only junk
> text files, but also a junk software required without any reason.
> I've
> added it to /etc/portage/profile/package.provided and everything
> compiles and works just fine. It means that in reality there is no
> real
> need in this software.
> 
> Please make these dependencies optional.
> 

This is not going to happen, because this dependency is not optional.
The fact that it seems to build for you without an apparent immediate
breakage on emerge, doesn't mean things aren't broken for you.
At least in the GNOME team we are not in the business of having silent
breakages to avoid build time dependencies of a 19kB simple utility
(192kB with a couple other tools and documentation).

desktop-file-utils is used to update the MIME types handling
applications cache database after .desktop files are installed or
removed.
xdg desktop files are not only for showing GUI applications in
application menus, but also handling of automatic startup on login of
things, MIME type associations (which this is used in particular at
buildtime to update the association database as stated above)

If you choose to INSTALL_MASK /usr/share/applications and/or other
.desktop files, you aren't just avoiding tiny text files from being
installed that you believe are only needed for application menu
entries, you are also breaking MIME type associations and various other
features these FreeDesktop.org standard files provide to the overall
system.

If such a USE=desktop-file is added and then these desktop-file-utils
utility calls are not made via xdg.eclass, then your system will have
no idea of MIME type capabilities. Your browser (opened via your dear
terminal from command line) will not be able to know what to use to
open a PDF file or whatever other file. That's just one example.

You are free to continue having things broken in such a way, but this
is not going to be made optional in the main tree in the name of
avoiding a 192kB package (as is its size when installed in the system,
including all of its documentation and manual pages). If you are
building an embedded system or whatever, it's a buildtime dep and can
be removed in the end. However care should be taken then to have a
properly up to date MIME association cache shipped as well in the final
image for things to work properly or in a properly performant manner.

If we are looking for something to improve here, it would be in the
package manager to support postinst triggers that could be grouped to
not be ran after each package, but only once in a while (but at least
once). Calling this after each package might be unnecessary, and a
couple times in the whole emerge session should be fine - that MIME
association can be a bit delayed, and not called after each package
postinst.


On behalf of the GNOME team,
Mart Raudsepp

Re: [gentoo-dev] Nominate global USE-flag harfbuzz

[Mart Raudsepp]

On K, 2015-01-07 at 07:29 +0100, Peter Stuge wrote:
 $ grep :harfbuzz profiles/use*desc
 profiles/use.local.desc:dev-libs/efl:harfbuzz - Enable complex text shaping 
 and layout support.
 profiles/use.local.desc:dev-qt/qtgui:harfbuzz - Use media-libs/harfbuzz for 
 text shaping (experimental in Qt 5.3.x, default in Qt 5.4.0 and later). If 
 enabled, it can still be disabled at runtime by setting QT_HARFBUZZ 
 environment variable to old.
 profiles/use.local.desc:media-libs/freetype:harfbuzz - Use 
 media-libs/harfbuzz for auto-hinting OpenType fonts. WARNING: may trigger 
 circular dependencies!
 profiles/use.local.desc:media-libs/libass:harfbuzz - Enables OpenType shaping 
 via media-libs/harfbuzz.
 
 Or isn't 4 enough?

I don't know about that, but I would say at least half of them should
continue to carry on a specific description of what the USE flag does in
its metadata.xml.
I guess consider this just a friendly slightly unrelated reminder that
when making USE flags global, please don't end up losing information by
deleting the specific description. And consider adding a local
description to a packages global USE flag usage if you can describe its
effect more specifically.
And if some tooling doesn't support that, well, bad luck. My tool does
(less metadata.xml)


Mart

Re: [gentoo-dev] stepping out

[Mart Raudsepp]

On P, 2014-10-12 at 20:47 +0200, Angelo Arrifano wrote:
 * media-plugins/gst-plugins-jack
 the version in portage is old

This is in GStreamer herd and will receive bumps together with the rest
very soon (and mustn't be bumped without everything else). But we could
use help from people known to actually use the thing to make sure it
actually works. Or at least just users/devs with JACK setup in place can
do basic tests with this, while validating it gets used (I can assist
with that on IRC).


Mart

Re: [gentoo-dev] Using LINGUAS

[Mart Raudsepp]

Hello,

LINGUAS is a concept in gettext tooling. I do not understand why we
overload it in package management in the first place.
It is an environment variable that we set up in make.conf, because
that's an easy way to get it into the build environment to have the
standard way of limiting translations work.

By overloading it for IUSE_EXPAND we effectively make it pretty much
impossible to have the choice of ALL translation files, except when it
means extra packages; without conditional LINGUAS setting, that is.


The standard LINGUAS variable acts as follows:

If unset: Build all translations
If set to an UNORDERED listing of language codes: Include translations
for listed languages (or dialects)
If set to an empty string or similar: Don't include any translations


We currently have wrong behaviour for when it's unset, as as far as
IUSE_EXPAND is concerned - we don't have a default that includes all
available linguas as far as I know.


Though in the real world, I don't think it matters much, and it's
convenient for those that just build a gentoo machine for use within the
family, with known language capabilities within.


As a side note: LINGUAS does not only control which .mo files happen to
be installed (which you could get rid of later easily with localepurge)
- it also is used to filter out unwanted translations in files which
have all the translations in the same file; this includes, but is not
limited to .desktop files.
This used to be a intltool thing, but nowadays gettext has derived such
support directly as well.


Mart

Re: [gentoo-dev] remove USE flag ldap from profile desktop

[Mart Raudsepp]

On L, 2014-03-22 at 12:50 +0100, Tom Wijsman wrote:
 On Sat, 22 Mar 2014 09:46:58 +0100
 Toralf Förster toralf.foers...@gmx.de wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  IMO it is the choice of users to opt in for LDAP, not to opt out for
  it. I'm convinced that the majority of Gentoo users does not need it
  per default.
 
 Before we discuss this again; looking for the source, I found this:
 
 https://groups.google.com/forum/#!topic/linux.gentoo.dev/yIfM8sV2zFQ
 
 It is discussed in your favor; however, it seems to be forgotten to do.

In that thread some of the takeaway points seem to have been (with my
comments):

* It would be better to do such changes alongside profile updates; alas
13.0 went by without this change being remembered

* It might be a good idea to show USE flags on packages and their
changes from before in case of reinstalls/upgrades by default, not only
with emerge --verbose  (but claimed to be the case already)

 Is anyone going to pick this up on their fork to send out a news item
 and change it; or, has there been disagreement? If so, Council item?
 
 (PS: This is about gentoo-x86/profiles/targets/desktop/make.defaults)

To add something -

I suspect this default might be related to ancient times when there were
no per-package USE defaults, and in times when there were no gnome
subprofiles, with sabayon (the old graphical tool to manage GNOME
desktop profiles, not the distribution) requiring it to be enabled, and
sabayon probably having been in the gnome meta-package.

That, or when thin clients were the next best thing after sliced bread.

Either way, that doesn't invalidate any news item considerations, etc.
Too bad we probably can't do a news item for users of only desktop
profiles or their subprofiles, and only when they haven't tweaked the
ldap USE flag themselves in make.conf to explicitly go either way. Or
can we?

[gentoo-dev] Use slot deps for all gstreamer package dependencies (including plugins); preparation for gstreamer-1.0

[Mart Raudsepp]

Hello,

The release of a new major GStreamer 1.0 release is going to happen
soon. It will be parallel-installable with the 0.10 series, so it will
be eventually introduced as a separate SLOT and co-exist for a while.

As such, if you maintain any packages that have any dependencies on

media-libs/gstreamer
media-libs/gst-plugins-*
media-plugins/gst-plugins-*

please get ready for it by pinning the dependencies to the appropriate
SLOT, which should currently be 0.10 in all cases.
Use SLOT deps if at all possible with your used EAPI, or at least a
=media-plugins/gst-plugins-foo-0.10* kind of dependency.

This way I'll have less package maintainers to chase around and bugs to
file once it's actually time to introduce the new SLOTs to the tree
(having all currently packages properly slot depend on 0.10 is
considered a blocker for 1.0 introducing).

media-libs/gst-plugins-bad used to be SLOT=0 accidentally, but this has
been slotmoved now, so SLOT 0.10 dep there as well.


Thanks,
Mart Raudsepp

Re: [gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?

[Mart Raudsepp]

On N, 1970-01-01 at 00:00 +, Tobias Klausmann wrote:
 Hi! 
 
 On Wed, 29 Aug 2012, William Hubbs wrote:
  On Wed, Aug 29, 2012 at 01:57:48PM +0200, Tobias Klausmann wrote:
   As a first crude datapoint, I compared the build times
   (configure+make) of udev-171-r6 and -188 on our dev Alpha. This
   is a machine that's on the speedier side of off-mainstream
   architecures, but as a datapoint, it should be enough.
   
   No, not exactly, because udev-188 doesn't build systemd. We use
   specific targets in the Makefile to avoid doing that.
 
 Amending my earlier post then, here are the numbers for the
 171 build and the target-specific build of 188:
 
 ver  (1)(2)   (1+2)
 udev-171-r6: 15s /  71s /  86s;  1m26s
 udev-188   : 28s /  78s / 116s;  1m56s
 
 Much less difference. Still, I figure _really_ slow
 machines/arches might be in more pain. I'll run my test with a
 Geode-based x86 later this week.

Geode LX700 (433MHz) with 256MB RAM
MAKEOPTS=-j2 (single core system)
gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2

ebuild prepare done before as well.

1. time ebuild foo configure — real time value
2. time ebuild foo compile — real time value

ver   (1)  (2)(1+2)
udev-171-r6: 47.2s / 4m36.4 / 5m23.6
udev-188   : 69.6s / 6m27.2 / 7m36.8

Personally of course don't care the slightest of this time.


Mart

Re: [gentoo-dev] supporting static-libs

[Mart Raudsepp]

On N, 1970-01-01 at 00:00 +, Gregory M. Turner wrote:
 On 8/28/2012 1:09 AM, Michał Górny wrote:
  On Tue, 28 Aug 2012 02:15:40 +0200
  hasufell hasuf...@gentoo.org wrote:
  static-libs
  pointless
 
 I have to mask this flag for dev-libs/{gmp,mpc} in my cygwin overlay, 
 where one can have static or dynamic, but not both, as per. upstream 
 requirements (no idea why).  So FTR, this is not always a matter of 
 personal taste.

static-libs is for installing static libraries IN ADDITION to shared
libraries, not instead.
USE=static is for what you have in mind there.


Best,
Mart Raudsepp

Re: [gentoo-dev] Global Systemd USE Flag

[Mart Raudsepp]

On N, 1970-01-01 at 00:00 +, Jason A. Donenfeld wrote:
 On Wed, Aug 8, 2012 at 4:33 PM, Michał Górny mgo...@gentoo.org wrote:
  You are right. In case users really intend to use that, they may be
  better using app-portage/install-mask, and:
 
  $ install-mask -a systemd
 
  which will add just the right path.
 
 Still misses the point. USE flags were invented to deal with these
 options. On a default install, which uses OpenRC, users shouldn't have
 to then emerge an additional program to add more configuration in
 order to have a clean system.

USE flags are not meant for controlling every little thing, such as
conditional installing a 400 byte file that does no harm when not used,
other than taking 1 block of filesystem space (4kB or so), which can be
workarounded by INSTALL_MASK if you are building an embedded system. I
seriously doubt they were invented for such a purpose, but rather to
control ./configure arguments and external dependencies.

No, wanting to get rid of those on a desktop/server via a USE flag (as
opposed to an INSTALL_MASK) is not a consideration, as that's users
completely unneeded desire for no technical reason. If taking 500kB
total for systemd service files is an issue, then the issue really is
that you are using a 1GB /usr partition or something.

This all is similar to how we in GNOME unconditionally install user and
developer documentation, as long as it does not impose any extra build
time or downloads.
(no, this is not really negotiable for change, and we are talking about
more than 400 byte files here; we'd be happy however if portage binary
packages supported splitting of the source packages files to separate
packages, so that binary distribution derivatives could work in a
similar model as purely binary distributions)

USE flags typically control the functionality of compiled binaries,
usually involving external dependencies to achieve such extra
functionality.

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=2#doc_chap1_sect2


Best Regards,
Mart Raudsepp

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Mart Raudsepp]

On L, 2012-06-23 at 15:10 +0100, Ciaran McCreesh wrote:
 On Sat, 23 Jun 2012 10:06:58 -0400
 Mike Gilbert flop...@gentoo.org wrote:
   I don't quite understand why this would be necessary.
  
   Would funky-slots just be used in situations where ebuilds with
   the same PV but different PVR have different slots?
  
   Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only
   used in libraries; applications use slot deps to select which one
   they need. Paludis should not remove the -r200 version if it is
   still referenced in the depgraph, correct?
  
  Or maybe you are saying that Paludis will not automatically install a
  new slot for a package that is already installed, even when referenced
  by a slot dep?
 
 The 'standard' behaviour (which can be changed by the user) for Paludis
 when doing complete resolutions is that whenever there's a slot of
 something installed, it will try to bring in the newest version of that
 package, even if it's in a different slot. This is generally a good
 thing, since newer versions are supposed to be better than older
 versions. The problem is that now newer versions are being used to
 mean with a different Ruby implementation or built in a different
 way, which screws up the meaning.

Don't do that if the slotted package in question is not in the @world,
and all packages depending on it strictly require the older SLOT.

Re: [gentoo-dev] Re: Gentoo Janitor scripts

[Mart Raudsepp]

On K, 2012-02-22 at 09:48 +0100, Corentin Chary wrote:
 I did a quick script to count most used prefixes in SRC_URI yesterday
 (https://github.com/iksaif/portage-janitor/blob/master/mirrors.py)
 
 Here is the (filtered) result:
 
 $ eix --only-names | python mirrors.py --count
 960 http://dev.gentoo.org
 372 http://xorg.freedesktop.org
 372 http://xorg.freedesktop.org/releases
 372 http://xorg.freedesktop.org/releases/individual
 306 http://pear.php.net
 306 http://pear.php.net/get
 256 http://oss.tresys.com
 255 http://oss.tresys.com/files
 255 http://oss.tresys.com/files/refpolicy
 225 http://hackage.haskell.org/packages
 225 http://hackage.haskell.org/packages/archive
 225 http://hackage.haskell.org
 206 http://ftp.xemacs.org
 201 https://github.com
 196 http://ftp.xemacs.org/pub
 196 http://ftp.xemacs.org/pub/xemacs
 193 http://ftp.xemacs.org/pub/xemacs/packages
 181 http://gstreamer.freedesktop.org
 181 http://gstreamer.freedesktop.org/src
 175 http://launchpad.net
 175 http://linuxgazette.net
 143 http://github.com
 130 http://pear.horde.org
 130 http://pear.horde.org/get
 101 http://savannah.nongnu.org/download
 101 http://savannah.nongnu.org
 100 http://get.qt.nokia.com
 97  ftp://sources.redhat.com/pub
 97  ftp://sources.redhat.com
 96  http://get.qt.nokia.com/qt
 95  http://get.qt.nokia.com/qt/source
 90  http://download.gna.org
 75  http://pecl.php.net
 75  http://pecl.php.net/get
 72  http://components.ez.no/get
 72  http://components.ez.no
 69  https://fedorahosted.org
 67  http://www.phrack.org/archives
 67  http://www.phrack.org/archives/tgz
 67  http://www.phrack.org
 
 
 From that output we can easilly find out new entries to
 thirdpartymirrors, for example:
 gentoo-devhttp://dev.gentoo.org
 xorg http://xorg.freedesktop.org
 gna  http://download.gna.org
 pecl http://pecl.php.net
 pear http://pear.php.net
 github  https://github.com http://github.com
 xemacs   http://ftp.xemacs.org/pub/ ftp://ftp.sa.xemacs.org/pub/
 launchpadhttp://launchpad.net
 redhat ftp://sources.redhat.com/pub/ (and probably others !)
 etc...
 
 The good part is that once you've modified thirdpartymirrors with new
 mirrors, running mirrors.py --all will generate a big patch for all
 your ebuilds to use those new mirrors !

If you want this, then you should better figure out actual upstream
mirroring systems and their list of mirrors they would want us to use.
Until such, this seems to be just for shortening SRC_URI addresses when
an upstream tarball domain name or path repeats, and that's definitely
not what thirdpartymirrors is for.


Best,
Mart Raudsepp

Re: [gentoo-dev] Understanding the LINGUAS variable and use-expand

[Mart Raudsepp]

On K, 2012-02-08 at 11:32 -0500, Mike Gilbert wrote:
 I just want to sanity-check my brain here.
 
 LINGUAS seems to be mainly a variable to control the behavior of
 gettext's autoconf code, installed as /usr/share/aclocal/po.m4.
 
 If LINGUAS is set to a list of language codes, the build system will
 only build/install MO files for those languages. If LINGUAS is unset,
 the build system will build/install MO files for all available
 languages.
 
 Portage will also use-expand LINGUAS, so an ebuild *can* make use of
 it where USE flags are needed. For example, in SRC_URI, where the USE
 flags may be used to control downloading of extra language packs.
 
 Given this information, I come to a few conclusions:
 
 1. There is technically no need to define IUSE=linguas_$x if an
 ebuild is not using the USE flags in other ebuild metadata (like
 SRC_URI).

I'm not sure, but it is not feasible to list them for exposing languages
a package has been translated to via gettext/intltool. That's completely
unmaintainable and unnecessary. Each version bump could change it, hard
and time consuming to validate, etc.

 2. In cases where the USE flags are needed, they should be enabled by
 default to emulate the default-all behavior of the autoconf macros.
 For example: IUSE=+linguas_fr_FR +linguas_de_DE.

I would like that, but I don't think any or many packages do so when
they use it in SRC_URI

 3. An ebuild could use LINGUAS to control installation of translation
 information which does not come from gettext PO files. It does not
 necessarily need to make use of the linguas_$x USE flags to do so.

One such widely used way is to use intltool, which amongst other things
handles PO files as well (of course via gettext tools in the end), but
also other things.

 Does all of that make sense?
 
 I am considering simplifying www-client/chromium from the current mess
 based on the linguas USE flags to basically just this:
 
 if [[ ${LINGUAS} ]]; then
   for x in *.pak; do
 mylang=${x%.pak}
 mylang=%{x/-/_}
 has $mylang $LINGUAS || rm $x
   done
 fi

It would perhaps be nicer if upstream honored LINGUAS itself too or
so...

I think users could be surprised a bit about cases where you have
variants or dialects, e.g currently as IUSE=linguas_fr_FR, when users
only have LINGUAS=fr - in gettext they often don't have a fr_FR.po, just
fr.po; if locale has LC_MESSAGE and LANG at fr_FR, it will look at fr
if more specific fr_FR not found.
I define things like LINGUAS=en en_US et et_EE to be really sure, but
I doubt many users do that (but that's just a guess).
If it's exposed via IUSE, then they can at least have some visual cue of
that.
I guess it wouldn't be a concern if we had a tool to set the LINGUAS
that handled this variant logic nicely, or just educating users in
documentation, make.conf.example comments and so on.

 As well, there are probably a few other places in the tree where
 conclusion #1 and #2 should be applied.


Best,
Mart Raudsepp

Re: [gentoo-dev] Dropping localepurge

[Mart Raudsepp]

On E, 2012-01-30 at 04:19 -0500, Philip Webb wrote:
 120129 Mike Frysinger wrote:
  On Sunday 29 January 2012 00:01:50 Philip Webb wrote:
  Below is the output from 'localepurge' after this week's system update.
  Please don't drop it till 'should' does = 'does'.
  the vast majority of that output comes from like 3 or 4 packages.
 
 All of it comes from  6  packages which I recently installed/updated :
  evince gdk-pix-buf rekonq xkeyboard-config gnome-doc-utils sane-backends
 The total rubbish cleaned out for these  6  was   9 MB .
 The last  3  belong to major projects -- X Gnome Sane -- ,
 which suggests that other pkgs they manage may suffer the same defect.

Do you even have LINGUAS set in /etc/make.conf or something?
Because at least evince, gdk-pixbuf, xkeyboard-config and
gnome-doc-utils DO honor LINGUAS.

All GNOME packages that use intltool (that is pretty much everything
except a few low-level libraries) honor LINGUAS much more than
localepurge would ever be able clean afterwards. For example, .desktop
files only have translation lines for languages listed in LINGUAS. Same
for gconf and dconf schemas. Also all end-user documentation
in /usr/share/gnome/help/appname/lang_code/

  file bugs if you want things to actually get fixed.
 
 No, that's not the way it should be handled.
 Filing bugs --  6  of them in this case -- is no guarantee of attention even,
 let alone action to fix the problem.  Moreover, if it's fixable by Gentoo,
 the dev involved should do it as a matter of course without needing a bug.

Per above, we would close at least 4 of those bugs as INVALID or at
least OBSOLETE (if some older version had it wrong).
At least in GNOME we feel quite strong about things properly honoring
LINGUAS per old standard GNU conventions. This means installing ALL
translations if LINGUAS is unset, and none if LINGUAS is set to an empty
string.

 There is a perfectly effective script which cleans up the mess
  the only problem with it seems to be temporary lack of a maintainer,
 who is not essential anyway if there's nothing which needs fixing
  should not be difficult to replace with a simple request for a volunteer.
 
 Please leave 'localepurge' where it is.

Above said, I also do find a use on some systems for localepurge, to
catch the packages that don't honor it.
Though for embedded deployments I might as well not include the
non-interesting language directories in the image.


Best,
Mart Raudsepp

[gentoo-dev] Re: Dropping localepurge

[Mart Raudsepp]

On E, 2012-01-30 at 06:56 -0500, Philip Webb wrote:
 120130 Mart Raudsepp wrote:
  Do you even have LINGUAS set in /etc/make.conf or something?
  Because at least evince, gdk-pixbuf, xkeyboard-config and
  gnome-doc-utils DO honor LINGUAS.
  
  All GNOME packages that use intltool (that is pretty much everything
  except a few low-level libraries) honor LINGUAS much more than
  localepurge would ever be able clean afterwards. For example, .desktop
  files only have translation lines for languages listed in LINGUAS. Same
  for gconf and dconf schemas. Also all end-user documentation
  in /usr/share/gnome/help/appname/lang_code/
  
  Per above, we would close at least 4 of those bugs as INVALID or at
  least OBSOLETE (if some older version had it wrong).
  At least in GNOME we feel quite strong about things properly honoring
  LINGUAS per old standard GNU conventions. This means installing ALL
  translations if LINGUAS is unset, and none if LINGUAS is set to an empty
  string.
  
  Above said, I also do find a use on some systems for localepurge, to
  catch the packages that don't honor it.
  Though for embedded deployments I might as well not include the
  non-interesting language directories in the image.
 
 Thanks for the useful  polite response.  I will look into LINGUAS.
 How to set it is not mentioned in  make.conf.example  or in  man make.conf :
 where is it documented ?

http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3 covers
this.

I presume you only have things set in /etc/locale.nopurge or so then,
and wrongly expect packages to honor it. Specific packages do not and
can not look at that file, as it's localepurge specific and upstream
projects shouldn't have any knowledge of it.
LINGUAS is the standard environment variable for this with gettext based
systems, and intltool honors it as well. I remember a longer description
of it in some info file, but right now only found
http://www.gnu.org/software/gettext/manual/html_node/Installers.html

Bugs are hopefully appreciated by maintainers for packages that don't
honor that environment variable (set via /etc/make.conf). If an upstream
doesn't honor it, they are probably just not using the standard
autoconf/automake glue for it correctly (or use a different build system
support for it wrongly or the build system is suboptimal on this).

Some Gentoo packages also have a LINGUAS USE_EXPAND, so show up in
emerge --verbose --ask world and similar outputs. This is typically used
when extra downloads are necessary for the languages (e.g firefox or
libreoffice per-language packs), and often don't honor the LINGUAS
unset == all languages convention.
Packages that don't need any extra downloads or long building time do
not expose this as USE_EXPAND USE flags and just silently work it out in
their build system, and that's the most reasonable approach for us.


Hope this helps,
Mart Raudsepp

Re: [gentoo-dev] Free Gentoo

[Mart Raudsepp]

Hello,

On L, 2012-01-21 at 21:01 +0300, . wrote:
 Hello there!
 
 Is there a chance that Gentoo may become a free distro?

You have all the tools available to only install FSF approved licensed
packages through the ACCEPT_LICENSE and related features. I'm sure
maintainers don't mind fixing license tags based on bug reports if some
are incorrect at places.
A Gentoo based distribution called Ututo GNU/Linux may be of interest to
you.

 I'm so unhappy with the fact that there are some non-free packages in
 the main tree.

Some of us need to get actual work done, and doing so without being
seriously impeded may require non-free software, or for even being able
to use their hardware.
Not all people are so radically viewed - meanwhile we provide the means
to achieve what you need per the above mentioned ACCEPT_LICENSE stuff.

 The main goal of the GNU project was to replace the proprietary Unix system.
 You are actually ruining this goal.

We are not paid by the FSF to achieve its goals. We are volunteers
getting our stuff done, developing a distribution to fit our needs and
minding our own business.

 I'm also dissatisfied with the name of the distro. Linux is the kernel
 not the whole system.

Feel free to go discuss that on the gentoo-users mailing list or the
forums. Here we'd like to get work done, and many of us want to be able
to easily use and configure open source and free software, not spend
hours on discussing and fighting about open source beliefs versus more
radical free software philosophies. We provide the means, and e.g Ututo
distribution and thousands of Gentoo users make use of it.


Best Regards,
Mart Raudsepp
Gentoo Linux developer, GNOME team

Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking

[Mart Raudsepp]

On L, 2011-11-26 at 12:43 +0530, Nirbheek Chauhan wrote:
 Hello folks,
 
 Attached is a short news file announcing the unmasking of GNOME 3.2
 with a link to the upgrade guide. Since GNOME 3 is already in the
 tree, and the news file content is straightforward, I'd like to commit
 this in 24hrs if there are no problems.
 
 It can also be found here:
 http://dev.gentoo.org/~nirbheek/gnome/2011-11-26-gnome3-unmask.en.txt
 (will be updated on the basis of comments).
 
 A question: it currently restricts only on the basis of If-Installed,
 but is there a workaround for the absence Display-If-Visible filter?
 If there isn't, I'll commit it as-is.

I think it'd be bad to get the news item out like that now for stable
users, and then after a long time once we stabilize it (if ever), it's
been long forgotten and marked away as read. Maybe the keyword checks
should be re-added for now and edited away later if necessary (before
stabling)?

Re: [gentoo-dev] RFC: Remove USE=v4l2 and rename the consumers to plain USE=v4l?

[Mart Raudsepp]

On T, 2011-05-17 at 03:48 +0300, Samuli Suominen wrote:
 And after the bugs are mostly (or all) dealt with, I suggest we remove
 USE=v4l2 and make USE=v4l mean:
 
 Enable support for video4linux (with or without userspace library libv4l)
 
 And rename the pkgs using USE=v4l2 to USE=v4l.  Since there will be
 only video4linux version 2, using libv4l or without (or possibly using
 libv4l compability layer for libv4l1).   But no more straight up version
 1 support since videodev.h is gone since Linux 2.6.38

I think for a while people would read v4l as v4l1, as v4l did denote
version 1. Any reason not to congregate everything to USE=v4l2
instead?

-- 
Mart Raudsepp

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Mart Raudsepp]

Hello,

On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote:
 http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt
 
 Please note that you must now update ChangeLog with each commit. For
 more information please see the meeting log and the preceding mailing
 list thread:
 
 http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt
 http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml


While I always was, and still am quite a strong proponent for
ChangeLogging removals, does this mean I need to spam the ChangeLog for
small or negligible affect mistakes and fix it probably even before any
rsync master updates have gone by, while said fix is more or less
covered by the previously committed ChangeLog entry of the same date?

To make it more clear, here's an example from the past:

I didn't have scripts for gstreamer split bumps before, and it was an
unwritten rule back then that for one of them I forget to edit the
required gst-plugins-base version in the ebuild to its new requirement
before repoman committing, and notice it within 5 minutes of committing.
Then I would just fix it up, and commit without a ChangeLog update (as
it's just noise to curious users), as the correction to the required
version is part of the Version bump work; plus the nature of the
packages is as such, that almost completely surely the new enough
gst-plugins-base version will be on the users system anyway, as other
new versions of the (more widely used) splits got it correctly earlier
on the first commit.

So am I required to ChangeLog such trivialities too now?
There seems to have been a slight discussion about typos and whitespaces
during the meeting, but I didn't see any conclusion on a cursory reading
and then it was just voted strict.

As a separate note, I'm also a strong proponent of writing in ChangeLogs
a bit about what has changed upstream for a version bump, so that users
can see the important things BEFORE upgrading (and
having /usr/share/doc/${PF}/NEWS* readily available); of course until
that doesn't significantly delay the version bumps themselves due to
potentially increased work for the maintainer.

-- 
Mart Raudsepp

Re: [gentoo-dev] Lastrite: LinNeighborhood and mondo

[Mart Raudsepp]

On L, 2010-10-30 at 11:22 +0300, Samuli Suominen wrote:
 # Samuli Suominen ssuomi...@gentoo.org (30 Oct 2010)
 # Still using GTK+-1.2
 # Masked for removal in 30 days
 net-misc/LinNeighborhood

What are the alternatives? Nautilus and Thunar?
I guess the suggestion is to mention in the mask message what could be
used instead.

 # Samuli Suominen ssuomi...@gentoo.org (30 Oct 2010)
 # For Linux 2.4, bug 335455. Time to upgrade to 2.6.
 # Masked for removal in 30 days
 sys-apps/mondo

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org

Re: [gentoo-dev] Policy for late/slow stabilizations

[Mart Raudsepp]

On E, 2010-06-28 at 09:49 +0200, Thilo Bangert wrote:
 Markos Chandras hwoar...@gentoo.org said:
  On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote:
   On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras hwoar...@gentoo.org 
 wrote:
What? I am talking about exotic arches and I didn't say to drop to
entire stable tree. Just to shrink it in order to keep it up to
date more easily
   
   But my question stands: what really is the advantage of having a
   stable tree, when you could better invest your time in keeping the
   testing tree up to date and working? Most production systems are
   running x86, right? Are stable versions of minority architecture
   installations really that much more stable than testing versions?
  
  Because a stable tree it is supposed to work. Testing tree on the other
  hand is vulnerable to breakages from time to time. We can't always
  ensure a working testing tree. We are people not machines. We tend to
  brake things and this is way we have the testing branch.
 
 also the stable tree implies security support (GLSAs etc).

Stable tree does NOT imply security support. I can understand why users
might think that, though.
A few architectures that have a stable tree are not security supported
(GLSAs waiting for them, etc), as can be seen from comparing the arches
with stable trees to the security supported architectures list over at
http://www.gentoo.org/security/en/vulnerability-policy.xml
(at least arm, ia64 and sh by my quick comparison)


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio

Re: [gentoo-dev] Re: New global USE flag: introspection

[Mart Raudsepp]

On K, 2010-06-23 at 09:33 +0530, Arun Raghavan wrote:
 On 23 June 2010 01:47, Mike Auty ike...@gentoo.org wrote:
 [...]
  Which should not be an issue since any library that has some sort of
  introspection can use this flag (and the use.desc can be changed
  appropriately at that time if it does not use gobject-introspection).
 
  Why have to change it in the future (and probably split it into two
  flags then), when the choice hasn't been made yet?  Or, to put your own
  question to you, why are you vehemently for introspection when others
  have shown concern with the choice?  As far as I can see, the only
  difference is requiring a slightly longer use_enable line.
 
 Mostly because I don't want to coin a new term if it's not absolutely 
 necessary.
 
 That said, you're right - more people seem to be comfortable with
 gintrospection than plain introspection. If no further objections
 arise, we'll go with gintrospection.

I object.


gintrospection doesn't describe anything. It's very hard to understand
from the USE flag name that it deals with introspection, as opposed, to,
uh, gint's or who knows what.

USE flags starting with g usually denote support for some GNU package,
not gnome, per some actual looking at use.desc.

Nothing stops QtCore packages to use the same USE flag name for the same
purpose - introspection. USE flags are primarily supposed to enable
certain functionality, not allow to depend on this package. That
functionality is introspection. It just happens that the only framework
this is currently supported in is on top of GObject and the appropriate
gobject-introspection package.
Introspection has nothing to do with GNOME. Most GNOME modules are
written in C and don't need introspection information (primary exception
being gnome-shell and its javascript stuff). All packages that currently
depend on PyGTK will and should eventually use PyGi and in turn the
introspection information provided by the necessary used libraries. This
includes many GUI software that has no relation to GNOME, other than
using the same toolkit.

I can't imagine what else introspection means than what this USE flag is
proposed to provide to many libraries (would api-introspection be more
clear?), all of which just happen to be GObject based right now (and as
such detailed in the currently proposed global USE flag description), as
other base frameworks currently don't have any introspection support to
our knowledge.

Note that you will soon not be able to really avoid
gobject-introspection package on desktop systems (unless you are a Qt
junky that refuses to install anything not based on Qt), so this USE
flag really isn't about dependency control at all. It's about defining
if embedded images need a .typelib introspection file at runtime or not.
So that embedded GUI image builders would be able to globally disable
the USE flag and enable it per-package as necessary by applications
(represented with USE depends). If it weren't for that, we'd simply
always install them, they are just not that big compared to the include
files that get always installed too. But embedded guys can easily delete
all of /usr/include, but typelibs (containing the introspection data)
may be necessary at runtime.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio

Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?

[Mart Raudsepp]

On Sat, 2010-04-03 at 12:50 +0300, Petteri Räty wrote:
 I don't think later is valid resolution. If there's a valid bug it just
 means it's never looked at again. If the bug is not valid then a
 different resolution should be used. So what do you think about
 disabling later? I would like to avoid things like this:
 
 https://bugs.gentoo.org/show_bug.cgi?id=113121#c21
 
 Not applicable to the bug above but in general our social contract says:
 We will not hide problems

The problem is really the RESOLVED connotation and the hiding that goes
along with that on searches, etc.

The LATER status itself can be useful when used properly (more as
ASSIGNED LATER). In the lack of that some bigger teams might need to
think of other methods to get things meant for LATER out of main views
of huge bug lists.

In my case, I want to have a gnome saved search that shows all OPEN
(non-LATER) bugs directly assigned to gnome, and another saved search
that shows those where gnome@ is merely in CC, or anything marked as
LATER. Though that might not be achievable, so three saved searches
really.
More useful might be a date field upon which it will simply
automatically re-open. Maybe something one is unable to set more than 30
or so days into the future.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Split desktop profile patches news item for review

[Mart Raudsepp]

On Fri, 2010-03-12 at 16:47 +0100, Ben de Groot wrote:
 
 Even so, if we choose not to implement the split now, there are
 problems that need addressing in the current situation. The Qt team
 finds the mysql dependency that was added to the desktop profile
 three months ago (see bug #291996) unacceptable. How would you
 propose to solve this without splitting the desktop profile?

Probably by solving the issue there. Either not requiring a mysql USE
flag in the relevant places, or USE defaulting it on there for now for
just that package; or package.use enabled in desktop profile, instead of
globally.



-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Split desktop profile patches news item for review

[Mart Raudsepp]

On Fri, 2010-03-12 at 11:48 +0200, Theo Chatzimichos wrote:
 I found your proposal about mixing profiles awesome, and I am willing to work 
 on this. In fact, I'm going to raise the issue on KDE's meeting this Thursday 
 at 20:00 UTC. Any freedesktop team members will be welcome there. But I'm not 
 going to step up from the current workaround I worked on, as things are not 
 that tragic. I will document and announce everything, and I will be watching 
 forums and IRC for some days to provide support. The only real problem in my 
 opinion would be this, people get confused about useflags and unexpected --
 newuse results. (btw I already announced it once in my blog, I will do it 
 again, and we'll also provide a news item, so I doubt this is even a real 
 problem as well).

I guess it's a question of how long the other proposal takes
implementing. If just a month or two, two migration within that time
period doesn't make so much sense. If we really estimate slow progress
there, then I guess we can have users deal with the multiple migrations
and some months of small benefits from the better profiles.
Just this situation with desktop profiles has existed for as long as
desktop profile have existed, so waiting a couple months more for the
perfect solution (while avoiding multiple migrations) doesn't sound like
a bad idea to me.

I appreciate you intending to take a lead on pushing the other proposal
too.

I guess I should review the gnome subprofile soon, I assume some of our
other guys already did though.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)

[Mart Raudsepp]

On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote:
 On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote:
  mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:
  
   Instead I think we should be improving eselect profile to support
   multiple inheriting /etc/make.profile files in a user friendly fashion,
   and in the end removing 249 subprofiles, instead of adding 28+.
   
  
  
  I vote for this one. A profile being a only contains what is interesting
  for that profile, and you can stash together some profiles into your
  own cocktail.
  Yeah, I know it sounds horrible, but it would still be better then to
  only be able to focus on one small set.
  
  For example if I am using the GNOME DE, and have someone other also
  using my computer, but who really wants to use KDE. Should I have to
  find out what from the KDE profile to enable in my env to make my
  GNOME-profile also tingle for KDE?
  
  I think having a set of base profiles for toolchains and alike (i.e.
  default, hardened) would be good. Then be able to add for example
  desktop/gnome or server and/or selinux profiles on top would be
  interesting. This also for maintainers, as for example PeBenito can
  focus on the selinux part of the profiles, and do not have to keep up to
  date with which hardened-compilers are currently masked/unmasked.
 
 While I agree in principle within mixins, no one here is discussing 
 the QA affect of it- right now we can do visibility scans of 
 combinations of gnome + amd64 + 2010 because they're defined.

What sort of QA affects do you imagine it having?
Though I'm talking in the context of what I proposed - using it for just
the target profiles that only tweak USE flags and other such defaults,
nothing else. I considered QA affects for that case, at least in my own
thoughts. I think QA would be checked anyhow there, as part of all USE
flags enabled assumpting testing or static testing of various USE flag
combinations of a package (e.g, for statically finding circular
dependencies or the like).

If you put selinux and toolchains in the mix, that indeed could be
problematic to QA. Though one could probably define some profiles
somewhere that would get used for QA testing, but not exposed to users.

Do you foresee bad QA affects for the for the
desktop/developer/gnome/kde/server profiles case too, or just when
mixing in selinux/toolchains/etc?

 If there is a shift to having users do the combinations themselves 
 (rather then combining w/in tree), there won't be visibility scans for 
 it- end result, more broken deps should be able to slide by, more 
 horked cycles, etc.
 
 A solution there would be useful- one that preferably doesn't involve 
 scanning every possible permutation of mixable profiles (you would 
 *not* like the speed affect that would have on repoman).
 ~harring

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Split desktop profile patches news item for review

[Mart Raudsepp]

On Thu, 2010-03-11 at 23:20 +0100, Ben de Groot wrote:
 On 11 March 2010 21:20, Mart Raudsepp l...@gentoo.org wrote:
  On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote:
  Seeing as there were no further comments, I think we are good to go!
 
  I suggest reading my comments...
 
 Unless I missed something, you didn't make any comments on this
 thread.

The subthread got renamed to more fit its purpose.

 If you mean the thread you started that tangentially took off from this
 one, about eselect profile improvements: I support that proposal,
 but it will take some time to get implemented. Is anyone already
 working on that?
 
 In the meantime I see no reason for that to halt or postpone the
 current desktop profile improvements as prepared by Theo.

I argued that it's a bad idea to add yet more profiles, when we could
avoid that (while even improving things additionally).

But I guess I'll have to bring some direct points why I think
implementing the alternative as I described ASAP is better than ever
doing this gnome/kde subprofile thing:

* The split desktop profile plan retroactively modifies 2008.0 and 10.0
profiles. Not a good thing for obvious reasons. (Of course the
subprofiles could also be added together with a new release, as proposed
for the alternative idea)
* Adding yet more subprofiles, increasing repoman and pcheck time,
possibly confusing users (migration things; changing USE flags in a
perceived stable release profile leading to unexpected --newuse
triggering, etc)
* Making it harder to get both GNOME and KDE things out of a profile
(though the common things in desktop profile right now is quite
suboptimal for GNOME)
* Putting the problem of suboptimal subprofiles handling under the
carpet again, greatly reducing the motivation for people to work on the
alternative better proposal

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Split desktop profile patches news item for review

[Mart Raudsepp]

On Thu, 2010-03-11 at 02:36 +0100, Ben de Groot wrote:
 On 8 March 2010 02:17, Theo Chatzimichos tampak...@gentoo.org wrote:
 
  I attached the news item, please review. Meanwhile, I'll create docs 
  patches.
 
  Also, I'm CCing hardened as my No.1 question was not answered. Please do.
  Thanks
 
 Seeing as there were no further comments, I think we are good to go!

I suggest reading my comments...

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)

[Mart Raudsepp]

Hello,

On Thu, 2010-03-04 at 16:52 +0200, Theo Chatzimichos wrote:
 Hello
 I have managed to split the desktop profile to gnome and kde submenus. The 
 result can be found in kde-crazy overlay (not in layman) [1]

I think this whole approach of adding yet more subprofiles is highly
suboptimal. You are wanting to add at least 28 more subprofiles (the
number would reach the 80s if including hardened/mips, etc), whereas we
just had a sort-of discussion on how we have too many of them already at
http://archives.gentoo.org/gentoo-dev/msg_be393426980d12f341cabccfe5ab10aa.xml

Instead I think we should be improving eselect profile to support
multiple inheriting /etc/make.profile files in a user friendly fashion,
and in the end removing 249 subprofiles, instead of adding 28+.

Also, even after doing the addition of kde/gnome subprofiles, users
would like a better eselect profile for multi-inheriting, if they use
both GNOME and KDE on the same system (using both once in a while, or
multiple users on the same machine), as gnome/kde specific USE flags
would be only in their separate subprofiles then, and you want both.

So what I believe should be done instead of adding yet more subprofiles
is improving eselect profile to have good support for
multi-inheriting /etc/make.profile
With at least portage, one can have /etc/make.profile/ be a directory,
which is basically a user created profile in its own right, whereas with
the symlink to profile directory method, the toplevel profile used is
simply one in $PORTDIR/profiles/. Through that one can do a
multi-inheriting profile, so you could have a parent file in there,
with the following contents:

/usr/portage/profiles/default/linux/amd64/10.0
/usr/portage/profiles/targets/desktop

And you would effectively have the same as a symlink pointing
to /usr/portage/profiles/default/linux/amd64/10.0/desktop

Now as targets/ don't really do anything more than add USE flags to the
global set or package.use, we could support adding targets to the basic
release set for an arch with eselect profile, so one could add both a
future gnome and a kde target, if desired. Or even also server flags as
well, if so desired by the user. And that without having to have all
those subprofiles per-arch/per-release profiles.

Once users are converted over to that method, there's no need for all
the target specific subprofiles we currently have. This at the last
count was 249 subprofiles for all the per-arch desktop/, server/ and
developer/ subprofiles, and we could remove them all, or simply phase
out when the 10.0 release phases out, replaced with a new release that
doesn't have the desktop/server/developer subprofiles in the first place
- giving a good migration and phase-out point.


So the steps for implementing this would be something like the
following:


* Improve eselect profile to have user friendly support for
multi-inheriting /etc/make.profile/, possibly special casing targets/ as
an add-on option/flag sort of thing.

* Test and stabilize the eselect-profile with those features

* Introduce the new gnome/kde targets and reorganize things. I would
suggest a new directory for this, that can have the options that
eselect-profile allows to add-on easily. For example basic-desktop,
gnome, kde, gentoo-developer, server, and so on - internally we can
inherit things as desired in there as an implementation detail (gnome
and kde can inherit from basic-desktop). Even adding lxde and xfce
targets is fine and simple, they can just inherit basic-desktop and
users don't need to find out that to get a target suitable for xfce,
they would have to go with the broad desktop or basic-desktop
target.
If targets is the best directory name for it, then that's fine too.
The current ones can be moved away to somewhere else, atomically with
tweaking all the inherits from default/ and hardened/ profiles at the
same time.

* Possibly have a new release set, that has no subprofiles from the
start, and can be accompanied with all the news and awareness raising it
takes to get users use this new method.

* All the things I forgot about.

* Eventually phase out completely the previous exponentially
increasing  subprofiles mess.

3) Profit.


Obviously I doubt to have time to work on it personally. I hope the guys
pushing for adding even more subprofiles can pick up this idea and
implement it, if discussion gives consensus this is a good way forward.



-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Mart Raudsepp]

On N, 2010-03-04 at 12:50 +0100, Ben de Groot wrote: 
 2010/3/4 Dawid Węgliński c...@gentoo.org:
  On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
  I'm not talking about selectively disabling cups. My proposal is
  to no longer enable the cups useflag in the base profile.
 
  How is that going to fix circular dependency problem? What will you do if 
  every
  user add cups to USE in make.conf? Say we don't support cups turned on by
  default? I hope no. Removing this flag from profile will not fix any 
  problem but
  hide it.
 
 It will fix the out of the box circular dependency for people who
 switch to a default desktop profile. This is the main problem we
 need to solve now.

The main problem to solve here is the circular dependency that you
yourself introduced as a co-maintainer of poppler, by converting poppler
to be monolithic. This from the outside looks like it was done to reduce
your maintenance workload in the (possibly accidental) expense of users
who are now getting circular dependencies in a fairly common setup.

If cups should be enabled in the desktop profile or not is a completely
different question.

The correct solution here is to fix the core problem that is now
happening - not to start removing common desktop needed USE flags from
the desktop profiles to delay the correct fix for this circular
dependency you guys have introduced for us.

 Certain useflag and package combinations
 will trigger a circular dep, that is a know occurrence in Gentoo.
 But at least with a default configuration things should work out of
 the box. For other configurations there are workarounds (in this
 case: install gtk+ without cups, or poppler without cairo enabled
 first).

Circular dependencies shouldn't happen in any situation. I claim there
is always a solution to avoid it. A different question is if the cost of
the solution is acceptable compared to the problems it causes. I believe
an inconvenience for the poppler maintainers is completely justified
here for the benefit of users in the form of properly split packages,
considering how this affects a majority of desktop users (problem hidden
by default or not).


I'll later make sure there is a bug for fixing this circular dependency
mess properly. I believe the only possible fix is to split poppler back
to at least core, bindings and utils, as it seems to be a problem due to
poppler-utils requirement by cups. It doesn't need poppler-glib, so
utils and bindings being a separate package, as it always was before,
would nicely solve it.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps

[Mart Raudsepp]

On E, 2010-03-01 at 13:40 -0800, Zac Medico wrote:
 On 03/01/2010 01:24 PM, Ben de Groot wrote:
  For some reason beyond my understanding, we have the cups useflag
  enabled by default in profiles. This has started to generate circular
  dependencies, at least for desktop profile users (gtk - cups -
  poppler - gtk). I propose we no longer enable the cups useflag.
 
 If you don't want to disable the cups flag globally, you might
 choose to disable for gtk+ by default in profiles/base/package.use
 like this:
 
   x11-libs/gtk+ -cups
 
 That can be overridden by user's USE=cups setting in make.conf, so
 the only effect would be to break the circular dependency by default.

I don't think there was any such problem until poppler maintainers
decided to unsplit poppler into one big packages with USE flags again
instead of the nice split poppler, poppler-glib (that should have been
named poppler-cairo probably instead), poppler-qt3, poppler-qt4 and
poppler-utils.
I don't believe we should selectively cripple one GUI toolkit with not
having proper printing support out of the box on a desktop profile,
while others do, just because maintainers are lazy.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://blogs.gentoo.org/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements

[Mart Raudsepp]

On Sun, 2009-08-30 at 16:11 +0200, Matthias Schwarzott wrote:
 Hi there!

A late hello,

 Second point: udev-145 bundles a lot of new extras, but they can only be 
 enabled/disabled all or nothing.
 
 These extras are:
 * udev-acl: Apply consolekit permissions to devices for users (audio, video, 
 joysticks, scanner, cameras, ...)
 * usb-db: Provide udev-rules with device names of pci and usb devices
 * hid2hci: Special utility to fix resume of some hid devices
 * keymap: Auto-configure model specific keys found on many laptops 
 (brightness up, next song, www browser, or suspend)
 * modem-modeswitch: Switch modems that provide virtual cd-drive with drivers 
 to modem mode

I think the thread hasn't seen an answer to the question of when these
are actually used or useful, as asked in another subthread as well.

 * gudev: glib/gobject support for libudev

Would it be possible to have this in a separate package? Of course then
with a temporary compatibility PDEPEND on it with udev[extras] until
packages needing gudev migrate over.
And what of the above listed other things besides core udev does gudev
require or potentially use?

 This makes udev depend on these libs:
 libacl, libglib2, libusb, usbutils, pciutils, gperf
 
 Up to now I have just added use-flag extras to control these. But I suppose 
 that udev-acl and maybe gudev is a hard requirement for newer hal or 
 devicekit versions. And upstream thinks these should be enabled by default.
 
 Are any of these extras considered harmful?

On some non-desktop systems perhaps, yes.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] URGENT: exotic arches need Qt 4.5.3 stabilization

[Mart Raudsepp]

On Mon, 2009-11-09 at 14:33 +0100, Ben de Groot wrote:
 I am of the opinion it is irresponsible to leave vulnerable versions of Qt 
 with
 known security bugs any longer in the tree. The Qt team therefore requests
 that arches that have not done so already move quickly on stabilizing Qt
 4.5.3, see bug 290922 and 283810.

It is more irresponsible and outright wrong to remove the latest stable
revision of a package for some arches, despite security implications.
Hard masking constitutes the same - the last stable version is not in
stable visibility anymore.

You can however remove the keywords of the arches from older versions
that do have a newer version/revision stable as seen in all profiles.


 We plan on REMOVING or at the very least HARDMASKING pending removal
 all =4.5.2 ebuilds by the end of this week. This means that arches that have
 not stabilized 4.5.3 would loose their stable Qt4 version.

How do you see this being acceptable for the users of these
architectures? Many of these architectures that are lagging behind not
being even security supported architectures.

 Please let us know if there is any way in which we can assist arches. We
 are aware that some arches are down to one active person. But if there is
 no other way, maybe the status of such arches should be reconsidered.

It seems most these arches that are at ~1 person are not security
supported either

 We especially request ppc64 to be marked as an experimental arch, as it
 is the worst one lagging in stabilization. See bug 281821 for a poignant
 example, a 3 months open security bug.

First its security supported status should be considered, not making it
an experimental arch, as that could very well throw it in a backwards
spiral of getting more and more problematic due to repoman iirc not
checking issues with it by default.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Improve policy of stabilizations

[Mart Raudsepp]

On Sun, 2009-11-01 at 17:36 +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
 Some packages have new releases more than once a month and sometimes it's 
 reasonable
 to not skip stabilization of any version. Given version of a package is 
 usually no
 longer tested by users after release of a newer version, so I suggest the 
 following
 change to the policy of stabilizations:
 Stabilization of given version of a package can be requested if this version 
 has been
 in the tree for at least 10 days and a newer version of this package has been 
 added
 to the tree.

I am not aware of there being a 30 day policy, and have always
considered it as a guideline, not policy. If the maintainer sees that 10
days is good for the package sometimes, I see no problem with it. Arch
teams might kindly request explanations of why the quicker
stabilization, but I don't represent any myself, but in case of quicker
stabilization of package I maintain myself I try to state in the
STABLEREQ bug why the quicker stabilization.

Is it stated in any documentation that 30 days is a policy?

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] News Item: GNOME 2.26 upgrade

[Mart Raudsepp]

On T, 2009-10-06 at 02:11 +0300, Mart Raudsepp wrote:
 Hello,
 
 See attached news item for consideration.
 Suggestions on how to improve it, including the text section, very
 welcome.

Attached is a tweaked version with wording fixes from dabbott and author
as me instead of team, as I understood to be more appropriate.

I will probably wait for further reviews for a couple hours and then
commit this and proceed with CCing arch teams for the stabilization
work.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
Title: Upgrade to GNOME 2.26
Author: Mart Raudsepp l...@gentoo.org
Content-Type: text/plain
Posted: 2009-10-06
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: gnome-base/gnome-2.26.0
Display-If-Installed: gnome-base/gnome-light-2.26.0
Display-If-Installed: gnome-base/gnome-session-2.26.2
Display-If-Installed: gnome-base/gnome-menus-2.26.2

We are pleased to announce the stabilization of GNOME-2.26. Users are 
strongly encouraged to read the GNOME 2.26 Upgrade Guide, to avoid any 
possible issues relating to the upgrade, such as Applications menu items 
disappearing, or nautilus constantly restarting when it is configured to 
not handle the desktop.
 
Please read the Gnome 2.26 Upgrade Guide:
http://gnome.gentoo.org/howtos/gnome-2.26-upgrade.xml



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] News Item: GNOME 2.26 upgrade

[Mart Raudsepp]

On K, 2009-10-07 at 06:24 +0530, Nirbheek Chauhan wrote:
 On Tue, Oct 6, 2009 at 4:51 PM, Rémi Cardona r...@gentoo.org wrote:
  not handle the desktop. = not handle the desktop's background image
 
 
 I thought it handled the icons on the desktop as well?

yeah, we cleared that on IRC and the e-mail was ack either way, but
s/desktop/desktop icons might be more clear.

Anyhow, how to I get eselect news or news-tng to actually see these news
items out of a svn checkout when my PORTDIR is from CVS, not rsync?
strace'ing eselect news{,-tng} suggests they stat metadata/cache, but
doesn't even try to look for a metadata/news with my setup, so I can't
verify on my end everything is working right to proceed with this..


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] News Item: GNOME 2.26 upgrade

[Mart Raudsepp]

Hello,

See attached news item for consideration.
Suggestions on how to improve it, including the text section, very
welcome.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
Title: Upgrade to GNOME 2.26
Author: Gentoo Gnome Team gn...@gentoo.org
Content-Type: text/plain
Posted: 2009-10-06
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: gnome-base/gnome-2.26.0
Display-If-Installed: gnome-base/gnome-light-2.26.0
Display-If-Installed: gnome-base/gnome-session-2.26.2
Display-If-Installed: gnome-base/gnome-menus-2.26.2

We're pleased to announce the stabilization of GNOME-2.26. Users
are strongly encouraged to read the GNOME 2.26 Upgrade Guide, to
avoid or know beforehand any possible issues relating to the
upgrade, such as Applications menu items disappearing, or nautilus
constantly restarting when it is configured to not handle the
desktop.

You may find the Upgrade Guide available online at
http://gnome.gentoo.org/howtos/gnome-2.26-upgrade.xml



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] New 10.0 profiles are in repository

[Mart Raudsepp]

On Thu, 2009-08-06 at 17:19 +0300, Samuli Suominen wrote:
 Jeremy Olexa wrote:
  Samuli Suominen wrote:
  As subject says,
  default/linux/*/10.0
  default/hardened/linux/*/10.0
  Profiles are up, the 10.0 releng / 10th anniversary ones.
 
  Given the multi-inheritance nature of profiles, it is not obvious what
  changed to me. So, what is new with 10.0 profiles or are they a
  cosmetic naming change?
 
 Cosmetics for now. I was asked to clone the 2008.0 ones, and that was
 done this morning. Don't know yet if release wants some changes. If
 someone wants to e.g. change make.defaults, now would be a good time to
 suggest proposals...

I wanted to work at some point on splitting out gnome and kde profiles
to separate ones. Perhaps desktop profile could be a generic universal
one with USE flags enabled that rox/lxde/fluxbox and so on would like as
well, and then gnome adds its stuff, and kde adds its own stuff.
Or desktop could be one that enabled both GNOME and KDE stuff as now, by
multi-inheriting both gnome and kde profiles.
Or perhaps both a lowest common denominator desktop-base profile and a
big desktop one enabling everything...

The current state is pretty suboptimal.
With desktop profile you get KDE/Qt flags and also GNOME flags, yet none
of them is complete of what you'd like to have - e.g in GNOME case most
everyone would want to add nautilus, gnome-keyring and some more USE
flags, but you can't do that by simply selecting the appropriate desktop
profile, so many don't get the correct and desired things enabled for
their desktop environment of choice.

 So for the 3 prefix-linux profiles that's using 2008.0 now, you can feel
 safe and simply change the parents to point at 10.0.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Adding a warning to description of global flag profile.

[Mart Raudsepp]

On Fri, 2009-07-24 at 12:04 +0300, Samuli Suominen wrote:
 Would it be OK if I change
 
 [-] profile - Adds support for software performance analysis (will
 likely vary from ebuild to ebuild)
 
 To
 
 [-] profile - Adds support for software performance analysis
 (WARNING: DON'T ENABLE UNLESS YOU KNOW WHAT YOU ARE DOING.)
 
 Or something similar? Suggestions welcome. People seem to add it
 randomly in combination with -fomit-frame-pointer which breaks with -pg
 as expected.

Note that -fomit-frame-pointer is the default with stable gcc (4.3 at
least) on many architectures - some of those that can still debug with
gdb without frame pointers thanks to location lists generated to debug
sections by default with -g on those platforms. This includes at least
amd64, and I believe x86.
However it might not default enable in combination with -pg, not sure
about that. Lets say this is a call for testing that, as combinatory
CFLAGS enabling -fomit-frame-pointer is your reasoning here.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] 2009 Council Elections

[Mart Raudsepp]

On E, 2009-06-29 at 12:32 +, Ferris McCormick wrote:
 On Sun, 2009-06-28 at 18:12 -0500, Dale wrote:
  Roy Bamford wrote:
  
  
   You agree that common sense can't be used and admit that a corner case
   exists that would in effect have the trustees pointing out to the
   council that they had made an error of judgement and need to reverse a
   decision that the last meeting made. I would prefer never to have to go
   there.
  
   I do not agree that an all proxy council meeting shows that the council
   does not take its responsibilities very seriously, rather that real
   life has hit everyone at the same time and they have appointed
   proxies. GLEP39 does not even set a limit on the maximum number of
   council members who may be proxied at any single meeting.  
  
   As I have already said, I'm against the idea of proxies altogether.
   We should amend glep39 to remove proxies and ensure that council
   members are drawn from the developer community. Of course, that
   does not eliminate the possibility of the trustees pointing out to the
   council that they need to reverse a decision but it does ensure that
   decisions are made only by council members who are Gentoo developers.  
  
  
  I'm just picking a random message so no fingers being pointed here.
  
  As a long time Gentoo user, I have to ask.  Why is that EVERYONE on the
  council must be there or have someone there to represent them?  Would
  Gentoo come to a end if one person or even two people were not present? 
  
 All that's required is a quorum (4 out of 7) to hold a meeting.

And when you have one less, it apparently immediately means a new
council election.
I guess that's one reason these days to always appoint proxies. The
other is otherwise getting a missed meeting record, then a slacker mark
and then a boot.
And then there's the long tradition of always when a meeting
un-attendance is foreseen a proxy getting appointed.


I guess the new council can think about this, but
a) time spent on figuring out such rules and whatnot to have to deal
with unfortunately happening corner cases is time better spent on
getting actual Gentoo improving done
b) I don't think the council itself should be having so much to do with
any such figuring out
c) there are far bigger reaching restructuring ideas in the works for
future proposals

  I do agree that if a proxy is going to be used, they should be a
  developer.  If it is not that way now, it should be changed.  I been
  using Gentoo for years and wouldn't even consider serving as a proxy.  I
  would certainly not want to be a tie breaker on a vote.
  
  As a American that sees his own country's government getting out of
  control, never count on common sense.  Elected people rarely have any. 
  If they do during the election, it disappears after taking their
  position.  I think the vast majority of people here have seen that over
  the years.
  
  My $0.02 worth.
  
  Dale
  
  :-)  :-) 
 
 Regards,
 Ferris
-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Gentoo Council Reminder for June 25

[Mart Raudsepp]

On E, 2009-06-22 at 15:18 -0400, Thomas Anderson wrote:
 (This is late because I was traveling and dev-zero is/was on devaway.)
 
 This is your friendly reminder! Same bat time (typically the 2nd  4th
 Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
 irc.freenode.net) !
 
 If you have something you'd wish for us to chat about, maybe even vote
 on, let us know! Simply reply to this e-mail for the whole Gentoo dev
 list to see.
 
 For more info on the Gentoo Council, feel free to browse our homepage:
 http://www.gentoo.org/proj/en/council/
 
 
 Attached is the preliminary meeting agenda.

I acknowledge that agenda, or something.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Gentoo Council Reminder for June 25

[Mart Raudsepp]

On E, 2009-06-22 at 21:23 +0100, Ciaran McCreesh wrote:
 On Mon, 22 Jun 2009 22:13:31 +0200
 Ulrich Mueller u...@gentoo.org wrote:
  | (so that certain people can't vote and discuss things based upon
  | what they think the feature is without bothering to find out if it's
  | anything to do with what they assume).
  
  Of course that's not desirable. But can you give a concrete example
  where such a thing happened?
 
 Yup. Some of leio's huge drawn out objections to EAPI 3 that wasted
 huge amounts of my time were based upon him only having read the short
 name we chose for things.

Thanks for your very detailed concrete examples where such a thing
happened.
And I'm sorry to have wasted your precious time by doing the opposite of
what you claim here and still objecting to things that don't make sense.

Now lets get back to useful things, like giving code names that make
sense and don't need to be looked up with what is actually meant when
they are being referred to in short names.


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[Mart Raudsepp]

On E, 2009-06-01 at 10:48 +0200, Patrick Lauer wrote:
 People I nominate:
 
 * leio / mraudsepp, because he's done a really good job protecting the 
 distro's interests

I accept


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)

[Mart Raudsepp]

On K, 2009-06-03 at 21:02 +0300, Samuli Suominen wrote:
 Mart Raudsepp wrote:
  On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote:
  USE network is used by 9 ebuilds, and one is using USE networking which
  can be converted, that'd be 10.
 
 USE network Enable networking support
 
 
 
  USE 3dnowext is basic optimization, 3 ebuilds, but it should be with mmx
  and others.
 
 USE 3dnowext Adds support for 3dnowext multimedia processor instructions
 
 (desc. almost copy from 3dnow desc)

Maybe it could say in parenthesis what kind of processors have it (foo
and later vendor bar CPUs) or something if it can be classified like
that. I think it's still pretty AMD specific and introduced with a
certain family.

 
  USE static-libs to enable or disable static libs (archives), used by 6
  ebuilds, soon more.
 
 USE static-libs Build static libraries

I think this should be clear on that dynamic libraries are still built
and installed

Build static libraries in addition to shared libraries

 
  USE mtp is used by 6 ebuilds, enables Media Transfer Protocol support.
 
 USE mtp Enable support for Media Transfer Protocol
 
 
  Any objections?
  
  Could you share it with everyone what the proposed global descriptions
  of these USE flags would be,

 and what the individual local USE flag
  descriptions currently are?

You seem to have ignored this part. I guess I'm just lazy to go look up
what packages actually have those as a local USE flags and go viewing
metadata.xml of each of those.

 So that everyone won't need to look up by
  themselves or guess the global description.
  
 
 
 Thanks Samuli
 

Re: [gentoo-dev] New global USE flags (network, 3dnowext, static-libs, mtp)

[Mart Raudsepp]

On K, 2009-06-03 at 02:13 +0300, Samuli Suominen wrote:
 USE network is used by 9 ebuilds, and one is using USE networking which
 can be converted, that'd be 10.
 
 
 USE 3dnowext is basic optimization, 3 ebuilds, but it should be with mmx
 and others.
 
 USE static-libs to enable or disable static libs (archives), used by 6
 ebuilds, soon more.
 
 USE mtp is used by 6 ebuilds, enables Media Transfer Protocol support.
 
 Any objections?

Could you share it with everyone what the proposed global descriptions
of these USE flags would be, and what the individual local USE flag
descriptions currently are? So that everyone won't need to look up by
themselves or guess the global description.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

[Mart Raudsepp]

On K, 2009-05-20 at 11:36 -0400, Richard Freeman wrote:
 Mart Raudsepp wrote:
  
  The maintainer-wanted team owns that foo package then, which is why
  having a different mail alias than the existing one for new package
  requests that aren't in gentoo tree yet would be a good idea.
  
 
 Ok, I think I see where you're coming from.  Essentially 
 maintainer-wanted is a group for people who want to collectively manage 
 ebuilds that don't otherwise fall into any particular project/herd. 
 Almost like a misc herd.
 
 If the packages are actually being maintained then I have no issues at 
 all with the proposal - in fact I'd endorse it (for what little that is 
 worth).  However maintainer-wanted seems like a bit of a misnomer - 
 these ebuilds would in fact have a maintainer.  Perhaps another name 
 could be used so that it is easy to distinguish between:
 
 1.  Packages not in the tree (bugzilla requests/etc).
 2.  Packages in the tree that truly nobody is caring for.
 3.  Packages in the tree that the proposed project is caring for but 
 would love to see adopted into another herd/project.
 4.  Packages that are part of a more dedicated project/herd, or which 
 have attention from one or more particular developers.
 
 I don't question the value in having group #3 which I think is what 
 you're proposing.  But, perhaps it should have a specific name/alias so 
 that we can tell that a package belongs to it.  Your proposed team could 
 scour #1/2 for new builds, and bump builds in #3 back to #2 if 
 necessary.  Treecleaners would prune #2 and ignore #3.  Of course, 
 cooperation with Sunrise would also be a plus.

Yes, that's all pretty much what I have in mind here. I have also
acknowledge in various e-mails that we need a better naming for the
herd name (not necessarily for the team) to distinguish bugzilla bugs
that are maintained by this proposed team and new package request bugs
that are still waiting for someone to pick them up.
Also I hope the flow from #3 to #2 doesn't end up happening often and
that the team would be caring about the packages in acceptable quality
until it can flow to under #4. So some (in)formal policies amongst the
team members to ensure the team doesn't get overwhelmed would seem
appropriate.

I hope the person I found to lead this project (if in the lack of others
willing to do that when it becomes an actual project) clarifies things
in the project proposal draft that opened this thread, which could then
in the end be mostly re-used as the project page text on gentoo.org


-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

[Mart Raudsepp]

On N, 2009-05-28 at 11:55 +0400, Peter Volkov wrote:
 В Чтв, 14/05/2009 в 03:32 +0300, Mart Raudsepp пишет:
  Project maintainer-wanted
  =
 
 Mart, I think that it's good idea to create such project but with a
 different goals. I think currently maintainer-wanted alias is missed by
 most developers: new packages are assigned there and from time to time
 random developer picks package he needs or user moves ebuild into
 Sunrise but nobody actually cares about packages/mail going there in
 general. The goal of maintainer-wanted project could be just gather
 statistics and highlighting most popular/interesting packages there.
 Something like Top 10 most popular maintainer-wanted packages monthly
 e-mail could be really useful.

Good idea in my opinion, but in a different way - the team could
maintain such a (unordered) list with varying package count size and
pick the packages to put to portage tree by them out of that list as
well when the manpower allows to maintain the package in question. But
having a list before actually packaging them in official tree could
serve as another list where other maintainers could pick them up and
package them before maintainer-wanted would, skipping the otherwise
supposedly short time maintainer-wanted would be maintaining it --
packages that are maintained by maintainer-wanted would have a list to
pick from as well, and the interested maintainer could find it from that
one too.

Above when I said maintainer-wanted I meant the herd/team with another
more suitable name then to not confuse with bugs assigned to that alias
that are still not maintained by anyone in the official tree (yes,
co-operation with Sunrise and the like I'd see as important).

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

[Mart Raudsepp]

On K, 2009-05-20 at 00:55 +, Duncan wrote:
 Mart Raudsepp l...@gentoo.org posted
 1242777068.30374.30.ca...@localhost, excerpted below, on  Wed, 20 May 2009
 02:51:08 +0300:
 
  It is about getting popular packages (based on various metrics) into the
  official tree for easy access and with known quality.
 
 Perhaps some concrete examples of packages you have in mind might be 
 useful.

A big part of the thing is to get things better qualified in popularity.
Encouraging users on maintainer-wanted bugs (automatically adding a link
to a describing page if assignee=maintainer-wanted?) to leave their
votes appropriately, automated methods to sort bugs based on comment and
activity, comparing with popularity metrics in other distributions that
have something like the not-really-existing yet gentoo-stats, perhaps
working on gentoo-stats, etc etc.

 I list in the footnote[1] a couple I originally merged from 
 sunrise, that are now in-tree.  I that the type of package you had in 
 mind?  What /about/ sunrise packages?  Will you be working with them to 
 bring popular packages from there in-tree too?
 
 Of course in your case the ebuilds aren't in the tree yet, but bug 
 numbers for apps you believe fit the popular description might be 
 useful.  Popular packages is a nebulous enough term on its own, that 
 some examples might help.

These metrics should be worked out by an upcoming team then, not
ignoring common sense. But perhaps a few examples then:

miro
songbird
moovida (previously known as Elisa Media Center)
paperbox
shutter

I see many of the ones I was able to list seem to be either complex
deptree packages that no-one has been motivated enough yet to push
through (so hopefully once that hard work gets done once, a dedicated
maintainer is found easily), and stuff that would be cool to use once
it's easily available and found, but not something people very much
depend on to care that much alone for themselves, hence a team finding
such packages at first could be useful.

 Also, an example or two of what you might consider a borderline case, 
 that you might consider adding if the load on the proposed project wasn't 
 too high already, but would reject if it was.  Feel free to add comments 
 or explanations on how you came to that conclusion, both for the popular 
 and borderline examples, as well, if you think it necessary.
 
 .
 
 [1] I still use sys-apps/moreutils.
 
 The other one was www-plugins/swfdec-mozilla and its dep media-libs-
 swfdec, which I had some trouble with and eventually unmerged in favor of 
 a couple of youtube downloaders, since youtube was what I mainly used 
 swfdec for anyway.

-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

[Mart Raudsepp]

On Fri, 2009-05-15 at 12:24 +, Duncan wrote:
 Daniel Pielmeier daniel.pielme...@googlemail.com posted
 6142e6140905150344y4a8007b5wd352ffe891e49...@mail.gmail.com, excerpted
 below, on  Fri, 15 May 2009 12:44:47 +0200:
 
  2009/5/15 Marijn Schouten (hkBst) hk...@gentoo.org:
 
  Thilo Bangert wrote:
 
  Fedora is a much more current distribution than Gentoo - and has been
  for a couple of years...
 
  Please elaborate what exactly you think Fedora does better than we do.
  I have no first-hand experience with Fedora, but from what I read I had
  the impression that sometimes they go with new stuff before it is
  ready, like KDE4 and pulseaudio. I like about the current situation
  that we also have all those things available AFAICS, but have very
  broad choices in how much we want to bleed. IMO this is a different
  issue than having supposedly popular ebuilds not in main tree.
 
  AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to
  compare it with the Gentoo unstable tree instead of the stable
  one. Assuming this there is probably not a big difference in the
  up-to-dateness.
 
 Well, yes and no.  As the GP said, they sometimes go with new stuff 
 before it's ready -- before Gentoo even has it in-tree hard-masked let 
 alone ~arch, while it's still in the various project overlays.   I know 
 they've had some serious issues with xorg on Intel GPUs at least, due to 
 running versions that aren't in our tree yet, only in the X overlay, 
 because Fedora is running clearly not even ~arch-ready packages, 
 sometimes even xorg prereleases.

I believe you are thinking of rawhide.
Fedora and quite most other distributions work fundamentally different.
We have a gradually moving tree, as we can do that by being source
based.
Fedora and other distributions are doing releases, which involves
switching to a newer repository branch with dist-upgrade and so on.
They release a new version typically every 6 month, we release new major
versions of packages all the time (considering the whole set).
I'd say that at the point of binary distribution releases their released
trees are somewhere between our ~arch and stable tree, while within a
month or two, they become similar to our stable tree until our continous
releases overcome it with newer versions.
Fedora has xorg prereleases in what they call rawhide. This is what
will become a new release in the future, as they have ~6 month cycles.
It's unstable on purpose, as they are thriving towards being stable with
that repository at the time of the planned next release, while having up
to date packages around the time of the release (with a ~1 month
stabilization period before the release time). That's the fundamental
difference, and where we can have an advantage over them in addition to
other things coming from being source based.

 Years ago we'd have put these in-tree but hard-masked for those who 
 wanted to try them.  Now, depending on the package and Gentoo but more 
 likely as the complexity rises to meta-package levels, those who want to 
 try them must load an overlay.  As someone who selectively unmasks and 
 tries these, having them in-tree but hard-masked is convenient, but I 
 understand why projects may prefer overlays in many cases.

We do tend to prefer overlays in many cases for unstable releases.
The project proposal at hand is of course talking about packages that
are not available at all in the main tree yet. Overlays are quite nice
for tracking unstable releases of package sets that do have their
upstream stable releases in official tree.

 However, none of this directly applies to the subject at hand, because 
 while we're talking new versions of packages already in-tree here, the 
 subject at hand is packages that aren't in-tree in any form yet.

Sorry, still felt like replying with my view on Gentoo vs dist-upgraded
distros :)



-- 
Mart Raudsepp
Gentoo Developer
Mail: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part