Re: [gentoo-dev] How to stabilize packages with frequent release cycles?

2020-09-19 Thread Rich Freeman
On Wed, Sep 16, 2020 at 4:08 PM Jonas Stein  wrote:
>
> Hi,
>
> > When the latest release remains 'latest ~arch' for less than 3 days,
> > stabilizing it after 30 days makes little sense.  After all, people with
> > frequent upgrade cycle will test it for no more than that, and people
> > with infrequent upgrade cycle may miss the version entirely.
>
> > Do you have any suggestions how we could improve this?
>
> At first we need a strict definition of "stable" and "testing", then we
> can discuss how to stabilize.
>

Not sure it is a definition issue so much that the concept doesn't fit
with these sorts of packages.  Normally the idea of stable is that
you're willing to trade speed for quality.

The problem is that in these sorts of packages you're often getting
neither.  For example, you're not going to have a more-bug-free
experience with youtube-dl if you run a two month old version, because
the APIs are all changing and you're just losing the cat and mouse
game.

IMO these sorts of packages probably shouldn't have stable versions at
all.  Then users will accept ~arch, and both know what they're getting
into, and also not get stuck with old versions that give them
suboptimal results.

Now, if somebody can come up with a better interface for that which is
cleaner than having to stick foo/bar in accept_keywords that would be
nice.  But that almost suggests another class of keyword entirely.
These packages aren't really "stable" - so much as stable not being an
option.

-- 
Rich



Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Rich Freeman
On Wed, Sep 16, 2020 at 11:44 AM Alec Warner  wrote:
>
>  - repomirror-ci and all the CI stuff is on infra because mgorny is also on 
> infra! It's not like we set his stuff up for him; instead we gave him access 
> to all the infra repos and he had to write his own puppet configs and 
> whatnot. The benefit of course is that anyone on infra can bump the stuff and 
> login to the machines and debug...but its not exactly a low bar.
> ..
> I think traditionally it's been a slog for non-infra people to get infra to 
> host much of anything and due to difficulties with the all-or-nothing 
> approach we take with infra credenteials; can really set a high bar to host 
> much of anything these days.

Seems like a way to improve this would be better documentation and a
DIY infra testing platform.

First, document how to prepare a service for infra hosting.  Maybe
provide an example service.

Second, publish a tarball of a container/chroot that basically
simulates an infra host for testing purposes.  Provide instructions on
how to configure/run it.  Make it easy - edit this config file to
point to your repo, put the name of your service/host here, etc.

Anybody developing a service could then just follow the instructions
and then test out their service in a similar environment to what infra
uses.  Nobody needs to be trusted with any credentials.  Nobody needs
access to any special repos.  They can run the container on their own
host, and point it at their favorite git repo hosting service.

Once it is working all they need to do is give the link to their
repo/etc to infra.  Infra can then fork it and host it.  The
maintainer can submit pull requests as needed to infra.

-- 
Rich



Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-16 Thread Rich Freeman
On Wed, Sep 16, 2020 at 4:17 AM Kent Fredric  wrote:
>
> On Mon, 14 Sep 2020 10:15:31 -0400
> Rich Freeman  wrote:
>
> > It might be easier to take smaller steps, such as having a policy that
> > "any call for devs to use/test a new tool/service, or any service that
> > automatically performs transactions on bugzilla, must be FOSS, and the
> > link to the source must be included in the initial communication, and
> > it must be clear what version of the code is operating at any time."
> > That is a pretty low barrier to those creating tools, though it
> > doesn't address the infra concern.  However, it does mean that infra
> > is now free to fork the service at any time, and reduces the bus
> > factor greatly.
>
> For the situation of things that take life before being part of infra,
> I think the least we can do is recognize their utility and importance,
> and at least, have infra *offer* some sort of shared location to run a
> deployment.
>
> That I think helps everyone, gives people a place to remove their own
> bus factor, but without mandatory strongarming.

This might be one option.  Another might be to try to have a more
"open infra" approach where core services like authentication are
provided by Gentoo, but available to 3rd parties.  This could allow
more services to be externally hosted, ideally with redundancy (not
just at the host level, but at the maintainer/software level as well).
The obvious downside to this would be chaos - we might have 3 list
servers, 5 bug trackers, 10 git repos, and so on.  However, if
anything did go down we'd have half a dozen potential replacements so
all anybody needs to do is migrate their own stuff to their chosen
copy.

The value add of Gentoo would be in central services like
identity/reputation and curation.  There might be 14 git repos out
there but Gentoo would control which ones end up on the master rsync
server and which rsync mirrors get advertised as being genuine, and
which list servers are official.

I realize this is a bit more tangential.  I just think that infra is
already a huge failure point, so having more stuff on infra actually
makes that failure point more critical.  A Gentoo where little is
hosted on stuff we own is much more resilient in the face of
legal/money/etc issues.  If Gentoo just becomes some blessed config
files, a website, and SAML then anybody could host the core from their
basement.

Maybe it is a good thing that core services aren't always hosted by infra?

-- 
Rich



Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-14 Thread Rich Freeman
On Sun, Sep 13, 2020 at 11:52 PM Kent Fredric  wrote:
>
> But when you file a bug, you rely on bugzilla being maintained by
> Gentoo Infra, not some 3rd party.
>

I think the Council will need to consider where it wants to draw the
lines on something like this.  Here is my sense of how these sorts of
things come about:

1.  Somebody sees an opportunity for improvement and writes some code.
They interface it on their own with git/bugzilla/whatever and host it
on their own systems.  They use it for a while and improve it.

2.  They start to advertise it and call for testers.  This is nothing
more than a list post at the start.  It is completely optional.  A few
people start using it and find that it is helpful.

3.  It is still optional, but since it is helpful the 10% of the devs
who do 90% of the work in the relevant area (like arch teams/etc)
adopt it, which means that 90% of the work is using the new tool,
still self-hosted by the dev.  It might or might not have any source
published.

4.  The devs who are using the tool are also the ones maintaining all
the documentation for the official workflows, and they update it to
reflect what they're actually doing.  It might still be optional.  (In
fact, as far as I can tell from reading the docs nattka is still
optional - you could still just CC arch teams and so on yourself -
heck, arch teams can stabilize things even if you don't file a bug
though this is unlikely to happen much.)

5.  At some point somebody notices that 80% of the problems come from
the 10% of the work that isn't doing things the new way, and the new
way stops being optional.

Maybe somebody closer to these tools might want to correct something
above.  However, as an observer this is how these things seem to
evolve - it is a very bazaar-like methodology.

Keep in mind that rules don't make things happen - they prevent things
from happening.  The hope behind a rule is that if you dam off
something suboptimal the enthusiasm travels down some other path and
doesn't just die off.  So, where do you build the dam above?  Do you
let steps 1-4 happen and draw the line at step 5, which might just
mean that we accept the 80% of the problems that come from it being
optional until infra hosts it?  Do we draw the line all the way up at
1 and block any use of APIs in ways that are not explicitly approved?
Do we block it at step 4, so the arch team is using nattka for 90% of
the cases, and they just trade notes via email and nobody else knows
what they're doing because the wiki reflects a process nobody actually
follows?

I realize that I'm mostly pointing out things that can go wrong.

I don't think anybody would say that it is better not having infra
maintaining critical infra.  The problem is that the infra team
probably isn't going to officially host stuff way back at step 1.  A
random dev can't write a script and ask infra to start running it and
bug them 3 times a day to do a pull from their git repo.  Infra is
probably going to wait until something closer to step 3-4 before they
get involved, which means the tool is already being used for a
substantial amount of work.  I'm not sure if we even have a defined
process for getting new tools like these onto infra, or how we do
config/change management in these cases.

The council can say "don't use non-infra-hosted services as part of
essential processes" but what does that actually mean?  Does that mean
going up to step 3, so 90% of your arch testing bugs are going through
nattka, but it just isn't documented on the wiki?  Does it mean going
up to step 2, so some portion of them are - if so how do you prevent
it from going from 10% to 90% if the new tool works better?  Does it
mean not interfering at all with 1-5 but imploring infra and the
service maintainers to figure something out?  If the service isn't
expensive to run, those maintaining the service might not see much
benefit in moving it over, and infra is of course always
manpower-constrained.

It might be easier to take smaller steps, such as having a policy that
"any call for devs to use/test a new tool/service, or any service that
automatically performs transactions on bugzilla, must be FOSS, and the
link to the source must be included in the initial communication, and
it must be clear what version of the code is operating at any time."
That is a pretty low barrier to those creating tools, though it
doesn't address the infra concern.  However, it does mean that infra
is now free to fork the service at any time, and reduces the bus
factor greatly.

-- 
Rich



Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-04 Thread Rich Freeman
On Fri, Sep 4, 2020 at 9:06 AM Michael Orlitzky  wrote:
>
> It's easy to say "well this is not an issue because it can be solved by
> ..."
>
> If it's easy, get it added to the PMS and I'll agree with you.
>

Current Gentoo policy:

"Maintainers must not assume that dynamic dependencies will be applied
by the package manager. When changing runtime dependencies the
maintainer should revision the ebuild if the changes are likely to
cause problems for end users." [1]

Certainly having a discussion about whether this could change down the
road is reasonable, but keep in mind this would require package
managers to actually be changed, which requires code.

Out of the box portage has issues with dynamic deps[2] so it isn't a
solved problem on any package manager, let alone all of them.

In the interim, devs MUST revbump in these situations.  The Council
left some room for discretion, and as a result I end up having portage
rebuild everything on changed deps because frankly I don't trust
people to get it right, since if people can't see for themselves the
reason for a rule it seems to be a reason to ignore it.

The rule is also documented in the devmanual[3].

1 - https://projects.gentoo.org/council/meeting-logs/20151011-summary.txt
2 - 
https://wiki.gentoo.org/wiki/Project:Portage/Changed_Deps#Ebuild_Revision_Bumps
3 - https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

-- 
Rich



Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-01 Thread Rich Freeman
On Tue, Sep 1, 2020 at 7:02 AM Michał Górny  wrote:
>
> QA reports provide a list [2] and a graph [3] of packages needing
> porting.

These lists would be far more useful if they actually listed the
maintainer(s) of each package.  Then devs could just grep to discover
if any of their packages need fixing.

Otherwise I fear that you're just going to run into the same issue as
last time - most devs will just wait until you take the time to do
this and file bugs.

-- 
Rich



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Rich Freeman
On Mon, Aug 10, 2020 at 9:55 PM Joshua Kinard  wrote:
>
> On 8/10/2020 11:22, William Hubbs wrote:
> > On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> >>
> >> If eudev is not broken, then why your proposed fix?
> >
> > bitrot and bus factor.
>
> Examples?

The sole maintainer of eudev is going to suddenly disappear before
getting a chance to tell anybody about the horrible security issue
they discovered earlier that day.

> You meant to say "has yet to come true".
>
> Elsewise, as long as that door remains open, then future tense is
> the correct tense.

Note that the disappearance of the sole maintainer of eudev has yet to
happen, but we absolutely need to be taking steps today because
everybody knows it will happen.  After all, it COULD happen, and so as
long as that door remains open the future tense is the correct tense.
:)

I find it amusing that everybody is still trembling in fear that
Lennart is going to take their shell scripts away from them in the
middle of the night.  But it isn't like anybody needs to touch that
cruft if they don't want to just because they're working on Gentoo, so
whatever rocks your boat.

Really though I'd just stick with "ain't broke don't fix it" as there
really is no reason to get into paranoid FUD.

-- 
Rich



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Rich Freeman
On Mon, Aug 10, 2020 at 8:16 AM Thomas Deutschmann  wrote:
>
> On 2020-08-10 14:07, Michał Górny wrote:
> > ...or a revert of a change made for change's sake.
>
> That's a bold statement for an unambiguous 7-0 decision as seen in
> https://bugs.gentoo.org/575718.

As one who voted yes, my rationale is already in the bug comments, and
I voted yes because it seemed to be the preference of most non-systemd
users on the mailing list.  I can't say whether this is still the case
but I'm guessing it is.  I don't think it is really a well-founded
preference but I don't really see a point in fighting it when people
can use whichever they prefer.

If the eudev bus factor drops from 1 to 0 and people get tired of
dealing with it, I suspect switching back will become more popular.
If that never happens that is fine too.  If people have unusual
configs not addressed by eudev, or just plain old good taste,  they
can always use udev or systemd.

If eudev were causing serious problems or holding back other projects
for some reason I'd feel differently.  Otherwise I tend to agree with
the sense that if you're going to make a change there should be a
reason.  The reason for the previous change was that a strong majority
had a strong preference.  Based on the tone of discussion I'm not sure
that has changed - there isn't as much vehemence in the discussion,
but I suspect that is mostly because most don't think this is likely
to happen so they don't bother to reply.

-- 
Rich



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Rich Freeman
On Sat, Aug 8, 2020 at 6:48 PM Roy Bamford  wrote:
>
> On 2020.08.08 23:22, Rich Freeman wrote:
> > On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford 
> > wrote:
> > >
> > > With the declared aim from upstream of making udev inseparable from
> > > systemd, its not something to be done lightly.
> > > That's the entire reason that eudev was necessary.
> > >
> > > I would want some convincing that it was not another step on the
> > road
> > > to Gentoo being assimilated by systemd.
> >
> > So, I really could care less what the default is since it won't impact
> > any of my Gentoo hosts either way, ..
>
> I don't have a dog in this fight. Being old and cynical, I have static /dev,
> so I use neither.
>
> I'm interested in what's changed since the Council decision [1] to make
> eudev the default.
>

And you'll note that this is the one line in your post I didn't quote,
because it was about the only thing that you said which made sense.  I
wasn't in any way criticizing that point, and basically asked the same
question myself.

-- 
Rich



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Rich Freeman
On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford  wrote:
>
> With the declared aim from upstream of making udev inseparable from
> systemd, its not something to be done lightly.
> That's the entire reason that eudev was necessary.
>
> I would want some convincing that it was not another step on the road
> to Gentoo being assimilated by systemd.

So, I really could care less what the default is since it won't impact
any of my Gentoo hosts either way, but this seems like a silly reason
to base the decision on.  IMO it was paranoid years ago when people
first brought it up.  Now it is even moreso considering that years
have elapsed without any grand systemd conspiracy being revealed.  If
their goal was to make it impossible to use udev on its own just to
mess with the 0.01% of Linux users who don't use systemd but do use
(e)udev, I'd think they'd have gotten around to it by now, or at least
they would still be talking about it.

William - can you actually elaborate on WHY you want to change things?
 Is there some problem with eudev?  Is it actively maintained and
generally tracking upstream udev commits (minus whatever they
intentionally don't want to accept)?

I'd be curious as to a list of the practical differences between the
two at this point.  For the longest time the only ones I was aware of
were the de-bundled build system, and the change in the default
persistent ethernet device name rule which was made in udev but not
made (by default) in eudev.  Perhaps at this point there are other
differences.

-- 
Rich



Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Rich Freeman
On Thu, Aug 6, 2020 at 4:19 PM Michał Górny  wrote:
>
> On Thu, 2020-08-06 at 23:03 +0300, Joonas Niilola wrote:
> > On 8/6/20 10:58 PM, Thomas Deutschmann wrote:
> > > Well, the purpose of this is to educate and avoid problems for
> > > headless/server users. But if so many devs seem to care about pushing
> > > maybe unrelated information and believe that avoiding that has much more
> > > value than avoid a problem like an unbootable system for just a few
> > > people (and for headless/servers this is a major problem in case you
> > > cannot trigger remote reboot)... ¯\_(ツ)_/¯
> > >
> > Yeah let's break some setups and make people change distributions instead.
> >
> > I'd support showing it. Weren't we all taught that too much
> > communication is better than no communication?
> >
>
> That's actually bullshit.  Too much noise leads to people stopping to
> read stuff, and losing important info as a result.  Compare: our mailing
> lists.

Well, we could solve that problem and the Foundation funding
challenges by switching the mailing list to a paid-superchat system.

The only thing that might bother some would be having to give me a
slot on the sponsor's page, but then again I would be paying your
salary at that point.  :)

More seriously, I think the simplest compromise is to just display the
news item to those with the relevant genkernel versions installed.
While the general principle of using UUIDs and such in boot lines is
important, this is better placed in the handbook, wiki, and so on.
The news should focus on what is actually changing, IMO.

-- 
Rich



Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Rich Freeman
On Thu, Aug 6, 2020 at 1:41 PM Mike Gilbert  wrote:
>
> On Thu, Aug 6, 2020 at 11:59 AM Thomas Deutschmann  wrote:
> >
> > On 2020-08-06 17:44, Michał Górny wrote:
> > > I'm not sure if you've noticed but there are people actively working
> > > towards removing stale news items and trying not to dump everything
> > > on once on a user freshly installing the system.  Don't you consider
> > > this a worthwhile goal?
> >
> > I don't see how this is conflicting.
> >
> > This news item can probably go away after 1-2 years.
> >
> > But for now, people who were just lucky will probably trigger this when
> > upgrading to genkernel-4.1 on their first reboot due to switched device
> > manager.
> >
> > But again: It's not a genkernel issue, so displaying that only for
> > people who have genkernel installed would miss a bunch of users.
>
> I would guess that most users do not utilize kexec at all, and this
> news item is irrelevant for them.
>
> Personally, I agree that this is not worth spamming every Gentoo user.
>

Has anything even changed with kexec?  Or is this an issue that has
been an issue for many years in kexec, that will suddenly become an
issue in genkernel?  In that case it is news from a genkernel
perspective, and something anybody with a correctly-booting system
fixed a long time ago if they're using kexec.

-- 
Rich



Re: [gentoo-dev] IPython 7.17 drops Python 3.6 support AKA upgrade reminder

2020-08-01 Thread Rich Freeman
On Sat, Aug 1, 2020 at 11:36 AM Aaron Bauman  wrote:
>
> On August 1, 2020 6:25:09 AM EDT, Lars Wendler  
> wrote:
> >
> >Honestly... seeing such replies from you or knowing that you do not
> >hesitate to hit other devs with your full QA deputy power once they
> >dare to touch python packages is not motivating in any way to even
> >consider helping you.
> >
> Lars, do you not recall the previous threads on this? The very same questions 
> were answered about tooling.

I'm sure everybody is tired of reading these threads over and over.
Simply saying that you answered these questions doesn't mean that
people will be satisfied with your answers.

> I see plenty of other devs and contributors touch Python packages with no 
> problems... Is it just you maybe?

You probably aren't being driven up the wall by these 50-reply threads
because only one dev has a problem with the approach that has been
taken in the past.

> Provide tooling? Not good enough.

Well, not if you don't advertise the tooling, and the tools don't
output maintainer info so that maintainers can quickly determine if
they're impacted.

> Provide a reasonable timeline? Not good enough.

Nobody has complained about timelines as far as I'm aware.

> Open bugs? We ignore them.

I'm not aware of ANYBODY who has complained about action being taken
after a bug was assigned to them.

Yes, some people ignore bugs.  They don't get much sympathy.  If you
file a bug and somebody ignores it for months, and then you depclean
their package, nobody is going to take their side.

The complaints you are getting are from devs who find out about a
problem with their package for the first time from a package mask,
perhaps due to a dependency/etc.

In any case, it sounds like we're now filing bugs, so hopefully we'll
see fewer problems like this the next time around.  Really, if you're
filing bugs I'd suggest leading with that as it will get you a LOT
more support than just pointing out the previous threads that nobody
seems to think were resolved but you.

-- 
Rich



Re: [gentoo-dev] IPython 7.17 drops Python 3.6 support AKA upgrade reminder

2020-08-01 Thread Rich Freeman
On Sat, Aug 1, 2020 at 7:09 AM Andreas Sturmlechner  wrote:
>
> On Samstag, 1. August 2020 12:15:18 CEST Rich Freeman wrote:
> > Just based on what is already happening, it seems like most devs don't
> > really care what versions of python are supported by their packages,
> > let alone the dependencies of their packages.

So, to start, I'll apologize as my original reply was worded a bit strongly.

I'm happy to hear that bugs were filed this time.  Obviously a lot of
fairly active devs were taken unaware by a bunch of package masks only
a few days ago, so that isn't being done consistently, but if we're
doing it going forward that is great.

>
> That's the definition of an unmaintained package to me.

I didn't say they were ignoring bugs.  I said they didn't care about
python.  It is ok not to care about python, or C, or glibc, or
whatever.  They're a means to an end for most devs.

Some devs like to focus on a tool, and some devs focus on the software
that uses those tools.  There is nothing wrong with either.  The key
is communication, which didn't happen enough (IMO) the last time
around.  Communication is what lets two people who have different
interests pool their resources.  Yes, some will ignore
well-intentioned efforts to communicate, but most won't, so it is
usually worth the effort.

> In case anyone still didn't know that list:
> https://qa-reports.gentoo.org/output/gpyutils/36-to-37.txt

So, if there are bugs filed then this list isn't all that important,
since maintainers will find out via bugs.  However, if you really want
lists like this to be directly useful to maintainers then you really
need to include maintainer names in them, because otherwise they're
very difficult to grep.  I doubt most devs know off the top of their
head the list of packages they maintain.

Somebody will no doubt link (again) repology or whatever.  Great, so
now we have two tables and we're asking humans to do a join on them.
Much better to just have the tools do this for us, and rather than
asking every dev to do it independently it makes more sense for the
first person that does it to just post the combined list.

In any case, this is moot if bugs were filed.

-- 
Rich



Re: [gentoo-dev] IPython 7.17 drops Python 3.6 support AKA upgrade reminder

2020-08-01 Thread Rich Freeman
On Sat, Aug 1, 2020 at 3:29 AM Michał Górny  wrote:
>
> I would like to take this as an opportunity to remind you to port your
> packages to Python 3.7 and 3.8.  According to our timeline [1], packages
> that are not ported by the end of the year are going to be last rited.
>  We would also like to switch to 3.8 in December.
>
> [1] 
> https://wiki.gentoo.org/wiki/Project:Python/Implementations#Implementation_support_timeline

So, has anybody given thought to publishing a list of packages that
still need to be updated, including their maintainers?

Or perhaps filing bugs?

Or is the plan to go ahead and watching nothing happen for the next
few months, then start masking hundreds of packages, and then watch
devs scramble to fix problems they didn't realize existed?

Just based on what is already happening, it seems like most devs don't
really care what versions of python are supported by their packages,
let alone the dependencies of their packages.  Expecting that to
change is just going to lead to a lot of frustration.

I don't think it is productive to just keep doing the same thing until
either the python team ragequits, or until we no longer have anything
that uses python left in the tree.

My guess is that a bit more communication will end up turning your
"enemies" into your allies, and ideally cut down on the amount of
masking/etc you have to do in the first place.  It certainly will be
less intrusive for users than having masks pop up and disappear.

-- 
Rich



Re: [gentoo-dev] Last rites: */*: More Py2 stuff

2020-07-29 Thread Rich Freeman
On Wed, Jul 29, 2020 at 4:09 AM Ulrich Mueller  wrote:
>
> > On Wed, 29 Jul 2020, Aaron Bauman wrote:
>
> > # Aaron Bauman  (2020-07-28)
> > # More Py2 only stuff. Plz see -dev ML for discussions
> > # Remove bindings, port to Py3, etc
> > # Removal in 30 days
> > [...]
> > app-office/lyx
>
> I have unmasked this one again:
>
> "All python scripts distributed with LyX should now be compatible with
> both python 2.x and python 3.x."
> https://www.lyx.org/announce/2_3_1.txt

Using package.mask in this way creates a TERRIBLE user experience.  It
causes users to look for alternatives and go through a lot of churn
expecting the package to be removed, when it turns out there is
nothing wrong and the package doesn't need to be removed.

Bugs are a much more appropriate way to handle these situations.  To
start with, they ensure the maintainer even gets notified at all.  A
package mask doesn't actually notify the maintainer at all - it
notifies anybody who has the package installed, and only when the host
it is installed on is updated.  It is possible (albeit less likely)
that the maintainer might not have it installed, and more likely that
they could have it installed in some container that they don't update
daily.

When the maintainer is able to fix the problem then users don't get
the churn of a package mask.

Obviously we're going to have packages that can't be migrated or which
aren't maintained, and these should be treecleaned as with any other
issue.

If for some reason bugs are just THAT difficult to create, why not at
least post the list on -dev-announce a few days before actually
implementing the mask?  You obviously have the list of packages if
you're masking them, and you're even posting it on the list.  So just
post it on the list ahead of time so that people can react before they
actually get masked.

It seems like we're creating a terrible user experience simply because
we can.  This seems to be going back to how things were 10+ years ago
when stuff broke for users often simply because nobody cared to even
bother with communication and QA.

-- 
Rich



Re: [gentoo-dev] Bug #733802, USE 'scp' now defaults to off in net-misc/openssh

2020-07-25 Thread Rich Freeman
On Sat, Jul 25, 2020 at 7:40 PM Joshua Kinard  wrote:
>
> This seems like something that needs a news entry, or
> at least a "heads up" on the mailing list?

Definitely not a "heads up" on the mailing list - that is not an
appropriate way to communicate anything to users - not even devs are
required to read this list.

The two appropriate ways to communicate something like this are
einfo/ewarn/etc or news.  Never hurts to use news.  Ideally I'd point
to a substitute, and I'd suggest one myself if I were aware of one...

-- 
Rich



Re: [gentoo-dev] RFC: Standard build environment variables

2020-07-01 Thread Rich Freeman
On Wed, Jul 1, 2020 at 9:36 AM Michael Orlitzky  wrote:
>
> On 2020-06-30 12:22, Matthew Thode wrote:
> >
> > I'd like to suggest allowing only approved variables in the build
> > environment, having portage unset all variables and setting only what is
> > needed (or configured).
>
> I think this is orthogonal to the problem I'm trying to solve. Even if
> all environment variables had to be whitelisted, ebuilds would still
> need to know how to use them when they happen to be defined.
>

Agree.  I'm not actually certain what that proposal was intended to
convey.  Are we talking about:

1.  Blocking anything that happens to be in the environment when
emerge is run?  (Ie 'CFLAGS="-O2" emerge -1 foo'?)
2.  Blocking any variable at all that isn't whitelisted by an ebuild
or eclass?  (ie CFLAGS in make.conf is ignored unless the ebuild
whitelists it)

I get how environment pollution can cause issues, but #1 is something
we've generally supported for a long time, and it is useful for
troubleshooting/etc or just trying out different things.  Maybe a
FEATURE flag could be used to control it to keep newbs out of trouble,
and you can just as easily pass that in the environment too.

I'm not sure that #2 adds a lot of value.  The default phase functions
probably already don't work well for exotic build systems, and
eclasses can of course take care of remapping for most of the popular
ones.  For one-offs some flag-o-matic or other eclass functions to aid
in remapping variables might be helpful in some cases if there isn't
already something there.

But in any case it isn't essential to what you're proposing.  It does
go along with it to a degree and is worth at least thinking about
(imo)...

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-26 Thread Rich Freeman
On Fri, Jun 26, 2020 at 10:36 AM Aaron Bauman  wrote:
>
> On June 26, 2020 7:13:07 AM EDT, Rich Freeman  wrote:
> >> Of all the methods listed in the previous posts, the QA reports, etc.
> >> there is no excuse individuals can't find out if their package is py2
> >> only.
> >
> >None of those methods were posted until a day or two ago, and the
> >python team has done nothing to actually ensure all the impacted
> >maintainers are aware of them.  Perhaps a communication to
> >-dev-announce with the preferred approach would be better?
> >
>
> You should also look at qa-reports. Do we really need to *teach* others "how 
> to fish" here? Why can't folks just ask for assistance?

Just looked at it:

1.  I had no idea that a list of py2-only packages was listed there.
I don't think I've ever actually looked at that page.

2.  The report does not list maintainers, which means nobody is likely
to know they have a package on the list.

>
> See above. Qa-reports will output a very nice list (even a graphic!) of such 
> things. Anyway, yes, I do expect devs to understand their packages state if 
> they maintain it. Don't be so myopic.

Well, you can expect whatever you want, and then you can be frustrated
out of your mind when 95% of devs fail to meet your expectations.

Or you could just work with them where they're at and maybe get your
project completed more quickly and with less effort...

If you want people to look at a qa-report, maybe post on -dev-announce
and ask everybody to do it?  Most people aren't going to be following
all the tools used by the python team if they aren't python devs.

> >At least some devs here seemed surprised about the masks.  Did you try
> >filing a bug?
>
> Have you looked for said bugs?

Of course.  Do you think I'd invite such an obvious reply without
actually checking.

I just went to the first complaint on this list about there not being
a bug, and verified that there wasn't a bug.

As far as I can tell there is no bug for app-misc/golly.  If I missed
one feel free to cite it.

>
> >
> >Masking something for all users is basically like torturing a kitten
> >to get the attention of its owner.  It is a necessary step if the
> >package is actually to be removed.  I don't think it is even allowable
> >under our policies if no bug was filed.
> >
>
> Do tell where said policy is?

https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html

Granted, a mask isn't a package commit, but I think the spirit of the
policy covers it.

In any case, there is no reason not to communicate with a maintainer
before touching a package.  That should involve something more than a
generic notice that everybody should become a detective to figure out
if they are covered by an upcoming change.  If you have a list of
impacted packages, then just file bugs against them.

>
> Nothing is really hard about masking packages for removal... honestly.

The complaint isn't that masks are hard on you.  The complaint is that
it bombards users with unnecessary warnings.

> The work comes in defending the position here for the few that complain.

And how are you enjoying doing all that extra work?  Would you prefer
if devs started opening up QA/Comrel bugs that you then have to
formally respond to?

Or maybe you could try notifying devs before masking their packages?

> If I filed a bug... they would complain or not respond... If I sent out a 
> dev-announce they would complain or not respond.

Sometimes, sure.  But at least you would have gone through due
process, and you're unlikely to get much push back.

And I suspect a number of those packages would actually get fixed.

>
> You see the fun here? Which method is effective? Mask a 100 packages for 
> removal... Someone complains... A few packages get saved and 90 get 
> removed... Life goes on.

Would you want a dev to just mask one of your packages if they saw a
bug in it, without bothering to open a bug?

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-26 Thread Rich Freeman
On Thu, Jun 25, 2020 at 11:07 PM Aaron Bauman  wrote:
>
> On Wed, Jun 24, 2020 at 04:21:14PM -0400, Rich Freeman wrote:
> >
> > We're removing python2 around .  You can help us out by updating
> > any packages you have that use python2.  If you want to easily
> > identify these packages just do .
> >
> > I think the problem here is that we're basically telling maintainers
> > that the beatings will continue until morale improves.  Then we're
> > wondering why nothing is getting done.
> >
>
> I am thoroughly confused here. Some how you have completely changed your
> opinion from previous posts.

Perhaps we failed to communicate then.  My opinion has always been this:

I support letting the python team manage the versions of python
available - if people want legacy versions to stick around they need
to do something to make it happen.

HOWEVER, the python team would also find its job much easier if they
partnered with the myriad of package maintainers to accomplish their
goals, instead of just throwing them over the fence and then breaking
things for users to try to get everybody's attention periodically.

>
> Of all the methods listed in the previous posts, the QA reports, etc.
> there is no excuse individuals can't find out if their package is py2
> only.

None of those methods were posted until a day or two ago, and the
python team has done nothing to actually ensure all the impacted
maintainers are aware of them.  Perhaps a communication to
-dev-announce with the preferred approach would be better?

You can't expect every Gentoo dev to independently cobble together a
bunch of scripts to go hunting for py2 reverse deps.

> Ironically, it would be a very sad state if an individual doesn't know
> what Python interpreter their package is compatible with. This is the
> essence of "maintainer" status, correct?

Maintainers generally care about what the package does, and how it
does it is a means to an end.  Sure, some care more about the build
system and dependencies than others, and when working on a package you
need to pay more attention to such things.  However, I suspect most
package maintainers do not know off the top of their head the
dependency list of all their packages.

> Obviously, the myriad of tools, ML threads, and all the other "avenues"
> individual developers have taken to alert others simply doesn't work...
> until something is p.masked... people don't budge.

At least some devs here seemed surprised about the masks.  Did you try
filing a bug?

Masking something for all users is basically like torturing a kitten
to get the attention of its owner.  It is a necessary step if the
package is actually to be removed.  I don't think it is even allowable
under our policies if no bug was filed.

But if filing bugs is painful at least make things easier on
maintainers.  Post a list of packages and owners, for example.

It just seems like you're making things harder on yourself.  Gentoo
has done countless migrations like this and for whatever reason in the
past creating a tracker and blocker bugs hasn't been a problem.

I don't think the community will be served by having the python team
work itself into a frenzy until they ragequit.  Just give in, send out
a -announce post, and maybe cut your workload in half at least.  I get
that you seem to want to stand on some kind of principle that
everybody in Gentoo should care about the py2 migration as much as you
do, but it probably isn't going to happen.  Help everybody else help
you...

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-25 Thread Rich Freeman
On Thu, Jun 25, 2020 at 2:45 PM John Helmert III  wrote:
>
> On Thu, Jun 25, 2020 at 07:32:04AM -0400, Michael Orlitzky wrote:
> > On 2020-06-24 16:08, Michał Górny wrote:
> > >
> > > $ git grep -l mgo...@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 |
> > > xargs gpy-py2 2>/dev/null
> > find -L "${REPO}" \
> maint=$(pquery ${pkg} --one-attr maintainers | tail -1)

Great, so now we have 4 ways (and counting) to get 4 answers to this
question that hopefully will be mostly the same.

My point is more that it makes more sense for one person to just file
the bugs or send out the list so that maintainers can go fix their
packages, as opposed to playing a game where every developer in Gentoo
independently engineers a solution to the same problem.  If some
maintainers decide not to play the game, or play it and make a
mistake, then it ends up being the python team or the users who lose.

If a maintainer ignores a blocker bug for too long nobody is going to
shed a tear over some treecleaning.  Spending a bit more time on
communication might save a lot more time in cleanup.

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-24 Thread Rich Freeman
On Wed, Jun 24, 2020 at 4:08 PM Michał Górny  wrote:
>
> $ git grep -l mgo...@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 |
> xargs gpy-py2 2>/dev/null
>

I have no idea what gpy-py2 is, but I'll take your word for it.

In any case, the solution in this case is to send a nice email to
-dev-announce saying:

We're removing python2 around .  You can help us out by updating
any packages you have that use python2.  If you want to easily
identify these packages just do .

I think the problem here is that we're basically telling maintainers
that the beatings will continue until morale improves.  Then we're
wondering why nothing is getting done.

I'm not saying anybody has to do it a particular way - it just seems
obvious that the way we're doing it is more successful at getting
people upset than actually getting results.

Ideally you would just open a tracker bug and then per-package bugs
for every impacted package.  That would be the cleanest solution.  If
that is too painful then by all means do some email announcements, but
make it easy for devs to realize when they're missing something.

Having a package mask be the first time a maintainer finds out that
they have a problem isn't good.  Now, you can blame that on the
maintainer, or you can blame that on the python team, but either way
the users end up getting exposed to breakage unnecessarily.

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-24 Thread Rich Freeman
On Wed, Jun 24, 2020 at 3:04 PM Andreas Sturmlechner  wrote:
>
> > On Wed, Jun 24, 2020 at 11:29 AM Rich Freeman  wrote:
> > > Sure, you can use the portage API to find this info.  However, that is
> > > as easy to do for a list of all impacted packages in the tree with
> > > their maintainers as for any individual maintainer to obtain this info
> > > for their own packages.
>
> I'm appealing to a more proactive maintenance, not in search for excuses why
> it is not like that. And ftr I don't mean trying to be "first!" on every
> upstream version bump; it is just that the python topic has come up often
> enough that it should have sparked individual head scratching at one point or
> another.
>
> > On Wednesday, 24 June 2020 20:40:58 CEST Alec Warner wrote:
> > You say there is not a straightforward way, but then you say there is an
> > api? :p
>
> grep all the things! But hey, there's even external tools to help you get an
> overview:
>
> https://repology.org/maintainer/rich0%40gentoo.org
>
> You're welcome.

I'm well aware of that.  That will get you a list of what you
maintain, but not which of those things use python2.  It is also
completely external.  (I do love that tool though - great for finding
bumps.)

grep is really not a reliable tool for parsing ebuilds.  The API is
really the right way to do it.

What I was getting at though is that just posting a big list up-front
will probably get more results than just telling everybody to try to
figure out if they're impacted.

(Also, I noticed that the list I sent out earlier contained some
overlay-only packages - probably best to re-run it on a clean
repository.  Since it uses the API it sees everything portage sees,
including overlays.)

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-24 Thread Rich Freeman
On Wed, Jun 24, 2020 at 2:40 PM Alec Warner  wrote:
>
> On Wed, Jun 24, 2020 at 11:29 AM Rich Freeman  wrote:
>>
>> Sure, you can use the portage API to find this info.  However, that is
>> as easy to do for a list of all impacted packages in the tree with
>> their maintainers as for any individual maintainer to obtain this info
>> for their own packages.
>
>
> You say there is not a straightforward way, but then you say there is an api? 
> :p
>

Yeah - the number of people around here who have used it is pretty
small.  My point though is that if you've done that work it is easiest
to just do it once for everybody.

> Extend the existing QA report?
>
> https://qa-reports.gentoo.org/output/gpyutils/py2.txt
>
> There is a list of py2 only packages. We just need to add the maintainer 
> metadata?

Exactly.

I decided to get off my rear end and try to contribute a bit.  See the
attachments.  Script adapted from my ancient (ironically v2-only)
script to find missing slot op deps.  Contents are meant to inform,
and not to shame (mostly)...

-- 
Rich
app-accessibility/SphinxTrain-1.0.8 - +python_single_target_python2_7 - 
accessibil...@gentoo.org, so...@gentoo.org
app-accessibility/sphinx3-0.8-r1 - python_targets_python2_7 - 
accessibil...@gentoo.org
app-accessibility/sphinxbase-0.8 - python_targets_python2_7 - 
accessibil...@gentoo.org
app-admin/conkyforecast-2.24-r1 - +python_single_target_python2_7 - 
app-admin/denyhosts-2.9 - python_targets_python2_7 - proxy-ma...@gentoo.org
app-admin/denyhosts-3.0 - python_targets_python2_7 - proxy-ma...@gentoo.org
app-admin/syslog-summary-1.14-r1 - +python_single_target_python2_7 - 
lmip...@gmail.com, proxy-ma...@gentoo.org
app-admin/syslog-summary-1.14-r2 - +python_single_target_python2_7 - 
lmip...@gmail.com, proxy-ma...@gentoo.org
app-admin/syslog-summary-1.14-r3 - +python_single_target_python2_7 - 
lmip...@gmail.com, proxy-ma...@gentoo.org
app-antivirus/clamtk-6.03 - +python_single_target_python2_7 - 
conik...@gentoo.org
app-arch/cfv-1.18.3-r1 - +python_single_target_python2_7 - 
app-arch/deltarpm-3.6 - +python_single_target_python2_7 - 
app-arch/ipkg-utils-1.7.050831-r3 - python_targets_python2_7 - 
jnr...@gmail.com, proxy-ma...@gentoo.org
app-backup/bareos-17.2.9 - +python_single_target_python2_7 - msch...@gentoo.org
app-backup/bareos-18.2.8 - +python_single_target_python2_7 - msch...@gentoo.org
app-backup/genbackupdata-1.9 - python_targets_python2_7 - robb...@gentoo.org
app-backup/holland-1.0.10 - python_targets_python2_7 - 
app-backup/holland-backup-example-1.0.10 - python_targets_python2_7 - 
app-backup/holland-backup-pgdump-1.0.10 - python_targets_python2_7 - 
app-backup/holland-backup-random-1.0.10 - python_targets_python2_7 - 
app-backup/holland-backup-sqlite-1.0.10 - python_targets_python2_7 - 
app-backup/holland-lib-common-1.0.10 - python_targets_python2_7 - 
app-backup/holland-lib-lvm-1.0.10 - python_targets_python2_7 - 
app-cdr/burn-cd-1.8.0-r1 - +python_single_target_python2_7 - 
canutethegr...@gmail.com, proxy-ma...@gentoo.org
app-cdr/burn-cd-1.8.1 - python_targets_python2_7 - canutethegr...@gmail.com, 
proxy-ma...@gentoo.org
app-cdr/cdcover-0.7.4-r1 - +python_single_target_python2_7 - 
app-crypt/openssl-blacklist-0.5.3 - +python_single_target_python2_7 - 
ha...@gentoo.org
app-crypt/openvpn-blacklist-0.4-r1 - +python_single_target_python2_7 - 
ha...@gentoo.org
app-crypt/openvpn-blacklist-0.5 - +python_single_target_python2_7 - 
ha...@gentoo.org
app-crypt/pius-2.2.4 - python_targets_python2_7 - nickaristocra...@gmail.com, 
proxy-ma...@gentoo.org
app-crypt/ssh-multiadd-1.3.2-r1 - +python_single_target_python2_7 - 
k...@gentoo.org
app-crypt/virtualsmartcard-0.7 - +python_single_target_python2_7 - 
mgo...@gentoo.org
app-dicts/opendict-0.6.7-r1 - +python_single_target_python2_7 - 
wxwidg...@gentoo.org
app-editors/bluefish-2.2.10 - +python_single_target_python2_7 - 
app-editors/editra-0.7.20-r2 - python_targets_python2_7 - wxwidg...@gentoo.org
app-editors/leo-5.6 - python_targets_python2_7 - 
app-editors/pluma-1.22.2 - +python_single_target_python2_7 - m...@gentoo.org
app-emacs/pymacs-0.26-r1 - python_targets_python2_7 - gnu-em...@gentoo.org, 
pyt...@gentoo.org
app-emulation/crossover-bin-12.5.0-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-12.5.1-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-13.0.0-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-13.0.1-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-13.1.0-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-13.1.2-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-13.1.3-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emulation/crossover-bin-13.2.0-r2 - +python_single_target_python2_7 - 
r...@gentoo.org
app-emu

Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-24 Thread Rich Freeman
On Wed, Jun 24, 2020 at 2:18 PM Andreas Sturmlechner  wrote:
>
> The lack of curiosity for one's own packages' python compatibility is not just
> a py27 isolated issue, it was a big problem with py36 -> py37 with so many
> devs simply not filing that necessary stabilisation.

That suggests that if you keep doing what you're doing, you're going
to keep hitting your head against the wall.

Right now in Gentoo there isn't really even a straightforward way for
a maintainer to cleanly obtain a list of all the packages they
maintain, let alone whether they use python v2.

Sure, you can use the portage API to find this info.  However, that is
as easy to do for a list of all impacted packages in the tree with
their maintainers as for any individual maintainer to obtain this info
for their own packages.

I think that if you give the maintainers a bit more info, you'll find
them being more proactive about helping you out.  Basically you would
be helping them help you.

Otherwise you're going to mask a bunch of packages and run into a
bunch of upset devs, and as a byproduct we create a bunch of upset
users.

There is no reason to mask a package only to unmask it a few days
later.  Masks are a mechanism for deprecating packages so that users
take action.  They're not a substitute for devs talking to each other.

-- 
Rich



Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-24 Thread Rich Freeman
On Sat, Jun 20, 2020 at 1:36 PM Aaron Bauman  wrote:
>
> On Sat, Jun 20, 2020 at 10:32:28AM +0200, Ulrich Mueller wrote:
> > > On Sat, 20 Jun 2020, Aaron Bauman wrote:
> >
> > >> # Aaron Bauman  (2020-06-20)
> > >> # Py2 only
> > >> # Removal in 14 days
> >
> > I see these short deadlines quite often recently. Any reason why this
> > can't be the usual 30 days?
> >
>
> Hi, Ulrich. Yes, the deadlines are meant to speed up the process as we
> have *roughly* 1000+ pkgs which must be converted to py3 or removed
> before we can drop the interpreter.
>

Wouldn't it make more sense to just file bugs on ALL the impacted
packages, wait a few weeks, and then makes ALL of them at once, with
the regular 30d deadline?

Or if filing bugs is administratively difficult then just post a list
with packages and maintainers on -dev - this has been done for changes
in the past.

Right now it seems like some maintainers are finding out that their
packages are impacted for the first time by having their packages
masked.  That means that end-users get a package mask notice and start
taking action.  Then a few days later the package is unmasked.  Of
course, by then half the users have probably started migrating to
other packages - perhaps ones that are less suitable for them.

You seem to think that maintainers should know if they're maintaining
a v2-only package.  I suspect that most maintainers don't pay that
close attention to what versions of python are supported by their
various packages, and neither do most users.  If it runs then it runs,
and most don't care which interpreter is being used.  I get that it
impacts the python team but we need to make these issues more visible
to maintainers.

Maintainers often have an assortment of packages, and probably don't
realize when any particular one has a particular python compatibility
issue.

If it is difficult for you to identify all the impacted packages, why
would it be any easier for a maintainer who has probably spent less
time than you hunting down v2-only packages?

It seems like we really need a better solution here.  And just masking
a package without filing any bug beforehand doesn't really seem
in-line with policy.  We don't even do that for serious security
vulnerabilities.

-- 
Rich



Re: [gentoo-dev] Re: [gentoo-dev-announce] */*: Mask Py2 only packages

2020-06-20 Thread Rich Freeman
On Sat, Jun 20, 2020 at 4:36 AM Sergei Trofimovich  wrote:
>
> On Sat, 20 Jun 2020 00:43:03 -0400
> Aaron Bauman  wrote:
>
> > # Aaron Bauman  (2020-06-20)
> > # Py2 only
> > # Removal in 14 days
> ...
> > app-misc/golly
>
> If you decided to delete a maintained package you should file a bug against
> the maintainer. Otherwise they won't see the effect until mask hits the users.

So, I get that the python mess has been a ton of work for those
involved, and mostly thankless work.  You get complaints from people
who are interested in a particular package, but not with maintaining
the vast number of packages in an old python implementation that
probably isn't as interesting to people interested in python for the
sake of python.  As such I don't really question the removal of v2
from the tree.  I also don't question the phased approach of
progressively fixing, removing packages, etc.  This sort of thing
should be done at the convenience of the python team, who do a ton of
work behind the scenes that keeps the whole distro working.

I would suggest that process-wise there are some things that could be
done to make this sort of thing smoother in the future (and please
understand that this is intended as a lessons-learned and not so much
as criticism):

1.  Just follow the standard policies like ulm suggested and pick 30
days.  You're already doing something that is going to get complaints.
Waiting two weeks at this point won't make much difference.  Of course
exceptions can be made for pressing security issues/etc, and if these
exist just mention them up-front to deflect criticism.

2.  Help maintainers help you.  Ideally that means opening a ton of
bugs on day 1 of this whole mess against all the impacted packages.  I
get that this isn't easy.  An alternative might be to post lists of
impacted packages on -dev periodically, and when you do this stick the
maintainers on the list.  A lot of maintainers maintain a lot of
packages, and they probably won't notice if a package they maintain is
on the list, but if you stick their name on the list they can just
grep it.  I bet a lot of maintainers would pitch in if they just
realized they needed to.  I've seen lots of bugs that say "fix this,
oh and fix anything else you might happen to have with the same
problem."  The problem with this is that the people cleaning up python
probably have scripts to go detecting impacted packages, but everybody
else in the distro doesn't, and it doesn't make sense to have 100 devs
all trying to figure out if they have a package with a particular
issue, especially if the package has a quiet upstream that doesn't do
a lot of bumps.

I get that this won't fix the entire problem.  You'll get that
stubborn dev that just refuses to fix a bug.  When that happens don't
waste your time fighting WW3 - just point out that packages depending
on v2 will get masked on $DATE and move on, and ideally get the
Council to bless your decision.  If the Council doesn't bless the
decision or a compromise you can live with then just remove v2 from
the python project and make it maintainer-needed, and thus somebody
else's problem.  Don't put the weight of the world on your shoulders -
when it comes to actual work focus on the stuff that is directly
python and make the rest of us do the rest, but you need to spend a
bit of time around engagement.  A bit of up-front bug-filing or list
posts might save you a ton of harassing later.

The rest of us do need to appreciate that this is fairly thankless
work.  Maybe python v2 COULD be supported longer. But are YOU stepping
up to do that?  The existing members of the python team aren't
obligated to keep v2 in the tree.  Indeed, they aren't obligated to
maintain python at all.  Of course if some are willing to do the work
to keep v2 around then we should find a way to allow them to do so,
but I don't really see that happening.

Now I'm sure I didn't appreciate some things that happened behind the
scenes.  Accept what makes sense and reject that which does not.  And
by all means feel free to share lessons-learned that others might
benefit from.  I don't want to turn this into a criticism thread/etc,
so I'd encourage others to refrain from doing so...

-- 
Rich



Re: [gentoo-dev] [RFC] Codec project

2020-06-12 Thread Rich Freeman
On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier  wrote:
>
> What about /j #gentoo-media, discuss, join the current projects, get a
> few things done (there is a lot of choice there ;) ), maybe orphan
> unmaintained players/viewers, or check if they are maintained and hand
> them to a specific maintainer, and then see about merging or splitting
> all those projects *after* gaining experience and knowledge about the
> peculiarities of some of those packages ?
>

Probably best to leave the details up to those doing the work, but I
would suggest this as a guideline:

Keep the scope reasonable.  If you expand the scope to a point where
90% of the project members don't care about 50% of the project scope,
then you're setting yourself up for a repeat of the past.  You want
80% of the project members to be interested in 80% of the packages
being maintained ideally.  Sure, there will be little niches that a
subset are more interested in, but you want to keep it focused around
a core where coordination makes sense.  You can have different roles
in the project but it should still be one project.

If most of the project members aren't talking to each other about most
of the things they're doing in the project, then it isn't really a
project - it is just a category tag.  The point of a project is to
coordinate things that actually NEED to be coordinated or at least
benefit from it in some way.

-- 
Rich



Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Rich Freeman
On Sun, Jun 7, 2020 at 7:22 PM Philip Webb  wrote:
>
> 200607 Pacho Ramos wrote:
> > I think this is the list of completely unmaintained packages now,
> > indeed most of them, around 100.
>
> -- extract from list --
>
> > media-gfx/imagemagick : 200516
> > media-libs/giflib : 200312
> > media-libs/libjpeg-turbo : 200328
> > media-libs/openjpeg : 200328
> > virtual/jpeg : 200606
>
> There have been upgrades of all these in recent months :
> dates when I upgraded on my desktop system are added (the last yesterday).
> Surely, that means someone is maintaining them.
> Perhaps the culprits could own up (smile).
>
> As a long-time user, I find it disturbing
> that a huge list of packages should suddenly be declared unmaintained,
> esp as some of them -- eg above -- are likely needed by most users.

They were not maintained by identified developers before - that is the
point.  The only thing that is changing is that metadata is being
updated to reflect reality.  Now these packages will get more notice
and developers can set up and maintain them as needed.

The packages aren't being removed - just the project.

If any of the packages assigned to the graphics projects already had
individual maintainers then those would still remain after the project
is removed.

Put it this way - suppose we created a project called "dummy" with no
developers in it, and we assigned that project to all the packages
that are maintaner-needed.  Would that actually change anything?  XML
tags in metadata files don't maintain packages - people do.

This sort of thing has happened many times in the past.  Sometimes it
does result in packages getting treecleaned, but mainly when they have
other serious issues.  Popular packages aren't likely to get removed
this way - certainly not something like libjpeg or imagemagick and so
on.

-- 
Rich



Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Rich Freeman
On Sun, Jun 7, 2020 at 2:14 PM Jonas Stein  wrote:
>
> On 07/06/2020 03.43, Aaron Bauman wrote:
> > On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote:
>
> > I will happily revert my change on the graphics project Wiki [..]
>
> Glad to read your offer. Yes, please do so.
>
> I think it would hurt the Gentoo project if single developers delete
> projects
>
> - without without informing the project members
> - without prior discussion (on gentoo-dev for example),
> - without vote/consent
> - without an organized shutdown (reassign bugs, archive things...).
>
> However we should continue to find a general solution for the problems
> discussed in this thread and find a general consent.

While I get what you're saying, I think it would also be helpful if we
just let people who feel they are actually impacted by changes like
this speak up for themselves, instead of assuming that they must exist
and that it is our duty to speak up for them.

Are you, directly, impacted in any negative way by this change?  If so
it would probably be helpful if you just explained the issue.

This really seems like a fairly uneventful change.  I do think it is
better to pre-announce changes.  However, I suspect that most of the
fuss is because a lot of people assume that a change like this must
have some kind of big impact, and for whatever reason all the people
who are being harmed by it are just afraid to speak up so we must do
so on their behalf.

I say this as somebody who used to raise a lot more hypothetical
objections to changes in the past.  I've since learned that it is easy
to over-react, and that when others are actually impacted by a change
they will tend to speak up.

I'm pretty sure in this case there was an organized shutdown - I doubt
they just removed the project without reassigning packages or bugs.
They were effectively already assigned to nobody as it was, since the
project was inactive.

I guess my point is that while this probably could be done in a better
way, I think it is likely to end up happening either way, so all
undoing it is going to do is send a lot of people two more rounds of
bugspam at best.  Or, it will result in one more round of bugspam and
then these packages continue to be unmaintained because nobody is
going to bother doing all the steps you're suggesting to get rid of it
in the future.  Easier to just leave the dead project around and let
users wonder why nobody pays attention to the bugs they open.

-- 
Rich



Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Rich Freeman
On Sat, Jun 6, 2020 at 7:49 PM Jonas Stein  wrote:
>
> our concept of "Projects" (Herds in the past) maintaining packages has
> several problems.

You might want to search the list archives as many of the issues
you've raised have been discussed extensively.  There was never a
complete push to fix things, but most project removals/etc have been
along the lines of what has been discussed.

While tangential, I'll point out that there have been similar
discussions around appropriate uses of eclasses and there are some
loose parallels for when eclasses make sense.

> * Many projects are too heterogeneous
>   Projects should only maintain either
>   a) many similar packages such as libraries (like Perl, Python) or
>   b) very few strong correlated packages (like KDE, Kernel, Xfce)
>
>   It makes no sense to group packages by usage as in
>   Science, Games, Theology, Sound, Netmon, Video, Electronics...

...graphics...

This is the gist of the outcome of previous discussions.  Projects
make sense when developers actually work TOGETHER to maintain things.
Nobody who works on qt is going to just upgrade one component of qt
without talking to the other maintainers.  It makes sense for those
packages to be managed by a project.

Historically a lot of projects worked more like "tags" as an
alternative way of grouping packages other than categories.  While
tags are a great idea projects are a terrible way to implement them.

> I think we should first find a consent about the following questions
> before someone deletes projects.

In general I'm a fan of announcing things like this BEFORE doing them.
However, I don't think they need pre-approval when they make sense.
If anything we haven't been doing it often enough.

I don't see any point in bringing back graphics though - if somebody
who actually intends to lead such a project wants to speak up on that
they should certainly do so, but it sounds like it is just a vestige
of an old herd that probably never worked as an actual team.

People reading the thread shouldn't think that this has anything to do
with the importance of the individual packages.  This is purely about
how devs are organized around them.

Some of what you wrote was more about our larger meta-structure and
how devs maintain packages in general.  That has also been discussed
quite a bit, like having a core group of devs who don't maintain any
individual packages and all they do is QA pull requests from a much
larger pool of individuals who do care about packages.  There are a
lot of pros and cons to that and I won't rehash the previous
discussions here.  That isn't to discourage anybody from doing so - I
mainly just want to point out that this stuff is in the archives.

-- 
Rich



Re: [gentoo-dev] Gentoo Council Election 2020 - Call For Election Officials

2020-05-30 Thread Rich Freeman
On Sat, May 30, 2020 at 6:09 AM Roy Bamford  wrote:
>
> We sill need more volunteers.
>

Not going to be running, so I'm happy to pitch in.

-- 
Rich



Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-26 Thread Rich Freeman
On Tue, May 26, 2020 at 4:12 AM Haelwenn (lanodan) Monnier
 wrote:
>
> [2020-05-25 23:41:23+0200] Piotr Karbowski:
> > There are 3 common ways the xorg-server is started:
> >
> > - via XDM of some sort, usually forked as root, does not require suid,
> > systemd or elogind.
>
> Launching X as root and having it be suid is quite the same thing…
>

Sort-of.  An SUID X binary is a potential source of vulnerabilities
even if you never run it, since it is still sitting there and ready to
be exploited by somebody else.  It also gives a user more control over
how X is launched as root (command lines/control over stdin/out, etc).
When X is launched as root by something the user doesn't control it
reduces the attack surface somewhat.  And if you never launch X11 at
all it is just another unprivileged binary that can't do anything the
user can't already do with system calls.

In any case, setting suid on any binary is something that should only
be done if there is no other practical solution.  It certainly seems
like this shouldn't be the default, especially if it is available for
users to toggle if they wish.  We can always put out a news item when
this changes.  If elogind is already enabled by default on a profile,
then it doesn't make sense to ship X11 suid with that same profile
when it isn't necessary.  If a user wants to depart from the default
config to not use elogind then they can just change the USE flag on
xorg as well.

-- 
Rich



Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Rich Freeman
On Mon, Apr 20, 2020 at 2:07 PM Michael Orlitzky  wrote:
>
> On 4/20/20 1:31 PM, Patrick McLean wrote:
> >> Simply having things in ::gentoo does not affect anyone who does not
> use them.
> >
>
> You keep saying that, but the fact that dev-go/* is filled with trash
> that has your name on it prevents anyone else from doing a better job.
>

As far as I'm aware Gentoo policy does not prevent somebody from
re-implementing a package that is already in Gentoo.  Obviously it
could get pretty confusing if that happened.

IMO it isn't really worth worrying about, because right now the main
limitation seems to be a lack of people working on projects, not 25
devs who each want to re-implement go their own way...

-- 
Rich



Re: [gentoo-dev] keywording workflow

2020-04-13 Thread Rich Freeman
On Mon, Apr 13, 2020 at 4:12 AM Michał Górny  wrote:
>
> An example workflow is to:
>

Just picking this to reply to though this is more of a general comment
on the two recent keywords threads.

I get that this is Gentoo and we don't want to dictate how people do
things.  However, I feel like this is an area where we'd actually
benefit from more direction.

It seems like we're trying to support more different workflows for
doing keywording/etc than we even have developers doing keywording in
the first place.  It seems like we probably have 5 people at any time
doing actual arch testing but we're maintaining a lot of legacy
code/etc to support 487 ways of going about arch testing because we
don't want to upset somebody who probably doesn't actually do any arch
testing.  At the same time, we have no idea how the 5 people doing the
actual work are actually doing their work, so we can't reliably ensure
that their workflows don't break other than by making sure that we
don't accidentally break any legacy behavior in any way.

What I don't want to do is start a conversation where 27 devs
(including myself) try to tell the people doing a lot of keywording
work how to do their work.  What I would love to see is the people who
actually do keywording share how they actually go about it in
practice, and then maybe try to document some kind of best practice
around this and put it in the devmanual or in a GLEP or something.
Then we can give that workflow more of a first-class support in our
tooling and maybe worry less about others.

I know I was completely taken by surprise by the idea that most
keywording is done using tools these days, and that STABLEREQ isn't
supposed to be a thing now.  Not that these are bad things, but it
seems to have been organic and not really formally transitioned.  The
devmanual no longer mentions the bugzilla keywords, but it also
doesn't mention the bugzilla components and I didn't realize that you
couldn't just turn an existing bug into a stable request just by
adding STABLEREQ and copying arches.  Obviously now I know but my
point is more that it seems like this whole area would benefit from
some kind of suggested workflow.

Heck, this thread is also the first time I think I've seen "pkgcheck
scan --commit" mentioned as a thing.  I see that it was blogged about
a few months ago, but I've stopped following planet Gentoo since
Google reader died.  Maybe we need a planet Gentoo mailing list or
something.

I guess my point is that there seem to be a lot of improved workflows
out there, and we'd probably benefit from them being pointed out a bit
more and mainstreamed.  Those maintaining these tools would probably
benefit as well if more people were using them as intended and they
didn't have to maintain as much legacy compatibility simply because
many don't realize there is a better way...

-- 
Rich



Re: [gentoo-dev] zoom concerns

2020-04-01 Thread Rich Freeman
On Wed, Apr 1, 2020 at 8:18 PM Alessandro Barbieri
 wrote:
>
> I have concerns about the inclusion of zoom in ::gentoo. For me it's more 
> like a malware.
> From the hacker news feed you'll find out that:

I guess we could stick an einfo in the post-install messages, but if
you're joining a zoom meeting are you going to be any more secure if
you manually install the files instead?  I can't imagine that people
are going to stop attending meetings just because they picked the
wrong software to host them.  Plus a few of those concerns apply to
MANY packages - such as a lack of end-to-end encryption, or ever
having had a zero day.

I'm not intending to endorse Zoom here, but Gentoo isn't really
intended as a purist distro that will never include a package if it is
associated with a service that might collect user data and so on.  In
fact, we have many packages with these associations.  Ultimately users
can decide what they want to run, and we're just providing the files
in the most convenient and secure manner possible.  For example, when
the zero day is fixed if you're using Gentoo you'll benefit from our
security policy, while you would not if you had just manually
installed some files/etc...

-- 
Rich



Re: [gentoo-dev] network sandbox challenge

2020-03-27 Thread Rich Freeman
On Fri, Mar 27, 2020 at 7:33 AM Michał Górny  wrote:
>
> On Fri, 2020-03-27 at 11:29 +, Samuel Bernardo wrote:
>
> > Same question for unpack context when using directly the source
> > repository with vcs functions.
>
> VCS ebuilds generally suck, for multiple reasons.  We allow users to use
> them but with minimal support.  However, e.g. git-r3 supports local
> mirrors to resolve some problems.
>

Any guides on using that from an ebuild maintenance standpoint?  The
eclass docs make it appear more for local sysadmin use vs as a way to
distribute things, but I could be reading into it.

Usually my solution to VCS ebuilds when that is all upstream supports
is to just create my own github mirror of the repo, tag an appropriate
commit, and then fetch the resulting tarball directly as a non-VCS
ebuild.  Essentially I end up running my own private fork of upstream.
At least, this is what I do for actual releases that upstream can't be
bothered to release properly - for a live - VCS ebuild I just
point to upstream.

I don't believe Gentoo has any kind of recommended/standardized
solution for this, but having ebuilds point to my own private fork of
things obviously is non-ideal.  However, I think it is still more
transparent than just bundling up a tarball manually and sticking it
in my devspace since at least with my forked repo everybody can see
where it came from and what state it is in, and of course it is easier
to maintain.

If there is a more preferred way of doing this I'd be interested to
hear about it.

-- 
Rich



Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

2020-03-13 Thread Rich Freeman
On Fri, Mar 13, 2020 at 1:29 AM Chí-Thanh Christopher Nguyễn
 wrote:
>
> Alec Warner schrieb:
> > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel  > > wrote:
> >
> > Someone needs to grow up here.
> >
> >
> > Meh, to me (someone who can't commit to ::gentoo) I have a few concerns 
> > here.
> > First, I don't see a lot of QA reverts on the gentoo-dev list. Is it common
> > practice to post reverts publicly? Second, I'm not aware that we would 
> > revert
> > for things like this. Most of the items you mention look fairly minor (maybe
> > the python comment looks impactful?) Why can't we fix these items in a 
> > future
> > commit, rather than revert? What did Patrice's commit break?
>
> If the issues are so serious that we have to prevent any breakage/regressions
> from reaching users, I guess an alternative response would have been to
> p.mask the offending new ebuild. Unless the commit caused some tree-wide
> breakage which I can't see here however.

Don't really want to comment on where the line should have been drawn
on this particular case, but the idea of reverting commits doesn't
seem particularly abhorrent, and certainly commits that don't create a
new ebuild couldn't be addressed with masking unless we want to impact
end users.

It seems like the drama here is mostly about how this ended up on the
lists vs just being a discussion between QA and the committer/etc.
Reading between the lines I'm not sure if it was ever intended to be
on the list at least initially.

If this was intended for public consumption it probably wouldn't hurt
to note why (hey, we're singling out this commit because it has this
error we've been seeing a lot of lately and you can see how this sort
of thing could sneak in...).  Otherwise it just seems like it causes
drama without actually achieving the desired impact.

-- 
Rich



Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-02-11 Thread Rich Freeman
On Tue, Feb 11, 2020 at 10:05 AM Haelwenn (lanodan) Monnier
 wrote:
>
> Maybe it could for now be a simple agreement on putting your code to
> the Gentoo Foundation under the GPL-2+ but it would be published under
> the GPL-{2,3,…}?
>

Well, if we were going to get people to start signing things I suggest
just sticking to the FLA since it actually was written by lawyers.

I attached a copy, but along these lines the key section is:
We agree to (sub)license the Contribution or any Materials containing,
based on or derived from your Contribution under the terms of any
licenses the Free Software Foundation classifies as Free Software
License and which are approved by the Open Source Initiative as Open
Source licenses.

That is, Gentoo would control the licenses, but they would have to be
FSF/OSI approved.  That doesn't mean that anybody could choose any
FSF-approved license - Gentoo would still have to do the licensing.
This is just a limitation on the grant of power from the original
author to Gentoo on WHAT licenses GENTOO can choose.

There is also a variant of the FLA that can further narrow down the
licenses that Gentoo gets to choose from, but IMO if you're going to
go down this path it makes sense to keep things flexible.  We could of
course just limit Gentoo to GPL v2+, and initially Gentoo does v2/3
and later Gentoo could revise to any later version of the GPL.  But if
for whatever reason the GPL falls out of favor then we can't adapt
futher.

Ultimately though anything like this involves giving up control.

For those interested in the FLA there is a license generator at:
http://contributoragreements.org/ca-cla-chooser/

You pick the terms (I used the defaults - which IMO are most
appropriate but not the only valid option).  It spits out an agreement
for you.


-- 
Rich


fiduciary-license-license-agreement-2.0-2020-02-11-15_47_12.pdf
Description: Adobe PDF document


Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-01-30 Thread Rich Freeman
On Thu, Jan 30, 2020 at 8:39 AM Hanno Böck  wrote:
>
> *If* Gentoo decides to go this relicensing way I'd recommend to only do
> that if it's coordinated with organizations that have deep legal
> knowledge of these issues (e.g. like software freedom conservancy) and
> if some lawyers that know this stuff well approve the plan.
>

IMO no organization has "deep legal knowledge" of these issues,
because as far as I'm aware something like this has never been done
and tested in court.  Really there are only a handful of legal cases
at all that deal with copyleft and FOSS relicensing.

There is no end of lawyers who will hand-wave on the issue.  I think
the bottom line is that doing something like this is legally risky,
because until something like this has been done successfully many
times it is novel.  You're never going to find a lawyer who will sign
off saying "this is safe and definitely legal."  The only way you
could make something like this risk-free would be to get governments
around the world to pass laws setting up requirements for
FOSS-relicensing without the consent of all contributors.

The best we can do is mitigate risks, if we elect to do something like
this.  That can include being transparent, giving notice, having a way
to opt out, and so on.  Then when somebody sends us a cease and desist
notice we just tell them no problem, their contributions will be
treated as v2-only.  That doesn't completely prevent them from suing
us, but it would mitigate the impact, and probably make it unlikely
that most would sue in the first place.  Really, with something like
this that is the best you're ever going to be able to hope for.

If you don't want to do something unless a lawyer can guarantee that
it can't be found to be a tort by a court, then you definitely don't
want to pursue this change, unless we only make it forward-going for
new contributions and carefully track existing code, and I doubt that
will ever be very practical, so you might as well just give up and say
we'll be v2 forever because that's how things were set up 20 years
ago.

-- 
Rich



Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-01-30 Thread Rich Freeman
On Thu, Jan 30, 2020 at 6:20 AM Haelwenn (lanodan) Monnier
 wrote:
>
> [2020-01-27 12:41:26+0100] Ulrich Mueller:
> > So, the question is, should we allow ebuilds
> > # Distributed under the terms of the GNU General Public License, v2 or later
> > in the repository, or should we even encourage it for new ebuilds?
> >
> > I have somewhat mixed feelings about this. One the one hand, I think
> > that GPL-2+ should generally be preferred because it offers better
> > compatibility. For example, the compatibility clause in CC-BY-SA-4.0
> > won't work with GPL-2.
>
> Is there another reason for GPL-2+ than just compatibility?
> Because I quite find the "or later" thing to be quite a scary one as
> whatever will come up next as a GPL will become applicable and it feels
> quite weird to me to have a license that can evolve to whatever
> license over time.

Well, there are two sides to this particular issue.

GPL 2+ means that anybody can choose to redistribute the code under
the terms of any version of the GPL that is >=2.  So, if they add
terms to GPL v4 that you really don't like, you can still redistribute
it under the terms of GPL v2-3 if you prefer.

The other side to this is that you can't stop others from
redistributing it under v4.  They could also incorporate it into other
code that is v4+ which you could only redistribute under v4 or
greater.  Of course, the original code can still be redistributed
under v2 - it is just the parts that are comingled with other v4 code
that is at issue.

Really the main threat (IMO) is that the code could be de-copylefted.
They could make GPL v4 a copy of the BSD license, and now anything
that was v2+ is effectively BSD and can be used in non-FOSS software
without issue.  I guess that isn't any worse than the previous case of
it instead being merged into some other v4 variant that you can access
the source for but prefer to avoid because of something else in the
license, except now you might not see the code at all.

The advantage of 2+ is of course flexibility:

For one it reduces license proliferation.  Code that is v2-only is
effectively orphaned with regard to v3, v4, v5, and so on projects in
the future.  GPLv2 is fairly restrictive by design around
compatibility with other licenses and accepting future versions helps
mitigate this insofar as you trust the FSF.

And of course if at some point some fatal flaw is found in the GPL in
a court case, it is possible that a future version could mitigate that
flaw.  Of course, if that flaw lets anybody ignore the copyleft bits
you can't prevent people from using it under the old flawed v2, but at
least you can still use the code in your own v4 or whatever.  Of
course, if the flaw effectively made the v2 code public domain you can
do that anyway, but if the flaw were of a different nature it might
cause problems having code being locked up as v2-only.

>
> I think I would personally slightly prefer to have it be properly
> dual-licensed GPL-{2,3} or GPL-2 & CC-BY-SA-4.0 instead.
>

The problem like this is that this is basically just kicking the can
down the road.  It is of course equivalent for the moment, but when
GPLv4 comes along we have to go through this again.  Right now most of
the Gentoo authors are alive and might be willing to explicitly sign
off on a relicense (maybe).  However, maybe in another 10 years when
GPLv4 comes out it is going to be much harder to track everybody down.

On the flip side the fact is that none of us know what the FSF will
look like in 10 years, or 40 years.  There are plenty of large
non-profits today that bear little resemblance to what they looked
like 100 years ago, for good or ill.  The GPL v2 (or v3) are known
quantities that we can debate on in a concrete manner, but unknown
future versions can only be speculated on.

Another solution to this problem is the FLA - which is something we've
talked about but shelved until we've sorted out some of our other
copyright issues which were thorny enough.  Perhaps we could consider
taking that up again.  Without getting into the details it is a bit
like a copyleft-style copyright assignment, which isn't actually an
assignment.  We envisoned it being voluntary and would allow any
contributor to give the Foundation the authority to relicense their
contributions, with a number of restrictions, like the new license
being FOSS.  I'd have to dig up the latest version and take a look at
it again.  Basically instead of trusting the FSF you'd be trusting the
Foundation instead, but there are some limitations on what they'd be
allowed to do, and if they violate those limitations the agreement
would be canceled and the rights would revert back to whatever was on
the original contribution, which would probably be whatever the author
originally wanted.  That said, I'm not sure it really provides a whole
lot more protection over what happens except for the fact that
Foundation members have more say in how the Foundation operations than
the FSF, if only because 

Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?

2020-01-27 Thread Rich Freeman
On Mon, Jan 27, 2020 at 6:41 AM Ulrich Mueller  wrote:
>
> Historically, all ebuilds in the Gentoo repository were licensed under
> GPL-2+. At a later point they were relicensed [1] to GPL-2. See [2] for
> a rationale (or absence of it, YMMV).

I think the historical policy made sense in its context, which was a
world where all copyrights were to be assigned.  In that case you can
already relicense at will, so you still have flexibility, but by
keeping it pinned at one version you don't get pulled into something
by somebody else that you didn't intend.

Now, over time the whole assignment thing became fuzzier and I don't
really want to get into a largely-moot debate at this point over how
effective those assignments were at various points in time.

Today we are in a world where our intent isn't for the default to
involve assignment, and so the v2-only licenses create (IMO) more
problems than they prevent.

> On the other hand, we would presumably never achieve a complete
> transition to GPL-2+, so we would have ebuilds with either GPL variant
> in the tree. Not sure how big an issue that would be. Updating ebuilds
> wouldn't be a problem (as the old header would stay), but devs would
> have to spend attention to the header when copying code from one ebuild
> to another.

Devs already have to be careful about copying code into ebuilds that
go into our repo.  Somebody could attach an ebuild to a bug and stick
"Copyright Joe Smith all rights reserved" at the top of it.

I think it would make sense to have a call for Devs to voluntarily
report in and give permission for their contributions to be licensed
v2+ with no change in copyright ownership and see what happens.  I
wouldn't be surprised if we could relicense 80-90% of the tree
quickly.  If that happens then we could just require it for new
contributions (if we wanted to), and then over time the problem would
just go away, just like an old EAPI.

We could also stick warnings in ebuild comments like "# Warning
v2-only ebuild - do not copy !" and maybe copy it
every 20 lines if we wanted to be super-paranoid.

I do agree with the general argument that much of this code isn't
really subject to copyright.  We could just do both an opt-in and
opt-out approach to this.  Have the opt-in so that we get as much
explicit approval as we can.  Also do an opt-out with a prominent
announcement like, "hey, we're about to adopt GPL v2+ for all our
ebuilds so if you think you have contributions that are non-trivial
and want to object to those contributions being relicensed please let
us know."  It isn't an airtight defense, but it isn't entirely
unreasonable either.

Or we could just see how many fish we catch with a very conservative
opt-in approach and go from there.  We might not need to even consider
the risk of an opt-out approach.

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky  wrote:
>
> This is retarded, stop wasting my time.
>

There is nothing retarded about shared /home directories.  They're
pretty common in the real world.

> >> I've already got responses from two QA members. This thread is pretty
> >> hard to miss.
> >
> > Well, then why go posting stuff like "guess we'll be triggering a
> > warning after all?"
>
> If these two things are logically connected, I don't see it.

If you're working with QA to change the QA checks, then you won't be
triggering warnings.

> >> I'm working on a patch for the install-qa-check.d check
> >> and I'm sure I'll get more when I post it.
> >
> > Are you just allowing it to not create the directory, or are we
> > considering patching it to allow creating stuff under /home?  It would
> > seem that the policy would also need updating in that case, but
> > probably not the former.
>
> The patch will make an exception for acct-user packages only; for /home,
> /home/${PN}, and /home/${PN}/.keep*. In other words, it makes things
> work exactly how they did before the GLEP81 eclass started keepdir'ing
> the home directory.

IMO this isn't the right direction to go in, but we can always put it
on the council agenda.  Maintaining the status quo (pre-QA-check) in
the interim isn't unreasonable, nor is keeping your package behavior
as it is for now.  Obviously this issue has been around for some time.
I realize that you didn't invent it.

I guess this is the sort of thing that people will tend to disagree
on.  At least Gentoo doesn't force this nonsense down my throat.  :)

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky  wrote:
>
> On 1/19/20 8:20 PM, Rich Freeman wrote:
> > It would be far simpler for the sysadmin to simply ensure that no
> > unsynced user owns a file or appears in an ACL.  That would be pretty
> > trivial to achieve.  Whatever is hosting /home could be designed to
> > block such changes, or you could just scan for these ownership issues
> > periodically and treat those responsible for them appropriately.
>
> Fantasy scenarios again. I'm not going to debunk a system that you just
> thought up and that has never existed. Why don't you find one person who
> actually does this, and see if it bothers him if we create a home
> directory under /home where it belongs?

Uh, I'm pretty confident that nothing in my /home is owned by a UID
under 1000, or has an ACL referencing such a UID.  I just checked with
myself and I don't want you creating directories in /home.

This really seems like it has the potential to create a mess for
anybody using LUKS-encrypted home directories, stuff mounted from
CIFS, and so on.  While I personally don't do either it seems fairly
mainstream, and I could eventually see myself using it more once
better supported on Gentoo (such as when systemd-homed is more
mainstream).

> > On the topic of treating those responsible appropriately, somehow I
> > could see this scenario turning into a quiz question.
> >
> > I mean, would it kill you to just talk to QA first?
>
> I've already got responses from two QA members. This thread is pretty
> hard to miss.

Well, then why go posting stuff like "guess we'll be triggering a
warning after all?"

> I'm working on a patch for the install-qa-check.d check
> and I'm sure I'll get more when I post it.

Are you just allowing it to not create the directory, or are we
considering patching it to allow creating stuff under /home?  It would
seem that the policy would also need updating in that case, but
probably not the former.

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky  wrote:
>
> On 1/19/20 2:47 PM, Rich Freeman wrote:
> >
> > Obviously the UIDs associated with the shared /home need to be
> > identical.  Simplest solution is to sync anything > 1000 in
> > /etc/passwd, and then not allow UIDs below 1000 in /home.  A cron job
> > could easily handle both, and of course regular users can't go
> > creating stuff with the wrong UID anyway.
>
> That's not enough. You also need to sync any user/group that appears as
> the owner or group of a file in /home, and every user/group that appears
> in an ACL in /home, and so on. And since you have no idea what files or
> access control lists will show up in /home, you'd better sync them all.

That doesn't seem reasonable, considering that this could require
syncing across various Distros, or even various Unix-like OSes.
It would be far simpler for the sysadmin to simply ensure that no
unsynced user owns a file or appears in an ACL.  That would be pretty
trivial to achieve.  Whatever is hosting /home could be designed to
block such changes, or you could just scan for these ownership issues
periodically and treat those responsible for them appropriately.

In any case, maintaining permissions on stuff in /home is a sysadmin
responsibility, not a distro responsibility.

On Sun, Jan 19, 2020 at 5:09 PM Michael Orlitzky  wrote:
>
> Just kidding, the eclass is rigged to die in src_install if you delete
> the home directory, and if you wait until pkg_preinst, the warning gets
> shown anyway (for a file that's not there, noice).
>
> Guess we'll be triggering a warning after all.

On the topic of treating those responsible appropriately, somehow I
could see this scenario turning into a quiz question.

I mean, would it kill you to just talk to QA first?

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 2:27 PM Michael Orlitzky  wrote:
>
> On 1/19/20 2:02 PM, Rich Freeman wrote:
> >
> >> If you're sharing /home, you also have to be sharing user accounts,
> >> unless you want everyone to be assigned a random set of files.
> >
> > I imagine that most people setting up something like this would only
> > be sharing high-value UIDs (>1000 in our case).  There is no need for
> > postfix on your Gentoo box and postfix on your Debian box to have the
> > same UID.  You wouldn't be sshing from postfix on the one to postfix
> > on the other and expecting to have the same home directory contents.
> >
>
> You can't do that. If you're going to mount files from one system onto
> another system, using only an integer <--> username mapping as your
> access control mechanism, then you'd better be damn sure that those
> integers and usernames match on all systems. Otherwise I might wind up
> sharing /home/mjo to rich0 because the "mjo" and "rich0" groups both
> have gid 1000 locally.

Obviously the UIDs associated with the shared /home need to be
identical.  Simplest solution is to sync anything > 1000 in
/etc/passwd, and then not allow UIDs below 1000 in /home.  A cron job
could easily handle both, and of course regular users can't go
creating stuff with the wrong UID anyway.

> We've talked this to death. Barring any new evidence, /home still seems
> like the best place for these, and I don't want to put them in the wrong
> spot (forcing users to migrate) just to appease a QA warning from before
> GLEP81 was a thing.

Well, great, then by all means ask QA for a policy exception.  Not my
place to yell at you if you don't, but don't be surprised if somebody
else does...

-- 
Rich



Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 2:32 PM Kent Fredric  wrote:
>
> Having a discussion at a bar, and you making a commit as a result is
> one thing, but if I discovered a bug, and then only told you about it
> at the bar, that would be possibly bad, because there's no guarantee
> that the bug is communicated sufficient to ensure it gets addressed,
> and you may go home at the end of the night and entirely forget the bug
> existed, and people could continue to suffer it, and potentially
> neglect to report it as well. ( End users are substantially less likely
> to file bugs, IME )
>
> When I mention bugs to people on IRC, I often follow up with "Would you
> like me to file a bug?".
>
> Often, the answer is "yes".
>
> The crux of the matter being bugs that exist, and are communicated
> outside the core bug tracker, weaken the assurance that it will be seen
> and fixed, which amounts to a negative thing.

Oh, I absolutely agree with this.

My point is that right now we have no policy that requires bugs to be
filed.  And hence stuff that happens on github really is no different
than your case of stuff happening in a bar.

I can't speak for the QA repo, but don't we have a bot that notices
open pull requests for the main repo mirror on github which are
missing bug references to post notices to this effect?  When this
started happening I think a lot of the concerns were reduced.

I mean, like was already mentioned, if there were a gitlab repo or
whatever being hosted a lot of this might become moot.  We're just not
there yet.

I'm not sure if the Foundation has considered approaching gitlab.com
about hosting.  Granted, that isn't their FOSS product, but I suspect
the repos could be exported and imported into the FOSS product as a
contingency.  I have it on good authority from somebody who works
there that their proprietary hosted product is identical to the FOSS
one aside from the proprietary modules, so as long as you avoid the
latter it should be the same thing.  If they're willing to donate or
offer cheaper hosting it might give us the benefits of the FOSS
repository while avoiding the hassles of hosting Ruby or whatever it
is written in.

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 1:37 PM Michael Orlitzky  wrote:
>
> On 1/19/20 12:42 PM, Rich Freeman wrote:
> >
> > Typically you wouldn't share service accounts across multiple hosts.
> > I'd think that something like amavisd is going to go on a mail server.
> > You're not going to be logging into that account to do typical
> > desktop-oriented functions.
> >
> > If you had three mail servers, you probably would want to share
> > /home/mjo across all of them, but you probably wouldn't want to share
> > your amavisd config across them.  That is why the config goes in /etc.
> > I don't see how stuff it launches would be any different.
>
> The stuff it launches is different because the stuff it launches is
> different. SpamAssassin, for example, can be run by normal users in a
> traditional UNIX mail setup. So its configuration goes in $HOME, because
> that's how it works. When amavis runs spamassassin, the SA configuration
> comes from $HOME, because that's how it works.

Sure, I completely understand that and have no issues with it.  Ditto
with having some apache module running sendmail, which has some plugin
which gpg signs emails, which requires a ~/.gnupg for the apache user.

> If you're sharing /home, you also have to be sharing user accounts,
> unless you want everyone to be assigned a random set of files.

I imagine that most people setting up something like this would only
be sharing high-value UIDs (>1000 in our case).  There is no need for
postfix on your Gentoo box and postfix on your Debian box to have the
same UID.  You wouldn't be sshing from postfix on the one to postfix
on the other and expecting to have the same home directory contents.

> And if
> you're sharing user accounts, you have to start each instance of amavis
> as a different user, because its configuration is per-user. That's just
> the way it works.

Since it is a local account, not in /home, then it would be a separate
user even if the UID is the same (or otherwise).  You'd set up amavis
on each mail server.  They might be running different distros.  They
would be using local users.

Don't get me wrong, it would be cleaner if POSIX users had a scope the
way that an OS like Windows does it, but it isn't a big deal if you
use high-numbered UIDs for shared users, and low-numbered UIDs for
local users.

> Everything is fine here, this all works and has worked for 20 years.

Sure, it works fine if you have a single host, or do nothing to share
your home directories, which I imagine is what 95% of Gentoo users do.
I doubt most Gentoo users even encrypt /home, even though this has
been standard for most of those 20 years on just about every major
distro out there.

If a user wants to put this stuff in /home we should certainly support
that, and it would work fine if the user sets up the account properly
before installing the package.  They might get a QA warning, but that
is the user's concern.

-- 
Rich



Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 1:45 PM Kent Fredric  wrote:
>
> On Sun, 19 Jan 2020 07:08:30 -0500
> Rich Freeman  wrote:
>
> > The official sources aren't in github.  A bugzilla component is
> > available, so if github goes away there is no problem and we aren't
> > relying on it.
>
> If github goes away after bugs and PR's are filed on github, then that
> historical context is lost, and may include the loss of open bugs and
> open PRs, which all may still be relevant.

Nothing of importance should be stored on github.

If you and I have a conversation at a bar, and as a result you decide
to make a commit without any useful comments, and then we both retire
from the project, just as much information is lost.

We don't require anybody to open a bug before making a commit today,
so why would we be concerned when non-required outside documentation
is stored in github?  That is more information than we already
require, so if it goes away nothing required by policy is lost.

If we made it a policy that all commits required some kind of peer
review in bugzilla, then of course we should do the same here.  Right
now we do not require that background for just about anything the
distro does be recorded anywhere.

If github's existence bothers you, then just pretend it doesn't exist
- stick it in your hosts file or block it at your router.  In theory
it shouldn't change your Gentoo experience at all.  :)

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky  wrote:
>
> On 1/19/20 6:29 AM, Rich Freeman wrote:
> >
> > Daemons are local users.  There is no guarantee that /home is a local
> > filesystem.  Heck, there is no guarantee that /home is even mounted
> > when portage is running.  Portage shouldn't be touching /home at all.
> > With stuff like automounted or encrypted home directories and
> > systemd-homed and so on it seems like it is even more important to
> > avoid sticking stuff in /home (and this is hardly something started by
> > systemd - stuff in /home that is non-static has been a thing for some
> > time - certainly it was happening in the 90s on some IRIX workstations
> > I used).
>
> If you're sharing /home, you're also sharing users. At that point, the
> daemon user is no longer local.

Typically you wouldn't share service accounts across multiple hosts.
I'd think that something like amavisd is going to go on a mail server.
You're not going to be logging into that account to do typical
desktop-oriented functions.

If you had three mail servers, you probably would want to share
/home/mjo across all of them, but you probably wouldn't want to share
your amavisd config across them.  That is why the config goes in /etc.
I don't see how stuff it launches would be any different.

This is why /root is typically outside of /home as well.

> I like your /var/lib/amavis/{home,work} suggestion second-best, but the
> most appropriate place for the home directory of an account that will be
> used interactively by a human (even if it's also used to start a daemon)
> is under /home. For example I do want to back up that home directory,
> but I don't want to back up the working directory.

Honestly, since you're only using it for what amounts to configuration
it almost makes sense to put it in /etc, and back it up for that
reason.

You don't really want to be using it interactively as a human per-se
any more than you interactively log in as root or any other service
account.  There are rare occassions where I'll launch a shell as
apache or postfix or whatever, but that doesn't mean that you want it
to have a home in /home.

> > Portage should provide a safe mechanism to fix permissions.  Or we
> > should just avoid nesting user home directories inside directories
> > that will be written to by that user.
> >
> > If this is the same hard-linking concern as with tmpfiles.d then
> > somebody really just needs to fix POSIX.  :)  But as a workaround just
> > avoiding nesting seems like the simpler solution...
>
> Essentially yes, but hard links aren't the only problem. It's unsafe to
> do anything as root in a user-controlled directory. POSIX can't fix
> that, and that means that portage will never be able to fix permissions
> (or do anything else) within a user-controlled directory safely.

I mean, you're still doing stuff as root.  You're just not running chown.

POSIX certainly could fix it, though whether it could do it in a
manner that doesn't break everything in existence is another matter.
For example, if POSIX just got rid of hard links many of the issues
would just go away.

Obviously if the problem had a simple solution it would have been
implemented by now.

BTW, thanks to the recent QA post I can at least point you at
documentation for your issue.  Per the article if you want to change
it the procedure is to ask QA for an exception or change in policy,
and if you don't like the answer go to Council...

https://projects.gentoo.org/qa/policy-guide/filesystem.html#installation-paths

-- 
Rich



Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Rich Freeman
On Sun, Jan 19, 2020 at 6:46 AM Ulrich Mueller  wrote:
>
> > On Sun, 19 Jan 2020, Michał Górny wrote:
>
> > The sources are stored in proj/policy-guide.git [3].  If you wish to
> > submit your own changes, you can either use the 'Policy Guide' bugzilla
> > component [4] and/or GitHub mirror [5].
>
> Please, no github for official policies. We should have a permanent
> paper trail for this kind of things, which isn't guaranteed if the
> discussion would happen entirely on github.
>
> Besides, by the Social Contract we cannot rely on a non-free service
> for anything official.

The official sources aren't in github.  A bugzilla component is
available, so if github goes away there is no problem and we aren't
relying on it.

It looks like there is the optional ability to do work on github, just
as people can optionally talk about anything, anywhere.

If I have a chat with another package maintainer at a bar, and they
modify their ebuild and push that to the Gentoo repo on infra, and no
bug is ever opened, that is 100% within our current policy.  I don't
see how having that discussion on github instead of at the bar changes
things.

They're just offering an alternative place to get things done.
Anybody who wants to could just file a bug instead.

If we want to have an additional Gentoo policy that nobody is allowed
to discuss a Gentoo policy outside of the lists and bugzilla that
would of course create issues with stuff like github, and probably
non-logged IRC channels and private messages as well.  However, that
is not our current policy.  Plenty of council decisions happen with
much of the actual discussion not being recorded anywhere.  I'm not
sure you could reasonably operate in any other way, as people do need
the ability to talk things out without having to posture.

I feel like this discussion has already happened in the past though...

-- 
Rich



Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Rich Freeman
On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky  wrote:
>
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky  wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really assuring a quality user
> >> experience here?
> >>
> >
> > Lots of daemons need a home directory for their users, and usually
> > they manage to get by in /var/lib.  It really seems like a bad
> > practice to start having packages creating stuff in /home.  Certainly
> > I don't want random daemons sticking stuff in /home, which I manage
> >
>
>   * The daemon DOES NOT need a home directory for its user.
>   * I DO NOT want to install anything to anyone's home directory.

My concern isn't with installing stuff to "anyone's home directory."
My concern is with creating ANYTHING in /home.

Daemons are local users.  There is no guarantee that /home is a local
filesystem.  Heck, there is no guarantee that /home is even mounted
when portage is running.  Portage shouldn't be touching /home at all.
With stuff like automounted or encrypted home directories and
systemd-homed and so on it seems like it is even more important to
avoid sticking stuff in /home (and this is hardly something started by
systemd - stuff in /home that is non-static has been a thing for some
time - certainly it was happening in the 90s on some IRIX workstations
I used).

>   * With respect to user.eclass, I'm proposing that /home be treated
> EXACTLY THE SAME as it always has been.

I'm not aware that it was ever considered good practice to stick stuff
in /home.  I suspect it just wasn't on QA's radar in the past.

>
> All I want to do is *set* a user's home directory to /home/foo.

You don't just want to "set" it.  You want to create the directory,
which is modifying the filesystem (otherwise, why have a .keepdir?).
And setting a home directory to something that doesn't exist doesn't
seem like an improvement unless it is /dev/null.

I get though that the daemon itself doesn't use the home directory,
and that you just want it for configuring other stuff it might launch.

> Spamassassin itself is a better example than amavis. We already set the
> spamd user's home directory to /home/spamd with user.eclass. We don't
> install anything there, and this works fine. If a human logs into that
> account and generates some configuration in ~/.spamassassin, then it's
> within the spirit of the FHS to have that data stored in /home.

Looks like we might have another package to deal with, and perhaps
others as well, depending on what comes out of this thread.

> Now, with GLEP 81, we get a QA warning for that, because the eclass
> installs a keepdir file there. I would like things to remain exactly as
> they are, with no QA warning. Otherwise, we have to tell users to move
> /home/spamd to /var/lib/spamd-home or something stupid like that. I can
> think of no good reason to do so.

Well, you won't get QA warnings from the tinderbox if the default home
isn't under /home.  Users who already have the home there might get
warnings at install time.  They can just ignore them.  You could
output an einfo to explain the situation to the user.  If they're fine
with /home then they can ignore the warning, and if they want to move
it they can do so.

I'll also note that GLEP 81 itself is silent on WHERE home directories
should be placed.  If some sort of definitive answer comes out of this
thread the GLEP should probably be updated to reflect this, unless
there is a better place to put it.  Seems like the fact that this
practice was undocumented in the past is part of how we got to where
we're at.

> > It seems like the straightforward solution is to stick everything in
> > /var/lib/amavis, and fix things so that everything has the right
> > permissions regardless of install order.
>
> Please stop telling people to do this. Calling chown on the live
> filesystem is rarely safe, and I already fixed one root exploit (bug
> 630836) in the amavisd-new ebuild from the last guy who tried to adjust
> wrong permissions after the fact.

That bug appears to be restricted.  Perhaps it is embargoed?  If not,
then it probably shouldn't be restricted, especially if already fixed
and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
this has anything to do with you most likely).

Portage should provide a safe mechanism to fix permissions.  Or we
should just avoid nesting user home directories inside directories
that will be written to by that user.

If this is the same hard-linking concern as with tmpfiles.d then
somebody really just needs to fix POSIX.  :)  But as a workaround just
avoiding nesting seems like the simpler solution...

Just on a side note, I'm just stating an opini

Re: [gentoo-dev] GLEP81 and /home

2020-01-18 Thread Rich Freeman
On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky  wrote:
>
> But now users have to follow one more step (create /home/amavis) when
> setting up amavisd-new. Is the QA check really assuring a quality user
> experience here?
>

Lots of daemons need a home directory for their users, and usually
they manage to get by in /var/lib.  It really seems like a bad
practice to start having packages creating stuff in /home.  Certainly
I don't want random daemons sticking stuff in /home, which I manage
differently from the OS-owned directories.  I'll just end up having to
manually create stuff where it belongs in /var/lib and then symlink
everything back from /home, and now I have distro cruft in /home and
non-distro cruft in /var/lib, and neither is ideal.

It seems like the straightforward solution is to stick everything in
/var/lib/amavis, and fix things so that everything has the right
permissions regardless of install order.

If /var/lib/amavis is getting installed root-owned then it should be
chowned when amavis is installed, especially for the first time.  That
seems sane.

Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Sat, Jan 4, 2020 at 3:13 PM Christopher Head  wrote:
>
>
> Of course this would be a bad argument if V-S were lagging behind upstream 
> significantly, and it’s a much better argument for packages that come with 
> expectations of security team support than those that don’t, but it is 
> something to consider.
>

This was my main concern when it was mentioned that it wasn't
security-supported.

If it is always up-to-date that definitely helps mitigate things.
Though, there should definitely be some kind of warning on the package
that it isn't security supported.  Even if it is up to date it won't
get GLSAs and GLSA-checker won't work.  Though, that really only makes
a difference insofar as the GLSAs are also timely.

In any case, if the just-announced distribution kernel project takes
off and remains active I could easily see that becoming the most
commonly used kernel option.  I'm not knocking minimal kernels but I
suspect a LOT of users are going to be well-served by a modular kernel
that just works 99% of the time.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford  wrote:
>
> On 2020.01.04 11:01, Rich Freeman wrote:
> >
> > Is there some reason that we should keep vanilla sources despite not
> > getting security handling?
> >
>
> Gentoo had this discussion before. The outcome was that
> vanilla-sources is just as Linus intended.
> If Gentoo did anything to it, it wouldn't be vanilla any longer.

Obviously.  I wasn't suggesting that we keep vanilla sources but not
make them vanilla.  That doesn't mean that they couldn't be
security-supported, or that we have to have them in the repo.

> Yes, it should be kept. We should not force users to learn
> git or tar.

Uh, all it does is install kernel sources.  They're useless unless you
build a kernel using them.

Apparently git and tar are too complicated for Gentoo users, but
managing symlinks, using make, managing a bootloader, dealing with the
kernel's configuration system, and so on are just fine?

I completely get the point of the distribution kernel project that was
just announced, as I already said.

> I agree git or a tarball of vanilla-sources is faster and more
> efficient but that's not a reason to drop it.
> By the same argument we could drop linux-firmware too.
> There are probably other packages that only install whatever
> they fetch. Could they be dropped?

So, a few issues with that argument:

1.  Those other packages are security supported.
2.  Those other packages are largely functional once installed, and to
the degree that they require configuration that is generally one-time
and after updates they remain functional.

All that said, it seems like vanilla-sources is pretty up-to-date, so
I'm not sure what we mean by it not being security supported.  I just
took that as a given.  Does that mean that we're not releasing patches
before upstream?  If so, that seems like a pretty minor issue since
upstream generally does security bumps pretty quickly.  4.4.208 isn't
in our repo but was released today - I'm not sure how quickly these
get bumped.  If our repo could be days behind that is definitely
another reason not to host this stuff, as users should be directed
upstream if our packages aren't security supported.

On a further aside, I just noticed how up-to-date gentoo-sources are.
Kudos to whoever is doing that these days - for a while it was tending
to slip a bit but it seems like we're basically current.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Fri, Jan 3, 2020 at 11:28 AM Aaron Bauman  wrote:
> On January 3, 2020 9:55:31 AM EST, Michael Orlitzky  wrote:
> >On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> >>
> >> But here we are. Do we make OpenRC Linux-only and steal the fix from
> >> systemd? Or pretend to support other operating systems, but leave
> >them
> >> insecure?
> >>
> >
> >Or the gripping hand: rewrite opentmpfiles in C, so that it's only as
> >insecure as checkpath.
> >
> >Every option sucks. I was only trying to point out that vanilla-sources
> >gets no security support -- security@ has stated this, but it's on a
> >private bug, so I won't quote it -- and the risk is more than academic.
>
> This should be known. Security does not support vanilla-sources. This is one 
> reason vanilla-sources are not stabilized.
>

Packages without security support should be masked.  Really I don't
see the point of even having this in the repo.

I run vanilla sources personally but I just get them from upstream.
Makes way more sense than worrying about whether the version in the
repo is up to date for the longterm kernel I'm following.  People
running vanilla sources are probably using out-of-tree modules (like
me) and as such are going to have particular requirements around how
they're updated.  So, Gentoo is adding fairly little value.

All they do is download sources anyway, which is trivially done from
git more efficiently (or tarballs that are probably easy to obtain
just as efficiently).  I can see more of the point in the new
distribution kernel project which will be turnkey.  I can see some of
the value in gentoo-sources (particularly as the upstream for the
distribution kernels) especially if they're tied to Gentoo-specific
bugs.  For more general bugs that apply to all distros I really don't
see the point in trying to compete with the upstream stable branches
(if they're taking forever to merge a patch, chances are there is a
reason for it, and I'm skeptical that Gentoo users are special in some
way).

Is there some reason that we should keep vanilla sources despite not
getting security handling?

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Rich Freeman
On Fri, Jan 3, 2020 at 9:41 AM Michael Orlitzky  wrote:
>
> On 1/3/20 9:40 AM, Toralf Förster wrote:
> > On 1/3/20 3:37 PM, Michael Orlitzky wrote:
> >> The gentoo-sources aren't 100% safe either, but the exploitable scenario
> >> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
> >
> > But this can be easily achieved w/o installing gentoo-sources, or?
> >
>
> Yes, if you know how to do it. And the hard part: if you know that you
> *should* do it.
>

If OpenRC contains a vulnerability wouldn't it make more sense to set
this as part of OpenRC, then to assume somebody is running a kernel
patch that does it, especially since OpenRC doesn't in any way ensure
that gentoo-sources is actually being used?

Of course, fixing the vulnerability seems like a better option.   At
least on Linux based on your one bug description it sounds like
systemd has a Linux-specific fix already.  Obviously it would be best
to secure this on all kernels but there is no reason not to at least
use that fix on Linux.  You could also try to convince the entire
world not to use tmpfiles.d but since it is only a problem if you
aren't using systemd I suspect you won't get much traction there.

In any case this seems more like an OpenRC issue than a Gentoo issue.

-- 
Rich



Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-20 Thread Rich Freeman
On Fri, Dec 20, 2019 at 8:41 AM Gerion Entrup  wrote:
>
> Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping:
> > On 19.12.19 18:37, Michał Górny wrote:
> > > We have a better alternative that lets us limit the impact on the users.
> > > Why not use it?
> >
> > Which one?  The CMake bootstrap copy?  The adding to stage3 one?
>
> If an error message can be shown, maybe this is enough as a hint:
> "expat and cmake have circular dependencies. Emerge it the first time with:
> USE=bundled-cmake emerge -1 cmake expat
> and then just don't care anymore about this use flag."
>

Not sure about custom error messages but in any case when using that
bundled-cmake USE flag it would probably make sense to do an ewarn
that the bundling took place and is only intended for temporary use,
and that the package should be re-merged without the flag once expat
is working.  That would also cover users who inadvertently set the
flag.

I think that bundled-cmake also might make more sense than
system-cmake, even though the latter is more established.  We have a
lot of users who set USE=-* and that means they're going to end up
with lots of stuff bundled that doesn't need to be.  I'm no fan of
USE=-* in general but it seems like we should try to avoid making not
setting a USE flag the less secure option since it does happen a lot.

I'm just commenting on the USE-based solution.  The compat package
solution obviously bypasses this particular problem entirely.

-- 
Rich



Re: [gentoo-dev] [EAPI 8 RFC] Selective fetch/mirror (un-)restriction

2019-12-16 Thread Rich Freeman
On Mon, Dec 16, 2019 at 8:33 AM Ulrich Mueller  wrote:
>
> > On Mon, 16 Dec 2019, Francesco Riosa wrote:
>
> > what about getting rid of RESTRICT="fetch" and manage everything
> > inside SRC_URI? Would that be technically feasible? Ideally marking
> > only the not re-distributable download and leaving untouched the
> > others
>
> That would have the disadvantage that mirror and bindist restrictions
> (which are strongly correlated) would be listed in different places.

An obvious way to address that is to also move the mirror restriction
into SRC_URI, so that they are both exclusively in this location as
well.  I believe those are the only two redistribution-oriented
options for RESTRICT currently.

-- 
Rich



Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Rich Freeman
On Tue, Dec 10, 2019 at 9:50 AM Michael Orlitzky  wrote:
>
> For esoteric packages with a dedicated user, though, you're probably
> right. The main benefit of the mailing list posts so far is that they
> let me track down pull requests and suggest that people ignore the
> example in the devmanual.
>

Do the list reviews really put people off that much?  It seems like
eclasses.  Plenty of packages have one-off eclasses that nobody cares
about except the specific project, in which case the list posts are
just a formality and largely a NOOP.  However, this list isn't really
high-traffic.  Ditto with last-rites and so on.  I think having the
opportunity for review is probably worth it even if often it is just a
NOOP.

If people are afraid to post something for review because of potential
criticism then maybe we need to work more to make sure people
understand that everybody makes mistakes and nobody knows everything,
and this is why we have reviews in the first place.  Nobody is going
to have their commit access removed because they didn't notice
something and were thoughtful enough to get more eyes on it before
commiting it.  IMO that is a sign of responsible commit access.

-- 
Rich



Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Rich Freeman
On Tue, Dec 10, 2019 at 8:25 AM Thomas Deutschmann  wrote:
>
> On 2019-12-10 13:44, Rich Freeman wrote:
> > I'm not talking about container-host mapping.  I'm talking about
> > building the same container 100 times and having the container end up
> > with the same UIDs inside each time.
> >
> > Build order in portage isn't really deterministic, especially over
> > long periods of time, so you can't rely on stuff getting installed in
> > the same order.
>
> Assume you are building a container for dev-db/mysql. I can only think
> of one scenario where you would end up with different UIDs: That's when
> dev-db/mysql (or a dependency) would suddenly create an own user and
> will be merged before mysql's user was created.
>
> But this is very theoretically. Especially in a container world, you
> will create one container per services so it's *very* unlikely that
> something like that will ever happen. Not?

There are cases where you might have more than one service in a
container, and there is certainly the issue of dependencies.  It
certainly makes sense to limit a container to a single function, but
internally that could involve multiple processes.

> Aside benefits from reproducible builds in general (which Gentoo doesn't
> provide), please share reasons why one would care about used UIDs/GIDs
> in containers...

Well, that is simple.  In the mysql example /var/lib/mysql would be
bind-mounted from outside the container, since it needs to be
persistent anytime the container is updated.  If you update the
container and it ends up with a different UID for mysqld, then it
wouldn't be able to read anything in /var/lib/mysql as it would still
have the previous UID.  You'd need to keep the two in sync somehow.

In fact, that is the very example you go on to offer...

> > Uh, the container processes shouldn't even see the host
> > processes/files whether they have the same UIDs or not...
>
> Especially when you put mysql or any other service using data into a
> container, service running in that container must be able to access this
> data. And one common way to do that is allowing container to access data
> stored on host, i.e.
>
> > $ docker run \
> > --name some-mysql \
> > -v /my/own/datadir:/var/lib/mysql \
> > -e MYSQL_ROOT_PASSWORD=my-secret-pw \
> > -d mysql:tag
>
> which will make /my/own/datadir from host available in container as
> /var/lib/mysql.
>

This is obviously exactly how you'd do it if you were using docker,
but you don't need to keep the UID in the container in sync with
anything else in the host.  If security is a concern you'd probably
want to make sure that nothing non-root can reach the directory since
its UID might be in use for something else.

In any case, this is why consistent UIDs in scratch installs are
useful.  When you're building a new version of a container you don't
want all its UIDs to change.  And of course this isn't just limited to
containers, but anything where you have persistent storage.  It is
just that the idea of creating new instances from scratch instead of
updating them in-place has become more fashionable around the same
time that containers have become more fashionable.  You could do the
same thing with a bare-metal host, though it would be a bit more
painful (perhaps using A/B partition booting, or less painful if
you're booting from a SAN or something like that).

-- 
Rich



Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Rich Freeman
On Tue, Dec 10, 2019 at 7:26 AM Thomas Deutschmann  wrote:
>
> On 2019-12-10 12:47, Rich Freeman wrote:
> > Having UIDs chosen completely at random seems fairly non-optimal.
> > Suppose you're building containers/etc and then bind-mounting in
> > persistent storage (/var/lib/mysql and so on).  Wouldn't it be nice if
> > the default were that mysql would get the same UID on every build?  I
> > guess you could provide an initial /etc/passwd on every fresh build
> > but it just seems like an extra step.
>
> In practice you will *never* assume proper container <> host user
> mapping. *Never*. If you do that, you are doing it wrong:

I'm not talking about container-host mapping.  I'm talking about
building the same container 100 times and having the container end up
with the same UIDs inside each time.

Build order in portage isn't really deterministic, especially over
long periods of time, so you can't rely on stuff getting installed in
the same order.

> - Container sometimes switch base images. You won't notice that unless
> you follow container provider very closely. But you are using container
> because you are focused on containerized application, not the container
> itself...

I'm talking about Gentoo containers here that YOU are the one
building.  Not just doing "docker run foo."  Obviously if you're using
somebody else's images you're going to end up with whatever UIDs they
use.  Chances are they're from some distro that actually DOES manage
their UIDs so they'll still be stable over time unless the base image
changes as you say.

> - Your host is maybe running some real services. You really don't want
> that a container suddenly become able to access these services just
> because container <> host mapping has match.

Uh, the container processes shouldn't even see the host
processes/files whether they have the same UIDs or not...

-- 
Rich



Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Rich Freeman
On Tue, Dec 10, 2019 at 12:44 AM Joonas Niilola  wrote:
>
> Honestly I'd say just put -1 on all acct- packages then let sys admins
> modify them locally to whatever they need. I feel like this whole GLEP
> just serves the minority while making many other contributors uneasy.
>

I think we're worrying far too much about people with decade-old
installs.  Just come up with a reasonable set of defaults and as long
as it can adapt to whatever is already in /etc/passwd we're fine.

Having UIDs chosen completely at random seems fairly non-optimal.
Suppose you're building containers/etc and then bind-mounting in
persistent storage (/var/lib/mysql and so on).  Wouldn't it be nice if
the default were that mysql would get the same UID on every build?  I
guess you could provide an initial /etc/passwd on every fresh build
but it just seems like an extra step.

This isn't about serving the minority so much as not letting the
perfect be the enemy of the good.  Yes, there are reasons why GLEP 81
won't be perfect.  That doesn't mean that it isn't a good idea...

-- 
Rich



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-06 Thread Rich Freeman
On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann  wrote:
>
> Sure, if packages don't work anymore or are blocking something, we will
> start last-rite process. But for the sabnzbd example (I haven't looked
> closely on any other package from that list) there isn't anything
> blocking and it's a working piece of software. The only thing which
> stands out is: It's a Py2-only package.
>

Well, that's simple enough.  If the python maintainers intend to
remove python2 then they need to remove anything that depends on it at
the same time.  Otherwise all those packages are going to break anyway
and users just end up with a mess of error messages due to a broken
depgraph.

That said, as I've already commented I think it makes more sense to
mask the reverse dependencies at the same time as masking python2
itself.

And of course for something this big it wouldn't have hurt to announce
the plans and what was going to get masked so that mistakes could get
caught.  Even though it is just a mask it is still a bit disruptive to
have packages masked/unmasked because of incorrect identification of
reverse/optional deps.

Ultimately though it is up to the python2 maintainers to decide when
they want to remove it.  If others want to step up and replace them as
python2 maintainers and they have a reasonable plan for keeping it
working that would seem like the approach that would make the most
people happy.  We can't force people to maintain python2 if they don't
want to.

-- 
Rich



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Rich Freeman
On Thu, Dec 5, 2019 at 5:23 PM David Seifert  wrote:
>
> And that's exactly the straw-man argument I've been making. You can
> always come up with an excuse to delay action on python 2, because
> "someone, somewhere, will maintain it".

Hey, if somebody actually does want to maintain it I don't see any
reason it can't stick around forever.  Of course maintain means
maintain, not just ignore bugs/etc if it causes grief for other
packages and so on, or allow security issues to fester.

So far I'm getting the impression that everybody wants somebody else
to maintain it, and that is when it becomes an issue.  "WE ought to do
this" - where "WE" usually means "not me."  There is no nebulous
"Gentoo" out there who will maintain ebuilds.  If they are to stay in
the repo then somebody has to actually tend them.

If somebody wants to keep around 2.7 for a long time IMO the most
straightforward thing to do is announce a desire to do it with a plan.
I really doubt that anybody is likely to interfere, and if they do it
can always be escalated to Council.  But, again, it has to be done
right and not cause issues for other packages (at least at the start
that shouldn't be a huge problem).

Personally I've always admired the Wikipedia policy:
https://en.wikipedia.org/wiki/WP:BOLD

If you want to see a change, go about it in a positive way.  If such a
change bothers you, assume good faith, but point out the issues.
Don't over-react in either direction.  This is how 99% of everything
positive that has ever happened in Gentoo has come about.  Most of our
improvements are the result of "unsanctioned crusades."  That doesn't
mean that you should go around breaking systems left and right, but in
this case we're just talking about a mask, or announcing an intent to
do a project.

But, such a thing will certainly involve work.  IMO it is work for
diminishing returns.  If it is an itch that bothers you, though, you
can always scratch it...

-- 
Rich



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Rich Freeman
On Thu, Dec 5, 2019 at 8:59 AM Jason A. Donenfeld  wrote:
>
> It's quite another to mask random packages that have USE flags to
> optionally support whatever python 2.7 library. If you're going to
> last rites these, talk with the maintainer first, and only then, send
> emails one at a time. Doing that en masse isn't appropriate.

++ - I have no idea if that happened.  For anything USE-controlled it
would make more sense to file a bug or mask the package-flag combo
itself.

>
> On another topic, I'd prefer for python 2.7 not to be removed from
> gentoo. Tons of code still uses it.
>

I'm sure a million people would share that preference.  I'm not sure
what the upstream/security status is of 2.7.  Obviously to keep it
around it would need to be reasonably secure, and somebody within
Gentoo would have to want to maintain it.  That's basically the
criteria for keeping anything like this around.  If somebody stepped
up and said "I'm maintaining 2.7 and here is why it will remain
secure..." I doubt they'd get a lot of resistance.

-- 
Rich



Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-05 Thread Rich Freeman
On Thu, Dec 5, 2019 at 8:42 AM Jason A. Donenfeld  wrote:
>
> Hi,
>
> Aaron has marked tons of important and useful Python 2.7 packages for removal:
>
> Can we not do this prematurely? I've revered this commit until such a
> thing an be appropriately agreed upon.

Might make sense to wait to mask them at the same time as masking
python 2.7 itself?  Maybe file a bug if not already done to make
maintainers aware that this is coming?

I assume the python team is the one deciding when python 2.7 has to go
(after all, who else is going to maintain it?).  The fact that this is
about a month off did come up in another recent thread but I don't
think it was intended as a formal announcement.

-- 
Rich



Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

2019-11-15 Thread Rich Freeman
On Fri, Nov 15, 2019 at 3:05 AM Michał Górny  wrote:
>
> On Wed, 2019-11-13 at 22:16 +0100, Michał Górny wrote:
> > I'd like to share my frustration at the state of Python in general,
> > and Python packages in Gentoo.  So I'd like to 'bootstrap' python3_8 --
> > that is, add it to the most common dependency, dev-python/setuptools.
> > Simple thing, right?
> >
>
> So I went with plan B instead: I'll do as much testing locally
> as possible, and add py3.8 when I manage to get the tests on the package
> in question working, independently of the testing of all deep test deps.
> This will mean that some packages will have tests disabled temporarily
> for end users.
>

Perhaps an overlay would be simpler just so that you can generally
avoid worrying about QA until you're tidying up, but otherwise this
seems like it could be done in-tree by just masking the use flag so
that only those willing to test/contribute run into issues.

You've described a number of issues and my sense is that many are just
inherent to python itself (the complex dep graph/etc - unless we want
a monolithic package).  Some of course go to Gentoo practices, some of
which cause pain outside of python.

In particular it seems like many still don't understand when
revbumping is necessary.  I'd have to dig up the wording of the actual
decision but as I recall when the Council made the decision they
wanted to leave a bit of room for maintainer discretion, trusting that
maintainers would use it properly.  An alternative proposal was to
just make a strict rule that would have erred on the side of QA, at
the cost of extra rebuilds for users (but at least consistent ones
that didn't break package managers).  Obviously developers can't
exercise proper discretion if they don't fully understand the impacts.
If in doubt a revbump should always be safe, just at the cost of some
rebuilds (which are probably cheap for python packages).

-- 
Rich



Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-01 Thread Rich Freeman
On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt
 wrote:
>
> > git log --format=oneline glibc-2.29-r2.ebuild | grep stable
> >
> How well does git handle that when the ebuild is deleted from the tree?
>

git log --format=oneline -- glibc-2.29-r4.ebuild
23d1c015230d9ff44bcdd7b72e00ca3533815fa4 sys-libs/glibc: drop old
f3872a506edc7da0d987bcf0a90d4709945328a7 sys-libs/glibc: restore strip
quirk for 'libpthread.so.0'
650d70eb5d91265329e2f730bc1aed0fa5863db6 sys-libs/glibc: disable
stripping for cross-glibc
e14229b10b513a164f8379ff14cc8c644c071f27 sys-libs/glibc: drop
prepallstrip, bug #587296
fb2fe75af62ad29a44aeba1b8e9e41ce5acb3992 sys-libs/glibc: Add 2.29
revision with compile-locales support

I was too lazy to find something that had stable keywords, but I'm
sure substituting the appropriate filename and grepping would work
fine.  The trick is to put the "--" in the command line.

However, you could hardly be blamed for hitting your head against the
wall trying to figure out how to do this.  I had to google it as I've
run into this myself.  As many have said git is an amazing data model
with a terrible UI.

-- 
Rich



Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-01 Thread Rich Freeman
On Fri, Nov 1, 2019 at 4:36 PM Matt Turner  wrote:
>
> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
>  wrote:
> >
> >
> > Therefore, it would be much /more/ useful to have the package-version
> > tagged in the commit message, so that you could easily grep logs for when a
> > given version of a package was stabilised, and/or keyworded.

git log --format=oneline glibc-2.29-r2.ebuild | grep stable
9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc
stable, bug 685818
b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable
2.29-r2 for hppa, bug #685818
fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable
wrt bug #685818
0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt
bug #685818
7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable
wrt bug #685818
bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha stable
2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable
wrt bug #685818
e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable
wrt bug #685818
52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable
wrt bug #685818
745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable
wrt bug #685818
332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable
(bug #685818)
9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable
(bug #685818)
b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable
wrt bug #685818

Seems to work fine for me.

>
> In the past people have argued that the version in the title is
> superfluous since you can get the same info from git (log|show) --stat
> but the same (misguided argument) can be used to justify something
> absurd like simply making the bug number the subject.

I don't think these are at all equivalent.  The current state just
relies on finding version history in git, which is basically the main
purpose git serves.  Your example involves joining two disparate
datasets, neither of which natively offer an SQL-compatible interface.

I think the rationale for not putting more mandatory content in the
commit summary was that its length is limited and the more boilerplate
we cram in there, the less room we have for meaningful description,
when the boilerplate is already easily searched using git (though
admittedly not from changelog extracts).  Sure, for stable/keyword
changes there isn't much in the way of description to worry about, but
for other changes I suspect that this could be limiting.

>From GLEP 66: The summary line must not exceed 69 characters, and must
not be wrapped.

In the example I cited the longest summary is already 59 chars:
sys-libs/glibc: Fix handling of ${EPREFIX} when building cross-glibc

If you wanted to stick 7 more chars of PV info in there then we'd be
just 3 chars short of the limit, and this is just a randomly chosen
example.  Packages with longer PV certainly exist, along with ones
with longer summaries.

Personally I don't really care that much one way or another as long as
repoman is updated to follow any new standard, but this seems like it
could be impactful to people doing more complex work in the tree.  I
get that some people really seem to want to avoid using git, but this
is basically what it was made to do, and IMO seems like a step in the
wrong direction.  I think the main purpose of putting PN in there at
all was so that commits that hit multiple packages would be more clear
in logs.

-- 
Rich



[gentoo-dev] Re: [RFC] News Item: Desktop profile switching USE default to elogind

2019-10-28 Thread Rich Freeman
On Sun, Oct 27, 2019 at 10:19 PM Andreas Sturmlechner  wrote:
>
> Enter the elogind project [2], which is a standalone logind implementation
> based on systemd code, currently maintained by a fellow Gentoo user.

A few minor comments:

1.  While it is somewhat implicit in the headers, you might want to
mention in the text that this will not impact systemd profiles and
that those will just use logind.  It is a natural question people will
end up asking anyway.

2.  As evidenced in [1], many users probably have no idea what
consolekit, logind, or elogind actually do (or policykit/dbus and a
bunch of other modern desktop-oriented tooling that wasn't around back
when we were all editing X11 mode lines).  You might want to just toss
in a sentence or two to explain that as background, since people are
going to worry especially with the dreaded s-word in there.  Or find
some website that explains what it is reasonably well and link it with
a note in the text...

1 - 
https://archives.gentoo.org/gentoo-user/message/8dae2579be22c206d0f4bded84154f2d

-- 
Rich



Re: [gentoo-dev] New distfile mirror layout

2019-10-22 Thread Rich Freeman
On Mon, Oct 21, 2019 at 12:42 PM Richard Yao  wrote:
>
> Also, another idea is to use a cheap hash function (e.g. fletcher) and just 
> have the mirrors do the hashing behind the scenes. Then we would have the 
> best of both worlds.

I think something that is getting missed in this discussion is that we
don't control all of our mirrors, and they're generally donated
resources.  Somebody has some webserver, and they stick a Debian
mirror in one directory tree, and an Arch one in another, and they're
kind enough to give us one too.

That is why we're seeing odder situations like ntfs and so on being
mentioned.  They're not necessarily even running Linux, let alone zfs
or some other optimized filesystem.  And their webserver might be set
up to do browsable directory indexes which could perform terribly even
if the filesystem itself is fine with direct filename lookups.  It
doesn't matter if you have hashed b-trees or whatever for filename
lookups if you're going to ask the filesystem to give you a list of
every file in a large directory - it is going to have to traverse
whatever data structure it uses entirely to do so.

If we want to start putting requirements on hosting a mirror, then
we'll end up with less mirrors, and with mirrors more is usually
better.  Ideally a mirror should just be a black box to us - we don't
really care what they're running because we don't depend on any mirror
individually.  Likewise if we negatively impact mirror hosts we'll end
up with less mirrors.  Sure, maybe those hosts have odd
configurations, but we're still better off with them than without.
That said we do seem to have a lot of mirrors so it probably isn't the
end of the world if we lose a limited number.

And there is nothing to say that we can't have some infra mirror set
up more for interactive browsing that we don't have people fetch from
but which dispenses with all the hashing or which bins by the first
letter of the filename/etc.  It seems like most of the use cases where
hashing is inconvenient are for more casual use.

To avoid another reply, people are talking about having utilities that
can fetch distfiles using the new scheme.  I'd think that "ebuild
foo.ebuild fetch" is probably the simplest solution for this.  Chances
are that you're dealing with SRC_URI strings that have variable
substitution in them anyway, so just letting ebuild do the fetching
means you're not substituting ${PV} and so on, let alone all the stuff
versionator and its ilk do.  And of course you can always just fetch
from upstream anyway if you do have a clean URI.

-- 
Rich



Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

2019-10-08 Thread Rich Freeman
On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka  wrote:
>
> On 10/8/19 7:21 AM, Andreas K. Huettel wrote:
> > In any case, since many people *do* rely on it, maybe we should declare it
> > official? [+]
> >
> > And, if that's OK with both of you, move it onto infra hardware?
> >
> > Happy to sponsor both for the next council meeting agenda.
> >
> >
> > [+] At some point the one remaining whiner doesnt count anymore.
> >
>
> In the past, infra has been understandably hesitant to take on new
> services due to staffing issues.
>
> Additionally, I understand that the current infra design does not easily
> allow granular access control, preventing non-infra members from easily
> performing maintenance on individual services.
>
> Has this situation changed? I doubt infra want to take responsibility
> for the bot, and I don't fancy the hassle of trying to find people to
> poke things on my behalf.
>

IMO we should have a few tiers:

1.  Absolutely core stuff that infra has to run (authentication, LDAP,
maybe some services, etc).
2.  Community-run stuff that is FOSS, with public config tracking
(minus passwords/etc), and reasonably good docs.
3.  Community-run stuff that is the wild west.

IMO having a service catalog that includes all of this stuff is
beneficial, with clear indications as to which tier each thing is in
and who to contact with issues.

Depending on #1-2 shouldn't really be a problem.  #3 can be a
playground for experimentation but shouldn't be something we really
depend on for core workflow.  To mitigate the risk of #2 we could have
exercises to clone services following docs/etc.  If anything #2 has
the potential to be more reliable than #1 if it gets enough attention
(though there is no reason our internal services couldn't also be made
easy-to-replicate).

I think the issue here is that we don't really have any standards for
#2, but it is clear that this particular bot is intended to meet those
requirements but doesn't quite do so today.

I think this is a compromise that could help us focus our infra
resources where they're needed most, with some separation of concerns.
Ideally we should also make it possible via single-sign-on
technologies to leverage infra's authentication services for stuff in
tier 2, and maybe tier 3.  Biggest risk is phishing if somebody spoofs
a sign-on page.

-- 
Rich



Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-22 Thread Rich Freeman
On Mon, Jul 22, 2019 at 8:35 AM Kent Fredric  wrote:
>
> Though I suspect *literally* using USE flags for this as-is might be
> the wrong approach, as that just causes user-side pollution :/
>

Maybe in some other situations this might be true, but as I mentioned
in my previous email, users who DO want to build their own manpages
wouldn't want to use the pregenerated ones.  Also, packages that have
them need to know on the user side so that they can fetch them.  So,
there is a relationship between packages that need to have manpages
pregenerated and the package manager.

-- 
Rich



Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-20 Thread Rich Freeman
On Sat, Jul 20, 2019 at 4:22 PM Michał Górny  wrote:
>
>
> Yes, I get it.  User experience is not important if it would mean
> developers would actually do anything but the bare minimum to get
> from one paycheck to another.  The usual Gentoo attitude.
>

Not sure where I go to sign up for those paychecks.  However, even
employers have to accept that policies have a resource cost to them.

Requiring people to do more than the bare minimum often just ensures
that they won't even bother to do the bare minimum.  I'm all for
finding ways to standardize things so that everybody benefits at a
very low cost.  This doesn't seem that, and honestly requiring
packages to bundle pre-built manpages seems a bit non-Gentooish to
begin with.

-- 
Rich



Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-20 Thread Rich Freeman
On Sat, Jul 20, 2019 at 2:28 PM Michał Górny  wrote:
>
> Could you please read the proposed policy?  It explicitly says you are
> *not* supposed to force extra deps on users but build manpages for them.
>

This seems like a significant increase in maintainer effort compared
to just leaving things as they are for very little benefit.  Simple
revbumps turn into needing to do a separate build just to build the
manpages, then package those up, host them somewhere, then fetch and
install that from the ebuild.  It would be easier to just make the
whole package a binary package since then all the logic happens
outside the ebuild, and all the ebuild does is fetch/install a
tarball, which it would have to do anyway just for the manpages.

Most packages with stable build systems take almost no effort to
revbump, and this would add a fair bit of complexity.  I suspect that
you'll find far more maintainers stop going to the trouble to strip
out the dependencies needed for building manpages vs maintaining two
build systems in parallel, with one having no place to host it.

Then whenever a maintainer disappears the package goes to
maintainer-needed, and anybody who wants to touch it has to figure out
how to build the manpages likely without the benefit of any scripts
the original maintainer had lying around.

If we REALLY wanted to do something like this it seems like it would
be better to build some tooling around it.  Maybe an eclass combined
with a special USE flag like "man-build".  A daemon would check for
packages that have this IUSE and would build the package using it,
which will generate the manpages.  It would then store those pages
using a standardized naming convention.  The ebuild would inherit the
eclass which would check if man-build was set, and if not it would
automatically fetch and install the manpages built by the build server
from the mirrors.

Then ebuilds that currently have IUSE=man would just inherit the
eclass and change to the man-build flag.  That flag would only be used
by the build servers and not by end users, unless they wanted to build
their own manpages from scratch, which would work fine, as the flag
would not suppress building the rest of the package.

Really though I don't see THAT much benefit from doing either.

-- 
Rich



Re: [gentoo-dev] rfc: making sysvinit optional

2019-07-11 Thread Rich Freeman
On Thu, Jul 11, 2019 at 1:22 PM William Hubbs  wrote:
>
> On Thu, Jul 11, 2019 at 12:46:02PM -0400, Rich Freeman wrote:
> > On Thu, Jul 11, 2019 at 11:56 AM William Hubbs  wrote:
> > >
> > > On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote:
> >
> > If somebody just installs openrc their expectation is going to be that
> > they get sysvinit or your substitute that actually works with openrc
> > out of the box.  They're not going to want to have neither installed
> > simply because they have runit or systemd already installed.  If
> > somebody is migrating from systemd to openrc that is exactly the
> > situation they would be in.
>
> And this would be handled by virtual/init and virtual/service-manager...
>
> If you are migrating, you would definitely want to be careful with
> --depclean until you knew exactly what you wanted to remove or make sure
> everything is in your world file that you don't want removed.
>

What value is virtual/init adding though?  You don't have to be
careful with migrating if you don't use it.  You get no benefit from
using the virtual instead of just depending directly on sysvinit,
because that is the only package in the virtual that provides a
reasonable init implementation for openrc to use.

Yes, we can add that extra layer and then half the time it doesn't do
anything and the other half the time it automatically does what the
user doesn't want it to do, and users can work around it.  What it
won't ever do is make it easier to do what the user actually wants to
do.

If you do create a virtual/init then I'd just limit it to stuff that
provides a generic sysvinit implementation that will easily work with
any other service manager.  I'd argue that is sysvinit, and maybe
busybox[make-symlinks].  Maybe your openrc init implementation does,
but I haven't looked at it.  The rest simply don't provide an init
that is designed to be used with an arbitrary service manager.

Maybe to look at it another way: is this actually fixing a problem
that anybody is concerned about?  It just seems like it is giving
portage freedom to shoot the user in the foot, for little real gain.

-- 
Rich



Re: [gentoo-dev] rfc: making sysvinit optional

2019-07-11 Thread Rich Freeman
On Thu, Jul 11, 2019 at 11:56 AM William Hubbs  wrote:
>
> On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote:
> > On Wed, Jul 10, 2019 at 11:02 PM William Hubbs  wrote:
> > >
> > > > RDEPEND="sysv-utils? ( !sys-apps/sysvinit )
> > > >  !sysv-utils? ( sys-apps/sysvinit )"
> > >
> > >  I like this, but the second branch (!sysv-utils) is not really needed,
> > >  because if we put sysvinit as the first RDEPEND of virtual/init, we
> > >  don't need to worry about installing it through rdepend in openrc.
> >
> > Does openrc actually work with all the stuff you have in your proposed
> > virtual/init?
>
>  Remember that OpenRC wasn't originally an init process at all. it was
>  designed to work with any init process you want it to work with. That
>  hasn't changed, I've just added an init to it which you can use if you
>  want.
>
> > For example, you have systemd in there.  I'm pretty sure you can't use
> > systemd as PID1 and then use openrc as your service manager.  I mean,
> > you probably could come up with some way to do that, but certainly
> > openrc doesn't work that way today, or systemd for that matter.
>
> There is nothing stopping you from that on the openrc side. It would
> take a lot of custom systemd units to make it work, but that is an
> exercise for the reader.
>
> > You have runit in there as well.  Can you use runit as PID1 and openrc
> > as your service manager?
>
>  Sure. There's no reason you can't.

I'm not talking about hypotheticals.  Sure, somebody could completely
dispose of the default set of systemd units and whatever runit uses as
its equivalents, and create new ones that invoke openrc and have it
take over, maybe, but none of this stuff actually exists right now.
And I'm not sure how easy it would be to even get this working since
systemd will still be trying to manage cgroups and whatever else that
openrc will presumably also be trying to do.

If somebody just installs openrc their expectation is going to be that
they get sysvinit or your substitute that actually works with openrc
out of the box.  They're not going to want to have neither installed
simply because they have runit or systemd already installed.  If
somebody is migrating from systemd to openrc that is exactly the
situation they would be in.

Neither systemd nor runit presume to be a drop-in replacement for
sysvinit to be used with other service managers.  Maybe you could
mangle it into something like this, but at that point you might as
well add python or bash to your virtual/init since you could just
write your own script for init.

My goal isn't to block user choice here - just to not just make it
trivial for users to get their system into non-working conditions to
support a configuration that nobody in their right mind is likely to
actually care to use.  I can't see the folks torn between Devuan and
Gentoo saying that they're interested in using Gentoo with openrc but
they've seen the light and it makes sense to use systemd as their PID1
with all its dbus dependencies just so that it can do nothing more
than run a few bash scripts to launch openrc.

I'd just stick with a direct conditional dependency on sysvinit.  That
is the only config that actually works with openrc reliably today.
Now, if somebody comes up with a nice openrc wrapper for runit or
systemd or whatever, then maybe add that wrapper to a virtual and
revisit the issue, and then the wrapper can pull in the init
implementation.  Then users still get a working config no matter how
portage resolves the virtual.

-- 
Rich



Re: [gentoo-dev] rfc: making sysvinit optional

2019-07-11 Thread Rich Freeman
On Wed, Jul 10, 2019 at 11:02 PM William Hubbs  wrote:
>
> > RDEPEND="sysv-utils? ( !sys-apps/sysvinit )
> >  !sysv-utils? ( sys-apps/sysvinit )"
>
>  I like this, but the second branch (!sysv-utils) is not really needed,
>  because if we put sysvinit as the first RDEPEND of virtual/init, we
>  don't need to worry about installing it through rdepend in openrc.

Does openrc actually work with all the stuff you have in your proposed
virtual/init?

For example, you have systemd in there.  I'm pretty sure you can't use
systemd as PID1 and then use openrc as your service manager.  I mean,
you probably could come up with some way to do that, but certainly
openrc doesn't work that way today, or systemd for that matter.

You have runit in there as well.  Can you use runit as PID1 and openrc
as your service manager?

If the only init implementations that openrc actually works with are
sysvinit and its own init, then I'd just do it the systemd way.  The
init virtual only adds value insofar as these other packages actually
provide an init that any other service manager could actually use.

If openrc works with busybox init/etc I could see an argument for
maybe having a virtual that can pull in either, though in that case it
might make sense to use that in systemd as well.

> We
>  can also add sys-apps/openrc as an rdepend of sys-apps/sysvinit
>  possibly. I'll take a look at that.

I think it makes more sense to have a service manager pull in a
compatible PID1 rather than the reverse.  For example, systemd can
pull in sysvinit for access to shutdown/telinit/etc but it makes no
sense in that case to force openrc to get installed.  You could even
use sysvinit without any other service manager.

-- 
Rich



Re: [gentoo-dev] rfc: making sysvinit optional

2019-07-10 Thread Rich Freeman
On Wed, Jul 10, 2019 at 8:03 PM William Hubbs  wrote:
>
> On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote:
> > On 7/10/19 7:16 PM, William Hubbs wrote:
> > > 3. add a sysvinit use flag to openrc, which will be off by default. When
> > > it is on, openrc will block sysvinit since it will provide /sbin/init
> > > and /sbin/shutdown.
> > >
> >
> > This logic, or maybe the name of the flag, sounds backwards to me. I
> > only get sysvinit when USE=sysvinit is NOT set?
>
> If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> and /sbin/shutdown as they are now, from sys-apps/sysvinit.
>

Systemd already has IUSE=+sysv-utils which has a similar function:
[-  ] sysv-utils
sys-apps/systemd: Install sysvinit compatibility symlinks and
manpages for init, telinit, halt, poweroff, reboot, runlevel, and
shutdown

RDEPEND="sysv-utils? ( !sys-apps/sysvinit )
 !sysv-utils? ( sys-apps/sysvinit )"

sysv-utils seems like a generic enough flag and I'd suggest that it
would be appropriate to use for openrc as well if it can install its
own implementation of these tools.

(For those who aren't aware, systemd is compatible with the sysvinit
versions of these tools, so you can run systemd with sysvinit
installed.)

-- 
Rich



Re: [gentoo-dev] Gentoo on Discord

2019-04-30 Thread Rich Freeman
On Tue, Apr 30, 2019 at 1:22 PM Kristian Fiskerstrand  wrote:
>
> It matters if things are perceived as official Gentoo and causing a
> negative reputation as in the article in this thread. One some level
> that actually goes to trademark infringement that should be of interest
> to the foundation, but the issue is broader than that.
>

While I don't speak for the Foundation, they already have a fairly
decent policy addressing this:
https://www.gentoo.org/inside-gentoo/foundation/name-logo-guidelines.html

I believe this really only applies to use outside of Gentoo, and not
internal use.  Whether a service like a Discord site falls under
internal use probably depends on the degree to which they are
completely subject to Council/Trustees/etc, and the social contract
and code of conduct as enacted by those bodies.

For non-internal use the name/logo guidelines already have
requirements around reputation and code of conduct.  You can't just
call yourself "Gentoo" and do whatever you want (not that I'm implying
that this is what any particular site is doing - I haven't even seen
the discord).

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread Rich Freeman
On Thu, Apr 25, 2019 at 6:29 PM Kristian Fiskerstrand  wrote:
>
> On 4/26/19 12:26 AM, Rich Freeman wrote:
> > I mean, I'd expect any Gentoo dev to be able to figure out how to use
> > git as well, but git also has a terrible command line interface,
>
> Not really, it is quite intuitive once you understand the basics.
>

So, I love git, and certainly understand the basics, and created a
python script to map/reduce our repo into a list of all unique files
in the history with their hashes and commit info to compare to cvs
during the migration.  I certainly think the command line is terrible.
How many different ways are branches identified in the various
commands?  git-am is a favorite whipping boy of many critics.  It is
just inconsistent from command to command, and some common things like
backing out one commit require arcane syntax.  Yes, it all makes sense
if you understand the data model, but it is hardly a clean interface.

I'm certainly not the first to say this, and it is not because of a
lack of git knowledge.  I suspect Linus himself would concur.  It was
a personal tool that scratched an itch that we're all stuck with
because it works well enough that nobody will want to create a new
interface.

gpg is the same.  Yes, the concepts are great once you understand them
(though the smartcard standard is needlessly limited).  The actual
command line interface is just painful to use if you're doing more
than just encrypting/signing something.  If you want to use something
other than your default key you pass --default-key, which seems odd,
since you don't really want to change your default, and there isn't
any way to pass a "non-default" key.  I get having a default key
option in a config file, since that is what it describes.  And then
there is all the interactivity, which makes sense to have as an
option, but not without a command line override.  I mean, the FTP
interactive console also makes sense but there is a reason everybody
uses curl/wget/etc, and not FTP+expect.

> >
> > Personally I think we ought to make it easier to just use the
> > Nitrokeys we spent all this money on in a more secure manner than just
> > leaving primary keys lying around on hard drives,
>
> The decisions involved are disjunct here, but leaving around on
> hard-drives is generally a bad idea irrespective of any nitrokey, and
> certainly something expected not to happen from a Gentoo Dev to begin
> with (for primary key material at least)

IMO this is quite naive.  The desire to store it offline isn't even
documented in the GLEP, nor is it enforceable.  I get that some people
like to care for their gpg keys the way other people like to wax their
cars, but not everybody signed up as a Gentoo dev so that they have an
excuse to participate in a WoT.

And I think that the practical side of security is VERY relevant here.
My argument is that having a single primary+signing key generated on a
smartcard is more secure than having a separate primary+signing key
stored on an internet-connected PC hard drive.  And yet the first is
forbidden by the GLEP and the second is allowed.  The fact that you
can't conceive of somebody using gpg in basically the most
out-of-the-box way available doesn't mean that this isn't how most
devs would actually do it.

The integrity of this entire exercise is as secure as the dev who
takes the least care to secure their keys, not the one who takes the
greatest care.  IMO it is in the interests of security to create a
process that is both convenient and secure, and I think that keys
generated on a smartcard achieve a better balance of this than other
alternatives allowed under the current policy.

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread Rich Freeman
On Thu, Apr 25, 2019 at 5:54 PM James Le Cuirot  wrote:
>
> if I understood it correctly, it only removes the primary private key
> from the online copy and not the entire primary key. The --list-keys
> option shows an [SC] primary with an [E] subkey and an [S] subkey and I
> gathered from a conversation in #gentoo-dev that this is correct. Are
> you suggesting the [SC] primary should not appear here at all?

No, the public key should remain in your keychain.  It is, after all,
public, so there is no risk of compromise.  You really want it to be
published as widely as possible actually to reduce the risk of
somebody using the wrong key.

>
> > Secondly, the reason for that is not (just) to have a backup
> > but that the primary private key gives you virtually unlimited control.
>
> Are you contradicting yourself here? You explained why the private key
> must be kept secure but you didn't say anything about the rest of the
> primary key.

The only keys you need to secure are the private keys.  These keys are
created in public/private pairs always.  In the case of our GLEP we
have three pairs: a primary, a signing, and an encryption.  The
signing and encryption pairs are referred to as subkeys, but this is
just a convention - mathematically they work exactly the same.
Ideally you want all your keys to be secure, but the concept of having
tiered keys is that you can keep the primary in a safer place, since
it can be used to invalidate and issue new subkeys, and thus you don't
have to completely replace the trust chain if one key is compromised.

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread Rich Freeman
On Thu, Apr 25, 2019 at 4:55 PM Kristian Fiskerstrand  wrote:
>
> Quite frankly I'd expect a Gentoo Developer to be able to manage the gpg
> interface.
>

Being able to is not the same as caring enough to be bothered with
it...  I don't want to custom-tailor my Gentoo key.  I just want to
generate a key that will make the commit scripts happy.  The key is
completely disposable from a personal standpoint - when the GLEP was
recently revised to make my old key no longer valid, I just generated
a new one.  I didn't even bother revoking the old one, since it had no
function as soon as I changed the fingerprint in LDAP.

I was generating PGP keys back when it used idea and I'm guessing md5.
I've had gpg keys for decades.  I used my personal one for Gentoo
until the point where there were specific requirements for a Gentoo
key, and rather than try to personally live with the Gentoo
requirements it makes far more sense to just generate a
Gentoo-specific key.  Then we can change the GLEP as often as we like
it it really doesn't bother me much.  I can just discard my key and
create a new one, though it would be nice if those creating the GLEPs
would actually document the simplest way to do this for those who
really can't be bothered to read the man page.

I mean, I'd expect any Gentoo dev to be able to figure out how to use
git as well, but git also has a terrible command line interface, so
rather than put a bunch of requirements in a document and force
everybody to dig through manpages to get it to generate signed
commits/pushes/etc we just give a handy workflow.  After all, our goal
is to maintain the repo, not spend all day independently decipering
how to sign pushes or figuring out that a commit sig and a push sig
are two different things.

Personally I think we ought to make it easier to just use the
Nitrokeys we spent all this money on in a more secure manner than just
leaving primary keys lying around on hard drives, which is where I
suspect the vast majority will reside, completely negating the expense
the Foundation and Nitrokey both went through to provide them for us.
While I'm all for GLEPs themselves sticking to specs, having a
workflow document to go along with it would go a long way to helping
devs to comply, rather than spending all our effort writing
increasingly clever scripts to yell at them when they aren't
complying.

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread Rich Freeman
On Thu, Apr 25, 2019 at 4:34 PM James Le Cuirot  wrote:
>
> On Thu, 25 Apr 2019 11:30:27 -0400
> Alec Warner  wrote:
>
> > > Seeing as separating the primary and the signing key has been part of
> > > OpenPGP best practices for a long, long time, I have got highly mixed
> > > feelings about this statement. On the one hand, it is not reasonable to
> > > expect someone with no or minimal prior knowledge of OpenPGP to master
> > > it overnight. On the other, we are not just some random people from Teh
> > > Intarwebz and we *have* been using OpenPGP signatures on commits for
> > > quite a while now.
> > >
> >
> > This is untrue though; we *are* random people from teh interwebs.
> >
> > I store my primary key on my desktop.
> > I don't have copies of my primary key.
> > My primary key is protected by a passphrase.
> > Most of the time its cached in gpg-agent, so the passphrase is easily
> > stealable by local attackers.
> > I've been a dev for like > 10 years.
> >
> > I assume that every other dev does the same. Obviously some do not (and
> > I've spoken to many who have better practices) but I assume
> > people do the lazy / easy thing and I highly recommend this assumption. If
> > you assume that people have your security practices, you should prepare to
> > be disappointed.
> >
> > Many devs have *no idea* how GPG works.
> > GPG is quite possibly the worst program I've even been forced to use in
> > terms of doing any operation, particularly around setup (hmm maybe Imation
> > Ironkeys were worse?)
> > Many devs are just following the wiki instructions and get what they get.
>
> I can sort of echo this. I believe I'm close to the recommendations now
> but it took me several evenings to actually wrap my head around all
> this and even then, I still felt very nervous setting it up and I had
> to rehearse it beforehand. As a professional software engineer for many
> years, it really shouldn't be this hard. People talk about GPG best
> practices but it was really difficult to find a reliable update-to-date
> guide and it certainly doesn't feel like best practise when you have to
> manually delete ~/.gnupg/private-keys-v1.d/KEYGRIP.key, where KEYGRIP
> is returned by the obscure --with-keygrip option.

I think a big problem is that gpg is sorely lacking in command line
commands/options for key management.  Almost anything having to do
with key management involves a back-and-forth console interaction.

This means that you can't just tell somebody to run "gpg --long --list
--of --options" and have it just do the right thing.  You also can't
script anything unless you feed input or even worse use something like
expect.  Some of the guides I've seen require editing config files
because presumably these options can't be set on the command line.

I completely get what asymmetric crypto is.  It is just a royal PITA
to actually get gpg to do something very specific like have a separate
signing key without pouring through manpages.  Generating a key with
the default options is easy, but after that you're on your own
largely.

Oh sure, once you know how to do it then it isn't a big deal.  Until
you have to do it again because you don't generate new gpg keys every
other week...

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread Rich Freeman
On Thu, Apr 25, 2019 at 7:57 AM Marek Szuba  wrote:
>
> On 2019-04-24 20:34, Rich Freeman wrote:
>
> > The only reason to have a separate primary key is to have an offline
> >  copy,
>
> Not quite. First and foremost, you don not want to have an offline copy
> of the primary private key - you want to have the primary ENTIRELY
> offline.

Agree, I could have said that better.  Though, to be clear the primary
key needs to be on a PC anytime you use it, which includes time of
generation and renewal.  Typically this PC will be online.

> > So, maintaining this requirement with a Nitrokey means that we in
> > reality have the primary key online most of the time,
>
> Seeing as separating the primary and the signing key has been part of
> OpenPGP best practices for a long, long time, I have got highly mixed
> feelings about this statement. On the one hand, it is not reasonable to
> expect someone with no or minimal prior knowledge of OpenPGP to master
> it overnight. On the other, we are not just some random people from Teh
> Intarwebz and we *have* been using OpenPGP signatures on commits for
> quite a while now.

IMO this has nothing to do with knowledge, and everything with risk
tolerance and incentives.

Generating a key on a smartcard is practically a one-liner and is
convenient.  It is also VERY secure.

Now, if you're going to have a completely offline PC that never gets
connected to the internet, and use that for key generation, and treat
any media used to transfer keys as if you're working on a classified
software project, then sure, that would be more secure.  It is also a
LOT less convenient.  I'd argue that most devs who understand how to
use GPG fairly well would not bother with this.  I've never kept a
primary key offline and I was using PGP back when you had to be
located in the US to download it from the original official source.

>
> > when if it were the same as the signing key then both would be
> > offline in the Nitrokey.
>
> Using a hardware security device is not the same as making the key
> offline - especially given that the Gentoo NitroKey workflow as
> currently posted on the Wiki suggests disabling forcesig, which could
> effectively leave the signing private key unlocked for extended periods
> of time.

I'm all for revising this, but it isn't part of the GLEP.  Maybe it should be.

A smartcard is a practical compromise.  It gives a great deal more
security than online keys, while being convenient.  Sure, it might not
be the most secure approach possible, but it is far more secure than
approaches most are likely to actually use, even if they know better
options exist.

>
> > Also, by generating the key outside the Nitrokey it is exposed to a
> > far higher risk of compromise.
>
> As Kristian has already mentioned, in principle one could keep the
> primary private key on a separate token.

Sure, though this is definitely more cumbersome, and not a one-liner
in gpg for sure.  And last time I checked we're only issuing one
Nitrokey per dev, so it is unlikely many would do this.

>
> > In any case, I think it is far more likely that somebody generating
> > keys using software has a rooted box than somebody is going to come
> > up with a way to extract keys from a Nitrokey.
>
> You do not have to extract keys from a smartcard in order to be able to
> use keys physically present on it. All you have to do observe the
> smartcard user's PIN - either physically or using said rooted box - then
> nick the smartcard off them, ehich given that we are talking about keys
> that are supposed to be used on a regular basis might be very simple.

Sure, but this requires physical theft, which is a HUGE escalation of
effort.  IMO the most likely attack is some script kiddie on the other
side of the planet.

I mean, somebody could steal my ID and get into my work and go cause a
mess.  However this is extremely unlikely in practice.

If we were defending against the CIA or whatever I'd consider this a
more serious concern, but this isn't realistic, and we would need far
better standards to do that.

> Hell, if said smartcard contains the primary key you might even return
> it to them once you're done compromising them (e.g. by generating your
> own set of subkeys) and chances are pretty good that as long as
> everything keeps on working fine for them, it will take a quite a while
> before anyone notices.

I don't see how it differs whether the primary vs signing key is
stolen, unless you regenerate new signing keys frequently.  If you
keep just re-extending expiry on your signing key then that stolen key
will work forever.

And if you do generate signing keys often then the window of
compromise is the same either way.

-- 
Rich



[gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

2019-04-25 Thread Rich Freeman
The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that
are being distributed to Gentoo developers, do not support having a
separate primary/signing key for keys that are generated on the cards.
As a result they can only be used in accordance with our current
requirements if the keys are generated in software, which places them
at a higher risk of compromise.

The intent of the separate primary key is to reduce the risk of it
being compromised by keeping it offline.  However, if it were
generated on a smartcard it would be exclusively be maintained
offline, so it is counterproductive to require that it be generated
online and then recommend that it be kept offline after this.
Additionally this key needs to be brought back online anytime the key
expiration is updated, which is at least annually.

I believe this is creating a false sense of security, and that
developers should be encouraged to generate new keys using their
smartcards, so that these keys are never stored outside the protected
hardware.  By default gpg creates revocation certificates at this time
as well.  If a key is lost it can still be revoked, and of course the
gpg fingerprint associated with the developer can be changed in any
case and is the de-facto root of our trust system.  These failure
modes really are no different from an offline primary key that is
separate from the signing keys.

The revision adds an exception for keys generated on a smartcard.  It
does not prohibit those who wish to have separate keys from doing so,
though doing this with card-generated keys requires having two
smartcards.

An obvious objection I can see is that nobody will be able to tell
whether any particular key was generated on a smartcard or not.  While
this is true, it is also the case that there is no way to verify that
a primary key is being stored offline, or used on a non-compromised
PC, or that it even has a passphrase set.  Unless we want to use some
kind of hardware key that supports remote attestation we're going to
have to trust developers to be security conscious, and IMO making it
easy to generate keys on smartcards actually will facilitate security.
This change actually makes the more secure mode of operation simpler
than the less secure one (unless the primary key is kept online, in
which case it provides no benefit).

Full version online at:
https://gist.github.com/rich0/7d11e2297d8b8a5586997baec2a99e30

Patch follows:


diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst
index 5895873..86e5fd9 100644
--- a/glep-0063-v3.rst
+++ b/glep-0063-v3.rst
@@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo
Linux distribution.
 Changes
 ===

+v3
+  The requirement to have a separate signing and primary key was removed
+  in the case of keys generated/stored on smartcards, to encourage the use
+  of these keys, and acknowledging that the main use case for a separate
+  primary key is largely fulfilled by having all the keys stay offline.
+
 v2
   The distinct minimal and recommended expirations have been replaced
   by a single requirement. The rules have been simplified to use
@@ -69,7 +75,8 @@ not be used to commit.
at least 256-bit.  All subkey self-signatures must use this digest.

 2. Signing subkey that is different from the primary key, and does not
-   have any other capabilities enabled.
+   have any other capabilities enabled.  This requirement does not apply
+   if the primary key was generated on a smartcard.

 3. Primary key and the signing subkey are both of type EITHER:


-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-24 Thread Rich Freeman
On Wed, Apr 24, 2019 at 11:57 AM Kristian Fiskerstrand  wrote:
>
> On 4/24/19 4:19 PM, Rich Freeman wrote:
> > If it is the case that Nitrokeys can't support a separate primary key,
> > I'd suggest modifying the GLEP to remove that requirement when a
> > smartcard is in use.  Its main purpose is to keep a key component
> > offline, and if the key is generated on the card that is already
> > accomplished.  Maybe somebody has a suggestion for how to make the two
> > work together, otherwise I'll go ahead and suggest a GLEP revision for
> > the next Council meeting.
>
>
> The GLEP should not be changed on the requirement for distinct signing
> subkey, this is one of the expected results of it to begin with.

So, I intend to propose this.  Council is welcome to vote it down.
However, I'm really interested in what the concern is here.

The only reason to have a separate primary key is to have an offline
copy, but it is not a current requirement that it be kept offline, and
I suspect that 99% of devs won't keep it offline, and of course there
is no way to verify if this is being done anyway.

So, maintaining this requirement with a Nitrokey means that we in
reality have the primary key online most of the time, when if it were
the same as the signing key then both would be offline in the
Nitrokey.  This requirement effectively makes the key less secure in
practice.  It doesn't matter if the signing key is safely stored in
the Nitrokey if somebody can steal the primary key, since they can
just create a new signing key at will.  Also, by generating the key
outside the Nitrokey it is exposed to a far higher risk of compromise.

At best for the 1% of devs who would actually keep the primary key
offline then this achieves the same level of security you have with
the Nitrokey anyway, which always keeps its keys offline
(effectively).  The only exception to this would be an exploit in the
Nitrokey, which seems like a pretty low risk.  And of course it is
only a risk when the Nitrokey is plugged in, and the intent would be
for devs to only plug it in when working on commits.  In any case, I
think it is far more likely that somebody generating keys using
software has a rooted box than somebody is going to come up with a way
to extract keys from a Nitrokey.

Now, I think it is a great best practice which we should support for
anybody who wants to have their offline key-generation machine they
keep in a vault or whatever.  And by all means require the additional
key when using keys not generated on a Nitrokey.  As to how you can
tell which are which, I'd simply point out that you can't tell if keys
are being stored offline or not, so really your risk is unchanged in
taking devs at their word.

I think most companies issuing these sorts of tokens to users would
generate their keys on the tokens for these very reasons.  The reason
they're using these hardware tokens is because they know that users in
practice will not take extraordinary care to protect keys, and the
token provides a similar level of security with very little
inconvenience.  Really the only thing we're missing with the Nitrokey
is some form of attestation to ensure the keys are in fact generated
on the device.

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-24 Thread Rich Freeman
On Wed, Apr 24, 2019 at 10:25 AM Alon Bar-Lev  wrote:
>
> On Wed, Apr 24, 2019 at 5:19 PM Rich Freeman  wrote:
> > Well, in that case recommendations for how to generate a key that
> > complies in software would be helpful.  There used to be a wiki
> > article on it, but it is marked with various warnings saying it isn't
> > recommended to follow it, and has seemingly vanished with a note that
> > it moved somewhere.
> In the meantime, I think that you may find the following commands useful...
>
> $ gpg --expert --full-generate-key

Well, sure, but the part that comes after would be the key bit.

> $ gpg --expert --edit-key ${MASTER_KEY_ID}
> gpg> addkey

This bit is already covered on the Nitrokey guide.

In any case, I'll stick with the key I have for the moment until the
Council rules on the GLEP.  Neither key I have currently complies with
the current one so I'm generating a new one either way, unless the
GLEP changes.

-- 
Rich



Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-24 Thread Rich Freeman
On Wed, Apr 24, 2019 at 10:01 AM Marek Szuba  wrote:
>
> On 2019-04-24 13:41, Rich Freeman wrote:
>
> > What is the recommended way to create an on-card key?
>
> I haven't got my NitroKey yet but between the specifications (which say
> NK2 can hold up to 3 private RSA keys) and my prior experience with
> OpenPGP smartcards (which have always had at most one slot each assigned
> to authentication, encryption and signing), chances are pretty high you
> cannot have two separate signing keys in hardware. If so, your best bet
> is probably to generate the primary key in software (preferably with
> usage bits stripped down so that it can ONLY be used for signing keys),
> generate hardware subkeys associated with it, then stash the private
> primary key away somewhere.
>

Well, in that case recommendations for how to generate a key that
complies in software would be helpful.  There used to be a wiki
article on it, but it is marked with various warnings saying it isn't
recommended to follow it, and has seemingly vanished with a note that
it moved somewhere.

Aside from that, it seems a bit odd to issue devs Nitrokeys (at
significant expense to both the Foundation and a kind sponsor), then
require a key design that can't actually be stored on the Nitrokey.  A
Nitrokey-generated key is going to be way more secure than the way 99%
of devs will actually implement what seems to be intended, which is to
just generate their keys on a regular online host, and probably just
leave it there.

If it is the case that Nitrokeys can't support a separate primary key,
I'd suggest modifying the GLEP to remove that requirement when a
smartcard is in use.  Its main purpose is to keep a key component
offline, and if the key is generated on the card that is already
accomplished.  Maybe somebody has a suggestion for how to make the two
work together, otherwise I'll go ahead and suggest a GLEP revision for
the next Council meeting.

-- 
Rich



[gentoo-dev] Last rites: games-rpg/eternal-lands

2019-04-24 Thread Rich Freeman
Removing this one as the maintainer, but would be happy to work with a
proxy maintainer if somebody wants to take over.  I suspect it isn't
actually in-use...

# Richard Freeman  (24 Apr 2019)
# Masked for removal in 30 days.  Likely does not work
# and is essentially unmainted.  Please comment in
# bug 548926 if you want to give this some care.
games-rpg/eternal-lands
games-rpg/eternal-lands-bloodsucker
games-rpg/eternal-lands-data

-- 
Rich



[gentoo-dev] Last rites: games-rpg/eternal-lands

2019-04-24 Thread Rich Freeman
Removing this one as the maintainer, but would be happy to work with a
proxy maintainer if somebody wants to take over.  I suspect it isn't
actually in-use...

# Richard Freeman  (24 Apr 2019)
# Masked for removal in 30 days.  Likely does not work
# and is essentially unmainted.  Please comment in
# bug 548926 if you want to give this some care.
games-rpg/eternal-lands
games-rpg/eternal-lands-bloodsucker
games-rpg/eternal-lands-data


-- 
Rich



[gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-24 Thread Rich Freeman
I just generated a gpg key on my nitrocard using the default options,
as I could not find any other official recommendations for how to
create a key.  However, it appears that the default config uses the
same signing and primary key, and thus generates a warning when
pushing to the main repo.

What is the recommended way to create an on-card key?  Or is the only
supported way to do this to create a local key and then export it to
the card?  If so, what is the current recommended way to do that?

-- 
Rich



Re: [gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only

2019-04-02 Thread Rich Freeman
On Sun, Feb 24, 2019 at 3:35 AM Michał Górny  wrote:
>
> Following the recent mailing list discussion indicating that developers
> are taking GLEP 63 as only source of truth about OpenPGP keys, and can
> make assumption that if encryption key is not listed there they should
> not have one.  Amend the specification to extend it beyond the previous
> limited scope of commit signing, and require an encryption key
> appropriately.  This matches the GnuPG defaults.

Does GLEP 63 actually match the gpg defaults?  That is, if you
generate a gpg key and accept every default value will the key be
acceptable?

If not, could we get some updated documentation as to how to generate
a minimally compliant key, similar to:
https://www.gentoo.org/glep/glep-0063.html#bare-minimum-requirements

-- 
Rich



Re: [gentoo-dev] rfc: cron.* and modern cron implementations

2019-03-02 Thread Rich Freeman
On Sat, Mar 2, 2019 at 8:25 PM Michael Orlitzky  wrote:
>
> Using run-parts in /etc/crontab also has its problems, but I don't have
> a solution handy for that one. Using run-parts runs those daily, weekly,
> etc. jobs as root, which may not be what you want if you're operating on
> user-controlled data (e.g. bug 662438). The best way to solve this would
> be to let packages install their own crontab entries into a directory
> like /etc/cron.d, but that location isn't standard.
>

So, the problem with cron.d is that you're now using crontab syntax,
and for compatibility you have to use the lowest common denominator
which is vixie.

That means your jobs are STILL running as root, so the only problem
you had with run-parts isn't solved.

In addition you lose the ability to cover the desktop use case of
non-24x7 systems running infrequent tasks.  If you used vixie cron
syntax for a monthly job it might never run at all on a typical
desktop, as it would have one opportunity to run in a month, at one
time of day.

The crontab syntax also forces each package maintainer to pick the
time of day their jobs run at, vs just letting the sysadmin choose the
time the entire set of scripts is run.

I'm sure there are alternatives like adding a compatibility layer
(which is basically what run-crons already is), or some kind of helper
where an ebuild can give it a set of parameters and it installs the
task for whatever cron implementation eselect points it at.  I'm just
not sure that they are worth the complexity or provide much more value
than the existing solutions.  This is also somewhat orthogonal to
run-crons, where you still are left with the choice around whether to
use it with vixie or other implementations that don't support more
desktop-oriented use cases.

This is of course why that bug has been fairly intractable.

-- 
Rich



Re: [gentoo-dev] rfc: cron.* and modern cron implementations

2019-03-02 Thread Rich Freeman
On Sat, Mar 2, 2019 at 7:26 PM Michael Orlitzky  wrote:
>
> On 3/2/19 7:05 PM, William Hubbs wrote:
> >
> > Is there a reason we still use run-parts and the
> > /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron 
> > jobs?
> >
> > From what I read in the chat earlier, it sounds like the modern crons
> > might be able to handle this without that structure, but I'm not sure.
>
> https://bugs.gentoo.org/69777
>
> Totally. We should replace run-parts with something much simpler and
> more predictable. Then, if that doesn't work for you, all modern crons
> can do the things that run-parts tries to do, but better.
>

I'm not sure I see the connection here.  All run-parts does is run all
the scripts in a directory.  That seems pretty simple and
deterministic.

The bug is about cronbase, which contains run-crons, along with
installing the cron.d directories.  I could see an argument for
splitting that package though obviously the package is already pretty
simple.

I imagine most cron implementations do not use run-crons.  Whether any
particular one (like vixie-cron) should seems like a matter of taste.

Are we just talking about not having vixie-cron use run-crons?  And
instead having it just have time-scheduled jobs for run-parts on the
various cron.* directories?  That seems a bit narrower in scope than
what was originally suggested, though it isn't clear to me what is
being suggested...

-- 
Rich



Re: [gentoo-dev] rfc: cron.* and modern cron implementations

2019-03-02 Thread Rich Freeman
On Sat, Mar 2, 2019 at 7:05 PM William Hubbs  wrote:
>
> someone brought this up on the chat channel today, so I'm bringing it
> here to ask for information.
>
> Is there a reason we still use run-parts and the
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
>
> From what I read in the chat earlier, it sounds like the modern crons
> might be able to handle this without that structure, but I'm not sure.
>

Are you proposing getting rid of run-parts?   Or are you proposing
getting rid of /etc/cron.*?

run-parts is part of debianutils, and ca-certificates apparently uses
it, so trying to purge that might not go far.  I don't think it is
directly in @system so it would go away on its own if it wasn't used.
Some of the cron implementations also use it, and some don't, and each
one can pull it in as needed I suppose.

I don't think you can get rid of the cron.* directories, since that is
the least-common-denominator way for packages to install scripts for
cron to run.  If we wanted to do something else we'd probably need
some kind of eclass that knows how to install a cron script for any of
the various cron implementations out there.  We can't really even just
go to generic cron syntax for some kind of crontab.d handler because I
don't think that is standardized for tasks that are to run if their
scheduled time is missed.

I suspect that maintainers of cron implementations that don't require
run-parts probably already avoid using it.

Maybe you had something specific in mind that I missed?

-- 
Rich



Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

2019-02-22 Thread Rich Freeman
On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode  wrote:
>
> Ok, after setting that up portage wants to update pgp keys, which fail
> because keyservers suck.  It doesn't look like we can change the
> keyservers or disable the update entirely but we can set the retries to
> 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> the update but it doesn't look like it was applied.

I assume that it proceeds after some timeout?  Or does it completely
bail?  IMO failing successful makes more sense though it is less
secure.

It definitely makes sense to attempt a keyserver update since that is
going to be the mechanism to catch key revocations.  It also will make
life easier on users using an older stage3 that happens to have
expired keys.  Well, assuming the keyserver works...

-- 
Rich



Re: [gentoo-dev] AUTHORS file for portage repository

2018-11-27 Thread Rich Freeman
On Tue, Nov 27, 2018 at 5:49 PM Michał Górny  wrote:
>
> On Tue, 2018-11-27 at 16:01 -0500, Rich Freeman wrote:
> > On Tue, Nov 27, 2018 at 3:42 PM Kent Fredric  wrote:
> > >
> > > That git manages not to die every day based on what we throw at it is
> > > frankly a miracle of engineering.
> >
> > Our repo is a linked list being constantly manipulated from the head
> > backed by a hashed object store for the contents.  For that use case
> > it is probably the ideal data structure.  Since our use case is
> > actually the typical use case, it isn't a surprise that this was the
> > design that was chosen...  :)
> >
> > Computers are pretty fast when you actually use the correct algorithm...
> >
>
> Yes, computers are fast and their work is cheap.  On the other hand,
> humans are not fast and their time is expensive.  Now use the power of
> human thinking to infer this to what you're doing to this thread.
>

Not wasting everybody's time with personal attacks?

-- 
Rich



Re: [gentoo-dev] AUTHORS file for portage repository

2018-11-27 Thread Rich Freeman
On Tue, Nov 27, 2018 at 4:50 PM Matt Turner  wrote:
>
> Or, I don't know. Come up with something better and continue
> bikeshedding. I won't.
>

I think antarus already came up with something better - let Sony
explain its thinking, rather than trying to guess at what they're
trying to accomplish and whether it is something we want to support or
not.

Or just stick with what we've already been doing for the last 15
years, which is completely compatible with the new GLEP.

-- 
Rich



  1   2   3   4   5   6   7   8   9   10   >