Re: [gentoo-dev] rfc: moving default location of portage tree

[Raymond Jennings]

On Thu, Jul 12, 2018 at 12:47 PM Brian Dolbec  wrote:
>
> On Thu, 12 Jul 2018 11:49:37 -0700
> Raymond Jennings  wrote:
>
> > In that case, I vote for /var/cache/portage, since that's literally
> > what purpose it serves.  Namely, the cache of the gentoo infra's
> > current copy of teh portage tree.
> >
> > On Thu, Jul 12, 2018 at 11:00 AM Alec Warner 
> > wrote:
> > >
> > > On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings
> > >  wrote:
> > >>
> > >> Just for the record, but would putting a setting inside
> > >> /etc/portage/make.conf be the appropriate way to handle this?
> > >>
> > >
> > > The settings already exist (and have existed for 10 years.) This
> > > bikeshed discussion is literally trying to decide what the default
> > > should be.
> > >
> > > -A
> > >
> >
>
> This is not a personal attack against you.  Just picked this one to say
> something again...
>
>
> PLEASE, PLEASE stop calling it the "portage" tree.  The repo name is
> "gentoo".  "portage is the default package manager, but not the only
> choice.  Far too often, it takes awhile to figure out what someone is
> trying to say because of that confusion between the tree and the
> package manager.

Point of order:

http://distfiles.gentoo.org/snapshots and numerous pieces of
documentation call it "portage"

The confusion is ingrained by documentation.

> PLUS, it has been decided already long ago that the directory name
> should reflect the repository name.  We have been enforcing that rule
> for overlays for a long time.  It has just been taking a long time to
> get our tooling in order so that we can change our own to follow that
> rule.
>
> So, "portage" should not be a directory name in the new default path.
>
> --
> Brian Dolbec 
>
>

Re: [gentoo-dev] rfc: moving default location of portage tree

[Raymond Jennings]

In that case, I vote for /var/cache/portage, since that's literally
what purpose it serves.  Namely, the cache of the gentoo infra's
current copy of teh portage tree.

On Thu, Jul 12, 2018 at 11:00 AM Alec Warner  wrote:
>
> On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings  wrote:
>>
>> Just for the record, but would putting a setting inside
>> /etc/portage/make.conf be the appropriate way to handle this?
>>
>
> The settings already exist (and have existed for 10 years.) This bikeshed 
> discussion is literally trying to decide what the default should be.
>
> -A
>

Re: [gentoo-dev] rfc: moving default location of portage tree

[Raymond Jennings]

Just for the record, but would putting a setting inside
/etc/portage/make.conf be the appropriate way to handle this?

Re: [gentoo-dev] rfc: moving default location of portage tree

[Raymond Jennings]

As long as an announcement is made in advance (perhaps as a NEWS item)
and portage itself is prepared to do an in-place migration if
necessary, I think things will be fine.

I do think it would be a wise idea to "grandfather" the current layout
for awhile.

On Wed, Jul 11, 2018 at 6:24 AM Gordon Pettey  wrote:
> On Wed, Jul 11, 2018 at 2:29 AM, Jory A. Pratt  wrote:
> > This is a mess, many systems are setup with portage already on a
> > seperate partition for reasons. What advantage does it provide to move
> > the tree now after all these years? I have seen nothing more then lets
> > do this cause I like the ideal lately and it is getting old, there is no
> > benefit that would justify moving the tree or many other changes that
> > are being made in Gentoo lately.
>
> 1. If you're able to mount /usr/portage from another filesystem, why
> would you think it wouldn't work in with /var/cache/portage?

> 1a. If your system is already installed, why do you think this even
> affects you? Did you read?

> 2. Pretty sure following FHS more closely is something most people
> would see as a benefit.

I agree on this point, and I always found /usr/portage to be...well, strange.



For me, though, the most important issue is giving end users advanced
notice and making sure nothing breaks.

Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland

[Raymond Jennings]

On Wed, Aug 30, 2017 at 12:37 PM, Duncan <1i5t5.dun...@cox.net> wrote:

> William L. Thomson Jr. posted on Wed, 30 Aug 2017 14:01:08 -0400 as
> excerpted:
>
> > This is more food for thought to start a discussion on new category
> > names. With Wayland becoming more of a reality every day. I think some
> > of the x11-* categories may need to change. Stuff in there may not be
> > bound to X and can run on Wayland or X.
> >
> > Examples x11-libs/gtk+
> > x11-terms/terminology
> >
> > Not sure what better "universal" category names would be. But seems it
> > maybe time for a discussion on such and some new categories and package
> > moves. Given thus stuff can run under X or Wayland. Not sure x11 makes
> > sense anymore.
> >
> > I can do this on my own in my own overlay. But likely best for official
> > categories as this effects the tree not just others overlays etc. I do
> > not really have any ideas for better names. Just seems like a need.
>
> That could be a lot of package-move churn.  It arguably might make sense
> to keep the current names "for legacy reasons".  (Or not.  Just
> speculating here.)
>
> FWIW, there was some related discussion awhile back on USE=X, proposing
> USE=gui instead, but I don't know what became of it.  Perhaps gui-*
> category names if that's actually moving forward, in ordered to maintain
> a bit of consistency and for lack of a better idea?
>

I think "USE=X" should be reserved for X specific stuff.  If it's being
used to control gui in general IMHO that's not appropriate.  It's bad on
principle and is likely to cause practical difficulties later if confusion
arises vs competing guis, like qt, gtk, wayland, etc.

>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Raymond Jennings]

On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey  wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> wlt...@o-sinc.com> wrote:
>
>> On Thu, 13 Jul 2017 01:03:00 +1000
>> Sam Jorna  wrote:
>>
>> > $ emerge -C apg
>> >  * This action can remove important packages! In order to be safer,
>> > use
>> >  * `emerge -pv --depclean ` to check for reverse dependencies
>> > before
>> >  * removing packages.
>>
>> That is my point. That message is always there. The chance that it is
>> ignored is very high.
>>
>>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
>

Just to be pedantic:

You can usually only be arrested for felonies and misdemeanors.

Ignoring a stop sign and most traffic related offenses in general are
infractions or violations.  For those, you just get cited with a nasty
ticket and an annoying fine.

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Raymond Jennings]

If I may ask, does anyone have any profiling information one way or the
other to shed light on the situation?

On Mon, Jul 10, 2017 at 6:12 PM, R0b0t1  wrote:

> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
>  wrote:
> > On Mon, 10 Jul 2017 17:47:45 -0500
> > Gordon Pettey  wrote:
> >
> >> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny 
> >> wrote:
> >>
> >> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> >> > > Stop getting lost in the weeds
> >> > > You all are making this about -c vs -C. I am not talking about
> >> > > that!
> >> > >
> >> > > LET ME CLARIFY
> >> > >
> >> > > When using -C, portage SHOULD warn for dependencies like it does
> >> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> >> > >
> >> > > When using -c the output should say in layman's terms,
> >> > > "Not removing package A because it is a dependency"
> >> >
> >> > William, I'm not sure if you're aware of how package managers work
> >> > but checking reverse dependencies of a package takes significant
> >> > amount of time.
> >>
> >>
> >> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> >>
> >> The only single package on my system that took more than 2 seconds
> >> total time was gcc. The idea that that is too much time to add to
> >> emerge -c or -C, which in my experience already takes multiple
> >> seconds to run anyway is kind of silly.
> >
> > IMHO anyone complaining about time taking for dependency resolution
> > etc. They should spend THEIR time writing stuff in a real native
> > language for speed.
> >
> > The difference I see with jem[1] vs java-config, is ridiculous.
> > Sometimes I merge hundreds of java packages. All those milliseconds add
> > up. Not to mention resources, ram, CPU, and all drains your battery...
> >
> > If aspects of portage were done in C or C++, or maybe even Go. There
> > would be substantial performance improvements. The existing python code
> > can remain. Python can load and call functions from C/C++ DSO. And vice
> > versa, calling Python code from C/C++. I would say C vs C++ but that is
> > up to others.
> >
>
> https://wiki.gentoo.org/wiki/Q_applets
>
> What you're suggesting is actually really hard, and the root of the
> problems tend to be graph traversals and path searches (for
> dependencies) not so much miscellaneous milliseconds spent in
> interpreter overhead.
>
> Then again, I suppose there will be people on computers slow enough
> where the latter does make a difference.
>
> > Put my time where my mouth is... Well I did, its called jem. What is
> > jem? Its java-config ported to C. I would be looking to port more of
> > Gentoo's tools to C for longevity and speed. Not speed of development,
> > but speed for everyone else. Instead I am doing C for other projects.
> >
> > 1. https://github.com/Obsidian-StudiosInc/jem
> >
> > P.S.
> > jem does need a bit more work to replace java-config entirely. Its
> > designed to not be Gentoo specific. There is little interest from
> > Gentoo, much less outside. Thus its more a case study than anything
> > benefiting anyone including myself. I will further it as I have
> > interest and time permits. Still have a few more defects to address.
> >
>
>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Raymond Jennings]

On Tue, May 16, 2017 at 12:20 PM, Michał Górny  wrote:

> Mike,
>
> I would really appreciate if you cared to follow procedures for eclass
> changes. Most notably, if you at least bothered to either ping us *or*
> sent the patch to the mailing list beforehand.
>
> This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
> changes in large patchsets to reduce cache updates. Of course it is all
> pointless if a random Mike Frysinger, developer on special rights, goes
> ahead and commits whatever he wants to whatever eclasses he wants to
> commit to, whatever time he pleases.
>
> Normally, I would revert it but I don't feel like causing third huge
> cache update today.
>

Just out of curiosity, and for the curious:

1.  How often do cache updates happen?
2.  How long do they take?
3.  Is there any downside to only having one such update running at a time
and just skipping them if there's already an update pending?

>
> --
> Best regards,
> Michał Górny
>

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

[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?

On Wed, Dec 21, 2016 at 12:54 PM, Andreas K. Huettel 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Dienstag, 20. Dezember 2016, 23:57:10 schrieb Jonas Stein:
>
> >
> > The shutdown is in two weeks.
> > One can see clearly a drop of broken ebuilds after the first mail on the
> > mailinglist and after the personal mail on 2016-11-24. [1] Thank you all
> > for fixing so many ebuilds already.
> > But still 400 ebuilds use googlecode.
> >
> > 56 of these do not have a maintainer.
> >
> > How should we proceed now?
> >
>
> There's absolutely no reason to panic. The Gentoo mirror system preserves
> all
> distfiles referenced in the Gentoo repository, even if the original source
> becomes unavailable.
>
> It's not nice that the original SRC_URI is gone, it's kind of a QA
> violation,
> but nothing breaks.
>
> So let's just keep fixing packages. At some point all will be gone.
>
> - --
>
> Andreas K. Huettel
> Gentoo Linux developer
> dilfri...@gentoo.org
> http://www.akhuettel.de/
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQKTBAEBCgB9FiEEwo/LD3vtE3qssC2JpEzzc+fumeQFAlha6/NfFIAALgAo
> aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMy
> OEZDQjBGN0JFRDEzN0FBQ0IwMkQ4OUE0NENGMzczRTdFRTk5RTQACgkQpEzzc+fu
> meStkA/+NGss26A4nR1bFTSuQaLuTNC/kqJnf57neEsY3k2Sx1jtA7/sAzWaxps+
> UoG8MrnyTN2yn/H0KyFRb5SpUeW/QMG5kyXoif21A+s2n1TBFslU/dDL9GWI2o/U
> Mcv0viJOAtox7rKd7TwwIhYIAGXy4wAwuWgPeSMfYrl7xke/yGl+I2fBbCLkh69+
> /a7GZvu8aYQebiX+gYxmXdoroMZxSXW8sSiCmfyFiOgGf/mydar3jIiH7E2HJwSb
> womD2V4vggYUeNv07DJ29Tc7LYGiVNZGatHjLLg1jxn9wyNFmG+s74MXUG1OD0lj
> x2/fE1ffbCYnfPpQT96ETU1X2/Ddc4C1RTMyeplbK89ETCUQvoYmSxsU2Y8J6ZvU
> ToEmWlZjLlX//KNLcJyAVPZAiYdPO5cR1QG1MPXVTAIhPxIgcQuibct8UgVvHbL6
> rvKExZ0ohCz59Vaks9VDJqN61+jkQix9+TioMBFRmoS07QADcxyEKa7IrhDJzLZA
> 4rSxWblr3fdDhnb6TMCZqH2KpMYH4zdM2TbUHtxiKHFz5MsKeijMn3LVdSApNd6W
> iyicxYN1jqx11szZSzsvY+DY/KmG3fPnT0Q9zEvwkIjFKVvKYbSG41vHydSCL9aV
> qrtLuyECAYYyjdDfIUjqVW/6Zg1zfqe3ahO02fq1GfwOFxYJ86c=
> =r5jA
> -END PGP SIGNATURE-
>
>

Re: [gentoo-dev] Re: Stabilisation procedure

[Raymond Jennings]

On Sun, Nov 27, 2016 at 4:07 AM, Rich Freeman  wrote:

> On Sun, Nov 27, 2016 at 5:56 AM, Raymond Jennings 
> wrote:
> > On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi 
> wrote:
> >>
> >> What about maintainers that are away without writing it in their
> >> maintainer bug ?
> >> After how many days of no replay can be fair to touch their package ?
> >
> > If a developer lapses long enough and doesn't use devaway properly to
> mark
> > any waylaid packages as touchable...then that's probably an example of an
> > even bigger fish to fry that undertakers would handle anyway.
>
> A maintainer can be actively doing other work and still not respond to
> a stable request bug.  The only thing the undertakers could do about
> it is get rid of them, which stops the work they were actively doing
> and doesn't make the situation with the bug they were ignoring any
> better.
>
> Are devs supposed to ignore stable request bugs?  No.  Has anybody
> come up with a way to make them not do it?  Unfortunately not.  Part
> of the issue is that some devs are just somewhat antisocial and prefer
> to do their own thing.  For the most part as long as they're not
> actually actively making trouble for others we tend to accept this,
> since the only visible change to getting rid of them is less stuff
> getting done (the stuff they passively ignored still ends up being
> passively ignored).
>

That's actually a very good point.

This is why we tend to favor procedures that don't block progress by
> default.  Just set a timeout.  If the maintainer doesn't respond
> within x days then stabilization can proceed.  Maybe make an exception
> for @system.  We do similar things when devs want to touch each
> other's packages; if you don't get a response the assumption is that
> you can just go ahead.
>

I think this is a good idea.


> --
> Rich
>
>

Re: [gentoo-dev] Re: Stabilisation procedure

[Raymond Jennings]

On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi  wrote:

> What about maintainers that are away without writing it in their
> maintainer bug ?
> After how many days of no replay can be fair to touch their package ?


I think we already have dev-away.

If a maintainer marks themselves as devaway, my understanding is that
they're expected to leave standing orders in place for how to handle their
packages, and in default of that it could well be fair game.

If a developer lapses long enough and doesn't use devaway properly to mark
any waylaid packages as touchable...then that's probably an example of an
even bigger fish to fry that undertakers would handle anyway.

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

[Raymond Jennings]

+1 for at least having this discussed out in the open.

The issue of copyright did tickle my mind when I saw the headers during my
dev quiz.

On Mon, Oct 24, 2016 at 4:21 PM, Rich Freeman  wrote:

> On Mon, Oct 24, 2016 at 7:10 PM, Matt Turner  wrote:
> > On Mon, Oct 24, 2016 at 4:07 PM, Rich Freeman  wrote:
> >> 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.
> >
> > I'm asking whether we're just cargo-culting it along, or if we have
> > (had) some kind of system in place to assign copyright. I think Ciaran
> > answered: we used to but not anymore.
> >
>
> As I said, you could debate whether the present system already assigns
> copyright.  I don't think it is ideal.  It certainly isn't backed by
> any court decisions that I'm aware of.  That doesn't necessarily mean
> that it wouldn't be upheld if it did go to court.  There is really no
> way to be certain without trying it.
>
> But, it is better to rely upon methods that are already proven in
> court over ones that have yet to be proven.  I'm not disputing that.
>
> --
> Rich
>
>

Re: [gentoo-dev] Commented packages in the @system set

[Raymond Jennings]

Why exactly isn't libstdc++ a separate package anyway?

We already have glibc as a separate package, so why the difference?

On Tue, Oct 25, 2016 at 8:47 AM, Mike Gilbert  wrote:

> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson 
> wrote:
> > That definition definitely excludes automake and autoconf (arguably gcc
> > should also excluded, under that definition, so the wiki might not be
> > 100% correct).
>
> gcc provides libstdc++.so.6, which is a necessary runtime component on
> most systems.
>
>

Re: [gentoo-dev] Commented packages in the @system set

[Raymond Jennings]

Don't you need autoconf and automake to build a lot of packages?

On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand 
wrote:

> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky  wrote:
> >
> >> Looking at profiles/base/packages, I see a bunch of lines that are
> >> commented out. For example,
> >>
> >>   *sys-apps/which
> >>   #*sys-devel/autoconf
> >>   #*sys-devel/automake
> >>   *sys-devel/binutils
> >>   #*sys-devel/bison
> >>   #*sys-devel/flex
> >>   *sys-devel/gcc
> >>
> >> Does anyone know why those are commented as opposed to just.. not
> >> there?
> >
> >
> > Those used to be in @system and were dropped at some point once ebuilds
> > had proper deps. My guess would be ppl wanted to keep them commented
> > out just in case it appeared to be a bad idea to drop them and be able
> > to "revert" easily. Nowadays, we can probably assume it was ok :)
> >
>
> Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
> or QA has any objections.
>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

My main concern in this thread, is that I don't want anything swept under
the rug in such a way that a wider issue is masked that actually needs
dealt with anyway.

Examples:
* A workaround to deal with a bug, especially one filed on b.g.o
  - What happens if/when the bug gets fixed?  Won't the workaround need
removed?
  - If the bug is serious enough, a workaround
* An upstream problem
  - Upstream might want (or need to be coaxed) into taking a fix
* Anything common to more than one package`

Routine workarounds, like stuff on gentoo that works differently from
upstream (aka build process mangling) probably doesn't count.

On Tue, Oct 18, 2016 at 11:11 PM, Daniel Campbell  wrote:

> On 10/17/2016 06:09 AM, Raymond Jennings wrote:
> > My biggest ​opinion regarding workarounds and bugs, is that we're
> > sweeping things under the rug that should at least be documented, and
> > perhaps fixed...or even punted upstream if its serious enough.
> >
> > Changing the status quo may require some adjustment though, but I
> > suppose we could start by openly documenting a bug if we find a
> > workaround that does not already have a bug number associated with it.
> > I've seen several ebuilds where workarounds are applied, but the
> > workaround also has a bug number in the comment.
> I'd say this falls under the scope of QA, and QA should have some sort
> of "quick reference" guide to help developers out and cover situations
> they've come across. At the moment, the only resource I'm aware of
> (aside from the obvious devmanual and PMS) that we have is either
> e-mailing qa@g.o or using repoman. repoman can't (and shouldn't) cover
> _everything_, but it's hard to take rants like this seriously when
> little is done to communicate to devs at large to "color in the lines".
>
> I ran into something similar when writing the wrapper script for
> media-sound/apulse. It took 3 attempts and being told "you're doing it
> wrong" 2-3 times before I figured out exactly how to do it. Had it been
> documented on a wiki page or something similar, it would have saved me
> and others a considerable amount of time.
>
> We need solid QA docs. The devmanual and repoman are great starts, and
> answer a bunch of questions. When/if QA comes across new situations and
> comes up with 'blessed' solutions, we need a way to check them out
> instead of waiting for it to hit Git and be smacked with a "this is
> wrong" e-mail.
>
> Just my 2¢.
>
> ~zlg
> --
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
>
>

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

My personal opinion:

If you have to work around it, its already a bug.

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

My biggest ​opinion regarding workarounds and bugs, is that we're sweeping
things under the rug that should at least be documented, and perhaps
fixed...or even punted upstream if its serious enough.

Changing the status quo may require some adjustment though, but I suppose
we could start by openly documenting a bug if we find a workaround that
does not already have a bug number associated with it.  I've seen several
ebuilds where workarounds are applied, but the workaround also has a bug
number in the comment.

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

On Mon, Oct 17, 2016 at 12:23 AM, Michał Górny  wrote:

> Hello, everyone.
>
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
>
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.
>
> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
>
>
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
>
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
>
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
>
> Your thoughts?
>
> --
> Best regards,
> Michał Górny
> 
>

+1.

Anything serious enough to require a workaround or an upstream deviation
should be documented in a bug report.

And may also be something we should poke upstream about anyway. If junk
hits us in gentoo, it may have come from upstream and may affect users
outside of gentoo.

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Raymond Jennings]

On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez 
wrote:

> On 10/04/2016 06:24 PM, William Hubbs wrote:
> >
> >  This would actually be another reason to get rid of grub-0, if it can't
> >  build on one of our profiles, it will more than likely never be fixed
> >  upstream because they are now focused on grub-2.x.
>
> grub-0 is 32-bit software. You could build it without multilib but you need
> the dependencies like any other package (and link them statically). And
> there
> are other packages on the tree that don't build on all profiles.
>

USE="abi_x86_32"

?

>> Another alternative would be simply hard-masking it, but leaving it in
> >> place for those who want it.  It does still work, and I see no evidence
> >> we're removing it due to security issues or breakage.
> >
> > We are removing it because upstream has a new version of the software
> > and has moved on from this one. For most packages, if foo-1.0 is
> > stable, then foo-2.0 comes to stable, after some point we remove foo-1.0
> > from the tree.
>
> Grub2 is not really a new version, it's a different product with different
> use cases. I don't use grub-0 to boot any of my gentoo boxes but I use it
> for
> some embedded x86 projects so it's convenient to be able build it off the
> tree. I remember trying grub2 on one of them a while back and IIRC it more
> than doubled the size of the image.
>
> Just my 2 cents worth.
>
> --
>
> Fernando Rodriguez
>
>

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

[Raymond Jennings]

On Sun, Sep 25, 2016 at 11:29 PM, Michał Górny  wrote:

> On Mon, 26 Sep 2016 08:18:27 +0200
> Michał Górny  wrote:
>
> > On Mon, 26 Sep 2016 00:42:11 +0300
> > Mart Raudsepp  wrote:
> >
> > > Ü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).
> >
> > Yes, yes, I am old :-P. You are right, it's AMDGPU these days.
> >
> > > > 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].
> >
> > How about nvidia users who seem to require NVPTX for libclc these days?
> > Do they set VIDEO_CARDS='nvidia nv nouveau ...'? The problem is that
> > this abuse of VIDEO_CARDS is never going to be 100% clear to users.
> >
> > I guess we can enable GPU targets in desktop profiles by default to
> > save most of our users from the issues.
>
> Hmm, I actually see we're enabling them in arch profiles. So I guess
> matching enable there would fit there as well.
>
> --
> Best regards,
> Michał Górny
> 
>

This might be a stupid question, but I have a hunch I'm not the only user
curious about this.

Doesn't VIDEO_CARDS factor in on xorg-server's video driver selection?

Re: [gentoo-dev] Last rites: app-misc/subsurface

[Raymond Jennings]

On Mon, Sep 12, 2016 at 1:11 AM, Marek Szuba  wrote:

> On 2016-09-11 14:19, Martin Gysel wrote:
>
> >> +1.  Any package whose upstream says "don't build this yourself" is
> >> hostile to open source principles.
> > just to make it clear, upstream never said such thing nor are they in
> > any way hostile to open source principles (I suppose you wouldn't state
> > that if you know subsurface's developers).
> They have, however, used the term "deprecated" to describe
> distribution-maintained packages. It's right there on the download page.
>
> And yes, I know (and so do at least several other devs) that one of the
> major contributors to Subsurface is one Linus Torvalds.
>

*eats humble pie*

Seems I was mistaken, and I also apologize for the venom.

>
> --
> MS
>
>

Re: [gentoo-dev] Last rites: app-misc/subsurface

[Raymond Jennings]

On Fri, Sep 9, 2016 at 11:30 PM, Kent Fredric  wrote:

> On Fri, 9 Sep 2016 21:59:10 -0700
> Raymond Jennings  wrote:
>
> > +1.  Any package whose upstream says "don't build this yourself" is
> hostile
> > to open source principles.
>
> That's also an open invitation to fork ;)
>

Oh believe me if I had the time and interest I would do so.  Unfortunately
I don't know anything about subsurface and I have other things going on.

Re: [gentoo-dev] Last rites: app-misc/subsurface

[Raymond Jennings]

On Fri, Sep 9, 2016 at 4:04 AM, Marek Szuba  wrote:

> # Martin Gysel  via g-p-m (09 Sep 2016)
> # Versions currently in Portage are old and block removal of other
> # packages. Current versions require building against modified versions
> # of dev-libs/libdivecomputer and kde-apps/marble which must be fetched
> # from Git, and which are not versioned (upstream uses branch tags).
> # Finally, upstream considers distribution-maintained packages deprecated.
> # Removal in 30 days.
> app-misc/subsurface


+1.  Any package whose upstream says "don't build this yourself" is hostile
to open source principles.

Re: [gentoo-dev] Empty project: Arch Testers

[Raymond Jennings]

On Mon, Aug 22, 2016 at 9:00 AM, Pacho Ramos  wrote:

> I am not sure when https://wiki.gentoo.org/wiki/Project:Arch_Testers wa
> s created, but it's empty and unused for a long time, hence, I don't
> know if anyone would be willing to join to it (I am unsure about what
> will it cover over the "dedicated" arch tester teams) or it should be
> removed simply :/
>
> Thanks
>

Does this project presently contain the various arch teams, like amd64 and
x86 and sparc etc?

If so, imho it is not really empty, but serves as a superproject much like
desktop does, possibly manageable in the same way.

And if not the project name is misleading anyway.

Come to think of it, does existing policy cover how to handle
"superprojects" that serve as nothing but umbrellas for collections of
other projects and have no tasks or members of their owns?

Recruiting process (Re: [gentoo-dev] base-system needs developers who care)

[Raymond Jennings]

On Tue, Aug 23, 2016 at 4:17 PM, Robin H. Johnson 
wrote:

> Over the years, the base-system package herd has grown in size. Today
> it comprises 320 packages, of which 61 of those have more than one
> maintainer. The packages with more than one maintainer I'm only
> concerned about if the other maintainer is also very busy or not
> available.
>
> Some of these packages are very niche, and while they continue to work,
> they could use a bit more attention than they get presently (you might
> only hear about them when they break and never when they work).
>
> They are generally NOT broken and in need of tree-cleaning, but are just
> lacking forward momentum (not a few bugs are reasonable upstream bugs or
> feature improvements). Many were once shiny and had lots of people that
> cared, but that dwindled as they become mundane and just expected to
> work.
>
> General increase in the number of developers in base-system would not be
> a bad outcome from this email either ;-).
>

This...kinda touches on a side issue.  I've been a bit waylaid by RL issues
during my quest to become a developer myself, and both of my prospective
mentors had to step aside for the same reason before the process could
finish.

I'm a little slow on the quizzes and some recent changes in gentoo
invalidated some of my answers, so part of it is my fault for falling
behind.

But I was kinda wondering, is there anything that can be done to beef up
the manpower?  Is there any need to?

>
> Some of this is from stuff I know needs eyeballs, and others are where
> the package seems to have more than a few old bugs open.
>
> Packages in need of review & tweaks or just more eyeballs
> --
> app-admin/sudo (upstream?)
> app-admin/sysklogd- (upstream?)
> app-shells/bash (upstream?)
> dev-util/strace (upstream?)
> net-dialup/ppp
> net-firewall/iptables
> net-fs/nfs-utils (upstream?)
> net-misc/dhcpcd (upstream?)
> net-misc/dhcp (upstream?)
> net-misc/ntp (upstream?)
> net-misc/openssh
> net-nds/rpcbind
> sys-apps/baselayout
> sys-apps/coreutils (upstream?)
> sys-apps/kbd (upstream?)
> sys-block/aoetools
> sys-block/iscsitarget
> sys-block/open-iscsi
> sys-block/thin-provisioning-tools
> sys-block/vblade
> sys-fs/lvm2 (mostly in regards to genkernel interaction)
> sys-fs/multipath-tools
> sys-fs/quota
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
>

Re: [gentoo-dev] [PATCH] subversion.eclass: support for EAPI 6

[Raymond Jennings]

Just an FYI, games-emulation/dosbox tripped over this recently.

On Sat, Aug 6, 2016 at 7:05 AM, Andrew Savchenko  wrote:

> Hi,
>
> On Sat, 30 Jul 2016 12:34:07 +0300 Andrew Savchenko wrote:
> > On Sat, 30 Jul 2016 07:37:08 +0200 Michał Górny wrote:
> > > > @@ -116,7 +123,8 @@ ESVN_PROJECT="${ESVN_PROJECT:-${PN/-svn}}"
> > > >
> > > >  # @ECLASS-VARIABLE: ESVN_BOOTSTRAP
> > > >  # @DESCRIPTION:
> > > > -# bootstrap script or command like autogen.sh or etc..
> > > > +# Bootstrap script or command like autogen.sh or etc..
> > > > +# Removed in EAPI 6 and later.
> > > >  ESVN_BOOTSTRAP="${ESVN_BOOTSTRAP:-}"
> > > >
> > > >  # @ECLASS-VARIABLE: ESVN_PATCHES
> > > > @@ -127,6 +135,8 @@ ESVN_BOOTSTRAP="${ESVN_BOOTSTRAP:-}"
> > > >  #
> > > >  # Patches are searched both in ${PWD} and ${FILESDIR}, if not found
> in either
> > > >  # location, the installation dies.
> > > > +#
> > > > +# Removed in EAPI 6 and later, use PATCHES instead.
> > > >  ESVN_PATCHES="${ESVN_PATCHES:-}"
> > >
> > > It would be a good idea to check if the variables are set and die if
> > > they are, so people don't accidentally use them.
> >
> > Impossible to implement. These variables (as well as all other
> > ESVN_* variables) are usually set after subversion eclass is
> > inherited. And even if I'll duplicate this check in all available
> > functions (which is ridiculous by itself), it still will not help,
> > since several functions are removed from EAPI 6 and people may
> > rely on default behaviour of src_prepare() alone.
> >
> > > >  # @ECLASS-VARIABLE: ESVN_RESTRICT
> > > > @@ -355,7 +365,10 @@ subversion_fetch() {
> > > >  # @FUNCTION: subversion_bootstrap
> > > >  # @DESCRIPTION:
> > > >  # Apply patches in ${ESVN_PATCHES} and run ${ESVN_BOOTSTRAP} if
> specified.
> > > > +# Removed in EAPI 6 and later.
> > > >  subversion_bootstrap() {
> > > > + has "${EAPI:-0}" 6 && die "${FUNCNAME[1]} is removed from
> subversion.eclass in EAPI 6 and later"
> > > > +
> > >
> > > Reverse the logic. This will require updating in every EAPI while it is
> > > rather unlikely the next EAPIs will return to previous behavior.
> >
> > Done.
>
> No further comments for a week => in the tree now.
> Thank you for review.
>
> Best regards,
> Andrew Savchenko
>

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Raymond Jennings]

Strict compliance with the handbook would seem to forbid having a stable
package depend on an unstable package, and if you have to downgrade a
dependency and it causes a cascade, I would opine, that, perhaps, the
package in question should not have been stabilized to begin with.

That said, I as a user have noticed that packages tend to stall in
stabilization for awhile.

What about a script that can rank ~arch keyworded packages by some sort of
priority?

Maybe point out which one has the most reverse dependencies?  Or which one
has been stuck in ~arch the longest?  Or some sort of scoring mechanism
that can flag the most urgently needed stabilizations?

Come to think of it, I think debian has a system that flags the most
popular packages.  Does gentoo have a way to note what packages are most
important?

On Wed, Aug 17, 2016 at 1:50 AM, Pacho Ramos  wrote:

> El lun, 15-08-2016 a las 15:27 -0400, Rich Freeman escribió:
> > [...]
> > Well, I wasn't suggesting that breaking the depgraph is great.  Just
> > that I think it is better than calling things stable which aren't.
> >
> > A better approach is a script that does the keyword cleanup.
> >
> > So, if you want to reap an ebuild you run "destabilize
> > foo-1.2.ebuild".  It searches the tree for all reverse deps and
> > removes stable keywords from those.  Then you commit all of that in
> > one commit.
> >
> > If you want to be extra nice you stick it in a pull request in github
> > and point it out to the arch team and ask them if they're sure they
> > don't want to stabilize your package...  :)
> >
>
> Well, the reason I was suggesting to allow maintainers to stabilize
> after the 90 days timeout over *current* policy of allowing the
> dekeywording is that the dekeywording is completely unrealistic to do
> as some packages have a huge amount of reverse deps. Even with the
> script (and, well, I would like to see that script existing... because
> we are having this issue for ages, and that is the reason that nobody
> is moving things to testing actively), you will find many many cases of
> packages having so many reverse dependencies that if you try to move it
> to testing it becomes soon a hell.
>
> The main issue is that, once you start dekeywording one package, you
> jump to, for example, dekeywording another 3 reverse deps, then you
> need to continue with the reverse deps of that reverse deps... and at
> the end, it's completely impossible to manage it (I still remember how
> hard was to move to testing most of Gnome... and we even were lucky as
> we were able to do that with the jump to Gnome3).
>
> Then, my point it to allow the maintainer to keep stabilizing it
> *after* the 90 days timeout. If after that time, the arch team is
> unable to even reply, nobody has reported any build/runtime issues
> related with that arch, I would go ahead. Otherwise, it looks pretty
> evident to me that that arch is near to be used by nobody and maybe it
> should be moved completely to testing (or most of their packages moved
> to testing and only the core apps in stable).
>
>
>
>

Re: [gentoo-dev] Empty project: LXDE

[Raymond Jennings]

>From an interested user, you have my thanks.

On Sun, Aug 14, 2016 at 1:38 AM, Pacho Ramos  wrote:

> El sáb, 13-08-2016 a las 22:39 -0700, Hanno Böck escribió:
> > Ok, so it seems I'm currently the only one interested.
> >
> > While the wiki page lists no other devs, there are two more devs
> > listed
> > in the email alias, yet they haven't replied to my questions whether
> > they consider themselve still part of the project.
> >
> > I'll take over the project now and will start committing latest
> > upstream
> > updates piece by piece.
> >
> > Not sure if there's any long term future for LXDE, but for the time
> > being I'll take care of it.
> >
>
> When looking to bugs assigned to the team I found some people willing
> to help via proxy-maint too... you should be CCed by me in that bug
> report for being aware :)
>
> Thanks for joining the team!
>
>

Re: [gentoo-dev] Empty project: Desktop

[Raymond Jennings]

I think that a superproject can serve as a good rubber-band grouping
construct, personlaly

On Thu, Aug 11, 2016 at 11:19 AM, Pacho Ramos  wrote:

> El jue, 11-08-2016 a las 13:15 +0300, Mart Raudsepp escribió:
> > [...]
> > 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
> >
>
> Apart of me not understanding why are we reviving this that was already
> discussed when killing the old freedesktop-bugs herds in favor of the
> correct project, I don't think it makes sense to keep this concrete
> dead project for that potential and hypothetical changes that could
> benefit from it in the far future.
>
> Maybe when something of that is finally going to be done, we need that
> project and, in that case, you will be able of course to create your
> Project following the standard policy that allows to do that to any
> developers.
>
>
>

Re: [gentoo-dev] Empty project: LXDE

[Raymond Jennings]

Hey, just a heads up as a user.  I'm currently using LXDE.

On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos  wrote:

> Now https://wiki.gentoo.org/wiki/Project:LXDE is empty
>
> Feel free to join, anyway, if I don't misremember, LXDE is dead for a
> long time in favor of LXQT... in that case treecleaning the packages
> would also be an option
>
> Thanks
>
>

Re: [gentoo-dev] Empty project: Desktop

[Raymond Jennings]

If an empty project has subprojects, I think that violates the definition
of empty.

On Sat, Aug 6, 2016 at 8:46 AM, james  wrote:

> On 08/06/2016 09:29 AM, NP-Hardass wrote:
>
>> On 08/06/2016 04:31 AM, Pacho Ramos wrote:
>>
>>> Now https://wiki.gentoo.org/wiki/Project:Desktop
>>>
>>> Well, it seems that it's only "containing" other subprojects... but I
>>> am unsure if we really need it. Anyway, he is now empty
>>>
>>>
>>>
>>>
>> I think it makes sense to keep desktop environments in a logical
>> grouping.  There isn't a need for an overarching control structure right
>> now, but if there needs to be coordination of efforts, I think keeping
>> it in its current structure allows that to happen more easily than if we
>> didn't have all the DEs in a project together.
>>
>>
> +1
> James
>
>

Re: [gentoo-dev] rfc: new global use flag: luajit

[Raymond Jennings]

My personal opinion is that anything that reduces complexity or duplication
in the tree is a good thing.

At least if there's some kind of version spat, you only need to fix it in
one place (the eclass) instead of in individual ebuilds.

On Thu, Jul 14, 2016 at 7:34 AM, William Hubbs  wrote:

> On Thu, Jul 14, 2016 at 04:15:42PM +0200, Michał Górny wrote:
> > On Thu, 14 Jul 2016 09:05:57 -0500
> > William Hubbs  wrote:
> >
> > > All,
> > >
> > > there are currently 19 packages in the tree that have the luajit use
> > > flag, and I am planning on adding 10 more.
> > >
> > > I think this use flag should be global with the following description:
> > >
> > > "use the lua just-in-time compiler for lua support"
> > >
> > > If there are no objections, I'll start the transition on or after 17
> > > Jul.
> >
> > I'd rather avoid adding more of this until we figure out what to do
> > about multiple Lua versions. The Lua5.1/5.2 split is still stuck
> > nowhere, and luajit is yet another variant to handle.
>
> If we don't do this, the only way to add luajit support to dev-lua/busted
> is to
> propegate the local use flag into all of its dependencies [1], and that is
> what I'm trying to avoid.
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=584694
>

Re: [gentoo-dev] Need design help/input for eclean-kernel

[Raymond Jennings]

Just to give kudos, I would not be able to keep my system tidy without
eclean-kernel.  It takes care of lots of stuff portage does not.

On Fri, Jul 1, 2016 at 10:58 AM, Guilherme Amadio  wrote:

> On Thu, Jun 30, 2016 at 02:38:26PM +0200, Michał Górny wrote:
> > So if you have some time, please reply to this thread with
> > a specific /boot layout that you think needs to be handled, with
> > as much helpful information as possible -- including possible
> > distinctive features and pitfalls.
>
> Looks like not too many people are booting kernels like me, so
> I'm going to add my crude setup to the pile :)
>
> I compile most stuff into the kernel (at least enough so I don't
> need to use an initrd/initramfs to mount / or /usr). I do not use a boot
> loader either, I use CONFIG_EFI_STUB=y and compile in the command
> line arguments to avoid trouble. Then, I use efibootmgr to boot the
> kernel at /boot/EFI/Gentoo/bootx64.efi
>
> I usually keep several kernels in the same directory with a version
> suffix (e.g. bootx64-4.6.2.efi, etc) and overwrite the bootx64.efi
> file with whatever kernel I want to boot with cp bootx64{-4.x.x,}.efi
>
> I keep a few older kernels around in case I screw up the configuration
> of a new one (usually video drivers), but for the most part, that's it.
>
> My compiled kernel command line is also pretty simple:
>
> quiet console=tty1 root=/dev/sda4 init=/usr/lib/systemd/systemd
>
> I never really though about writing scripts to manage this, since it's
> quite a simple setup, but having tools to manage it would be nice.
>
> Just think about supporting a simple EFI/UEFI setup, I would say, in
> addition to the more common setups using a boot loader.
>
> Cheers,
> —Guilherme
>
>
>

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Raymond Jennings]

I'd like to chime in if I may.  I've found "VERIFIED" to be needless.
Especially in cases where I have logs or whatnot, having to prove the bug
is there is tedious.

Shouldn't the existence of the report be evidence enough?

On Fri, Jun 17, 2016 at 10:39 AM, Rich Freeman  wrote:

> On Fri, Jun 17, 2016 at 1:26 PM, Kristian Fiskerstrand 
> wrote:
> > On 06/17/2016 07:05 PM, Brian Dolbec wrote:
> >>
> >> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
> >> portage.  Reserve portage for the upstream PACKAGE MANAGER.
> >
> > indeed
> >
>
> Agree, though this wasn't the sense I meant it in (in case there was
> any confusion).
>
> 1. There is the Gentoo Repo (which I always try to describe using those
> words).
>
> 2. Then there is the sys-apps/portage package in the Gentoo repo.
>
> 3.  And then there is the portage upstream that occasionally makes
> releases that end up as #2.
>
> It is between 2-3 that we need to distinguish here.
>
> I agree with the suggestion that context is sufficient already.
>
> --
> Rich
>
>

Re: [gentoo-dev] Council Council: call for agenda items for June 12 meeting

[Raymond Jennings]

I think the demise or replacement of the sunrise project should be put on
the agenda possibly.  This is not anything official, just a hopefully
helpful suggestion.

On Fri, Jun 10, 2016 at 2:45 PM, Michał Górny  wrote:

> Hello,
>
> Considering the strength of response from a Council member, I would
> like to officially apologize for providing the agenda items and I would
> like to withdraw them all appropriately. Thank you for your time, and I
> wish you re-election.
>
>
> On Fri, 3 Jun 2016 16:06:25 +0200
> Michał Górny  wrote:
>
> > On Fri, 3 Jun 2016 07:01:03 -0400
> > "Anthony G. Basile"  wrote:
> >
> > > Hi everyone,
> > >
> > > The Council will be meeting on Sunday June 12.  This is a call for any
> > > agenda items.
> >
> > In preferred order of discussion (i.e. shortest topics first):
> >
> > 1. the 'file installation masks' GLEP [spec:1, RFC:2, bug:3]. It still
> > hasn't been merged by the GLEP editors but it's otherwise ready with
> > reference implementation for Portage. Preferably please discuss this
> > separately/before LINGUAS as it is quite generic and I think having it
> > approved would benefit us. The part specifically needing Council
> > approval is the extra configuration file in metadata/ dir of the
> > repository.
> >
> > 2. The patch fixing USE_EXPAND handling in Portage to adhere to
> > the rules enforced by the PMS for EAPI 5 and newer [patch:4,
> > patch v1:5, bug:6]. The patch comes in two variants. The former
> > (preferred by me) applies the change to all EAPIs since this way we can
> > kill the ugly logic for earlier EAPIs and PMS leaves the behavior
> > undefined for them. The latter applies it only to EAPI 5 and newer,
> > leaving current behavior for older EAPIs. I don't think it really makes
> > sense to have different logic as EAPI 5 is quite common already, and
> > different behavior will only increase confusion.
> >
> > 3. New sys-devel/gcc USE=multislot [QA bug:7]. I originally wanted to
> > do this via QA but considering the replies to bugs opened so far, I
> > think Council approval would be additionally helpful. The key point of
> > my request would be to kill the flag, and stop force-removing old
> > versions implicitly.
> >
> > 4. LINGUAS [8,9]. Long story short, PMS considered, we implicitly strip
> > localizations from most of the packages out there. I think the first
> > step towards fixing it that the most people can approve is renaming
> > the USE_EXPAND from LINGUAS to I18N or L10N, or generally something
> > else, plus a news item.
> >
> > 5. USE=gui [10]. It seems to get some appreciation but I suspect it's
> > going to end up going to the Council anyway.
> >
> > I think that's all for now. If I recall something else, I'll let you
> > know.
> >
> >
> > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> > [2]:
> https://archives.gentoo.org/gentoo-dev/message/af5de8be051fdf60d4d4aef97df6e683
> > [3]:https://bugs.gentoo.org/show_bug.cgi?id=584452
> > [4]:
> https://archives.gentoo.org/gentoo-portage-dev/message/42e3a134d14e33e037e35e6c5df9d05d
> > [5]:
> https://archives.gentoo.org/gentoo-portage-dev/message/b79fc6bd174a356c62bda59d0b0e9e8e
> > [6]:https://bugs.gentoo.org/show_bug.cgi?id=583750
> > [7]:https://bugs.gentoo.org/show_bug.cgi?id=584610
> > [8]:
> https://archives.gentoo.org/gentoo-dev/message/a08ea09c2c8e534fd9bc1146703c66ff
> > [9]:
> https://archives.gentoo.org/gentoo-dev/message/41e09d1ddc8b30abb9f9d21d205b7b82
> > [10]:
> https://archives.gentoo.org/gentoo-dev/message/eecad370248118c474a0d819fa7f3576
> >
>
>
>
> --
> Best regards,
> Michał Górny
> 
>

Re: [gentoo-dev] The future of the Sunrise project

[Raymond Jennings]

How about simply closing sunrise to new packages, and migrate them to
elsewhere as resources permit?

Just plugging the spigot and deprecating it would improve things.

On Tue, Jun 7, 2016 at 12:55 AM, Robin H. Johnson 
wrote:

> On Tue, Jun 07, 2016 at 09:44:42AM +0200, Dirkjan Ochtman wrote:
> > On Mon, Jun 6, 2016 at 11:23 PM, Michał Górny  wrote:
> > > Your thoughts?
> > I would agree that proxy-maint and GH pull requests are better than
> > sunrise, and so we should probably sunset (pun intended) the latter.
> The new method is better, but that doesn't cover what to do with the
> 500+ packages in sunrise.
>
> I have found them useful in the past, when I suddenly had a need for
> something, and there was an ebuild in sunrise that I could adopt into
> the tree.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
>
>

Re: [gentoo-dev] The future of the Sunrise project

[Raymond Jennings]

In my humble opinion, sunrise is a needless layer of bureaucracy to getting
new packages into the tree.  Personlly, I think it's not a bad idea for new
packages to be submitted as enhancements directly on bugzilla, possibly
CCing any relevant projects who could provide a review.


On Mon, Jun 6, 2016 at 2:23 PM, Michał Górny  wrote:

> Hello, everyone.
>
> It has recently came to my attention that things are quite bad with
> the Sunrise project [1] lately. Most of the developers have left
> the project, and it seems that the contributors have done the same.
> The public reviewed repository has major QA issues and hasn't been
> updated since mid-2015. The last non-developer commit to the private
> repo also seems to come from mid-2015, followed only by a number of
> removals and fixes done by Gentoo developers.
>
> Therefore, I'd like to ask the following question: is it time to
> announce the project dead, or do some developers want to revive it?
> If the former, could someone try to contact last active contributors
> and ask them if they'd like to move their ebuilds to ::gentoo
> via proxy-maint?
>
> I should point out that Sunrise has lost a lot of popularity to
> proxy-maint, then also to GitHub pull requests (and the two combined).
> The developers involved with those provide quite a good review
> workflow, with the extra advantage of getting packages straight
> into ::gentoo. I don't know how many users would be interested
> in keeping them in ::sunrise if they could have them straight
> in ::gentoo with similar (if not less...) effort.
>
> Your thoughts?
>
> [1]:https://wiki.gentoo.org/wiki/Project:Sunrise
>
> --
> Best regards,
> Michał Górny
> 
>

Re: [gentoo-dev] app-text/htmltidy: Maintainer Request

[Raymond Jennings]

I'm not a gentoo developer yet (rl drama has majorly lagged me on getting
my quizzes done) but if there's a way I can help it I wouldn't mind.

On Mon, Jun 6, 2016 at 7:55 AM, Yury German  wrote:

> Well a few things need to happen:
>
> 1. app-text/tidy-html5 - Need to go Stabl
> 2. dep and rdep need to be migrated to tidy-html5 and tested.
>
> Since Patrice (monsieurp) is the maintainer of tidy-html5, do you want
> to become maintainer of htmltidy temporarily to help kill it and move to
> tidy-html5?
>
>
> On 6/6/16 10:41 AM, Raymond Jennings wrote:
> > If tidy-html5 can take care of anything htmltidy can, then we can boot
> > the latter as obsolete anyhow.  Are there any backwards compatibility
> > issues if we just punt it and let tidy-html5 take over?
> >
> > On Mon, Jun 6, 2016 at 7:15 AM, Yury German  > <mailto:bluekni...@gentoo.org>> wrote:
> >
> >
> >
> > On 6/5/16 8:02 PM, Patrice Clement wrote:
> > > Sunday 05 Jun 2016 19:39:26, Yury German wrote :
> > >> app-text/htmltidy currently has no maintainers. It has a
> vulnerability
> > >> [Security Bug] filed against it. And a number of other [package
> depend
> > >> on it]. Is nyone willing to pick it up?
> > >>
> > >> [Secuity Bug]
> > >> https://bugs.gentoo.org/show_bug.cgi?id=561452
> > >>
> > >> [package depend on it]
> > >>
> https://qa-reports.gentoo.org/output/genrdeps/dindex/app-text/htmltidy
> > >>
> https://qa-reports.gentoo.org/output/genrdeps/rindex/app-text/htmltidy
> >
> > > Don't bother. Have a look at [1], [2] & [3] to find out why.
> > >
> > > tl;dr
> > >
> > > htmltidy has got to be culled at some point since it's now
> considered obsolete
> > > after tidy-html5 entered the tree a little while ago. It's roughly
> the same
> > > codebase yet it's HTML 5 compliant. Yay!
> > >
> > > I've been maintaining the latter since its inclusion in the
> Portage tree but
> > > would definitely need help to remove the former. I didn't swap
> htmltidy for
> > > tidy-html5 cause they're two different projects. As you can see
> from the links
> > > above, htmltidy has a gazillion deps.
> > >
> > > [1]: http://tidy.sourceforge.net/
> > > [2]: http://www.html-tidy.org/
> > > [3]: https://github.com/htacg/tidy-html5
> > >
> >
> > This is all agreed, but unless someone is driving this it will never
> get
> > removed from tree. The security patch is one thing, but cleaning it
> up
> > and switching to tidy-html5 is why we need a maintainer so that we
> can
> > get rid of the dependencies otherwise it will sit there unsecured for
> > the next 5 years.
> >
> >
> >
>
>

Re: [gentoo-dev] app-text/htmltidy: Maintainer Request

[Raymond Jennings]

If tidy-html5 can take care of anything htmltidy can, then we can boot the
latter as obsolete anyhow.  Are there any backwards compatibility issues if
we just punt it and let tidy-html5 take over?

On Mon, Jun 6, 2016 at 7:15 AM, Yury German  wrote:

>
>
> On 6/5/16 8:02 PM, Patrice Clement wrote:
> > Sunday 05 Jun 2016 19:39:26, Yury German wrote :
> >> app-text/htmltidy currently has no maintainers. It has a vulnerability
> >> [Security Bug] filed against it. And a number of other [package depend
> >> on it]. Is nyone willing to pick it up?
> >>
> >> [Secuity Bug]
> >> https://bugs.gentoo.org/show_bug.cgi?id=561452
> >>
> >> [package depend on it]
> >> https://qa-reports.gentoo.org/output/genrdeps/dindex/app-text/htmltidy
> >> https://qa-reports.gentoo.org/output/genrdeps/rindex/app-text/htmltidy
>
> > Don't bother. Have a look at [1], [2] & [3] to find out why.
> >
> > tl;dr
> >
> > htmltidy has got to be culled at some point since it's now considered
> obsolete
> > after tidy-html5 entered the tree a little while ago. It's roughly the
> same
> > codebase yet it's HTML 5 compliant. Yay!
> >
> > I've been maintaining the latter since its inclusion in the Portage tree
> but
> > would definitely need help to remove the former. I didn't swap htmltidy
> for
> > tidy-html5 cause they're two different projects. As you can see from the
> links
> > above, htmltidy has a gazillion deps.
> >
> > [1]: http://tidy.sourceforge.net/
> > [2]: http://www.html-tidy.org/
> > [3]: https://github.com/htacg/tidy-html5
> >
>
> This is all agreed, but unless someone is driving this it will never get
> removed from tree. The security patch is one thing, but cleaning it up
> and switching to tidy-html5 is why we need a maintainer so that we can
> get rid of the dependencies otherwise it will sit there unsecured for
> the next 5 years.
>
>
>

Re: [gentoo-dev] [RFC] New global USE flag: webp

[Raymond Jennings]

+2

I don't know how many packages that is but it's WAY over the minimum of 5
advised in the dev handbook

On Sat, Jun 4, 2016 at 3:55 AM, Davide Pesavento  wrote:

> On Sat, Jun 4, 2016 at 12:45 PM, Chí-Thanh Christopher Nguyễn
>  wrote:
> > Suggested description: Add support for the WebP image format
> > Currently in use by the following packages:
> >
> > app-text/tesseract:webp - Enable support for webp image format.
> > dev-games/aseprite:webp - Enable webp image format support
> > dev-libs/DirectFB:webp - build WebP image provider
> > dev-libs/efl:webp - Enable WebP image loader
> > dev-python/pillow:webp - Enable support for webp image format.
> > dev-qt/qtwebkit:webp - Add support for WebP image format
> > media-gfx/darktable:webp - Enable WebP export support
> > media-gfx/fbida:webp - Enable support for the WebP image format
> > media-gfx/graphicsmagick:webp - Enable support for webp image format
> > media-gfx/gthumb:webp - Enable support for webp image format
> > media-gfx/imagemagick:webp - Enable webp image format support using
> > media-libs/libwebp
> > media-gfx/imageworsener:webp - enable webp image format support
> > media-gfx/nomacs:webp - Build support for WEBP image format
> > media-gfx/qiviewer:webp - Build support for WEBP image format
> > media-libs/gd:webp - Enable support for the webp format
> > media-libs/gegl:webp - Enable support for media-libs/libwebp
> > media-libs/jbig2enc:webp - Add support for WEBP image format
> > media-libs/leptonica:webp - Adds support for the WebP image format
> > media-libs/opencv:webp - Enable support for webp image format
> > media-libs/sdl-image:webp - support loading WEBP images
> > media-libs/sdl2-image:webp - support loading WEBP images
> > media-video/ffmpeg:webp - Enables WebP encoding with media-libs/libwebp.
> > media-video/libav:webp - Enable WebP encoding with media-libs/libwebp.
> > www-client/netsurf:webp - WebP image support (media-libs/libwebp)
> > x11-wm/windowmaker:webp - Enables WebP image format support using
> > media-libs/libwebp
> > x11-wm/xpra:webp - Enable webp image format support
> >
>
> +1
>
>

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

[Raymond Jennings]

use case:  Telling a package to build a gui without deciding which one to
build.  Also helps in cases where you have package A that can only build a
qt gui, and package B that can build both qt and gtk, and package C that
can build gtk only.  You want to have a gui for all three, but you don't
want to hav epackage B build both guis and at the same time while you may
prefer qt, you don't want to leave package C without a gui.

On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius  wrote:

> On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote:
> > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> >
> >> waltd...@waltdnes.org wrote:
> >>
> >>>   I see this as at least a redundancy, if not a problem.  First, let's
> >>> look at the general case.  An optional "UI" (User Interface) is also
> >>> selected...
> >>> * via the "tools" useflag 78 times in use.local.desc
> >>> * via the "ncurses" useflag 10 times in use.local.desc.
> >>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >>>   does "ncurses" show up in use.local.desc ???)
> >>>
> >>>  There is no need for an additional "TUI" (Text User Interface) use
> flag
> >>> for these cases.  "tools" and/or "ncurses" tells you enough.
> Similarly,
> >>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> >>> thing they have in common is a hard-coded dependancy on graphics libs.
> >>> "GUI" is an implicit dependancy of
> gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> >>> Using any of them tells you enough.  What do we accomplish by requiring
> >>> one more USE flag?  This will also make dependancy resolution of
> ebuilds
> >>> more complex, i.e. slower.  Why?
> >>
> >> Simple regular users don't want to be concerned with choice of toolkit
> >> for every single package, as long as a GUI is provided.
> >
> >   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> > make.conf.  This will *FORCE* a gui where applicable.
> >
>
>
> The whole point of USE=gui is to get away from needing to do that.
> Those flags should be used to choose -which- gui toolkit users want
> when one is available, not to choose IF a gui should be built or not.
> Take my example into account, i don't want anything qt based if I can
> avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
> not going to set that globally though because I don't want to choose
> qt4 based front-ends for anything else, and having to guess for every
> random package when i don't care so that I can set a package.use entry
> for it is annoying.
>
>
> >> Furthermore, this matches the recommended USE flag design where the
> >> more important flags are provided as feature flags, while specific
> >> dependency choice flags are minor.
> >
> >   This is going to require *THREE* levels of flags, with the first one
> > being totally unnecessary...
> >
> > Level 1) GUI
> >
> > Level 2) X or xorg or Wayland or Mir
> >
> > Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
>
>
> 1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
> needed.
>
> 2 - If X or Wayland or Mir support is available in a package, then yes
> -- also i don't see a way that we don't need these.
>
> 3 - toolkit selection choices when a package supports multiple (but
> only chooses one) is also a yes.  AND, because we're not tying any-gui
> to one of these flags it means that users are free to set just the one
> variant that they prefer, globally, instead of having to mess about
> per-package.  It also means we can get rid of any or all of these
> particular flags from profiles (except for 'gnome' or 'plasma' or the
> desktop-variant-specific ones).
>
> The point here is that if there's an app (say, wpa_supplicant as
> mentioned before) that provides a gui tool but no options as to what
> that tool needs in terms of toolkit etc, we can -just- have USE=gui
> control whether or not it's built.  It'll pull in qt because qt is
> what it needs, and if someone is dead set against having qt in their
> system then they'll know from the dependency tree.  There's no need to
> peg the individual toolkit to packages like this just to enable a gui.
>
>
> >
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> > or xorg or Wayland or Mir being a requirement for any of
> > qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> > a GUI of one sort or another.
>
>
> Likely there is but I'd need to search.  Extending libraries mostly --
> cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...
>
>
>
>
>

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

[Raymond Jennings]

What about a global "default gui" somewhere in make.conf that says what GUI
to use if a package provides multiple?

Relatedly, I also like having a general "qt" USE flag to select any/the
best version of qt, and then having "qtX' for each version of qt...ditto
for gtk and gtkX

On Wed, Jun 1, 2016 at 9:59 AM, NP-Hardass  wrote:

> On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:
> > On 01/06/16 11:19 AM, NP-Hardass wrote:
> >> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
> >>> Hello,
> >>>
> >>> So here's something more simple wrt GUI USE flags.
> >>>
> >>> Global USE=gui for
> >>> gui - enable an optional graphics user interface or extra GUI tool
> >>>
> >>> 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.
> >>>
> >> I know that it was previously mentioned that there was discussion about
> >> this long ago, but I'm not familiar with those discussions. Is someone
> >> more familiar with those discussions able to bring up the talking
> points?
> >>
> >> One issue that springs to mind though is, let's say a pkg supports only
> >> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
> >> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
> >> remove the gui flag?  I feel like the latter might lead to confusion,
> >> while the former suggests that the flag should be used more generally
> >> than just one toolkit/version being available.
> >
> > This would be the:
> >
> >>> 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.
> >
> > ...portion. :)
> >
> >
> Ah :)
>
> --
> NP-Hardass
>
>

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

[Raymond Jennings]

I'd honestly as a minor issue like ot know why we called it linguas in the
first place.  Linguas itself is latin/romance based in name, so gentoo at
least has been showing a bit of a bias.

Personally I think its a bad name on neutrality grounds alone.

I think though I should also point out...don't we already have existing
ebuilds that expose LINGUAS options in their USE flags?

On Wed, Jun 1, 2016 at 7:17 AM, Michał Górny  wrote:

> Dnia 1 czerwca 2016 16:03:40 CEST, Mart Raudsepp 
> napisał(a):
> >Ühel kenal päeval, K, 01.06.2016 kell 15:19, kirjutas Michał Górny:
> >> As for LINGUAS, it should be left as a toy for advanced users and not
> >> presented as a recommended solution.
> >
> >There is nothing advanced in it for the user, only 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.
>
> You forget the important point that it's done silently and implicitly,
> with no clear way of knowing which localizations were actually discarded
> afterwards.
>
> And the fact that currently LINGUAS affects both packages listing the
> flags and not doing so is causing even more confusion.
>
> >
> >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
>
>
> --
> Best regards,
> Michał Górny (by phone)
>
>

Re: [gentoo-dev] Re: please remove me off your mailing list

[Raymond Jennings]

AFAIK, gentoo-dev is nothing more than a mailing list, and does little more
than take in messages, archive them, and then distribute them to list
members.  I don't believe that such things as IMAP or POP even apply in any
technical sense.

On Tue, May 24, 2016 at 2:51 AM, Duncan <1i5t5.dun...@cox.net> wrote:

> Vadim A. Misbakh-Soloviov posted on Tue, 24 May 2016 14:20:38 +0600 as
> excerpted:
>
> >> thanks.  i just don;t want my inbox full of gentoo anymore.  i use
> >> gentoo
> >
> > Actually, if the case was only to "not had full INBOX of gentoo", it was
> > possible to just enable "sorting" and place gentoo-dev in separate
> > IMAP-folder (like I did). But I guess, you've already unsubscribed, so
> > nevermind ;)
>
> Of course, to place gentoo in a separate IMAP-folder, you must actually
> /have/ an IMAP folder, which implies having an IMAP account, not, say,
> POP3, which seems to be what gets offered 'round here.[1]
>
> Tho of course it's possible to sort local mail, as from POP3, into
> folders/directories too, as I do for various commercial lists and mailed
> notifications from wordpress, etc, tho not for community mailing lists
> like the gentoo lists.
>
> For community lists I normally use gmane's list2news service, getting the
> lists as newsgroups, which I process using my favorite news client (pan,
> FWIW).
>
> ---
> [1] Yes, it is of course possible to run your own mail server locally,
> and serve IMAP, while pulling in mail from various accounts, but then
> that's simply doing the same division into local folders to serve over
> IMAP, that you can do with a mail client pulling in the mail and sorting
> it into similar local folders without the additional IMAP complexity, so
> no need for IMAP in the loop, at least if you have only one primary
> machine, as I do.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>

Re: [gentoo-dev] usr merge

[Raymond Jennings]

Please don't do this.  I want my system left alone.



On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld  wrote:

> On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > On Sun, 10 Apr 2016 02:09:35 +0200
> >
> > "J. Roeleveld"  wrote:
> > > I actually write my own initramfs because neither dracut not
> > > genkernel end up with a convenient boot system.
> > >
> > > I have 2 disks, both encrypted.
> > > I prefer only to enter the decryption password once. Both Dracut and
> > > Genkernel insist on asking for the password/key for every single disk.
> >
> > Dracut on RHEL actually handles this out of the box. Might be worth
> > finding out how.
>
> Might have even been fixed in a more recent version of Dracut.
> I just have passed the point where I am interested in it enough to try it.
> The
> initramfs I use gets embedded into the kernel and doesn't need any kernel
> parameters to work.
>
> It does what it needs to do with minimal work. The simplicity should also
> make
> it faster than the scripts generated by either Dracut or genkernel. (As
> they
> need to parse the kernel cmdline and try to figure out static details on
> the
> fly)
>
> --
> Joost

Re: [gentoo-dev] usr merge

[Raymond Jennings]

My personal opinion:

Unless we have a good reason to do otherwise, don't fuck with upstream.

On Thu, Apr 7, 2016 at 8:12 PM, Damien Levac  wrote:

>
> > Three points :-
> > 1) systemd - not all gentoo users subscribe to this 'philosophy' .. >but
> >no, I don't want get drawn into debates of yes/no of systemd ..
>
> The article start by saying the points are not just for systemd, even
> though the latter might find the merge more 'needed'...
>
> >2) "Today, a separate /usr partition already must be mounted by the
> >initramfs during early boot, thus making the justification for a
> >split-off moot." - no, not all gentoo users have an initramfs and
> >need/want one .. so this is a false assumption.
>
> Agreed, this does not apply to Gentoo.
>
> >3) I still believe there is merit in distinguishing between binaries
> >that can/should be run as root, and those that can/should not. Those
> >that run as root 100% of the time, or use VMs, don't really 'use' linux
> >in the original sense of the OS ..
>
> /usr/sbin still exists in a merged usr, so I don't get that point...
>
> >*hides in his bike-shed, awaiting the flaming torches*
>
> Don't worry: no troll here.
>
> --
> Damien Levac
>
>

Re: [gentoo-dev] usr merge

[Raymond Jennings]

Personally I think that merging things into /usr is a major policy decision
that is likely to contravene upstream installation locations.  I wouldn't
do it lightly, if at all.

On Thu, Apr 7, 2016 at 11:54 AM, Rich Freeman  wrote:

> On Thu, Apr 7, 2016 at 2:32 PM, M. J. Everitt  wrote:
> > In the spirit of hearing arguments for/against .. could someone with the
> > appropriate 'fu' throw up a quick survey for those on this ML (and/or
> > possibly the g-users?) to indicate a preference for a change to a
> > flattened-/usr system?
> >
> > I did think re: the eudev "debate" that it was really hard to quantify
> > the opinion for and against a change, and take it away from the  vocal
> > people that obviously feel passionately about their cause :) .
> >
>
> By all means do so, but we can probably save the trouble and assume
> that 95% of the respondents would prefer things remain as they are,
> and probably 80% would suggest that Gentoo should fully support
> systems without /usr mounted during early boot.
>
> Gentoo has become a fairly conservative distro, even more so when
> everybody else dropped support for not running systemd.
>
> I personally think the /usr merge is a cleaner approach (and I'd go a
> step further and merge sbin and bin), but it was rightly said that
> many of the benefits of a merge only come when you do a lot of other
> things as well.  Of course, we could go ahead and do those things
> later.
>
> I think the main immediate benefit of a usr merge is that it actually
> reduces the risk of shebangs and such pointing to the wrong place (due
> to compat links, and there only being one right place in general), and
> it greatly consolidates the static stuff on the filesystem.
>
> --
> Rich
>
>

Re: [gentoo-dev] usr merge

[Raymond Jennings]

May I suggest first moving everything into /usr one at a time, and for each
file moved out of /bin or /sbin or whatever, replace it with a symlink?

This will allow the /bin and /sbin directories themselves to atomically be
replaced with symlinks later.

Doing it all at once will leave a gap.

For each file:

1.  Install it in the new location
2.  Delete the old file and replace it with a symlink


On Thu, Apr 7, 2016 at 9:36 AM, Alexis Ballier  wrote:

> On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote:
>
>> Again, I don't see this as a reason not to make it optional, but I
>> suspect that we will find bugs here from time to time which users who
>> run with the split /usr will have to report/fix.
>>
>
>
> Considering the advantages of usr-merge are rather specific IMHO but risks
> during the migration are high, I think you're optimistic on the user base
> of usr-merged systems :)
>
> Heck, it hasn't happened yet because there hasn't been such a big need for
> it.
>
>

Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]

[Raymond Jennings]

I think best of all would be the good discipline not to break the tree in
the first place.

Is this something that Repoman could have caught?  If no, should it in the
future?

On Tue, Feb 9, 2016 at 11:30 AM, Mike Frysinger  wrote:

> On 03 Feb 2016 22:35, Andreas K. Huettel wrote:
> > Am Dienstag, 2. Februar 2016, 02:33:30 schrieb Mike Frysinger:
> > > > I took the liberty of doing (2) and reverted the commit. Not sure why
> > > > this needs so much discussion; after all a broken tree is always
> > > > suboptimal.
> > >
> > > unless things are on fire (which i don't think this was), i don't
> > > generally clamor for 0-day fixes.  if we can find a better fix in
> > > a day or so, then i'm happy for that.  i dislike repos with history
> > > that is just a constant stream of land, revert, land, revert, land.
> > >
> > > not that i'm saying your revert was wrong ... just airing my
> > > general personal preferences.
> >
> > You're right of course... but there's one thing we have to keep in mind.
> >
> > We're not running a project were releases are made from the vcs. The vcs
> *is*
> > the release... and whatever is out there gets pushed to users.
> >
> > This is why my personal preference is more to revert if I'm not sure
> that the
> > fix will happen soon.
>
> which is why you weigh the impact on users.  how many people are actually
> affected and for how long ?  in this case, fairly sure no actual user saw
> the failure on their system.
> -mike
>

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Raymond Jennings]

Especially if the changelog files are broken up by year or so.

On Sat, Feb 27, 2016 at 5:14 AM, Luca Barbato  wrote:

> On 24/02/16 01:33, Duncan wrote:
> > That option is there, and indeed, a patch providing it was specifically
> > added to portage for infra to use, because appending entries to existing
> > files is vastly easier and more performant than trying to prepend entries
> > and having to rewrite the entire file as a result.
>
> This sounds wrong in many different ways. The changelog files are tiny
> and makes next to no difference truncate+write or append.
>
> lu
>
>

Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Raymond Jennings]

I think this might be one reason that /etc/mtab was deprecated in favor of
a symlink to /proc/mounts :P

On Thu, Feb 18, 2016 at 9:07 PM, Duncan <1i5t5.dun...@cox.net> wrote:

> Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpted:
>
> > 4.  In the runlevel paradigm you usually think of services running
> > inside a runlevel (perhaps this isn't strictly true, but most people
> > think this way, in part because runlevels don't change much).  In
> > systemd this really isn't the case.  Services run before targets, or
> > after them.  A target won't be considered running if anything it depends
> > on isn't running.
>
> Some minor additional notes, with the first one being here.
>
> Systemd target units are analogous to edge-triggered interrupts, which
> they resemble in that they are simply "synchronization points" (the term
> used in the systemd.target (5) manpage itself).  Level-triggered
> interrupts can be held on or held off (high or low), but edge-triggered a
> re simply events that occur and then are passed as time moves on.  As
> such, targets can be started, but not normally (while the job queue is
> idle) stopped, as they de-assert as soon as they are actually reached,
> tho many of their requirements generally continue to run until stopped by
> some other event, often conflicts= against some other target or general
> unit being started, or specific admin systemctl stop.
>
> Tho the systemd FAQ suggests this wasn't always so, as it suggests using
> systemctl list-units --type=target in answer to a question about how to
> find what "runlevel" you're in.  That command seems to return nothing,
> here, tho, at least while no target is actively starting, so it would
> seem that answer's a bit dated.
>
> It can be noted, however, that certain units, most often specific targets
> intended to be specifically invokable by users, can be "isolated", as
> they have the AllowIsolate unit setting.  Systemctl isolate  will
> then cause it to be started exclusively, stopping anything that's not a
> dependency of that unit.  The systemctl emergency, rescue, reboot,
> shutdown, etc, commands, then become effectively shortcuts to the longer
> systemctl isolate  command form.
>
> > 5.  I'd have to check, but I wouldn't be surprised if systemd doesn't
> > actually require specifying a target at all.  Your default "runlevel"
> > could be apache2.service, which means the system would boot and launch
> > everything necessary to get apache working, and it probably wouldn't
> > even spawn a getty.  This is NOT analogous to just putting only apache2
> > in /etc/runlevels/default, because in that example openrc is running the
> > default runlevel, and it only pulls in apache2.  Systemd is purely
> > dependency driven and when you tell it to make graphical.target the
> > default runlevel it is like running emerge kde-meta.  If all you wanted
> > was kde-runtime you wouldn't redefine kde-meta to pull in only
> > kde-runtime, you'd just run emerge kde-runtime.  Again, I haven't tested
> > this, but I'd be shocked if it didn't work.  Of course, specifying a
> > service as a default instead of a target is very limiting, but it would
> > probably work.  Heck, you could probably specify a mount as the default
> > and the system would just boot and mount something and sit there.  Or
> > you could make it a socket and all it would do is sit and listen for a
> > connection inetd-style.
>
> As mentioned both in the systemd FAQ and in the systemd.special (7)
> manpage, under default.target, this is the default unit started at
> bootup.  Normally, it'll be a symlink to either multi-user.target
> (analogous to sysvinit semi-standard runlevel 3, CLI, no X), or
> graphical.target (analogous to sysvinit semi-standard runlevel 5,
> launching X and and a graphical *DM login).
>
> I don't see specific documentation of whether symlinking to a non-target
> unit is allowed, but systemd does have a commandline option --unit=,
> which is explicitly documented to take a _unit_, default.target being the
> default, but other non-target units being possible as well.  Presumably
> systemd would examine said unit, looking for DefaultDependencies=no, and
> if not specifically set, would start the early "system level" targets,
> before starting the named unit in place of the normal default.target.
>
> So it's definitely possible to do via systemd commandline, but I'm not
> sure if default.target is followed if it doesn't symlink a target unit,
> or not.  I'd guess yes, but have neither seen it specifically documented
> nor tested it myself, nor read of anyone else actually testing it.
>
> >
> > I find it more helpful to think of targets as just units that don't do
> > anything.  We don't use them in openrc but I suspect it would work out
> > of the box, and maybe we should even consider doing it in at least some
> > cases.  For example, right now /etc/init.d/samba uses some scripting to
> > launch both nmbd/smbd and fancy config file parsing to

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[Raymond Jennings]

Seems like there's a trade off in resource usage re: git vs rsync

Rsync seems to be relatively cheap, but has a fixed part of its overhead.
Probably one of the reasons that you get temp-banned from the mirrors if
you sync too often.

Git overhead appears ot be higher on the variable parts but lower on the
fixed parts, and from what I gather, the more often you sync, the lower the
overhead.

As far as changelog generation, what about causing the changelogs to be
autogenerated by the end user's computer?  Divide and conquer.

Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

Speaking of which is there a bug filed for that?

On Sat, Feb 13, 2016 at 5:16 PM, Rich Freeman  wrote:

> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings 
> wrote:
> > So what do you guys think of leaving behind empty stubs for compatibility
> > and then simply filing a tracking bug blocked by any packages that
> removing
> > herds broke?
>
> It isn't entirely clear that anything is actually broken at the
> moment, but if distributing an empty herds.xml file makes somebody's
> life easier I have no objections.  I don't think it would have
> alleviated Patrick's original concerns in this case.
>
> --
> Rich
>
>

Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

So what do you guys think of leaving behind empty stubs for compatibility
and then simply filing a tracking bug blocked by any packages that removing
herds broke?

On Sat, Feb 13, 2016 at 2:44 PM, Rich Freeman  wrote:

> On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings 
> wrote:
> > The guys making the API change bear the burden of fixing anything it
> breaks,
> > however, if something gets officially deprecated, don't go out of your
> way
> > to support continued use.
>
> We tend to do this already for things like PMS, which is as close as
> Gentoo gets to something like the kernel API.
>
> However, sometimes a gradual transition doesn't always make as much
> sense, and Gentoo doesn't always have the manpower to make every
> change a pretty one.
>
> And there is a cost to maintaining that kind of backwards
> compatibility.  For example, debian chose to keep its LSB init scripts
> and write systemd unit wrappers around them.  If they had chosen
> openrc instead I wouldn't be surprised if they kept the LSB init
> scripts and wrote an openrc compatibility layer around that.  While
> this does provide a more stable experience, it also leaves around a
> ton of cruft.
>
> In general I tend to favor a balance.  Trying to get everything just
> right was why the git migration literally took years, and even that in
> the end had a few bumps.  Gentoo users need to be willing to deal with
> the occasionally bump in the road - we try to provide a fairly cutting
> edge experience, with minimal layers in integration.
>
> But, there is nothing really wrong with your suggestion, and we try to
> accommodate that approach when we can.
>
> > And yes, the personal attacks probably should die down.
>
> ++
>
> --
> Rich
>
>

Re: [gentoo-dev] Uncoordinated changes

[Raymond Jennings]

My two cents:
Do it like in linux kernel.

The guys making the API change bear the burden of fixing anything it
breaks, however, if something gets officially deprecated, don't go out of
your way to support continued use.

I for one would consider "ok, this method is not working, deprecate it so
that it doesn't get any worse because we're going to be changing it later"
is quite an appropriate way to bear the burden.

Anyone getting grandfathered from doing it the old way escapes the burden,
but by putting the entire community on notice via the GLEP process, well,
grandpa got put out to pasture and after that point the community inherited
the burden of not deepening the dependency on the freshly deprecated
feature.

Since this is a collective superproject it can also be said that we all
bear the collective burden of cooperating towards a common goal.

And yes, the personal attacks probably should die down.  I'm not with
devrel or comrel but even I can tell such sniping and whatnot can decrease
overall productivity of the distro by bringing down morale.

Solution?

If anything broke because herds were removed?  My suggestion is to leave
behind herds as empty stubs somehow, officially deprecate herds (which the
council already did from what I gather), and file a tracking bug to have
herds removed entirely.

Then just do what they do with new versions of gcc, and have existing tools
that break when herds are removed have new bugs filed on them that block
the tracking bug.  The breakage cited in the first post would be a good
example of a dependent bug that ought to block the "we still have herds"
bug.

What do you guys think?  Just use a tracking bug to flush out anything
still using herds like they do when new versions of GCC come out and break
stuff?

On Fri, Feb 12, 2016 at 2:02 PM, Michał Górny  wrote:

> On Fri, 12 Feb 2016 10:07:10 +0100
> Patrick Lauer  wrote:
>
> > On 02/12/2016 08:48 AM, Michał Górny wrote:
> > > Dear Ignorant Patrick,
> > Hello human! Your politeness module seems to have crashed.
>
> Please do not expect politeness when you insult someone.
>
> > > On Thu, 11 Feb 2016 21:15:34 +0100
> > > Patrick Lauer  wrote:
> > >
> > >> ... or why just changing stuff is not enough:
> > >>
> > >> A few days ago I was told that
> > >> http://euscan.gentooexperimental.org/herds/ was displaying an empty
> > >> list. Which is annoying because people sometimes want to see what
> > >> upstream updates are available for their herd.
> > >>
> > >> Well, we renamed herd to project. Because reasons.
> > > No, we didn't. Herd was collection a packages. Project is a collection
> > > of developers. Project coexisted with herds for a long time. As it was
> > > explained already in length. Multiple times.
> > So you just pivoted the organization from A->B to B->A.
> >
> > I still don't see the advantage in that. Maybe I should have expressed
> > my concerns more vocally, but in general I don't have time to worry
> > about all the little things.
>
> You still have trouble understanding who did what. I'm tired of being
> blamed for something that wasn't my idea.
>
> > >> I don't care how it is named, but this change broke euscan in a
> > >> user-visible way. Now I could just try to rename things there too, but
> > >> that won't work:
> > >>
> > >> euscan uses gentoolkit for parsing metadata.xml and herds.xml
> > >> (Since herds.xml is basically unmaintained cruft at this point this
> will
> > >> break soon anyway ... but ...)
> > >> Changing gentoolkit to use projects.xml instead of herds.xml won't be
> a
> > >> simple migration since the data organization changed.
> > >>
> > >> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
> > >> -> email it goes backwards:
> > >> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
> > >> -> Project name
> > >>
> > >> Since this involves XML and python's ElementTree library it's a
> > >> nontrivial change that also removes a few now useless helpers
> > >> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> > >> helper instead. Err, get_proj ... ah well, whatever name works)
> > >>
> > >> And all that just so (1) gentoolkit output works and (2) euscan
> updates
> > >> properly. Both of which I don't really care about much, but now that
> > >> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> > >> IRRITATED.
> > > You are completely incorrect, as you have been told already multiple
> > > times. People would really appreciate if you spent at least a little
> > > part of the time you spend complaining, inventing issues and insulting
> > > others listening to what they're telling you.
> > >
> > > So let me repeat, again. euscan works. Want packages from Python
> > > project? Then select the appropriate maintainer from the 'maintainers'
> > > section:
> > So you're saying I have no way to search by herd, err, project now.
>
> Yes, you have. You can use project's e-mail address to find
> the project. And as 

Re: [gentoo-dev] "Lazy" use flags?

[Raymond Jennings]

Yeah the "soft" thing was meant as "do this unless something breaks, then
do it otherwise"

On Wed, Feb 10, 2016 at 8:57 PM, Kent Fredric  wrote:

> On 11 February 2016 at 15:51, Rich Freeman  wrote:
> > In this case you just wouldn't enable python 2.7 support, but you
> > wouldn't disable it either.  Portage would just pull it in where it is
> > needed.
>
>
> But you still need a mechanism in place if you *dont* want that to happen.
>
> I might choose to forbid python2.7 support, and portage really
> shouldn't "auto enable" python 2.7 support if I've explicitly
> indicated I don't want python 2.7 support.
>
> Unless of course you're suggesting "USE=-python_targets_python2_7"
> would not be "auto-enableable"
>
> But then you're *still* requiring a tri-state USE.
>
> USE="-foo" + IUSE="+foo" => "-foo"  => autouse enables foo if required
> USE=""  + IUSE="+foo" => "foo"=> standard EFFECTIVE_USE="foo"
> USE="foo" + IUSE = "+foo" => "foo" => standard EFFECTIVE_USE="foo"
> USE="-foo" + IUSE="foo" => "-foo"  => autouse enables foo if required
> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> USE="foo"  + IUSE="foo" => "foo"   => standard EFFECTIVE_USE="foo"
>
>
> So the logic composing USE + IUSE has to change in generating the
> effective USE set so that USE + IUSE can emit a 3rd and 4th state.
>
> USE="-foo" + IUSE="+foo" => "-foo!!"  => autouse fails if foo is required
> USE=""  + IUSE="+foo" => "foo"=>  standard
> EFFECTIVE_USE="foo", auto-unuses foo if blocked by a dep
> USE="foo" + IUSE = "+foo" => "foo!!" => standard EFFECTIVE_USE="foo",
> fails if foo is "blocked" by a dep
> USE="-foo" + IUSE="foo" => "-foo!!"  => autouse fails if foo is required
> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> USE="foo"  + IUSE="foo" => "foo!!"   => standard EFFECTIVE_USE="foo",
> fails if "foo" is blocked by a dep.
>
>
> Mentally keeping track of this accounting magic would be complicating
> matters.
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
>

Re: [gentoo-dev] "Lazy" use flags?

[Raymond Jennings]

I suppose we could consider it as a hard vs soft configuration?

hard enable = Enable no matter what, and cause an error
soft enable = Enable, unless it would break dependency
soft disable = Disable, unless it would break a dependency
hard disable = Disable no matter what, and cause an error

On Wed, Feb 10, 2016 at 12:00 PM, Róbert Čerňanský 
wrote:

> On Wed, 10 Feb 2016 15:23:27 +1300
> Kent Fredric  wrote:
>
> > >> I'd personally rather the list of "automatically turn this on if
> > >> required" be something I had the power to restrict than have a
> > >> blanket "autodostuff", because in the event some USE can't be
>
> Although I prefer non-explicit auto/lazy use flags, the explicit
> approach is also perfectly fine (especially when compared to current
> situation).  In the end I would most certainly be able to specify all
> use flags as lazy and thus have effectively the same behaviour as with
> non-explicit approach.
>
> > So in comparison:
> >
> > /etc/portage/package.use  is essentially "the world file but for
> > useflags"
> >
> > And we have no analogue of
> >
> > /etc/porage/package.unmask  or /etc/portage/package.keywords that
> > applies to useflags.
>
> I find /etc/portage/package.use (or make.conf) analogous to world AND
> mask files.  For packages world + mask files give you possibility to
> specify which packages you:
>
> - want (listed in world file)
> - don't want (listed in a mask file)
> - not care (not listed in any of them)
>
> (Assuming non-explicit approach) similarly for use flags, package.use
> or make.conf gives you possibility to specify which use flags you:
>
> - want (listed in package.use or make.conf)
> - don't want (listed with '-' in package.use or make.conf)
> - not care (not listed in any of them)
>
> The advantage of explicit approach could be that even if a use flag is
> enabled or disabled globally, it would still be possible to make it
> lazy/automatic for specific packages.
>
> > I can see how some people might want an analogue of "just install
> > dependencies if they're needed regardless if I said I need them" that
> > applies to useflags, but you'd probably want a "don't install this
> > even if it appeared to be needed" companion tool that behaves akin to
> > /etc/portage/package.mask
>
> This would be package.use or make.conf.
>
>
> --
> Róbert Čerňanský
> E-mail: ope...@tightmail.com
> Jabber: h...@jabber.sk
>
>

Re: [gentoo-dev] EAPI 6 portage is out!

[Raymond Jennings]

On Wed, Nov 18, 2015 at 1:25 AM, Alexander Berntsen 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 18/11/15 08:25, Ulrich Mueller wrote:
> > - If you mix stable and unstable then you are by definition an
> > advanced user, who will be able to cope with the situation. :)
> This attitude is shitty, and I am willing to wager a really big bunch
> of users fall into this category.
>

I second the motion.

I can vouch for myself as such a user who often uses unstable packages to
get new features or dodge bugs in the stable versions.

As a general default, though, I stick with stable packages.

Taking an occasional unstable package in an otherwise stable system (and
obeying any revbump directives provoked by dependencies) is a legal
operation that is actually supported by commit rules that prohibit stable
versions from depending on unstable versions of dependencies.

Why would that policy exist if mixing stable and unstable were unsupported?

I don't think EAPI 6 is *that* shiny, that we need to start using it
> prior to stable Portage supporting it. It's a potential mess for a
> huge portion of our users.
>
>
> That said, I'd like to extend my thanks to Micha? for working on this.
> - --
> Alexander
> berna...@gentoo.org
> https://secure.plaimi.net/~alexander
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJWTEQCAAoJENQqWdRUGk8BrQ0P/j4ZDShZNWtvyw/QtCSgY5+i
> CTYx2cqv0+dmtIE4pdteaf535I8Ax7WH9c1OnTbMl1taAmTvEIulQUof64rjz/PB
> t5csfLQqgNV6w0ck5g6+dJq2iNgC65QpPbtENXYOwkq6bo9Zs1KFuodq6b0y9M7y
> 7Wk3gLIzjZBwXFpEbSupu0lM3nS/RPUJ20SH0aUfkpxgUVJJr5UENsxPyk8XzETf
> caJyfGmb5LcNVKmq6bRUA67KPzAWtQJTw2eUHyyTd0lob1QVIKDwizFXA5ZxCPsC
> PrZZ7txyOEiKdOOupF2HYlit2pWCITaS1ELyzr9aKDsRB4+WsrvuSA0JuRUNV9yn
> PP4aocOpmSbGiuYsQl2kvZcuEipVjqFc+iqZAW6HQlf6/v2LMOTSeCp1lpwLEbxQ
> zvK29IdR0uOQDctI3i0X0arV0CW/C3DVxdHlyxHMMKgjmCmr2lPmB+xPSzpU1aYE
> kB8+9l82PjoBvI5+A3S0ynACF4c018NrIDWC+RLgPh3KfBw2yiXRZOouW1snfXca
> 7Rqv5BDaURKuwlfckl2mNG5bWCq0jc2K+Rru9JcgviX7HaAO3SBIhH1g860Xi9Nn
> UN4CoXZohXph8XD/o6CEu+TD4puu5H1xMGsDkD5PihGsxnYyhR9pJdlz0nf5ZuPk
> p8r78oHdqMX2Sb7LmUh1
> =WAIc
> -END PGP SIGNATURE-
>
>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Raymond Jennings]

As a possibly relevant side note, I've observed how api changes are handled
in the linux kernel:

You can change whatever you want if it's a good idea, but as part of
proving it, you have to be willing to take over the warranty for anything
you break.

So basically you change what you please ONLY if you also take the burden of
fixing everything that depended on what you screwed with.

Is this how things are handled by gentoo as well?

On Mon, Nov 16, 2015 at 11:19 PM, Michał Górny  wrote:

> On Mon, 16 Nov 2015 23:38:08 + (UTC)
> "Mike Pagano"  wrote:
>
> > commit: aac24917ebe254a23990f0d7fff9f6f570b99d15
> > Author: Mike Pagano  gentoo  org>
> > AuthorDate: Mon Nov 16 23:37:55 2015 +
> > Commit: Mike Pagano  gentoo  org>
> > CommitDate: Mon Nov 16 23:37:55 2015 +
> > URL:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aac24917
> >
> > kernel-2.eclass: Fix for git-sources 4.4_rcX
> >
> >  eclass/kernel-2.eclass | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index 0f47b8c..5a9ea9f 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -1079,9 +1079,9 @@ unipatch() {
> >   # https://bugs.gentoo.org/show_bug.cgi?id=507656
>  #
> >
>  
> >   if [[ ${PN} == "git-sources" ]] ; then
> > - if [[ ${KV_MAJOR}${KV_PATCH} -ge 315 &&
> ${RELEASETYPE} == -rc ]] ; then
> > + if [[ ${KV_MAJOR}.${KV_PATCH} > 3.15 &&
> ${RELEASETYPE} == -rc ]] ; then
>
> Don't do string comparison on numbers. It can fail randomly,
> and teaches others who read it bad practices. For example, it would
> fail when kernel reaches version 10 ;-P.
>
> Instead:
>
> [[ ${KV_MAJOR} -gt 3 || ( ${KV_MAJOR} -eq 3 && ${KV_PATCH} -gt 15 ) ]]
>
> >   ebegin "Applying ${i/*\//} (-p1)"
> > - if [ $(patch -p1
> --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -eq 0 ]; then
> > + if [ $(patch -p1
> --no-backup-if-mismatch -f < ${i} >> ${STDERR_T}) "$?" -le 2 ]; then
> >   eend 0
> >   rm ${STDERR_T}
> >   break
> >
>
>
>
> --
> Best regards,
> Michał Górny
> 
>

Re: [gentoo-dev] Re: ChangeLog

[Raymond Jennings]

Isn't the whole anongit.gentoo.org concept designed to allow anonymous,
read-only git to scale indefinitely in the future?

Are there any plans in the works on how to utilize this domain name?

On Thu, Nov 5, 2015 at 6:33 AM, Alexis Ballier  wrote:

> On Tue, 3 Nov 2015 16:04:38 +0100
> Chí-Thanh Christopher Nguyễn  wrote:
>
> > Matt Turner schrieb:
> > > The git transition had been 9 years in the making and has massively
> > > improved Gentoo development. Look at the graph of contributions per
> > > month: https://www.openhub.net/p/gentoo
> >
> > I'd like to point out that some stuff that has previously been done
> > in a single commit is now several commits (e.g. bump + removal of old
> > version). How much of the rise in commit activity is attributable to
> > actual development increase is not clear to me.
>
>
> Also, last I checked, openhub couldn't even process our CVS tree.
> Meaning the only stats it had were some random overlays hosted on git.
>
>

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Raymond Jennings]

Can a single project have multiple super-projects?  If so, herds might
become redundant.

On Sat, Sep 19, 2015 at 5:07 PM, Rich Freeman  wrote:

> On Sat, Sep 19, 2015 at 7:32 PM, Raymond Jennings 
> wrote:
> > Is it possible for projects to be nested, possibly within multiple
> > super-projects?
> >
> > Like, for example, a project dealing with a gnome chat client itself
> being
> > members of both the gnome and the chat projects (hypothetically
> speaking)?
>
> Yes, many projects are already nested in such a manner.
> For example, the website project is a sub-project of PR.
>
>
> --
> Rich
>
>

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Raymond Jennings]

Is it possible for projects to be nested, possibly within multiple
super-projects?

Like, for example, a project dealing with a gnome chat client itself being
members of both the gnome and the chat projects (hypothetically speaking)?

Maybe allow projects themselves to be members of other projects when needed.

On Sat, Sep 19, 2015 at 3:26 PM, Rich Freeman  wrote:

> On Sat, Sep 19, 2015 at 5:07 PM, Daniel Campbell  wrote:
> > +1 in general, but I'm a little pensive about allowing non-devs to
> > become official project members. Becoming a developer can be a
> > grueling process, so I understand that some don't have the time or
> > motivation, and still want to help out. So perhaps we could have
> > contributors who wish to be project members pass our ebuild test, or
> > some other litmus test to prove themselves, like a developer proxying
> > them or something. Non-devs don't have direct push permissions to our
> > main repo, so to my knowledge they'd still have to go through a dev.
> > I'd just like to see some sort of documentation that sets expectations
> > for non-dev project members so that a new contributor understands what
> > would be expected.
>
> I don't think that project member and commit access have to be
> all-or-nothing together.
>
> I'd suggest leaving it up to each team to decide who is allowed to be
> a member if they're a non-dev, and the rest are just contributor.  The
> team can use whatever rules seems best.
>
> Project members don't necessarily have formal powers, though typically
> they participate in elections for the lead.
>
> As always, if there is trouble there is always comrel or council.  I
> think most teams should be able to figure out who should and shouldn't
> be acknowledged as a member.
>
> But, there is still the GLEP 39 issue.  I'd suggest the "contributor"
> label for things like alias members until that is sorted out.  There
> isn't really much distinction in reality.
>
> --
> Rich
>
>

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

[Raymond Jennings]

Gentoo is a distribution that incorporates heterogeneous software packages,
each of which may have their own versioning scheme.

We kinda have to treat the upstream version as an opaque blob because of
this.

Maybe I'm missing something but I don't think it's ok to screw with
upstream supplied version numbers.  Sorting them is fine but to me they
appear best treated as whole atoms that shouldn't be picked apart.

On Fri, Sep 18, 2015 at 6:02 PM, Kent Fredric  wrote:

> On 19 September 2015 at 10:09, konsolebox  wrote:
> > As for A6FGHKE and TRIAL, it's impossible to tell their actual level
> > values so even if we choose to map them lexicographically, we would
> > still not be able to use a universal algorithm that could tell how it
> > affects the base version (just like how stages affects it) and how it
> > compares with other values as well.  So it would still be up to the
> > maintainer how he would represent the versions on ebuilds.
> >
> > One could do:
> >
> > Math-BaseCnv-1.6.20YYMMDD
> >
> > and
> >
> > Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD
>
>
> And both of those translations would be wrong.
>
> Math::BaseCnv's version is illegal even by Perl standards, but it uses
> it anyway.
>
> And that also means the is no way in Perl to declare you need
> 1.6.A6FG, any such dependency will either be treated as impossible to
> satisfy, or satisfiable by all versions, and there is no way to even
> *sort* versions that have invalid string components. Using a date
> based segment in Gentoo will allow us to package the component itself,
> but date order doesn't actually imply version order, they're just
> highly similar. Which basically means even *if* we normalise it
> somehow, any dependency we have on it in tree is just waiting to be
> wrong.
>
> Fortunately, cases like that are rare, and the associated yelling in
> bug reports are preferred avoided.
>
> And in the latter case, the "TRIAL" component is not actually part of
> the version, but is itself a release-grade specifier, and just
> so happens to be part of the *archive* name.
>
> This is because CPAN upstream are not "archive" oriented dependencies,
> but *module* oriented dependencies.
>
> And an archive can have >1 modules and they may not all have the same
> version.
>
> Hence, http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/
>
> Is actually just "1.58_01" + Alpha signifier
>
> Which here is redundant, because the "_" is an alpha signifier as
> well, and is deemed invisible in perl code.
>
> Alas, there's a horrible historical bug in version.pm  that stupidly
> treats "_" in any version as significant.
>
> But either way, the right way to nomalise those versions is to elide
> the _ and '-TRIAL' parts.
>
> So the version is in fact: 1.5801  + ALPHA grade
>
> And then you get to the horror of the fact CPAN has *2* versioning schemes:
>
>MAJOR.FLOATINGPART
>
>DECIMAL.DECIMAL.
>
> Which means:
>
>1.58.1  is less than 1.58
>
> Why?
>
> Because 1.58.1 would be 1.058001   ( decimal to float conversion )
> And 1.58 would be 1.58  ( float not converted due to only 2 parts )
>
> This is the horror of mixing too many version schemes into the same
> namespace.
>
> You get recurrent horrible gotchas that nobody intends on making, and
> makes repeatedly.
>
> The collective experience of Perl/CPAN and versions is that the
> toolchain operators
> wish we'd only ever had one version scheme, because there are just
> *so* *many* *ways*
> to confuse yourself when you switch from one scheme to another
> thinking its fine.
>
> And there are *so* *many* *ways* to royally cock it up, or do it the
> best way possible, and then have
> a downstream vendor not understand the reality of perl versions and
> then have downstream make a mess of it.
>
> For instance, downstreams without education are tend to see:
>
>  1.1,  1.10 , 1.2, 1.20
>
> as:
>
>   1.1 , 1.2,  1.10, 1.20
>
> When in reality, 1.10 = 1.10, and 1.2 == 1.20
>
> In short: I'd rather Gentoo just had a tighter version scheme and good
> tooling to allow mapping from one-scheme to another
> on a case-by-case basis with forced normalised versions on the package
> itself.
>
> Perl Herd are doing just that because it greatly simplifies version
> interactions.
>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
>

Re: [gentoo-dev] RFI: A better workflow for github pull requests

[Raymond Jennings]

I agree.  I think that any "master" version of whatever repo we use should
be hosted on gentoo owned infrastructure.

Github might be allowed to take pull requests but I think it should be a
slave to whatever's hosted on gentoo.

That way if anything gets screwed up on github gentoo could always hit the
big fat reset button on gitub


On Sun, Sep 13, 2015 at 10:56 AM, Andrew Savchenko 
wrote:

> On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote:
> > Hello, everyone.
> >
> > The current workflow for handling github pull requests is at least
> > suboptimal. Handling pull requests takes a fair effort from the few
> > developers contributing there, and the progress is often stalled by
> > package maintainers which are either unresponsive or not registered on
> > github at all. That's why I'd like to get your ideas on how we could
> > improve the workflow.
> >
> >
> >
> > Current workflow
> > 
> >
> > Let's summarize the current workflow first. Right now, there's a few
> > Gentoo developers who actively monitor pull requests on gentoo/gentoo
> > repository. Those developers review incoming pull requests and help
> > submitters get their contributions in shape. Some of those developers
> > also try to 'CC' (@-mention) package maintainers to get their attention
> > on the pull request.
> >
> > Sadly, @-mentioning sucks for a few reasons:
> >
> > 1. Many of the Gentoo developers have different nicknames on GitHub.
> > Some developers don't even set their real names which makes them even
> > harder to find.
> >
> > 2. Teams can be created only by repository 'owners' (which pretty much
> > is equivalent of Infra). Which practically means I'm the only person
> > migrating teams (projects, herds) to GitHub.
> >
> > 3. GitHub notifications are not very reliable. Some developers get only
> > some of them via mail, some don't. And some simply don't care.
> >
> > 4. Some developers openly refuse to work with contributors via GitHub.
> > Proxying them manually is not really productive.
> >
> >
> >
> > Potential solution: bi-dir github <=> bugzilla integration
> > ==
> >
> > My current idea would be pretty much that:
> >
> > 1. a new dedicated Gentoo bug would be automatically created for every
> > pull request on github,
> >
> > 2. all comments from github would be automatically copied to bugzie.
> > All bugzie comments would be automatically copied to github,
> >
> > 3. resolving the bug would automatically close the relevant pull
> > request.
> >
> > This way, all pull requests can be assigned to package maintainers in
> > Bugzilla without having to resort to GitHub user or team names. All
> > involved parties would get more reliable Bugzilla notification mails.
> > They could choose to either use the provided URLs to discuss the pull
> > request on GitHub, or discuss it directly on Bugzilla, whichever is
> > more convenient to them.
> >
> > The additional Bugzilla load should be manageable, though we may want
> > to employ some kind of rate limiting in case someone though it'd funny
> > to spam our bugzilla via spamming github.
> >
> > Problems:
> >
> > - handling line comments (probably a Bugzie comment with quoted code
> >   snippet),
> >
> > - handling comment edits and removals,
> >
> > - some people will get double mail for each comment,
> >
> > - extra bugs for existing issues (we shouldn't really try to reuse
> >   existing bugs for this).
> >
> >
> >
> > What are your thoughts? Any other proposals?
>
> Gentoo workflow should not depend on a proprietary tools like
> github issue tracker and github pull requests.
>
> Best regards,
> Andrew Savchenko
>

Re: [gentoo-dev] www-client/chromium gtk3 support

[Raymond Jennings]

On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman  wrote:

> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell  wrote:
> >
> > I like the general 'gtk' flag we generally use to choose *which*
> > toolkit, and local USE flags for specific versions, if they are
> > supported. But in that case, the general gtk flag should be
> > interpreted as the latest version supported, so users don't come
> > across weirdly behaving packages that default to gtk2 (unless that
> > version is the most stable).
> >
> >...
> >
> > For starters, versioned USE flags more than likely don't belong in
> > make.conf's USE variable and shouldn't be global.
>

Personally i disagree with this.

Versioned use flags for widely used dependencies (like a windowing toolkit)
IMO qualify as global USE flags because they have a common effect across
many packages.

That was roughly my proposal.
>
> USE=gui or something like that if the main effect is to have a gui or
> not.  That is the sort of thing that SHOULD go in make.conf or in a
> profile.  If disabling gtk makes it a console-only application then
> use the gui flag.
>
> USE=gtk if the main effect is to select /which/ toolkit is used if
> more than one is optionally supported.  That /might/ go in a make.conf
> or profile, but probably shouldn't in general.  It is more appropriate
> for something like the desktop/gnome profile than the desktop profile.
>
> USE=gtk# if you're picking which version to use.  That should /almost
> never/ go in a profile (unless you're talking about a testing profile
> of some kind, such as on an overlay), or in a global config unless you
> REALLY know what you're getting into.  Users setting this globally
> should expect to run into bugs.  The package should default these
> flags to whatever is most appropriate for the specific package.
>

I really like this approach, and I think that having tiers of
(gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE
flags coherent.

I'd be tempted to even say to not have gtk3 but instead call the flag
> chromium-gtk3 or whatever so that it becomes very difficult to put in
> the global config.  However, that goes against our general principle
> of letting the user break their system and keep the pieces if they
> think they know what they're doing.  If somebody WANTS to test out a
> gtk3-only system or whatever they should have the freedom to do so,
> understanding that testing sometimes uncovers problems.
>

I actually also think that there should be a single USE flag for building
on gtk3, called gtk3.  calling it "(packagename)-gtk3" is a bit redundant,
and also flies in the face of having a single global flag with a coherent
purpose.

Of course any change will need a transition period, news, handbook
> updates, etc.  For the person who wants the "just works" experience
> they can pick a profile and it will do the right thing, and if they
> want to tailor things a bit more the USE=(-)gui flag will do what it
> would be expected to do.
>
> --
> Rich
>
>

Re: [gentoo-dev] RFC: EAPI 4 deprecated & ban

[Raymond Jennings]

What's the best way to get rid of deprecated ebuilds?

Do we just wait for their maintainers to migrate them or should they be
sought out and flagged?  I'm pondering searching for EAPI 0 ebuilds and
filing bug reports on them.

On Sun, Aug 16, 2015 at 6:57 AM, Rich Freeman  wrote:

> On Sun, Aug 16, 2015 at 9:47 AM, "Paweł Hajdan, Jr."
>  wrote:
> > On 8/16/15 3:29 PM, Rich Freeman wrote:
> >> They are deprecated already:
> >> https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf
> >>
> >> Deprecated means stop adding them, and move away from them.  Repoman
> >> will give you a warning about them.
> >
> > Is anything blocking deprecating EAPI4 in the same way?
> >
>
> Not that I'm aware of, and it is probably something worth discussing
> at this point.  Moving to EAPI5 has some user-visible improvement for
> many packages, like slot-operator dependencies.  EAPI6 will also have
> a user-visible improvement in forced support for user-patching for all
> ebuilds (any ebuild can support user-patches now, but it isn't
> mandatory).  So, more than in the past it is useful to nudge devs
> along to the most recent EAPIs (in the past they've been more about
> maintainability and less user-visible).
>
> --
> Rich
>
>

Re: [gentoo-dev] RFC: EAPI 4 deprecated & ban

[Raymond Jennings]

On Fri, Aug 14, 2015 at 6:16 PM, Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 14/08/15 06:43 PM, Johannes Huber wrote:
> >
> >
> > Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
> >> Hi,
> >
> >> While I have no objections about EAPI 4 deprecation (except
> >> concerns mentioned above), I see no strong need for this also.
> >> Just declare EAPI 5 as recommended. Having legacy support for
> >> EAPI 4 will not hurt possible contributions.
> >
> > Just imagine that the Gentoo developer quiz doesn't contain
> > question about ancient stuff. Would reduce the question count at
> > least by some questions. Which could lower the barrier to step
> > forward for some people. Or do we have enough developers?
> >
> >> Best regards, Andrew Savchenko
> >
> >
>
> So first of all, yes i believe all eclasses support EAPI5 by now.
>
> Secondly, though, conversion to EAPI5 is not actually trivial, there
> are a couple of things, 'usex' related for instance, that also need
> to be taken care of.  If it was just a matter of running a sed -e
> 's/^EAPI=4/EAPI=5/' on all in-tree ebuilds this would have been done
> a long time ago.
>
> So although deprecation of EAPI4 is a nice thought, there is still
> some work to be done.
>
> Finally, the gentoo developer quiz -should- still contain questions
> about ancient stuff.  There are still EAPI0 and EAPI2 ebuilds in the
> tree at least.


Why not deprecate those before we deprecate EAPI4?

Just my opinion here but I think that we'd do better deprecating the oldest
versions one at a time until they're all upgraded to the newest stuff.

-BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iF4EAREIAAYFAlXOkvMACgkQAJxUfCtlWe1VkQD/cBeJW7Go12EkpSDL86MGzcNJ
> nHOBBHkdH9iQPCNfeo0BAO3v6rs7FHEIeJ7ze+JDFGqvJcZbsdcXZafRZaqbpwLE
> =bh9T
> -END PGP SIGNATURE-
>
>

Re: [gentoo-dev] RFD: new global USE flag gtk3

[Raymond Jennings]

If I may ask, isn't usage by 27 packages ample grounds on its own to make
it a global use flag?

This is one of the questions I noticed on the ebuild quiz, and there the
ballpark is around 5 packages sharing a use flag.  we're way over that mark.

my two cents.


On Tue, Feb 25, 2014 at 11:22 AM, Tom Wijsman  wrote:

> On Tue, 25 Feb 2014 17:28:41 +0200
> Samuli Suominen  wrote:
>
> >
> > On 20/02/14 18:27, Tom Wijsman wrote:
> > > On Thu, 20 Feb 2014 11:26:18 +0200
> > > Samuli Suominen  wrote:
> > >
> > >> On 20/02/14 10:47, Steev Klimaszewski wrote:
> > >>> On Thu, 2014-02-20 at 10:40 +0200, Samuli Suominen wrote:
> >  On 20/02/14 09:44, Steev Klimaszewski wrote:
> > > On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote:
> > >> On 20/02/14 00:23, Ulrich Mueller wrote:
> > >>> Following up to today's QA meeting: The gtk3 USE flag is used
> > >>> by 27 packages, so I suggest making it a global flag:
> > >>>
> > >>> gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit)
> > >>> version 3
> > >>>
> > >>> Ulrich
> > >> that would suggest it's fine to use, and is anything but
> > >> temporary
> > >>
> > >> -1 from here
> > >>
> > > MATE desktop (which I hope to bring in to Portage soon) can be
> > > built against gtk+ 2 or gtk+ 3, and upstream supports doing
> > > both, so +1 from me.  Just because gtk+ 3 is the latest, does
> > > not mean it's the greatest, and I really wish people would
> > > realize that newest != bestest.
> > >
> > >
> >  Then you pick whatever is best supported for MATE, and ship it
> >  using that. Later when they have completed their support for
> >  GTK+-3, and it's the best supported, you ship that. It's not
> >  rocket science.
> > 
> > >>> OR, since I'm the maintainer, I decide that I'm willing to deal
> > >>> with both, instead of you telling me that I need to pick one or
> > >>> the other. Upstream says both are supported and viable, and I'm
> > >>> willing to deal with the headaches.  Just because you're
> > >>> unwilling doesn't mean others aren't.  kthx.
> > >>>
> > >>>
> > >> Bye bye distribution level consistency :-(
> > >>
> > >> It's sad that few stubborn developers can do that.
> > >>
> > >> - Samuli
> > >>
> > > "'Ey! Have you heard about it. Gentoo doesn't provide X with support
> > > for Y, then what are their USE flags even for; what a shame, ..."
> > >
> > > If people want to support and use multiple things, let them do so.
> > > It is pretty much what Gentoo and its philosophy are about; which
> > > somewhat can be summarized as providing choices such that we fit
> > > the users' need, and not force our one true way upon them...
> > >
> > > Greetings from someone who runs GNOME 3 and MATE simultaneously;
> > > you can intentionally break it, but why would you? It takes away
> > > our happiness. On the other hand, there's the part where you want
> > > to break it for a reason, perhaps for your happiness; but then I'd
> > > like to hear why.
> > >
> >
> > So, no more setting USE="gtk" and assuming the best packaged software
> > will be get installed, be it with what version of the toolkit, 1, 2
> > or 3
>
> What is "best"? What you would deem best, could be worst for the user.
>
> > Instead, now you have to selectively do the maintainers job for
> > figuring out which one is the best supported one
>
> The maintainer can use IUSE flag defaults for this; but, there are
> users that want to control which toolkit is installed. Going further,
> they want to decide which toolkit the software is built with.
>
> > Despite already picking up a modern theme with both GTK+ 2.x and GTK+
> > 3.x looks, now you might end up with half-crippled software just
> > because some stubborn people choose the looks, not the functionality,
> > to be their motivation
>
> You need to mask that as a packager.
>
> > Such people really don't deserve to own a packager status if they
> > can't take the time to determine / examine the package's best
> > supported graphical toolkit
>
> What is "best"? If upstream provides both and claims they both are
> well supported, I consider both are.
>
> > If multiple ones with similar feature set is supported, then the
> > latest toolkit is preferred
>
> What is "preferred"? What you prefer can be different than the user.
>
> > But seems like I'm repeating common sense which the GNOME guideline
> > layed out long ago
>
> The GNOME guideline fits just the GNOME team and developers whom follow
> that; however, in the bigger picture, there are maintainers that do not
> follow that and do something different. Looking at the tracker [1]; it
> appears that it is more common for such a bug to be marked as INVALID
> or WONTFIX, than it is to be marked as FIXED.
>
> As a result of this, the users get an inconsistent USE flag presented.
>
> The "common sense" is just another wording of "opinion" here; if it
> wants to be real "common sense" shared amongst alm

Re: [gentoo-dev] Gentoo Hangouts

[Raymond Jennings]

Not to mention how do you actually log a hangout for the record instead of
already having logs from an irc session or mailing list.


On Thu, Jul 4, 2013 at 2:10 AM, Peter Stuge  wrote:

> Diego Elio Pettenò wrote:
> > just opening a webcam and talking is just going to give an amateurish
> feeling
>
> ..as opposed to the very professional mailing list.
>
>
> //Peter
>
>

Re: [gentoo-dev] bash-3.1 stable

[Raymond Jennings]

You know guys, I just joined this list so I could get an inside look at how
gentoo development is supposed to work, and hopefully find a few role
models so I know what to do to get the ball rolling on becoming a developer
myself.

I never expected to walk into this sort of tit for tat mud slinging fest.

Carry on or whatever but sheesh...


On Tue, Apr 2, 2013 at 7:26 AM, Markos Chandras  wrote:

> On 2 April 2013 15:21, Alexis Ballier  wrote:
> >
> > Did you even check if my first reply to this thread was not complete
> > BS ? I didn't.
> >
> > Alexis.
> >
>
> Apologies. My reply was below yours because it was the last one in the
> thread. It was not referred to you but to the endless
> "oh lets keep it, oh lets remove it" discussion that it is about happen
> soon ;)
>
> --
> Regards,
> Markos Chandras - Gentoo Linux Developer
> http://dev.gentoo.org/~hwoarang
>
>

[gentoo-dev] Hi

[Raymond Jennings]

Hey devs, and hopefully fellow devs before long.

Just joined this list as suggested on irc and I'm going to be lurking for
awhile to see what you guys actually do every day.

Carry on.