Re: [gentoo-dev] Guidance on distributed patented software

2021-09-20 Thread Rich Freeman
On Mon, Sep 20, 2021 at 12:46 PM Alec Warner  wrote:
>
> Could we add some text to the license concepts covering patents? It
> seems to have been omitted?
> Is my understanding of how we manage patented software correct?

I think you have the gist of it.  Is there actually anything in the
repo these days which is patent-encumbered?  I realize this is a
little tangential, but I think this is probably why we don't have a
well-thought policy: it just doesn't come up much.

The situation comes up less often since everything is copyrighted by
default, but software patents in FOSS are relatively rare.  (Partially
because they're such a minefield that it discourages even creating
FOSS in the first place.  Partially because they're such a minefield
that people tend to favor non-encumbered algorithms for things that
are commonplace now.)

Things that used to be patent-encumbered that were prevalent in FOSS
in the past include:
1. The GIF file format.
2. FAT-based filesystems.
3. MPEG-related codecs (codecs might be a space where patents are
still relevant).
4. RSA

I'm sure there are others I'm not thinking of offhand.  All of these
helped drive adoption of more open standards, which is why we don't
run into this stuff as often.

Another topic like this are encryption keys like for DVDCSS and so on.
Those fall outside both copyright and patent law, but are legally
troublesome.  Then there are export controls like ITAR/etc - less of
an issue today but might still apply to some things.

-- 
Rich



Re: [gentoo-dev] [GLEP78] Updating specification

2021-09-13 Thread Rich Freeman
On Mon, Sep 13, 2021 at 5:02 PM Michał Górny  wrote:
>
> On Mon, 2021-09-13 at 12:08 +0200, Ulrich Mueller wrote:
> >
> > Also, IIRC one of the goals of the format was to allow partial
> > download
> > of metadata. That will only work if the Manifest file will be the
> > first
> > file in the archive (or at least appear before the image archive).
>
> I disagree.  This is solved by having detached metadata signature -- you
> can do a partial fetch and verify the metadata directly.
>

Another option I've tossed out there in the past is having a content
hash of the metadata and putting that in the filename.  That obviously
won't tell you anything about the contents of the file without reading
it, but if you're looking for a file with specific metadata you could
predict its filename.  This was intended to work with having multiple
hashes for the same file using subsets of the metadata, using symbolic
links.

The thinking here is that you'd just hash a subset of metadata useful
for identifying what file you'd want to download, such as CHOST,
linked dependency versions, use flags, etc.  You'd probably hash it
with/without stuff like use flags so that you could either take a shot
at getting the file exactly configured how you want, or accepting a
version with any set of flags.

Of course, this idea goes in direct opposition to your statement about
not wanting to specify the filename.  I get that argument.  The intent
here was to allow portage to go hunting through trusted repositories
to find packages it can use without having to sync a lot of data - if
you know the exact filename then a simple GET tells you if it is there
or not.

-- 
Rich



Re: [gentoo-dev] News item for eudev deprecation

2021-08-23 Thread Rich Freeman
On Mon, Aug 23, 2021 at 10:46 AM David Seifert  wrote:
>
> Let assume the counterfactual for a moment here: We retained the
> USE=systemd flag for all unit files and what not, so people can cleanse
> themselves of the systemd units etc. without resorting to INSTALL_MASK.
>
> How would USE=-systemd have prevented this situation? USE=-systemd would
> randomly mv and sed random files so the "systemd-" prefix doesn't show
> up?

So, I think using USE=systemd to control installing units is a bad
idea, for the same reason that it is a bad idea for controlling init.d
scripts.  It results in users having to rebuild half their system just
to get those files installed if they later need them.

However, the argument would be that if we had used USE=systemd to
control installing units, then users wouldn't set an INSTALL_MASK, and
thus when udev comes along it would still install everything just
fine.  I doubt we'd have it rename anything - the systemd- prefix
would still apply, but since there are no INSTALL_MASKs then it
wouldn't cause any issues.  The issue isn't systemd in the
filenames/paths, but users attempts to keep things from being
installed with those names/paths.

I'm not sure what exactly udev installs, but obviously install masks
might or might not cause harm depending on how specific they are.  If
they are just for "*systemd*" then that would be pretty likely to
clobber important stuff.  If it is just targeting systemd units in
/etc/systemd/system then that seems pretty unlikely to harm anything
if you aren't running systemd as your service manager.

I notice systemd installs udev to /lib/systemd/systemd-udevd and that
would be probably the path most likely to cause issues.  Most of the
rules are under /lib/udev and so on, and there are things in the
generic lib directories.  However, I'm using systemd and not the
standalone udev ebuild - it might do some things differently.

IMO if users really just want to get rid of unit files they're
probably better off masking /etc/systemd/system and
/lib/systemd/system.  Most of the other stuff in that path is
installed by systemd itself, which users won't have if they're not
using it.  I get that there are a lot of strong opinions in this area,
but the issues that can arise probably aren't worth the fuss except in
very extreme situations where every inode counts/etc.

-- 
Rich



Re: [gentoo-dev] News item for eudev deprecation

2021-08-23 Thread Rich Freeman
On Mon, Aug 23, 2021 at 10:36 AM Ulrich Mueller  wrote:
>
> > On Mon, 23 Aug 2021, Anthony G Basile wrote:
>
> >>> **WARNING**
> >>>
> >>> If you happen to have an INSTALL_MASK with a blanket "*systemd*"
> >>> glob, you will inevitably break your system. sys-fs/udev contains
> >>> "systemd" in some of its filenames, hence a blanket filter rule will
> >>> likely lead to a non-functional udev installation.
> >>
> >> Will an INSTALL_MASK of "/usr/lib/systemd /etc/systemd" cause any
> >> issues?
>
> > I have not tested, but I think so since "systemd-" is used as a prefix
> > for files installed by sys-fs/udev.
>
> So, we've abandoned the systemd USE flag, and I remember that one of
> the arguments was that users could use INSTALL_MASK for precisely the
> above mentioned directories.

Well, the argument is that we don't use USE flags to prevent packages
from installing small text files.  It is the same reason we don't have
an openrc USE flag to control installing init.d scripts.  We're now
talking about pretty far back in history but I think this was a
general guideline before systemd even came along.

> Now the message is that users' systems will be broken if they had
> followed our previous advice? Seriously?

Did we ever officially advise people to use INSTALL_MASK at all?  I
thought that was mostly a "you can keep the pieces if you break
things" option we provide.  IMO the risks of people misusing it are
far greater than the possible harm of having a few hundred small text
files installed on their system, but it is there if people really want
to use it.

However, having used the option in the past shouldn't hurt anybody.
It only impacts people if they use it when they install udev, hence
the news item.

-- 
Rich



Re: [gentoo-dev] About the 'eapi' file in profile directories

2021-08-02 Thread Rich Freeman
On Sun, Aug 1, 2021 at 5:54 PM Ulrich Mueller  wrote:
>
> Quoting ciaranm [1]:
>
> | > "EAPIs whose value starts with the string paludis- are reserved for
> | > experimental use by the Paludis package manager."
> |
> | Don't tell anyone, but that's mostly just in there because some people
> | insisted that EAPIs were numbers (and thus comparable), so I wanted an
> | explicit mention of one that wasn't.
>

The other aspect of it is that they cannot be assumed to be ordered.
You could at some point in the future have a branching hierarchy of
sorts where some EAPIs contain some features and others contain
others, with neither being a superset of the other even accounting for
deprecation.

I get that we haven't generally done that historically, but you
shouldn't be doing ordered/range/etc comparisons with EAPIs (ie "if
EAPI < 5 do this, else do that").  Such things should always be based
on explicit values ("if EAPI in (1,2,3,4) do this, else do that").

-- 
Rich



Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests

2021-07-25 Thread Rich Freeman
On Sun, Jul 25, 2021 at 11:23 AM Ulrich Mueller  wrote:
>
> We can reiterate when there are indications that SHA512 would be broken.
> (Then again, the same applies to BLAKE2B.)

Unless both are broken at the same time you'd also have the advantage
of not having to try to scramble to figure out whether anything was
compromised.  I get that typically hash functions are first broken in
a way that makes them very difficult to exploit, but that isn't some
sort of guarantee.  In the very unlikely event that somebody comes up
with a preimage attack against one of the functions, it would be even
more unlikely that an attack would be devised against both.

Sure, we're talking about low risks here, but we're also talking about
low cost and security.  When security is this cheap, why not have it?
I mean, if people didn't care about this stuff they wouldn't bother
migrating off of md5, and you'd have critical software like source
code control using broken hashes like sha1.

-- 
Rich



Re: [gentoo-dev] Declare the type of source

2021-06-28 Thread Rich Freeman
On Mon, Jun 28, 2021 at 11:58 AM Agostino Sarubbo  wrote:
>
> On lunedì 28 giugno 2021 17:07:57 CEST Michael Orlitzky wrote:
> > If the package declares a dependency on e.g. virtual/c-compiler, ago
> > would want to re-test it whenever a new version of any compiler is
> > released that satisfies virtual/c-compiler. Conversely, if the package
> > doesn't require virtual/c-compiler, we may assume that it doesn't
> > compile C code, and is not affected by the new version.
>
> I need to admit that your solution is more simplest because there is nothing
> to implement.
>
> We can create a new category (like virtual) called tinderbox, then for example
> we could have:
> tinderbox/c
> tinderbox/c++
> tinderbox/go
>
> and so on.
>
> Those tinderbox 'packages' added as DEPEND must not pull a default compiler or
> so, instead they will not pull anything.

This seems unnecessarily complex.  Why not make them REAL virtuals.
If your package depends on any C compiler then have it pull in
virtual/c-compiler (or whatever we want to call it).  If your package
depends on gcc explicitly, then just depend on gcc.  With the system
of empty virtuals you provide you then need to have logic for what the
virtuals "really" mean since they don't actually pull in anything, and
they're also useless for actual dependency-resolution as a bonus.

> They are there with the purpose of show the output of something like:
> equery depends tinderbox/c

The problem with this is that if something works with gcc and not with
clang, and clang changes, you test it anyway, because you have these
hard-coded definitions of what "c" is.  If you use real virtuals, then
you just find all the reverse deps of clang and that is what you need
to test, because they're just normal dependencies.

You don't actually have to implement the full removal of the @system
special logic to do this.  You can specify things that are in @system
as dependencies even if our policies don't currently require it.
Listing two paths to the same dependency doesn't hurt anything as far
as I'm aware.

-- 
Rich



Re: [gentoo-dev] Declare the type of source

2021-06-28 Thread Rich Freeman
On Mon, Jun 28, 2021 at 9:46 AM Michael Orlitzky  wrote:
>
> On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> >
> > Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or
> > similar, or in metadata.xml if you prefer ) and with a tool like equery/eix 
> > we
> > are able to get the list of all packages that compiles C code.
> >
>
> I think all you are really asking for is that we stop omitting a random
> subset of @system from *DEPEND.
>
> This is long overdue, for many reasons, but in particular it would
> force us to declare a dependency on a C compiler if one is needed and
> allow you to re-test only those packages that use a C compiler.

++ - this would also support parallel building of @system.

Obviously we'll still need a core set of packages needed for
bootstrapping/etc, but there is no reason @system couldn't just be
another virtual.

You could also have convenience virtuals for things like the C
toolchain and so on.  This will both support alternate implementations
and avoid having to have laundry lists of deps in every ebuild.

A simple way to transition would be to create a system virtual and add
it to all ebuilds, but ask that this be removed in future updates in
favor of more specific dependencies.  Over time then the tree would
move to specified true deps.  Catalyst could still use a virtual as a
target for bootstrapping stages.

Another tool that would be useful is what some other distros do - use
mount namespaces/etc to allow build systems to only see parts of the
filesystem (down to the file level) that are specified in
dependencies.  This would basically eliminate unspecified or automagic
dependencies, since anything not specified basically doesn't exist at
build time.  If you didn't want to use mount namespaces then our
sandbox already allows limiting read access to only specified files -
we just configure it to allow read-only to everything for every
package.

-- 
Rich



Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?

2021-06-16 Thread Rich Freeman
On Wed, Jun 16, 2021 at 11:42 AM Michał Górny  wrote:
>
> What is the point you're making?  If GF decides to kick you from Gentoo,
> will you also claim that it was their legal right?
>

IMO the lesson to be learned here is that we ought to design Gentoo in
such a way that if the GF kicks us all from Gentoo, it isn't a big
deal at all.  The reason everybody is all upset is that the Freenode
change WAS a big deal and has been difficult to work through.
Obviously it wasn't THAT big of a problem, but ideally we should be
more resilient and just take things like this in stride.

People get deplatformed all the time these days, often from multiple
platforms at the same time.  Anybody sane doing anything online should
just expect it to happen to them at some point.

-- 
Rich



Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?

2021-06-16 Thread Rich Freeman
On Wed, Jun 16, 2021 at 7:28 AM Michal Prívozník  wrote:
>
> On 6/16/21 11:21 AM, Ulrich Mueller wrote:
> >> On Wed, 16 Jun 2021, Michał Górny wrote:
> >
> >> We've moved our official support channels from Freenode to Libera.chat.
> >> All that's happened afterwards pretty much proves that this was
> >> the right decision.  Maybe even to the point of saying that staying
> >> on Freenode would be dangerous to our users (e.g. because of the late
> >> NickServ impersonations, ops with bad reputation etc.).
> >
> >> However, there are still IRC clients in Gentoo that default to Freenode.
> >> I think the next questions we need to answer are:
> >
> >> 1. Should we be proactively changing the default network in IRC clients
> >> (provided they have one) from Freenode to Libera.chat
> >
> > Yes. IMHO Freenode is no longer a reasonable default.
>
> Why should we mangle with packages this way? I mean, to me Gentoo was
> one of the few distros that allowed real choice for users (systemd vs
> openrc, selinux or !selinux, etc.). We shouldn't be making choices on
> behalf of users. The best we can do is to open issues for whatever IRC
> client we have in portage to switch from freenode to something different.

++

This makes about as much sense as changing the default homepage on
browsers or the default address book on email clients.  All of these
things are used to interact with Gentoo.

At this point I think it should be pretty obvious to anybody
connecting to Freenode that something has changed.  If our concern is
users getting bad advice there, perhaps we ought to have more devs
participate on the gentoo-user mailing list where we seem to hand out
plenty of bad advice daily?  :)

I think that some point we need to just call this done.  I was a
proponent of switching networks, but at this point it seems like every
FOSS org I'm in has some kind of daily Freenode drama going on.  Just
about everybody has switched - just call it a win already...

I'm sure there will be people on Freenode 10 years from now, probably
in many of these same channels.

FWIW many IRC clients are already taking these steps.  Connecting to
Freenode on my phone IRC client is a bit like connecting to my UniFI
controller at home using a browser...

--
Rich



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-27 Thread Rich Freeman
On Sat, Mar 27, 2021 at 5:43 PM Joshua Kinard  wrote:
>
> I kinda wish the Linux kernel had an ability to partially boot, init the
> networking subsystem, then fetch an initramfs image over TFTP like it can do
> with NFS Root.  That would solve the problem on my MIPS system(s) (and make
> install netboots better).  I've dug around, but this does not seem to be a
> capability currently in the kernel, unless I have over looked something.

Support exists, in the form of an initramfs.  Bear with me for a second.

An initramfs does not need to be large.  It is just software.  Sure,
they're often implemented in bash with all sorts of userspace tools in
the image, and that uses lots of space.  However, an initramfs could
be nothing but a small compiled binary and nothing else - a few
kilobytes even.

I'm not aware if anything like this has already been created, but you
could do something reminiscent of coreboot, and it would be
distro-agnostic.  Just build a minimal kernel with only support for
whatever you need to read a kernel and initramfs (from disk, network,
whatever).  Then build an initramfs that minimally fetches that kernel
- it could just be a tiny binary, or it could use tools like curl/etc.
Then you'd kexec the new kernel/initramfs which would do the full
boot, and this wouldn't have any size limitation.

An initramfs is just a way to automate the kernel boot process using
userspace code, vs needing to do a lot of fancy stuff in kernel space.
They can get a bit bloated when you make them full-featured/generic,
but if you just want a secondary bootloader you can shrink both the
kernel and the initramfs considerably, and use that to boot another
kernel.

If I were to look anywhere for something I could use out-of-the-box it
would be with coreboot.  That is a linux-based kernel/initramfs
designed to be a bootloader really.

-- 
Rich



Re: [gentoo-dev] rfc: usrmerge script

2021-03-24 Thread Rich Freeman
On Wed, Mar 24, 2021 at 11:09 AM William Hubbs  wrote:
>
> On Wed, Mar 24, 2021 at 08:48:41AM +0100, Michał Górny wrote:
> >
> > What really can help is reflinking on filesystems supporting that.
>
> What really can help is more info instead of being terse like this.
> Which filesystems support it?
>

According to Google right now: Btrfs, CIFS, NFS 4.2, OCFS2, overlayfs, and XFS

Lizardfs ought to, but doesn't currently.  zfs does not because clones
only are supported at the dataset level.

In any case, if you're using coreutils cp to do the copy, just pass
--reflink=auto.  Honestly, I have no idea why this isn't the default
behavior.  Who wouldn't want instant copy operations that consume zero
space (aside from metdata)?  If you're doing this in C or some other
language you would need to see if they have a library call to do it
easily - see man ioctl_ficlone.

-- 
Rich



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-23 Thread Rich Freeman
On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel  wrote:
>
> > > Council decided years ago that we don't support separate /usr without
> > > an initramfs, but we haven't completed that transition yet.
> >
> > Which doesn't imply that we deliberately break things.
>
> That's right. Though we should at some point start thinking about an end of 
> support for separate usr without initramfs.
>

Just to clarify - it is already unsupported at a distro level.  It is
just that some individual packages still work with it.

The current Council decisions on the issue are (just providing for
general reference):

- "Since that particular setup may already be subtly broken today
  depending on the installed software, Council recommends using an
  early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
  is on a separate partition."
  Accepted unanimously. [1]

- "The intention is to eventually not require maintainers to support
  a separate /usr without an early boot mechanism once the Council
  agrees that the necessary docs/migration path is in place."
  Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1]

- "The Council agrees that all preparations for dropping support for
  separate /usr without an initramfs or similar boot mechanism are
  complete. A news item will be prepared, and users will be given one
  month to switch after the news item has been sent."
  Accepted with 5 yes votes, 1 no vote, 1 abstention. [2]

Current policy documentation:
Developers are not required to support using separate /usr filesystem
without an initramfs. [3]

1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt
2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt
3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202

-- 
Rich



Re: [gentoo-dev] New project: binhost

2021-02-14 Thread Rich Freeman
On Sat, Feb 13, 2021 at 8:51 PM Zac Medico  wrote:
>
> > 2.  Generate a hash of the file contents - this can go in the filename
> > so that the file can co-exist with other files, and be located
> > assuming you have a full matching set of metadata.
>
> For FEATURES=binpkg-multi-instance we currently use an integer BUILD_ID
> ensure that file names are unique.
>
> > 3.  Start dropping attributes from the file based on a list of
> > priorities and generate additional hashes.  Create symlinked files to
> > the original file using these hashes (overwriting or not existing
> > symlinks based on policy).  This allows the binary package to be found
> > using either an exact set of attributes or a subset of higher-priority
> > attributes.  This is analogous to shared object symlinking.
> > 4.  The package manager will look for a binary package first using the
> > user's full config, and then by dropping optional elements of the
> > config (so maybe it does the search without CFLAGs, then without USE
> > flags).  Eventually it aborts based on user prefs (maybe the user only
> > wants an exact match, or is willing to accept alternate CFLAGs but not
> > USE flags, or maybe anything for the arch is selected> 5.  As always the 
> > final selected binary package still gets evaluated
> > like any other binary package to ensure it is usable.
> >
> > Such a system can identify whether a potentially usable file exists
> > using only filename, cutting down on fetching.  In the interests of
> > avoiding useless fetches we would only carry step 3 reasonably far -
> > packages would have to match based on architecture and any dynamic
> > linking requirements.  So we wouldn't generate hashes that didn't
> > include at least those minimums, and the package manager wouldn't
> > search for them.
> >
> > Obviously you could do more (if you have 5 combinations of use flags,
> > look for the set that matches most closely).  That couldn't be done
> > using hashes alone in an efficient way.  You could have a small
> > manifest file alongside the binary package that could be fetched
> > separately if the package manager wants to narrow things down and
> > fetch a few of those to narrow it down further.
>
> All of the above is oriented toward multi-profile binhosts, so we'll
> have to do a cost/benefit analysis to determine whether it's worth the
> effort to introduce the complexity that multi-profile binhosts add.

The hash label on the filenames was also considered around
multi-profiles.  I figured that if you're going to be building
variants of packages you'd want to parallelize and hashes work better
for that.  Plus at least in concept you could potentially identify and
fetch files by hash using info already in the local repo without
having to sync additional metadata from the binhost.  User-contributed
binaries would also work better in such a world though for obvious
security issues that might just take the form of local user-generated
repos (allowing users to supplement the upstream repo with local
builds for a cluster, without having to mirror/reporoduce the entire
upstream.

I do get that multi-profiles aren't entirely an essential feature, but
when you consider stuff like X11 support or stable/unstable it seems
like we're probably going to have to provide at least a few variants
on packages for this to be practical.  You could just put each profile
in a separate repo, but then anything that doesn't actually change
across profiles gets built multiple times.  The hash-based solution is
also a form of deduping.

But, hey, it is great to see anything like this being done at all.
Walking before running isn't a bad thing!

-- 
Rich



Re: [gentoo-dev] New project: binhost

2021-02-10 Thread Rich Freeman
On Wed, Feb 10, 2021 at 12:57 PM Andreas K. Hüttel  wrote:
>
> * what portage features are still needed or need improvements (e.g. binpkg
> signing and verification)
> * how should hosting look like

Some ideas for portage enhancements:

1.  Ability to fetch binary packages from some kind of repo.
2.  Ability to have multiple binary packages co-exist in a repo (local
or remote) with different build attributes (arch, USE, CFLAGS,
DEPENDS, whatever).
3.  Ability to pick the most appropriate binary packages to use based
on user preferences (with a mix of hard and soft preferences).

One idea I've had around how #2-3 might be implemented is:
1.  Binary packages already contain data on how they were built (USE
flags, dependencies, etc).  Place this in a file using a deterministic
sorting/etc order so that two builds with the same settings will have
the same results.
2.  Generate a hash of the file contents - this can go in the filename
so that the file can co-exist with other files, and be located
assuming you have a full matching set of metadata.
3.  Start dropping attributes from the file based on a list of
priorities and generate additional hashes.  Create symlinked files to
the original file using these hashes (overwriting or not existing
symlinks based on policy).  This allows the binary package to be found
using either an exact set of attributes or a subset of higher-priority
attributes.  This is analogous to shared object symlinking.
4.  The package manager will look for a binary package first using the
user's full config, and then by dropping optional elements of the
config (so maybe it does the search without CFLAGs, then without USE
flags).  Eventually it aborts based on user prefs (maybe the user only
wants an exact match, or is willing to accept alternate CFLAGs but not
USE flags, or maybe anything for the arch is selected.
5.  As always the final selected binary package still gets evaluated
like any other binary package to ensure it is usable.

Such a system can identify whether a potentially usable file exists
using only filename, cutting down on fetching.  In the interests of
avoiding useless fetches we would only carry step 3 reasonably far -
packages would have to match based on architecture and any dynamic
linking requirements.  So we wouldn't generate hashes that didn't
include at least those minimums, and the package manager wouldn't
search for them.

Obviously you could do more (if you have 5 combinations of use flags,
look for the set that matches most closely).  That couldn't be done
using hashes alone in an efficient way.  You could have a small
manifest file alongside the binary package that could be fetched
separately if the package manager wants to narrow things down and
fetch a few of those to narrow it down further.

Or you could skip the hash searching and just fetch all the manifests
for a particular package/arch and just search all of those, but that
is more data to transfer just to do a query.  A metadata cache of some
kind of might be another solution.  Content hashes would probably
still be useful just to allow co-existence of alternate builds.

-- 
Rich



Re: [gentoo-dev] [News item review] Python preference to follow PYTHON_TARGETS

2021-01-24 Thread Rich Freeman
On Sun, Jan 24, 2021 at 2:09 PM Michał Górny  wrote:
>
> On Sun, 2021-01-24 at 13:53 -0500, Rich Freeman wrote:
> > On Sun, Jan 24, 2021 at 7:21 AM Michał Górny  wrote:
> > >
> > > For this reason, we have decided to change the default python-exec
> > > configuration to match PYTHON_TARGETS by default, in the eclass
> > > preference order, that is from the newest CPython version to oldest,
> > > with alternative Python implementations coming afterwards.  This change
> > > will be propagated via the configuration protection mechanism whenever
> > > dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS
> > > changes.  This will permit the users to interactively confirm
> > > the updates.
> > >
> > > If the new default is not correct for you, please use your preferred
> > > configuration update tool to discard or edit the new configuration file.
> >
> > Could we just spell out what the actual setting is?  That way if a
> > user accepts or rejects the change accidentally it is trivial to fix,
> > vs making them hunt through the installed files to do a diff...
> >
> > Nothing wrong with the instructions - I'd just add one line about what
> > setting controls this.
> >
>
> The exact paths are provided in the second paragraph.  Am I missing
> something?
>

No - the way this works makes sense now.  For some reason I missed it
on the first two reads, which makes me suspect others will as well.
It wasn't the location of the config file I missed, but the fact that
the eclass will just do what eselect python used to do, and thus
trigger config protection (which is at the end of paragraph 4).

For some reason when I read the section about discarding the changes I
was thinking that there was some config toggle to change this behavior
vs the old way things worked.  Instead the new behavior is
unconditional, but the updates it makes to the python-exec config can
be rejected.

-- 
Rich



Re: [gentoo-dev] [News item review] Python preference to follow PYTHON_TARGETS

2021-01-24 Thread Rich Freeman
On Sun, Jan 24, 2021 at 7:21 AM Michał Górny  wrote:
>
> For this reason, we have decided to change the default python-exec
> configuration to match PYTHON_TARGETS by default, in the eclass
> preference order, that is from the newest CPython version to oldest,
> with alternative Python implementations coming afterwards.  This change
> will be propagated via the configuration protection mechanism whenever
> dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS
> changes.  This will permit the users to interactively confirm
> the updates.
>
> If the new default is not correct for you, please use your preferred
> configuration update tool to discard or edit the new configuration file.

Could we just spell out what the actual setting is?  That way if a
user accepts or rejects the change accidentally it is trivial to fix,
vs making them hunt through the installed files to do a diff...

Nothing wrong with the instructions - I'd just add one line about what
setting controls this.

-- 
Rich



Re: [gentoo-dev] Re: [gentoo-dev-announce] We are finally shutting down CVS

2020-12-27 Thread Rich Freeman
On Sun, Dec 27, 2020 at 1:31 PM Alec Warner  wrote:
>
> On Sun, Dec 27, 2020 at 6:39 AM Ulrich Mueller  wrote:
> >
> > > On Sun, 27 Dec 2020, Max Magorsch wrote:
> >
> > > To access the old repositories you can use gitweb.gentoo.org instead.
> > > We have migrated all old cvs repositories to git. All of them are
> > > available read-only now at [0].
> >
> > I've just looked at
> > https://sources.gentoo.org/archive/cvs/gentoo.git/
> > and its commit history ends in 2004.
> >
> > Can you please reinstate CVS until a more accurate conversion is
> > available?
>
> I'm happy to make tarballs available (as discussed in a bunch of
> places on irc.) Is that sufficient or is there some particular
> requirement for the CVS protocol specifically?
>

The conversion tools all just work on a bare repository (RCS
files/etc) and don't use any CVS network protocols - you don't need
any daemons running.

-- 
Rich



Re: [gentoo-dev] Pushing to distfiles?

2020-11-11 Thread Rich Freeman
On Wed, Nov 11, 2020 at 7:23 PM Joshua Kinard  wrote:
>
> Forgive me for being a dunce, but what is the current procedure to push
> files to distfiles for distribution to the mirrors?  The devmanual is blank
> on this topic, and GLEP75 just talks about the motivations behind the change
> away from the flat directory format.  I am not easily finding anything that
> details how to get new distfiles onto the mirrors.
>

I thought that the whole mirror:// thing was discouraged.  For
anything else you just stick SRC_URI in the ebuild and the mirrors
should fetch it when they see it in the repo.

I just host stuff like that on my dev webspace, or better yet on
github or something else that will auto-tarball stuff.

-- 
Rich



Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Rich Freeman
On Wed, Nov 4, 2020 at 3:57 PM Joonas Niilola  wrote:
>
> On 11/4/20 10:43 PM, Rich Freeman wrote:
> >
> > Do you really think that users who just blindly run "emerge
> > --autounmask-write" are going to be both masking and unmasking
> > packages by hand (per your other email)?
> Just by following wiki...
>
> >
> > And how are they any better off if they do? They just end up in the
> > exact same state, except now we have zero control over their
> > experience instead of only a little control.
> Exactly, we should try to prevent this situation! Glad we agree.
>

Great, then no need to remove working packages that only have live
versions.  Just add snapshots where appropriate.

> >
> > Then why not do that, instead of removing things?
> Did you bother reading my reply?

Did you consider that somebody could read your email and not actually
agree with you?

> There's work being done towards fixing
> packages which seem to have hope. Now for some of these packages there's
> been last upstream activity 8 years ago. Is having a - ebuild
> justified there?

Does it work?  If so, then there is no harm.  If not, then just remove
it - you don't need a new policy to treeclean stuff that doesn't work.

> Also for some, upstream is dead, gone, making the
> package totally un-emergeable.

Then treeclean it.  Again, no need for a new policy here.  Stuff that
doesn't build is already grounds for removal if it isn't fixed in a
timely manner.

> Now imagine if we had a snapshot tarball
> in our mirrors, maybe it wouldn't need to be removed, if it still could
> be built.

Stuff that has no working SRC_URI still should be removed.  By all
means create your own upstream for it if you wish.

Removing that package years ago wouldn't have done anything to make a
snapshot available.

You're saying that live-only packages should be removed because they
could have snapshots.  I'm saying that if you want to maintain a
snapshot just add it and co-maintain - you don't have to remove
packages that don't have them.

-- 
Rich



Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Rich Freeman
On Wed, Nov 4, 2020 at 2:46 PM Joonas Niilola  wrote:
>
> On 11/4/20 8:52 PM, Rich Freeman wrote:
> >
> > 4.  If somebody finds one they probably have to add some random
> > overlay to their config, which causes this package to become
> > available, probably along with 47 other packages that can potentially
> > conflict with other things in the tree, all with zero QA.
> (It's common practice to mask the entire overlay then unmask the
> package(s) you need from it)
>

Do you really think that users who just blindly run "emerge
--autounmask-write" are going to be both masking and unmasking
packages by hand (per your other email)?

And how are they any better off if they do? They just end up in the
exact same state, except now we have zero control over their
experience instead of only a little control.

> > Certainly it is good to have snapshotted versions that get more QA
> > where appropriate, and that should probably be communicated.  When it
> > is done with an "or else" attached the result is likely to be that a
> > lot of stuff just gets removed, with little benefit...
> >
> Well my intention is to get up-to-date packages KEYWORDED properly, for
> better visibility and support.
>

Then why not do that, instead of removing things?

We should be careful with QA policies to avoid the concept that we
want somebody to do A, but we can't make them do A, so we tell them
they're not allowed to do B unless they also do A, and then we're
shocked when nobody wants to do B now.

If A is absolutely essential then maybe it is better to not have B to
ensure that A happens.  However, often A is a nice-to-have, and we end
up pruning stuff that really isn't that bad because we were just
trying to force devs to do something else.

If we want snapshots, then we should just add snapshots.  Removing the
package doesn't accomplish adding a snapshot.

-- 
Rich



Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages

2020-11-04 Thread Rich Freeman
On Wed, Nov 4, 2020 at 1:39 PM Marty E. Plummer  wrote:
>
> On Wed, Nov 04, 2020 at 06:24:39PM +, Alexey Sokolov wrote:
> >
> > What you're describing is live ebuilds, and I agree they are useful.
> > Joonas was talking about packages which have *only* live ebuilds, and no
> > other versions, and not even snapshots.
> >
> I must have misread, then, as I assumed a kill of all ${PN}-**.ebuild
> I suppose no live-only is reasonable for the most part, if there are
> non-live releases (not all software is at that point in their release
> cycles).

This still seems like a solution searching for a problem.  What is the
downside to having these in the tree?

If you remove them from the tree:

1.  They move from having minimal QA to zero QA.
2.  They don't get updated when larger Gentoo-wide things happen.
3.  People have to do searches to realize they even exist.
4.  If somebody finds one they probably have to add some random
overlay to their config, which causes this package to become
available, probably along with 47 other packages that can potentially
conflict with other things in the tree, all with zero QA.

Obviously if somebody notices that such an ebuild is broken it should
get treecleaned if the maintainer doesn't respond to a bug.  However,
it sounds like we're talking about a handful of packages after almost
two decades of allowing them.  Since they're masked, they don't do
anything unless somebody actually goes poking at them, and if they do
they probably file a bug and they'll go away.

Certainly it is good to have snapshotted versions that get more QA
where appropriate, and that should probably be communicated.  When it
is done with an "or else" attached the result is likely to be that a
lot of stuff just gets removed, with little benefit...

-- 
Rich



Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package

2020-10-18 Thread Rich Freeman
On Sun, Oct 18, 2020 at 4:17 AM Andreas Sturmlechner  wrote:
>
> I'm sure there is a way for the display-manager ebuild to migrate from old xdm
> configs on users' systems. How much do config and init scripts differ at all?
>

Couldn't you just use a symlink so that either script name works?
Then the news item can be about deprecating the old name.  There need
not be any rush to stop supporting it.

-- 
Rich



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



  1   2   3   4   5   6   7   8   9   10   >