Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?

[Peter Stuge]

m1027 wrote:
> Wow, wasn't aware of catalyst at all. What a beast in terms of control.

It's not so well-known maybe because it was created by and for
gentoo-releng but if you know what you want it's a fantastic tool.


> (FYI: I enjoyed the links on catalyst you sent me directly.
> Unfortunatelly I cannot answer you directly due to the default
> TLS guarantee

Thanks! Glad you liked them. And yes, TLS is on my list.


> While being able to build exact environments with catalyst I wonder
> how it could help fixing the issue of my original post.

Thank you for connecting back to the original post! Let's see:


> Whenever we need to deliver a updated app to customers whose OS is
> too old (but updating it is too risky), we could either
> a) keep evenly outdated dev build OSes around forever (oh no!), or
> b) post our newly built app in a container (leaving the lovely native
> world); and both ignore the fact that customers wish maintenance of
> the entire OS actually, too.
> So, ideally, there is c): In a hypothetic case we would prepare a
> entire OS incl. our app (maybe via catalyst?) which would require
> a bootloader-like mini-OS on the customer's side, to receive updates
> over the internet, switch the OS at boot time, and fallback.

I had a) in mind. Why "oh no!" ? I didn't mean forever.

I think it's already a very good value proposition that you can deliver
updates of your apps for the particular systems that your customers run.

catalyst building specific, "old-like" OSes on which you build new (binpkg)
versions of your app to be installable by emerge on old customer OSes is
admittedly a lot of work, at least initially.

Separate from those app updates you can then use catalyst to also tackle
OS maintenance/updates. You can create either full milestone OSes or just
individual (binpkg) packages through which customers' OSes can become
less fragmented over time, at the pace each customer is comfortable with.
OS updates can take only small steps at a time, since catalyst allows
exact control.

This could reduce target OS diversity drastically over time with probably
relatively moderate development effort. More effort might go into holding
customer hands along the bespoke update paths.

So, I see controlled paths forward in both problem dimensions. I don't
know if the effort is actually practical for you but it /is/ doable and
most importantly it can be customized for the individual systems
currently in production at your customers.


//Peter

Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?

[Peter Stuge]

Peter Stuge wrote:
> Essentially you will be maintaining a private fork of gentoo.git,

If this seems too heavy handed then you can just as well do the reverse:

Maintain an overlay repo with the packages you care to control in the
state you care to have them, set that in the catalyst stage4.spec
portage_overlay and add unwanted package versions in gentoo.git to
the package.mask directory used by catalyst.

This may sound complicated but it isn't bad at all.

For total control also make your own profile, e.g. based on embedded,
but that's not per se neccessary, only if the standard profiles has too
much conflicts with what you want in @system.

catalyst will rebuild @system according to spec file but with too much
difference that just becomes annoying and feels more trouble than a
controlled profile.

This approach falls somewhere between your options (1) and (5).


Good luck!

//Peter

Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?

[Peter Stuge]

Hi,

m1027 wrote:
> So, what we've thought of so far is:
> 
> (1) Keeping outdated developer boxes around and compile there. We
> would freeze portage against accidental emerge sync by creating a
> git branch in /var/db/repos/gentoo. This feels hacky and requires a
> increating number of develper VMs. And sometimes we are hit by a
> silent incompatibility we were not aware of.
..
> (5) Inventing a full fledged OTA Gentoo OS updater and distribute
> that together with the apps... Nah.
> 
> Hm... Comments welcome.

I recommend taking ownership (and responsibility) of your OS.

Gentoo tooling (catalyst) is really fantastic for doing so.

Essentially you will be maintaining a private fork of gentoo.git, but
one where you only really need to manually process the packages you
care to control, only when you care to control them.

Use catalyst to build tarballs (and binpkgs) from snapshots of that repo.

emerge can install binpkg at least from FTP.


//Peter

Re: [gentoo-dev] New category: media-print/

[Peter Stuge]

Hi Marco,

mscard...@icloud.com wrote:
> Looking at packages seems there’s not any package strictly related
> to net (tell me if You think some of these should remains to it). 
..
> things more common-used like cups).

cups certainly has a network component both as server and as client.

It's one of a few different methods (by far the most common) to
access networked printers so it may not be so misplaced in net-print.


//Peter

Re: [gentoo-dev] Last rites: www-servers/boa

[Peter Stuge]

Alec Warner wrote:
> Currently mgorny is the listed maintainer of boa. What if instead of a
> bunch of CVEs he just decided he had better things to do with his
> time.
> He last-rites the package, giving a 90d deadline for the package to
> find a new owner.
> No one cares to maintain boa, so no one steps up, and the package is
> removed after 90d.

That would be perfectly fine of course.

Note that mgorny protested in the lastrite bug way before my mail.


> I think the current state is that no one with commit access to
> ::gentoo cares, so it will be removed unless someone changes their
> mind.

That seems accurate.


John Helmert III wrote:
> > Do you continue to believe that boa has vulnerabilites involving files
> > and functionality (as mentioned by the maintainer mgorny in #882773#c1)
> > which do not exist in the package?
> 
> Just like it isn't your responsibility to "cleanup NVD", it's not my
> responsibility to authoritatively verify every CVE that Gentoo
> Security acts upon.

Of course not by others in Gentoo Security, but I think it is for
inputs that you yourself act on. (Everyone of course and I am mindful
to do it too.)


> Even if I did make such a judgement, I will *not* risk my being
> wrong and exposing Gentoo users to vulnerabilities unecessarily,
> even when prompted to by users on mailing lists.

Your nginx example seemed to say otherwise.

It's good to be afraid of being wrong but then please work with
trusted peers to feel confident about being right instead of racing
to bottom quality.

Since you don't trust my analysis of both versions of the source code
published by upstream please do collect further analysis from peers,
so as to not be wrong in the opposite.


> > The CVEs are obviously invalid and yes someone could contribute time
> > to clean up NVD but I honestly don't think that either upstream or
> > myself can reasonably be made responsible for invalid CVEs submitted
> > by third parties.
> 
> Again, we're not making judgements about "obviously invalid".

I do think Gentoo Security needs to validate. *scratches head*

This is obviously the most interesting part of this thread.


> The time you've spent arguing with us on gentoo-dev could've been
> easily spent asking upstream about the issue.

I verified the three CVEs to be non-issues, what is there for me to
ask upstream about?

I analyzed the source code before sending my first mail and confirmed
that the CVEs do not exist in boa. That's why I sent the mail saying
that the reports are false.

A lastrite commit in Gentoo based on invalid CVEs has little to do
with upstream.

You're reversing the burden of proof based on a false claim.


> > I disagree, that's only a good way to measure how many distributions care.
> 
> Which is *precisely* the point I'm making. If distributions with many
> times the resources of Gentoo don't care to package it, that's a bad
> indicator of how well the package is taken care of.

How can you know why someone else does or *doesn't* do something?
That's absurd.


> > Each distribution has its own dynamic (but actually distributions also
> > tend to herd behavior)

You really leaned into the herd behavior there. :\


> > Again: Impact shouldn't matter, correctness should.
> 
> And again, I'm generally not going to be validating every CVE ever for
> correctness.

Only those you act on.


> > > It generally can't work better with MITRE being useless in many
> > > cases. Yes, the CVEs seem garbage, but I can't say that
> > > authoritatively, so I don't.
> > 
> > What would convince you?
> 
> Anything from upstream, or a withdrawal of the CVEs, or a notice from
> the CVE reproters that they're invalid. But I really don't understand
> why anybody cares about this leaf package that nobody actually seems
> to use, including you.

Imagine that I fork boa to a project called boah, change nothing but
the version number, create a release and then tell you again that the
three CVEs are invalid for both boa and boah.


//Peter

Re: [gentoo-dev] Last rites: www-servers/boa

[Peter Stuge]

John Helmert III wrote:
> > > There are multiple CVEs for it, is it really on us to discriminate
> > > between which CVEs are valid and which are not?
> > 
> > Yes.
..
> > > We can't possibly hope to do that accurately in all cases.
> > 
> > Some times it will be easy, other times less easy.
..
> > Maybe the accurate bigger picture is that no (current) Gentoo developer
> > knows enough about the package and thus can't be expected to action
> > such bogus CVEs correctly without a couple of minutes of investigation,
> > which would be too long, then I guess maintainer-needed is the most honest?
> 
> No, when a package is believed to be vulnerable, it is not responsible
> for us to just leave it as maintainer-needed, that's not an accurate
> reflection of the situation.

Do you continue to believe that boa has vulnerabilites involving files
and functionality (as mentioned by the maintainer mgorny in #882773#c1)
which do not exist in the package?

I wanted my mail to change that belief. If I've failed so far can you
tell me how I can accomplish it, ie. what it would take for you to
please revert the lastrite commit?


> If you think the CVEs are invalid, maybe talk to upstream? Or MITRE?

The CVEs are obviously invalid and yes someone could contribute time
to clean up NVD but I honestly don't think that either upstream or
myself can reasonably be made responsible for invalid CVEs submitted
by third parties.


> Or anybody that isn't only a CVE downstream?

I expect every downstream of everything to apply themselves in order to
improve quality of what they consume, not reduce it. To be clear: It's
also not your job to improve NVD but at least don't lastrite in Gentoo
because of invalid CVEs.


> I also note that very few distributions package Boa:
> 
> https://repology.org/project/boa/versions
> 
> This is a good way to measure how many people care about the package
> (and thus, its security health).

I disagree, that's only a good way to measure how many distributions care.

Each distribution has its own dynamic (but actually distributions also
tend to herd behavior) and especially commercial distributions are more
often than not bound by law to be driven only by profit, with *everything*
else secondary. This includes software quality and/or "security health".


> If the commercial distributions don't carry a package, nobody cares for
> it, and thus security issues are unlikely to be tracked and handled well.

This seems based on an assumption that only commercial software has
high value? I could not disagree more with that.

But if we play out the argument then CVEs for packages not in many
distributions would more likely be invalid than others. While true
in this case I don't find it convincing as a general conclusion.

These things can all be true at once:

1. a package is secure
2. the package is not popular
3. a CVE for the package is invalid but not (yet) rejected
4. another CVE for the package is valid (low severity; still secure)

Only 1. says something about "security health" (whatever that means).

I think it's both irresponsible and wrong to indiscriminately give
authority to CVEs. People are wrong on the internet all the time,
some even intentionally, it's not correct to blindly believe CVEs
any more than tweets.


> > The mere existance of CVEs can not be reason enough for any change,
> > that would mean resignation to fear instead of encouraging rational
> > behavior as required to actually improve technology.
> 
> That's not a real concern. We're not going to last rite something like
> nginx simply because there's a CVE against it. In the case of Boa,
> which doesn't seem to have been touched in approaching 20 years, the
> impact of last rites is minimal.

All packages are equal but some are more equal than others? ;)

Again: Impact shouldn't matter, correctness should.


> > The answer I receive so far is something like
> > "it can't work better because we react indiscriminately to CVEs",
> > that's an honest answer (thank you!) but not great quality. Does
> > everyone mostly agree with that policy?
> 
> It generally can't work better with MITRE being useless in many
> cases. Yes, the CVEs seem garbage, but I can't say that
> authoritatively, so I don't.

What would convince you?


Thanks a lot

//Peter

Re: [gentoo-dev] musl, sbcl, and ros

[Peter Stuge]

Andrey Grozin wrote:
> This means that no user of the musl profiles has ever been able to emerge 
> all these packages (because they did not have sbcl). And all these 
> packages should be pmasked in the musl profiles.

Is the last sentence actually true?

Shouldn't only ebuilds with actual problems be masked?

Even if there's currently no possibility to emerge other packages
which depend on that it seems incorrect to mask those other packages
only because a dependency can't be emerged?

I don't think portage cares; it will show sbcl masked if it is a
dependency, right?


Thanks

//Peter

Re: [gentoo-dev] Last rites: www-servers/boa

[Peter Stuge]

John Helmert III wrote:
> So much yapping on the mailing lists, and no response in the bug which
> triggered the last rites...

Apologies if I responed in the wrong forum. I thought on list would
be good, why are those mails on the list if not?


> So, Peter, do you use Boa?

Not right now, but I have before and I might again.


> If you do, what niche does it fill that isn't filled by anything else?

That's a strange question. Why should I agree with or even
reconfigure because of something that is in fact an error?

I ask you to revert the lastrite not because it would break a use
case of mine but because the CVEs do not apply to boa itself but to
some unknown appliance that uses boa to serve unknown buggy CGI scripts.


> There are multiple CVEs for it, is it really on us to discriminate
> between which CVEs are valid and which are not?

Yes.

You are obviously /not/ responsible for what bogus CVEs people may
report, but we're all responsible for the commits we create.

I assume that everyone wants to improve the overall state with each
commit - that we want to make things more correct since that's what
enables reliability, hence yes: it really is on every one of us to
verify our inputs before taking action on them.


> We can't possibly hope to do that accurately in all cases.

Some times it will be easy, other times less easy.

In this case the CVEs could be dismissed by searching the source code
for the file names in the CVEs. Or by having experience with what the
package provides, in particular that it doesn't include any CGI scripts.

Maybe the accurate bigger picture is that no (current) Gentoo developer
knows enough about the package and thus can't be expected to action
such bogus CVEs correctly without a couple of minutes of investigation,
which would be too long, then I guess maintainer-needed is the most honest?

The mere existance of CVEs can not be reason enough for any change,
that would mean resignation to fear instead of encouraging rational
behavior as required to actually improve technology. It would also
create incentive for permanent denial-of-service attacks by way of
bogus CVEs manipulating people into incorrect lastrites and other
changes. I don't want that to become common.

My question about the lastriting process was not an attack but a
genuine inquiry. The answer I receive so far is something like
"it can't work better because we react indiscriminately to CVEs",
that's an honest answer (thank you!) but not great quality. Does
everyone mostly agree with that policy?


Thanks

//Peter

Re: [gentoo-dev] Last rites: www-servers/boa

[Peter Stuge]

Michał Górny wrote:
> > Shouldn't this process work a lot better?
> 
> Processes tend to work better when people are contributing towards
> making the processes work better rather than complaining from their
> comfy armchairs that they tend to confuse with thrones.

LOL!

Are you honestly arguing that the Gentoo lastriting process relies on
third party contributions to work or improve? That would amount to
declaring Gentoo (developers) incapable of self-improvement, something
that would be absolutely unacceptable to say about any one or any group
of people.

If you feel that Gentoo is unsustainable like that then please think
about how you should react to it.


Instead of writing a passive aggressive response to my demonstration
of this process failure I wish that you would have drawn on your
knowledge of the process and the learnings in my mail to 1. educate
us on what gaps you see, if any, that caused this particular error,
and maybe even 2. suggest some improvements.

Expecting and/or demanding that from me because I dared describe a
symptom and question the process is neither reasonable nor fair nor
useful. Shooting the messenger reveals that you can't deal with the
message, but that's a you problem, it's not okay to project that onto
the messenger or anyone else.


If you wanted to encourage me to become a Gentoo developer and (among
other things) improve the lastriting process then you missed the mark,
in fact your behavior consistently remains one strong reason for me
to *not* become a Gentoo developer.


Kind regards

//Peter

Re: [gentoo-dev] Last rites: www-servers/boa

[Peter Stuge]

John Helmert III wrote:
> # John Helmert III  (2022-11-27)
> # Unmaintained upstream, several unresolved public vulnerabilities,
> # Removal in 30 days. Bug #882773.
> www-servers/boa

This is bogus, please revert.

Who are you to declare unmaintained? It's a simple program so maybe
it simply needs no further change.

Anyway, none of the three CVEs you list in #882773 are valid.

CVE-2022-44117 is an empty claim with no detail at all. And as mgorny
points out, boa does not have anything to do with SQL.

CVE-2021-33558 and CVE-2017-9833 refer to issues in applications or
appliances which use boa. They have nothing to do with boa itself.
The named files do not exist in the boa package.

Shouldn't this process work a lot better?


Thanks

//Peter

Re: [gentoo-dev] Last rites: net-mail/vchkuser

[Peter Stuge]

John Helmert III wrote:
> > Searching for the repo name on GitHub finds this however:
> > 
> > https://github.com/bdrewery/vchkuser
> > 
> > ..which seems to be a 2010 version of the code. I did a test, it works
> > fine. Maybe just change the SRC_URI.
> 
> Can you produce a guarantee that the code there is equal to the code
> which the ebuild currently refers to? Or maybe that it's equivalent to
> the now-removed repository?

Git thinks so.

I unpacked vchkuser-0.4.tar.gz from a Gentoo mirror on top of a
bdrewery/vchkuser checkout and:

$ git status
# On branch master
nothing to commit, working directory clean
$ 

The v0.4 tag in bdrewery/vchkuser also equals the commit hash in the
directory name of the .tar.gz. (This is of course weak.)


//Peter

Re: [gentoo-dev] Last rites: net-mail/vchkuser

[Peter Stuge]

John Helmert III wrote:
> > Jonas Stein wrote:
> > > # Dead upstream
> > > # Removal after 2023-01-01.  Bug #881249.
> > > net-mail/vchkuser
> > 
> > Was there an actual issue with the package that prompted you to do
> > this - something that a package maintainer should have resolved?
> > 
> > I think it's a bad idea to remove a package if "Upstream Homepage and
> > SRC_URI is gone" and "Gentoo is the last distro with this package"
> > are the only reasons...
> 
> Do you use it? Is it still functional?

I don't use it, I use something else for the same task.

Looking up the GitHub user that person seems present, just that
particular repo is no longer there.

Searching for the repo name on GitHub finds this however:

https://github.com/bdrewery/vchkuser

..which seems to be a 2010 version of the code. I did a test, it works
fine. Maybe just change the SRC_URI.


//Peter

Re: [gentoo-dev] Last rites: net-mail/vchkuser

[Peter Stuge]

Jonas Stein wrote:
> # Dead upstream
> # Removal after 2023-01-01.  Bug #881249.
> net-mail/vchkuser

Was there an actual issue with the package that prompted you to do
this - something that a package maintainer should have resolved?

I think it's a bad idea to remove a package if "Upstream Homepage and
SRC_URI is gone" and "Gentoo is the last distro with this package"
are the only reasons...


Thanks

//Peter

Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt

[Peter Stuge]

Mikhail Koliada wrote:
> This idea has been fluctuating in my head for quite a while given
> that the migration had happened a while ago [0] and some other
> major distributions have already adopted yescrypt as their default algo
> by now [1].

Please only do that based on proven merit and nothing else.

Fedora or anyone else for that matter making a change is a truly
terrible reason to take any action whatsoever, since other
organizations are driven by /their/ interests - with Fedora in
particular being driven by the business interests of Red Hat.

I consider Gentoo a leader in many regards and it makes me really
sad whenever Gentoo changes based on nothing more than "others did it".


Thanks and kind regards

//Peter

Re: [gentoo-dev] Deprecating repoman

[Peter Stuge]

Matt Turner wrote:
> repoman is inferior to other tooling mentioned. The other tooling is
> actually run in CI.

The problem seems to be that CI is running something other than
developers run, not the other way around.


> Developers should get the same warnings locally as in CI.

I agree. And developers and their tools should not have to bend to
whatever CI does, I think the other way around makes more sense.


CI doesn't use repoman because of performance issues.

What if pkgcore evolves to provide a portage-compatible API?

Then CI could use repoman without performance problems, and
developers would also enjoy improved performance, without spending
time on replacing tooling which already works for them.

Looking into the future then maybe portage could even come to use
pkgcore for the low-level things that pkgcore does, then even users
could enjoy improved performance.


Right?

//Peter

Re: [gentoo-dev] Maintainer needed: dev-db/sqlite

[Peter Stuge]

Mike Gilbert wrote:
> The current (proxied) maintainer is somewhat difficult to work with

Why is Arfrever being treated so bad here? To me, it looks like
you're the one who is difficult to work with. :\


Jakov Smolić wrote:
> From what I've investigated, other major distributions don't apply
> any similar patches which means that we are likely to stop carrying
> most (or even all) of the current patches.

What kind of silly groupthink is this? I expect Gentoo to champion choice.


Mike Gilbert wrote:
> There is an open QA bug [1] regarding the large set of undocumented
> patches that are being applied in the stable ebuilds.

Arfrever is active in the bug you linked, has provided explanations
for the patches and prepared to restructure the patches so that they
can be gated by local USE flags, has made several different concrete
suggestions for possible implementations and requested feedback, but
has received no reply in the bug and instead there's now this
backstabbing discussion on this list.

Really?


//Peter

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

[Peter Stuge]

Mike Gilbert wrote:
> > > It's a waste of time and effort to pepper random ebuilds with checks
> > > for options that everyone should have enabled in the first place.
> >
> > It's not for you to say what everyone should have enabled in their kernel.
> 
> Do you not agree that there are some options that should always be
> enabled, or at least that we can assume are enabled?

"Should be enabled" no, but I agree with the latter - some assumed set
should be fine. I think it would be good if it's (somehow) documented
though.


> To use my earlier example, should every package that uses AF_INET
> check for CONFIG_INET in the kernel?

CONFIG_INET is a perhaps surprisingly tricky example!

A package could e.g. use getaddrinfo() with no address family hint
but because of USE=-ipv6 exclude all AF_INET6 address results and
so end up using AF_INET based on whether it's available in the
running kernel or even based on third party DNS entries.


I'm not sure about the best approach for very basic options,
CONFIG_NET could be another such candidate.

Thinking towards robbat2's proposal (which I like) it might make sense
to try to map requirements of packages, but there will probably be
cases where it can't really be done successfully.

Ultimately that work should not be the responsibility of distribution
package maintainers but something upstreams deliver, similar to systemd
units, but maybe we'll invent it (if noone else has)..


//Peter

Re: [gentoo-dev] moving kernel config checks forward: potential config checking tool

[Peter Stuge]

Robin H. Johnson wrote:
> We have some set of packages (A) which collectively depend on one or
> more kernel options being set in specific ways, and the options need to
> REMAIN set if you want the packages to continue work.
..
> Can we consider moving the checks for set A somewhere else, such that we
> don't check the kernel config during package compile & install time, but
> only check it later?

I only see one problem with this; that USE flags could influence which
kernel options are required, which would be useful to know at/before
compile time.


> It would need to keep long-term state about which packages want
> specific options set/unset/modular, as well as short-term state
> about the config from each boot.

It's a cool idea. A standardized solution would be quite nice for the
whole Linux ecosystem.


//Peter

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

[Peter Stuge]

Mike Gilbert wrote:
> It's a waste of time and effort to pepper random ebuilds with checks
> for options that everyone should have enabled in the first place.

It's not for you to say what everyone should have enabled in their kernel.

There's significant value in ebuilds documenting required kernel options in
a structured manner.

So I welcome simplifications in the checking to achieve millisecond
test times. But the benefit of structured requirements is given even
without any runtime checking at all, as long as required options
continue to be codified /somehow/.


Thank you for your work!

//Peter

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

[Peter Stuge]

Joshua Kinard wrote:
> > I'm not entirely sure what you'd like to ask the libtomcrypt authors.
> > "We think there may be patents, but we don't know. Did you consider
> > that?"
> 
> No, actually, I was thinking something more along the lines of "Hey, are you
> aware of these supposed patent claims about ECC/ECDSA implementations that
> Red Hat says exist, and if so, did you do any research on them that you
> could possibly share that led you to feeling confident to release your
> implementation into the public domain".
> 
> But I am open to better language.

There's not neccessarily a conflict between a patented idea and a
public domain implementation of that idea.

Take a fictional example:

You and I independently invent the same thing. You patent it, then
write and publish an LGPL implementation. I, ignorant of your
accomplishment, later write and publish a different implementation,
placing it in the public domain.

You having a patent doesn't neccessarily matter to me publishing my
implementation.

It can be problematic for *users*. They might violate your patent
terms (or not; it depends on your terms in the patent) if they use
*any* implementation without having licensed the right to use your
patented idea from you. (Of course only until your patent expires.)

What users have to do is determined by the terms set forth in the
patent. E.g.: the QR-code patent has (I believe) not expired yet but
has always permitted using the idea without any explicit license under
the condition that all use is actually spec conformant.

The license for a software isn't connected to patents unless it
explicitly states so, like GPL-3 Section 11 or Apache-2.0 Section 3.
Public domain has no license text, so can have no such language. :)

You seem to expect some due diligence from libtomcrypt authors before
having decided to publish their work and I don't find that reasonable.
I hope I've managed to explain why?


Kind regards

//Peter

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

[Peter Stuge]

Joshua Kinard wrote:
> Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions
> provided in libtomcrypt, and that library's homepage states all its code is
> public domain.  Our ebuild has no bindist restrictions on that library.
> Perhaps that is how dropbear, and thus Red Hat, avoids the issues with
> licensing or patents?

Licenses apply to implementations and patents apply to inventions/ideas.

A software license can allow you to theoretically use an implementation
while a patent says no you can't without licensing that right separately.

The reverse is equally possible; an expired patent means that using the
invention/idea is not restricted by the patent anymore, but there may
still be no free/open source implementation (yet).


AIUI USE=-bindist is all three variants (swlicense_says_no || patent_says_no)
while USE=bindist promises that (swlicense_says_yes && patent_says_yes)
is guaranteed to be true at the cost of functionality?


//Peter

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Peter Stuge]

Sam James wrote:
> > https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
> > 
> > it seems that it may be possible to need only very simple tools for the
> > deblob program(s).
> 
> Instead of linking to a huge release announcement, could you summarise it?

Fair enough - though the relevant part is the short commentary preceding
the perhaps mechanical release announcement.

The deblob program(s) previously used sed and awk instead of python
or perl and seem to have switched more because of performance than
because of any features in either python or perl. A quick look into
the source code seems to confirm that there's no strong tie to Python.


//Peter

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Peter Stuge]

Alice wrote:
> +++ b/eclass/kernel-2.eclass
..
> -   PYTHON_COMPAT=( python2_7 )
> +   PYTHON_COMPAT=( python3_{7..10} )

From

https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html

it seems that it may be possible to need only very simple tools for the
deblob program(s). I think that would be a worthwhile improvement and it
would probably also simplify integration of deblob not only in Gentoo.

That said, if python2_7 is not a thing in Gentoo anymore then the patch
makes sense to me.

I think the discussion on merits concluded well - kernel maintainers who
want can support it. Everyone who considers it pointless can ignore it.
All good.


Kind regards

//Peter

Re: [gentoo-dev] Packages up for grab

[Peter Stuge]

Marco Scardovi wrote:
> mail-filter/bogofilter

I'd like to proxy-maintain this.


//Peter

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Peter Stuge]

Ben Kohler wrote:
> Nobody is "disabling choice" here,

Fair! Sorry about the hyperbole.


> a change in defaults doesn't remove your ability to choose something else.

True. My argument is more specificically that setting USE flags by
default in a "low-level" profile goes in the wrong direction.


> And I understand your sentiment that adding more default-on flags goes 
> against YOUR goals of a minimal gentoo, but I'd like to remind you and 
> others that this minimalism is not the goal of every gentoo user.

It's important that this is a low-ish-level profile. Unfortunately Matt
didn't respond to my question/point about profile inheritance.

I don't expect a gentoo desktop system to be minimal. I would however
like being able to build upon a minimal profile (not a desktop one)
with nothing in it, as opposed to having to essentially create a new
profile for each of my configurations.


> I want to be clear that I'm not saying you are wrong, but remember that 
> your perspective is not the only correct one on this topic.

Maybe the discussion should focus on different kinds of profiles?

I'm not concerned about typical "user-facing" profiles here, it can
make plenty sense to enable these USE flags by default in those.


Michael Orlitzky wrote:
> all I personally want is to be reasonably sure what my configurations
> are going to do without having to list every individual package and
> USE flag explicitly.

Exactly this. Unfortunately I've had to give up on it, as USE flags
are set by default here and there, but I'd love to be able to rely
on a minimal starting point that will stay minimal.

Thank you for your mail Michael, you expressed my concern very well.


Kind regards

//Peter

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Peter Stuge]

Matt Turner wrote:
> > > If you can find a case where you wouldn't want to enable one of these
> > > USE flags, please let me know and I'll reconsider my position.
> >
> > My catalyst spec files all have  use: -* foo bar x y z
> > specifically because the defaults are never what I want for any given
> > system. I build desktops, servers, containers, VM appliance images and
> > embedded system, and I know what I want in each one. Especially the
> > latter frequently have only very few USE flags set and I want zero
> > extra dependencies.
> 
> I think you're making a great argument that you'd be completely
> unaffected by any of the suggestions in this thread.

I don't consider needing "use: -*" at all a desirable situation. This
catalyst warning might support that:

Warning!!!
The use of -* in $stage/use will cause portage to ignore
package.use in the profile and portage_confdir. You've been warned!


I see it as a shortcoming of the standard profiles that I have to
essentially create my own in order to get what I want, as opposed
to being able to build upon something truly minimal.


> > > I'd claim most of these packages' bzip2/lzma/zstd USE flags should
> > > be removed in favor of statically enabling them
> >
> > That is the direct opposite of Gentoo's single most core value: choice
> 
> Choice makes sense when there's a legitimate trade-off to be made.

I explained that and why I frequently do not want those USE flags set,
demonstrating that I want choice here.

You can of course dismiss any concern which disagrees with your opinion as
illegitimate. Please do not bother asking questions if that's your style.


> Choice isn't dogma.

Is there a difference between dogma and value? I understand choice to be
a core value in Gentoo. Maybe that's wrong (now)? Core values are more
important than pretty much anything else.

Choice isn't always possible. That's not this case. If choice is indeed
a core value then where choice is pretty easy (this case) in my mind
there needs to be an overwhelmingly strong argument to conciously and
intentionally disable choice.


> > Just don't do it. Kthx.
> 
> This kind of thing is nothing but irritating. Please don't do this.

I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant
exactly what you wrote:

This kind of thing (increase default USE-flags) is nothing but irritating.
Please don't do this.


Kind regards

//Peter

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[Peter Stuge]

Matt Turner wrote:
> If you can find a case where you wouldn't want to enable one of these
> USE flags, please let me know and I'll reconsider my position.

My catalyst spec files all have  use: -* foo bar x y z
specifically because the defaults are never what I want for any given
system. I build desktops, servers, containers, VM appliance images and
embedded system, and I know what I want in each one. Especially the
latter frequently have only very few USE flags set and I want zero
extra dependencies.

I completely agree that the default USEs should rather be reduced,
not increased. Isn't this what profile inheritance is for? It would
be great if I didn't essentially have to create my own profile when I
want a very minimal system.


Matt Turner wrote:
> I'd claim most of these packages' bzip2/lzma/zstd USE flags should
> be removed in favor of statically enabling them

That is the direct opposite of Gentoo's single most core value: choice

Just don't do it. Kthx.


//Peter

Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

[Peter Stuge]

Rolf Eike Beer wrote:
> The previous algorithm would scan for all primes for a given number,
> which takes needlessly long.

Please also mention how this caused a problem for you in the commit
message, to help us understand why you're proposing to change this.


> +++ b/eclass/qmail.eclass
> -# @FUNCTION: is_prima
> +# @FUNCTION: is_prime
>  # @USAGE: 
>  # @DESCRIPTION:
>  # Checks wether a number is a prime number

Maybe name the algorithm? Looks like an optimization of the sieve of
Eratosthenes?


>  is_prime() {
>   local number=${1} i
> - for i in $(primes ${number} ${number})
> +
> + if [[ $[number % 2] == 0 ]]; then
> + return 1
> + fi

While 2 itself is prime the above returns 1 for any even number.


> + for ((i = 3; i * i <= number; i += 2))
>   do
> - [[ ${i} == ${number} ]] && return 0
> + if [[ $[number % i ] == 0 ]]; then

An inconsistent space after "% i" here. I don't know what style is correct.


//Peter

Re: [gentoo-dev] EAPI 8 is here!

[Peter Stuge]

Sam James wrote:
> * Brings IDEPEND, usev enhancements, --disable-static by default, and more!

How to undo that --disable-static ?

I'm asking both for my own ebuilds and as a regular portage user.


//Peter

Re: [gentoo-dev] Packages up for grabs

[Peter Stuge]

David Seifert wrote:
>   mail-filter/bogofilter

In principle I'm interested in proxy-maintaining this but do not have
cycles immediately.

The current ebuild has little special stuff so probably also works for
the #763024 bump without much change - though I'd like to rework the
rather messy database USE logic..


//Peter

Re: [gentoo-dev] Package up for grabs: sys-boot/lilo

[Peter Stuge]

Hi Joshua,

Joshua Kinard wrote:
> > The base system project is dropping LILO: it really needs to be
> > maintained by someone who actually uses it.
> 
> I'll claim it.

Awesome, thanks a lot.


> Never took a liking to GRUB.  Simpler is better

+1


> However, I am very time-limited, so I will defer to Hank or Peter if they
> wish to tackle any open bugs and I'll serve as final reviewer, tester, and
> committer.

Fair enough, I'll follow up in the bugs. I think my #741912 patch
works but I want to look closer at the clang/musl suggestions.
Thanks a lot for researching that issue!


//Peter

Re: [gentoo-dev] Package up for grabs: sys-boot/lilo

[Peter Stuge]

Mike Gilbert wrote:
> The base system project is dropping LILO: it really needs to be
> maintained by someone who actually uses it.

I also use it.

Hank Leininger wrote:
> I still use/prefer LILO; I'll take a look at the open bugs and
> consider submitting PRs for them & taking on p-m of it.

Hank, please feel free to ping me for another pair of eyes or Cc me on bugs.


//Peter

Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed

[Peter Stuge]

Great idea and happy anniversary! :)

Roy Bamford wrote:
> Here's where I reed your help.

I can't help with that.


Roy Bamford wrote:
> I have a similar media problem with a pile of 5 1/4" floppies. A have a 
> drive that reads all the 5 1/4" formats and a motherboard to connect it 
> to ... until I replace this 12 year old system.
> 
> USB to Floppy interfaces won't do it as they are all made for the data 
> rate used in 3 1/2" floppies.

But with this. Look at these projects:

https://cowlark.com/fluxengine/
https://github.com/keirf/Greaseweazle

And these ready-to-buy products:

https://shop.deviceside.com/prod/FC5025
https://www.kryoflux.com/


Kind regards

//Peter

Re: [gentoo-dev] Idea: User centric kernel configuration

[Peter Stuge]

Hi,

Gerion Entrup wrote:
> the Linux kernel has _a lot of_ configuration options, way too many to 
> configure them by hand.

I actually disagree strongly with that; I think it's important to
actively decide what kernels include, and I routinely do, but of
course not everyone will. I've made sure to include a kernel build
when teaching systems administration courses and would again.

As the kernel becomes more complex the threshold for the first
configuration also rises, but it's still completely possible to learn
what you need in order to successfully configure your own kernel.
I guess it's on the order of a weekend project given some basic
understanding of computer architecture and programming.


> This requires a mapping between user oriented "features" and the kernel
> internal configuration options.

So the challenge here is that the kernel is disjoint from user space,
and while the kernel API remains stable over time consumer requirements
such as "docker" or "cryptsetup" will mean different things for
different versions of particular user space software.


> Do you think that it is useful and feasible to combine these two mechanisms?

AFAIK there's no generic method for formal kernel requirements in user
space packages and there's also no sanctioned method for quering
kernel capabilities. The only thing available is /proc/config if that
was enabled in the kernel build, and there are of course reasons to
leave it out, and it only applies to the particular running kernel,
e.g. useless for cross-compilation. There, it would be possible to
read the kernel configuration file if the kernel source code is
available when the userspace package is being built, but that's not
guaranteed.

In Gentoo, linux-info.eclass provides linux_config_exists() to do all
of this, but order to become a widespread success there would have to
be one method for upstreams to maintain these requirements as part of
their packages, rather than forcing the burden on package maintainers
to repeat the same detective task in every single distribution.

I think it would be very useful to create something generic for that,
but that's certainly no small task.

And realistically I only see it succeeding if Linux Foundation decides
to push it onto the world.


> A possible way could be to automatically extract the kernel config
> flags from the wiki pages and map them to Kconfig options.

At very best that will only be valid for some particular point in time,
like current CONFIG_CHECK in ebuilds using linux_config_exists() are
only valid for particular package versions. At worst it's plain wrong
because the requirements have to be reverse-engineered downstream.


//Peter

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

[Peter Stuge]

Mike Gilbert wrote:
> > > The first big blocker we're going to hit is trustme [3] package that
> > > relies on cryptography API pretty heavily to generate TLS certs for
> > > testing.
> >
> > For which testing? Could it be changed to generate certs differently?
> 
> He is probably referring to the test suite in dev-python/urllib3,
> which uses the python "trustme" package in several places.
> 
> https://github.com/urllib3/urllib3/search?q=trustme
> 
> Someone would need to convince the urllib3 developers to use something
> else to manage certificates in their unit tests.

Ah - non-Gentoo packages - thanks, I understand.

The trustme API isn't very large, so it seems doable to create a
different implementation of it without rust dependencies, add
virtual/trustme and be done?


//Peter

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

[Peter Stuge]

Michał Górny wrote:
> I'm seriously wondering why I'm wasting so much effort on open source.

Open source only ever works when taking responsibility for one's problems.


> I don't see a good way out of it.

I see a couple. Of course all require some effort.

One was already mentioned; move Gentoo package management from Python
to some compiled language. High effort but maximum independence/reward.

Another option, less effort and less reward, is to investigate how much
CPython portage in fact requires, and make that a special package in Gentoo.

This essentially means a special-purpose fork of CPython, only for running
portage. Obviously portage development must then be comfortable without
using the latest shiny Python language stuff that only future RustPython
will offer. I guess that's not a problem.

Yet another is a variant on the previous, but even less effort and
much less reward; freeze what language stuff is allowed in portage code
and always run portage with some chosen existing/later CPython version.


Like libressl and gtk2 this thread also converges on the common point in
my argumentation: it's not per se bad, and sometimes supremely wise, to
quit chasing the latest version, and rest on a known platform.

Coupled with independent efforts to place security-relevant parts in
isolated environments (see sandbox) - ongoing effort regardless of Python -
I don't see why portage couldn't depend on a CPython interpreter of its own,
some last version that works well and is then copied and renamed.

It seems like that would be rather straightforward.

It might also be a good thing to take portage out of the overall Gentoo
Python picture? I don't know here - this bit is just a guess.


> arrogant zealots who want to destroy everything in their path

LOL, priceless.


> The first big blocker we're going to hit is trustme [3] package that
> relies on cryptography API pretty heavily to generate TLS certs for
> testing.

For which testing? Could it be changed to generate certs differently?

CAs aren't magic. Attached is a basic script of mine.


//Peter


mkca.sh
Description: Bourne shell script

Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

[Peter Stuge]

Joonas Niilola wrote:
> There's a script by jkroon in data/api.git
> (https://gitweb.gentoo.org/data/api.git/) that prints the next available
> UID/GID pair for new acct-* packages.

This is super nice! Thanks a lot jkroon!


> It is not forbidden to mix and mash UID/GID between different packages,
> but I'd still suggest to find a new "pair" even if you push just an UID
> or GID. Since we don't seem to be in danger of running out any time soon.

Mh - so the obvious first feature request for the script is to also output
Free UID+GID pairs. Counting them manually in your screenshot I get 36.

That's not a whole lot; just 7% of 500.


//Peter

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

[Peter Stuge]

John Helmert III wrote:
> > Until there's a relevant flaw that will remain unfixed or there is
> > significant incompatibility with infrastructure (recurse my argument)
> > no signs actually exist.
> 
> Waiting until such a problem pops up and bites everyone before doing
> anything about it doesn't sound like a good way to handle it.

I guess that's a matter of opinion. But more importantly, "anything"
can mean a lot, and removing gtk2 is the ultimate sledgehammer.

Deciding to certainly use it at an unknown point in the future seems
unneccessary and premature to me.


> If an application never ports, do you expect the distribution to
> maintain that package ad infinitum?

As always it depends on the required effort.

When keeping the package requires little or no effort I *do* expect it
to not be removed solely because there will be no more releases, which
is really what was stated in the announcement, and why I piped up.


Alec Warner wrote:
>  - I expect gtk2 (the library) to be around for a while. As written it
> gets at least one more release.

Ack. My point isn't about immediate action, rather about what drives decisions.


>  - I expect Gentoo to come after gtk2-only leaf packages pretty hard;
> either to get upstream to port, or to remove them.
>- This is true even if the packages are fully functional with gtk2,
> or don't have other bugs.
>- This is because we will eventually remove gtk2 from the tree
> (which will make these packages unbuildable, and cause their removal.)

That's indeed what I'm trying to give more perspective to.

If there's in fact no other reason to "come after packages hard" and
"remove gtk2" than "no more releases" then I'm strongly against doing so.


> I'm less clear why we would keep libgtk2 in the tree for years and
> years (just to keep nominally unmaintained gtk2 leaf packages buildable?)

This assumes that "maintained" neccessarily means "will port from gtk2"
which I don't agree with at all.

There are many reasons to not port from gtk2 to something else. As long
as there are no concrete problems, especially if one knows the relevant
parts of gtk2 well and is convinced that they are free of issues, there
is in fact no reason *to* port from gtk2. Except if distributions create
one.

It's awfully unneccessary to do that without good reason.


> > Assuming that there will be a significant maintenance burden which
> > affects all uses doesn't seem rational - hence my question.
> 
> I think you need to keep gtk2 (the library) for a fair bit (just like
> we kept python2.7; the interpreter; for a fair while after its EOL.)

I'd argue that python2.7 should remain until demonstrably untenable,
ideally indefinitely.

At some point probably no longer within Gentoo's Python infrastructure -
but at a minimum as a trivial package.


//Peter

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

[Peter Stuge]

Hanno Böck wrote:
> > "It does mean, however, that GTK 2 has reached the end of its life. 
> > We will do one final 2.x release in the coming days, and we encourage
> > everybody to port their GTK 2 applications to GTK 3 or 4."
> 
> I read that as there will be one more gtk2 release and none after that.
> 
> This seems to imply:
> * When there's a security flaw in gtk2 there won't be a fix from
>   upstream.
> * When there's an incompatibility with new infrastructure (e.g. new gcc
>   version / new glibc / changing API of libraries gtk depends on) there
>   will be no updates from upstream.
> 
> This means in all those instances maintainers will have to get patches
> from somewhere. We'll likely end up with some form of
> gtk-2.x-r[largenumber] with a large patchset at some point.
> Maintaining that will be an increasing burden.
> 
> No urgency, but a sign to slowly move off gtk2.

Until there's a relevant flaw that will remain unfixed or there is
significant incompatibility with infrastructure (recurse my argument)
no signs actually exist.

Assuming that there will be a significant maintenance burden which
affects all uses doesn't seem rational - hence my question.

The blog post shouldn't be misunderstood. The intended audience seems
to be application developers, encouraging them to port applications,
not so much distributions.

Distributions quite often overlook that they wield much power, and
thus also have much responsibility.

Of course, GTK maintainers in Gentoo choose what to work on, and have
made many (only?) excellent choices.

I'm merely pleading for rational choices based on actual problems.


//Peter

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

[Peter Stuge]

Peter Stuge wrote:
> We will do one final 2.x release in the coming days, and we encourage
> everybody to port their GTK 2 applications to GTK 3 or 4."
> 
> 
> The recommendation in the blog post is for application developers to
> port to 3 or 4, nothing more and nothing less.

Correction: It /encourages/ porting to 3 or 4. It's not even a recommendation.


> What's the reasoning for this driving "killing off GTK:2" in Gentoo?
> 
> Are there (presently or foreseeable) technical issues with GTK:2?
> 
> 
> Many thanks and kind regards


//Peter

Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

[Peter Stuge]

Aisha Tammy wrote:
> We are now in the process of cleaning up GTK:2 ebuilds and moving the
> packages to use GTK:3 and drop GTK:2 support.

Quoting the blog post you linked to: (thanks for including the link!)

"It does mean, however, that GTK 2 has reached the end of its life. 
We will do one final 2.x release in the coming days, and we encourage
everybody to port their GTK 2 applications to GTK 3 or 4."


The recommendation in the blog post is for application developers to
port to 3 or 4, nothing more and nothing less.

What's the reasoning for this driving "killing off GTK:2" in Gentoo?

Are there (presently or foreseeable) technical issues with GTK:2?


Many thanks and kind regards

//Peter

Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

[Peter Stuge]

Jaco Kroon wrote:
> > I can think of two ways of solving it:
> >
> > 1. We could patch system-installed libtool to respect environment
> >
> > 2. We could regenerate libtool and force local instance of libtool
> > in the packages needing it.
> 
> 3.  Have it always use some fixed compiler somewhere (ie, compile it

4. Make gcc-config regenerate libtool, otherwise as 2.


//Peter

Re: [gentoo-dev] Static libraries

[Peter Stuge]

Alessandro Barbieri wrote:
> > Obviously this will only be useful for packages wanting to statically link
> > with libressl lib{crypto,ssl}
> 
> There is an ongoing effort to remove static libraries from packages.

I know, and I couldn't disagree more with that effort.


> > but I think that's far better than removing libressl.
> 
> No, it's not better, it's more work for the security team.

The security team isn't be responsible for what people do.

Flip side: The security team is also not entitled to decide what people
can and can not do.

Security is a policy and technology generally needs to avoid forcing
policy onto humans, but enable human decisions. You can tell that I
value choice.

It's certainly a good default to use shared libraries, but it's no good at
all to hamper legitimate functionality under a guise of security. That's a
far too common and really diseased pattern throughout society, and it makes
me sad that it proliferates also in Gentoo.


//Peter

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

Hi Jaco,

Jaco Kroon wrote:
> So a few points that I picked up during this discussion.
> 
> 1.  Nobody is AGAINST libressl per sé,

Michał gives me a distinctly different impression.


> 2.  A number of people are AGAINTS the effort involved to make
> libressl work for various packages.

Yes, and I've written that I am as well.


> Without the latter, libressl is dead

On this I disagree.


> since it can't install concurrently with openssl.

Again, that need not be the case, and I'm looking into what's
possible with little to no effort:


Installing both openssl and libressl lib{crypto,ssl}.{a,so} in the same
directory is not possible since file names are the same.

Installing both openssl and libressl .so:s in different directories is
not extremely useful (but perhaps still worthwhile) since one dep for a
given package may pull in openssl and another dep may pull in libressl -
even if path stuff is resolved neatly this doesn't work at load time.
This is only useful for the case of packages explicity needing
libressl, e.g. because of (ab?)use of internals, which have no deps
which can not also use libressl without constant overhead in Gentoo.
Maybe openntpd actually falls in this category.

Installing both openssl and libressl .a files in different directories
seems both useful and straightforward. I don't object to openssl being
favored for /usr/lib here, libressl gets a directory of its own, but
libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
Obviously this will only be useful for packages wanting to statically link
with libressl lib{crypto,ssl} but I think that's far better than removing
libressl.

Installing libressl libtls.{a,so} (built using libressl lib{crypto,ssl}
code of course) in /usr/lib also seems both useful and straightforward.
I expect this to be the default provider for (a new) virtual/libtls.


The latter two cause no conflicts and have no running overhead cost.


> Again, this will mean for libraries that they will need to have
> multi-implementation installations again

This is interesting; I suppose that this is supported very well by Nyx,
and I think it would be a great addition to Gentoo, but in any case it
will not be trivial, and I wouldn't want to make it a requirement for
having /some/ libressl code on Gentoo systems.

Hence I propose to redefine the meaning of "support for LibreSSL" to
what works well without causing lots of overhead. Again: It's not
reasonable for Gentoo to patch the world, but we should model it as
accurately as possible.


> So how do you deal with package-b-libressl vs package-b-openssl in terms
> of dependencies?

I've mentioned a couple of ideas in this thread but they're all
non-trivial and I propose to not solve this problem for now and
settle for less than a full install until someone finds a good,
manageable solution.


> Lots of very finicky risks that needs to be eliminated wih installing
> both openssl and libressl concurrently.

So again, the point is to redefine what "libressl installed" means
such that the problems are avoided, accepting that libressl
lib{crypto,ssl}.so may not get installed, at least for now,
until there's a good solution - which is really orthogonal to
libressl. Quite probably the same solution could then apply to the
other packages in similar situations (ffmpeg/libav, imagemagic, etc.).


> Someone (Michał?) mentioned it's more pain than gain currently.  And
> unless someone is willing to change that, I seriously doubt anything
> you say is going to carry much weight.

I hope it's becoming clear that what I am saying is about /how/ to
change that, and that should carry weight. Consider it brainstorming
solutions if you will.


> having written my fair share of code -

Same.


> the level of ask that you're asking for is much, much larger than I
> think you realise.

I hope what I am asking for is becoming clear. I wrote fairly early
in the thread that it's something other than the status quo.


> mysql and mariadb started out very similar, and now there are two major
> projects, and parts of it are installable separately (client libs).

Off-topic, but I'm really happy about MariaDB! I remember helping with
a MariaDB developer meeting in the early days and I was very excited
that most long-time developers decided to join Monty on MariaDB. Ever
since, MySQL is irrelevant to me. But I do appreciate that people who
are stuck with some Oracle support contract can still use it in Gentoo.


> I trust (hope) that this will give you a small amount of insight into
> what you're asking.

I thought it was clear for a good number of mails that I'm /not/ asking
to continue ensuring that openssl and libressl are interchangeable in
Gentoo;

I'm asking to ensure that libressl stays available /in some capacity/ even
if that can only be as a special case, and it looks like that would
require only very little upfront effort and zero recurring effort.


Thanks a lot for your thoughtful response! I hope I could clarify 

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

Mike Gilbert wrote:
> > It is important to me that you can choose dev-libs/libretls instead of
> > having any libretls code on your systems, but I reject you forcing that
> > choice of yours on everyone else.
> 
> I'm having trouble making sense of this sentence. Did you mean to
> write "libressl" instead of "libretls" somewhere?

Sorry, yes, that's right. "having any libressl code" is what I intended.


> Anyway, it seems like the people maintaining libressl in Gentoo are
> really not interested in keeping it going.

I don't know? There wasn't much discussion about my suggestion to keep
libressl code available in Gentoo in some ways causing no interference
with same SONAMEs openssl.

So again what I'm advocating for is creative ways to at the very least
not have to remove it completely, which I think becomes easy, by
redefining what a libressl ebuild installs for now. At the moment I'm
thinking about these two:

1. no-brainer: libtls .so with libressl implementation

2. more novel: lib{crypto,ssl} static-libs in non-standard location
with libressl.pc in default search path


> A libtls wrapper around openssl seems much more manageable to me,
> and that should probably be the default option for people.

I disagree on both points.

I'm still working on checking what 1. above requires. So far it looks like
the answer will be "nothing"; an ebuild wouldn't need any patch at all,
meaning zero overhead on bumps.

And I for one certainly expect libressl libtls to be the default - that
is the canonical upstream.


Thanks

//Peter

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > > I think the three main ways forward from here would be to either:
> > > 
> > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > 2. Eventually move LibreSSL to libressl overlay.
> > > 3. Eventually remove LibreSSL.
> > 
> > 4. A libressl or libressl-libtls ebuild installs only libtls.
> 
> dev-libs/libretls already does that.

dev-libs/libretls doesn't install a libressl libtls.

This thread is obviously about how the libressl implementation remains
in use.

It's clear now that you want to hinder that in Gentoo at any cost to
the community, but that's not useful, so please take a step back unless
you are actually going to be constructive.

My proposition 4. (which I suggested already earlier - you shouldn't
have ignored it) is obviously not about having any libtls provider in
the tree, but to model reality accurately and ensure that libretls is
the primary and prefered libtls provider, since it is literally the
libtls upstream.

It is important to me that you can choose dev-libs/libretls instead of
having any libretls code on your systems, but I reject you forcing that
choice of yours on everyone else.


//Peter

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> let's summarize what was said so far.

Thanks for the good summary!


> I think the three main ways forward from here would be to either:
> 
> 1. Keep LibreSSL for indefinite time (possibly masked)
> 2. Eventually move LibreSSL to libressl overlay.
> 3. Eventually remove LibreSSL.

4. A libressl or libressl-libtls ebuild installs only libtls.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

We could clearly discuss forever, but since you refuse to engage with
my constructive proposition and my ask for feedback there's no point,
is there? It's super sad that you behave like that in Gentoo.


Michał Górny wrote:
> Choice for the sake of choice is meaningless.

Far from it.


> So far nobody has been able to find a strong argument for choosing
> LibreSSL.  There are strong arguments for using OpenSSL instead.

That's like your opinion, man. :)


> Maybe LibreSSL had promised a better taste in the beginning but today
> 9 out of 10 consumers say OpenSSL tastes much better.

It's usually harmful to optimize for popularity; smoking isn't a good
idea even if everyone in school does it.


> The only difference is that you don't have to pay
> for it (but we do!), so you think that it's free.

Please stop playing the victim and engage with my proposal instead.

I'd appreciate feedback from everyone.


Thanks a lot

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

David Seifert wrote:
> > Maybe because it is so well-known that monoculture is harmful per se,
> > which is why the commitment to choice in Gentoo is very valuable.
> > 
> > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > reputation on code quality.
> 
> Like strong-arming 99% of the users of OpenSSH because they were
> unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
> of the OpenSSH consuming world doesn't actually use libressl? How is
> explicitly tying OpenSSH to libressl not a form of monoculture?

Now we're properly off-topic :) but considering that OpenSSH is developed
for OpenBSD and that openssh-portable is merely provided as a service to
other systems it's easy to understand why OpenSSH (remember, part of OpenBSD)
uses the libressl API for crypto, and why the -portable team is not so keen
on maintaining patches for other crypto providers. Another example is systemd
binding tightly to Linux. In both cases it's understandable, but also quite
unfortunate; better portability would be better.


> Case in point: Have you tried using the official libjpeg package instead
> of libjpeg-turbo? Go ahead, give it a try.

I'll take a look. I chose libjpeg-turbo for a project because it
cross-compiled better.


> "Monoculture"s are mostly a coincidence, not some sinister conspiracy.

I don't claim conspiracy, I just say that it's healthy to avoid them.


> Implementation-diversity-but-API-compatibility is mostly a
> pipe dream, as libav, imagemagick, libjpeg have shown.

I've been fortunate to have a different experience with other codebases.

It's completely possible, but takes (extra!) effort, meaning you have
to really want it. If there is some rivalry then it's also quite easy
to sabotage your colleagues.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > I would be happier if some other developers were able and willing to
> > participate actively in the LibreSSL project.
> 
> But why would they do that?  What I'm really missing in all the replies
> is a single reason why LibreSSL would be better for anyone.

Maybe because it is so well-known that monoculture is harmful per se,
which is why the commitment to choice in Gentoo is very valuable.

Further, LibreSSL comes out of the OpenBSD project, which has a good
reputation on code quality.


> a real proper, verifiable argument 'LibreSSL is better in this regard'.

Choice is about enabling people to decide for themselves.

Choice is /not/ about forcing people to formally prove utility to yourself.


I acknowledge that what I suggest isn't immediately enabling libressl as
a choice either, but it is at least far less destructive than masking and
removal.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Matt Turner wrote:
> > I think many mails in this thread suffer from some tunnel vision, expecting
> > that a libressl ebuild in the tree must continue to work exactly like the
> > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.

To clarify, by "stop that" I mean "stop efforts to make libressl a
drop-in replacement".


> If they suffer from tunnel vision, it's because the intersection of
> "people who care about libressl" and "people who have patches in
> gentoo.git" is the empty set.

Tunnel vision refered not to people but what a libressl ebuild delivers,
which you seems to have turned into an ad hominem against me?

Who will do actual work is a separate question, of course if noone wants
to then nothing matters, but it seems that some people /do/ care about
libressl; I suppose the 61 patches mgorny found were committed by someone.

If you were somehow trying to belittle /me/ then it's certainly true that
I'm not a Gentoo developer, but there are some patches by me in gentoo.git.


> I think we all understand your points: libressl could be kept in-tree
> and allow people to play with it. Unfortunately that requires much
> more work than removing it, and I haven't seen evidence that you're
> prepared to contribute to the required effort.
> 
> I don't think you're going to convince a bunch of people with little
> interest in libressl per se to continue allowing the extra burden
> unless you do the work that's needed to keep it in-tree (e.g., to
> allow it to be installed beside openssl).

You seem to not understand my point at all.

As I've written I (like others) argue against "continue allowing extra burden"
and I've suggested and offered to help with one approach to keep a libressl
ebuild in the tree.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Andreas K. Huettel wrote:
> > I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> > to continuosly patch the entire world for libressel.
> > 
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
> 
> a) The two cannot be installed concurrently. To fix that would require even 
> more hacks.

As we've discussed in another part of the thread, that's not really true.
Both can for sure be installed, just not in the same place and/or
with same names.


> -> all relevant ssl consumers on the user's system must be linked against
> the one selected

Also not the case. Considering the two installed in different paths
with same names it's still easy for consumers to use one or the other
with -rpath at link time.


I do agree that the two are not always 1:1 replacements for each other.
If they are API incompatible somewhere then for sure not.

I think many mails in this thread suffer from some tunnel vision, expecting
that a libressl ebuild in the tree must continue to work exactly like the
openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.


> b) The libraries are not guaranteed to be binary compatible, so switching 
> implementation requires rebuilding consumers.

We can only consider ABI compatibility if we have API compatibility,
which might not even be a given.


> c) If a single package that the user wants to install is not "fixed" for
> one ssl library, it blocks that option for all packages.

Please think of a libressl ebuild in a new way.


> I guess if you can come up with a solution that
> * provides secure usage of the libraries,
> * provides choice to the user, and
> * doesn't lead to unupgradeable systems or unresolvable dependencies
> we'd all be happier. So far we haven't found one.

Right! I think letting a libressl ebuild install only libtls could be a
good start, because it provides a stable situation, without risking
conflicts. Would you agree?


Thanks

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

David Seifert wrote:
> > > I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> > 
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
> 
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs.

Did the debacle actually involve -lssl ?

I guess that it depends on the particular library - with an old library
such as ncurses I can imagine that .pc is much less established, and
I have indeed seen pretty ugly OpenSSL detection in configure.acs,
they could still remain, and would then simply never catch libressl,
I think that would be fine.


> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load LibreSSL and OpenSSL to the same executable.
> > 
> > I'd suggest investigating whether symbol versioning could help with
> > this, or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
> 
> While this sounds like a theoretical solution, it isn't tractable because
> 1. We're inventing our own ABI that is incompatible with everyone else's

ABI for a given library doesn't neccessarily matter beyond the
individual system, does it?

For something like reproducible builds of course it does.


> 2. We'd have to maintain a huge swamp of downstream patches

Nono, no patches of course, it would have to be automatic, if only for the
local system.


> 3. ABI can still break even with perfect symbol versioning

Oh? This may be unrelated, but can you tell more or provide a pointer?


Thanks!

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > /usr/lib/libressl and have the linker link to a specific version,
> > /usr/include/{openssl,libressl} too).
> 
> For the record, this is something I've been wondering about for a long
> time.  However, there are two problems with that: a small one
> and a huge one.
> 
> The small problem is that this requires a lot of additional downstream
> work.  I mean, you have to explicitly support the choice in ebuilds,
> and this means making things even harder for newcomers.

pkg-config/pkgconf and .pc files can help with this part, taking care
of all abstraction if/when downstream uses a libressl.pc.


> The big problem is that (unless I'm mistaken) we won't be able to load
> LibreSSL and OpenSSL to the same executable.  So we'd actually have to
> enforce that the whole link chain links to the same SSL provider,
> and effectively land pretty close to where we are now.

I'd suggest investigating whether symbol versioning could help with this,
or if the only way forward would indeed be to require some symbol
mangling/rewriting.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > net-misc/openntpd
> 
> I've just tested it and it builds fine against dev-libs/libretls.

I hope you're not planning to suggest that dev-libs/libretls should
be the only libtls on Gentoo, since that would be an arbitrary and
artificial limitation - the very opposite of choice. I'm strongly
against that.


Jaco Kroon wrote:
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
> 
> Are you willing to put in the work to allow installing openssl and
> libressl concurrently on the same system?

I'm willing to help. I know that it's one or the other. And I have
experience with distributions making arbitrary decisions about libraries,
and I think I have an idea about the challenges and possibilities.


> The only real solution then to make libressl viable is to make it
> co-exist with openssl reliably.

Ack.


> Of course there are various strategies (or combination of), to mention
> but a few:
> 
> 1.  Use a virtual/??? (but since the APIs aren't compatible despite the
> libressl promise thereto ...)
> 2.  Install them into different prefixes (eg /usr/lib/openssl +
> /usr/lib/libressl and have the linker link to a specific version,
> /usr/include/{openssl,libressl} too).
> 3.  Make ssl USE flag another single-choice USE_EXPAND, posibly by way
> of openssl.eclass.

These are all interesting and I think worth exploring! But also
non-trivial, so maybe better saved for later?

What do you think about my suggestion in a previous email to have the
libressl ebuild install only libtls .so and .a files built from static
libs/objects, so that there are no conflicting shared objects?

I can certainly help accomplish that if there is interest.


> would be in willing and in support of updating the packages I maintain
> to assist with libressl support if the eco system can be improved.

Cool! I really appreciate your openness. I'm asking essentially to
keep options open, so that the ecosystem can be improved step by step.


Thanks

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> 1. Stuff that does not build against LibreSSL.
> 2. Stuff that builds just fine but fails at runtime in unpredictable
> ways (e.g. Tor mentioned today).
> 3. Stuff that builds and works 'fine' but ends up being crippled (e.g.
> doesn't support new algorithms).
> 
> The first one is somewhat easy to test (e.g. via tinderbox).  The other
> two are very hard.

Nod.


> > > Actually, I see that someone has apparently forked libtls into
> > > libretls (the irony!) that works against OpenSSL [1].
> > 
> > To me, that proves value in the libtls API and in keeping libressl in
> > the tree in some capacity, even if not as an alternative to openssl.
> > 
> > Maybe with a USE flag which makes it install only libtls (built from
> > libressl static libs), which could be one provider for a
> > virtual/libtls.
> 
> I don't see why we would put an effort into that.

In my very next sentence (not quoted in your reply) I wrote explicitly
that I do /not/ ask anyone to do so, but ask that you don't hinder it
by masking libressl and also don't remove existing work potentially
supporting such efforts, ie. the libressl ebuild.


> I've just packaged dev-libs/libretls

Thanks! That seems useful.


> Trying to get the same result from libressl is just repeating the work.

Maybe for you, and I'm saying that you should be able to make that choice
for your systems, but also that you should not hinder others from making
another choice, where that's possible and as I wrote without needing
Gentoo to patch the world.


Thanks a lot

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > I'm sure that there are numerous cases where libressl doesn't work,
> > but that's no reason to dismiss cases where it *does*.
> 
> Are you asking people to put an effort into maintaining something that
> can't be practically installed?

No, I'm rather asking to change the level of commitment.

I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
to continuosly patch the entire world for libressel.

I'm asking to stop doing that, yet still enable the choice between
openssl and libressl where that is possible without patches, even
if that's only openntpd and one other package.

The method for that choice could of course depend on the number of
packages where it applies.


> A side effect of this approach is that users will be tricked into using
> LibreSSL, only to discover that they eventually have to transition
> their systems back.

I believe I'm asking for the opposite. I think it's fine to say that
libressl has to be a deliberate choice rather than a default.


> > Did anyone gather actual numbers?
> 
> $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l
> 61

I'm more interested in the number of packages which can use either
library without patches (like openntpd?). This may be tricky to find out. :\


> > > > B. It brings its own TLS API, a unique feature which by itself
> > > > warrants the package.
> > > 
> > > ...which by itself has no future
> > 
> > That's arrogant and silly coming from anywhere but upstream.
> > 
> > You can argue that you will never use the API in your TLS programs,
> > but even then that says really nothing about the API provider itself.
> 
> That's my opinion and I have a right to have it without being insulted.

You absolutely have a right to your opinion but you stated it as fact,
that made me react so strongly.


> I don't dispute whether it's good.  I dispute whether tightly binding
> it to a problematic LibreSSL is a good idea.

I agree with this, but only in cases where libressl is indeed problematic.

I can think of systems where it isn't, there the choice is a good thing.


> Actually, I see that someone has apparently forked libtls into libretls
> (the irony!) that works against OpenSSL [1].

To me, that proves value in the libtls API and in keeping libressl in
the tree in some capacity, even if not as an alternative to openssl.

Maybe with a USE flag which makes it install only libtls (built from
libressl static libs), which could be one provider for a virtual/libtls.

Note: I'm not at all expecting anyone to do such work for me, I just
don't want it to become impossible (libressl mask) or any existing
effort supporting something like the above to be sunset.

Does that make sense?


Thanks!

//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> > A. It is a distinct implementation with probably /quite some/ stable
> > compatibility, meaning that it will work perfectly fine as an
> > alternative in many cases.
> 
> Except that it doesn't, as has been proven numerous times.

I'm sure that there are numerous cases where libressl doesn't work,
but that's no reason to dismiss cases where it *does*.

Did anyone gather actual numbers?


> > B. It brings its own TLS API, a unique feature which by itself
> > warrants the package.
> 
> ...which by itself has no future

That's arrogant and silly coming from anywhere but upstream.

You can argue that you will never use the API in your TLS programs,
but even then that says really nothing about the API provider itself.


> > More elaborate OpenSSL API users can (arguably should) just block on
> > libressl instead of requiring patch work.
> 
> It's all nice theory but in practice it means that nobody will be able
> to install libressl because some important system packages will block it.

Gentoo can't be expected to do magic. If libressl would conflict on another
system then of course it will on Gentoo too. Give users more credit here.

Also, think more about other use cases than your own. I mentioned one;
non-releng stages. The point here is that it's possible to deliberately
create a system using libressl by making tradeoffs, e.g. not using some
"important" system packages which would block it.

Finally, I find it quite beautiful if Gentoo can clearly show that
important system packages have slipped far down a monoculture slope -
this is a great incentive for new projects which tackle creating
alternatives for those packages.


> waste our users' time pretending that we do support LibreSSL,
> while anyone actually trying it will hit a brick wall.

You shouldn't pretend to be something you are not. With a little effort
to set users' expectations according to the technical reality (a function
of upstreams; rather unrelated to Gentoo) I don't expect wasted time.


//Peter

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

Michał Górny wrote:
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.

I think that's a horrible idea, since Gentoo is about choice and this
particular component is one of the most important in a system.

But "support" can mean different things...


> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?

Yes, at least two:

A. It is a distinct implementation with probably /quite some/ stable
compatibility, meaning that it will work perfectly fine as an
alternative in many cases.

B. It brings its own TLS API, a unique feature which by itself warrants
the package.


> All this considered, provided that nobody is able to find a good reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.

There is no reason at all to do all three of those atomically:

1. Stop patching packages to make them build also against libressl
2. Stop maintaining libressl-*.ebuild
3. package.mask

I think the complaint is really only about 1. and I can understand
that the effort here outweighs the perceived benefit, that's fine,
I don't think it's the responsibility of Gentoo developers to patch
the world to build also against libressl.

But as long as a single package can be built with either openssl or
libressl without changes I consider it appropriate to maintain both
libressl ebuilds and either virtual/openssl or another way to decide
system-wide to use libressl instead of openssl. This remains very
valuable especially for non-releng stages.

More elaborate OpenSSL API users can (arguably should) just block on
libressl instead of requiring patch work.


//Peter

Re: [gentoo-dev] libressl / libtls

[Peter Stuge]

Paul B. Henson wrote:
> Would it be possible to have a use flag such as 'libtlsonly' or whatever 
> for the ebuild which only installs libtls,

Sure.


> Or have a separate ebuild just for libtls (which couldn't 
> be installed with the full libressl ebuild or vice versa)

That's also technically possible.


I'd personally prefer the latter.


//Peter

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

[Peter Stuge]

Georgy Yakovlev wrote:
> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles
> by the end of the week by updating virtual/tmpfiles ebuild.

Michael Orlitzky wrote:
> Corollary: the tmpfiles.d specification can only be implemented (safely)
> on Linux after all.

So should virtual/tmpfiles differentiate based on system?


//Peter

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Peter Stuge]

Andreas K. Hüttel wrote:
> it's probably time to deprecate the amd64 17.0 profiles!

I for one am not so excited about the amd64 17.1 profiles. On the surface
it appeared to me that one developer has "taken over" just about everything,
which (regardless of the individual) can't be a good thing..


Jaco Kroon wrote:
> ...just wondering where the lib32 => lib symlink comes from now.

baselayout contains a conversion to/from lib symlink(s).


Kind regards

//Peter

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

[Peter Stuge]

Michał Górny wrote:
> Read: it's important to slap users to satisfy developer's wannabes.

LOL! Michał, you managed to squeeze both misrepresentation and ad hominem
into so few words. Please take care. Anyway, you missed my point:

It's important that (the project) developers set accurate expectations
for contributors.


Michał Górny wrote:
> If user puts effort to make a good contribution, the developer
> shouldn't be rejecting it to 'demonstrate other methods'.

Here you confused a couple of different things, maybe you didn't
understand what I meant.

"demonstrate other methods" is something that the Gentoo project does by
enabling choice also in the development process. This is made possible by
self-determined infrastructure in parallel with GitHub. This is important
and valuable both philosophically and practically, and I think Gentoo
should be both proud of it and also proud to present it.

"rejecting" would require an action, that's not the case; we're talking
about simply documenting which developers don't use GitHub, so that
contributions can know the right place to go.

Then there's your opinion that developers should do all that contributors
want. I disagree with that for two reasons:

1. it doesn't scale, and
2. developers too work in their spare time, and choose how they do so


> This is the horrible attitude that kills the project.

In general I think that individual lack of reflection is a far greater
problem than developer workflow choices within community projects.

For Gentoo specifically I think that a fairly small number of structures
are the main reason to rather spend time on other projects - that's off
topic for this thread though.

Assuming good faith and asking for clarification when something seems
negative is always a good idea.


//Peter

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

[Peter Stuge]

Joonas Niilola wrote:
> some of you may already have seen the new packages.gentoo.org page,
>   https://packages.gentoo.org/

I had not seen that - that's wonderful!

I would just request that /packages/ is removed from the start of
package URLs. I understand how this makes request routing more
complicated, but I consider it a significant usability improvement.


..anyway:

> I'm suggesting of adding a new metadata flag to our Wiki's
> User:/Project: page which then prints a message to this page saying
> whether the maintainer (be it project or user), "accepts" or "deals
> with" Github contributions. The wording can be a bit better, but it'd be
> there to **notify** our **contributors** whether their time and effort
> will most likely be wasted making a pull request for this particular
> maintainer.

I think this is a very good feature.

If I ever do become a proper Gentoo developer I will certainly not spend
any time on anything to do with GitHub, and in my current position of
occasional contributor I don't either. The workflow imposed by GitHub
isn't good and it's important to demonstrate other methods.


//Peter

Re: [gentoo-dev] Last-rites: dev-libs/liboobs

[Peter Stuge]

Jimi Huotari wrote:
> # Jimi Huotari  (2020-08-04)
> # No consumers since 2015, and no known stand-alone use.
> # Removal in 30 days.
> dev-libs/liboobs

Wut - isn't that a really poor reason to remove from the tree? :\

Why not just keep it unless there is an actual technical problem?
(Security, maintainability, etc.) If there is, then please mention it.


//Peter

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

[Peter Stuge]

Remco Rijnders wrote:
> I'd like to volunteer myself as proxy maintainer for this package. As
> this would be the first package in gentoo I'd be working on, I ask for
> advice on the following two points:

Note that I'm no developer but have been proxy-maint for some time.


> - Can the removal of this package from gentoo be pushed backwards with
> a month or so to allow me to work on packaging this new version as well
> as do some rudimentary testing to ensure it works properly with Gentoo?

I have no idea about this one.


> - As upstream for this program would be changed, should the name
> getmail in gentoo be kept or would it better to use getmail6, and if
> so, what would be the best way to go about this?

Since you want to avoid clobbering the existing name outside of Gentoo
I think you should strive for the same also within Gentoo. That said,
if the two are interchangeable then a virtual/getmail ebuild would
probably be reasonable.


//Peter

Re: [gentoo-dev] Gentoo/OpenBSD current status

[Peter Stuge]

Benda Xu wrote:
> > I was wondering if the openbsd prefix support is something
> > that is still garnering any interest from gentoo?
> 
> There is still interest in Gentoo.  But no one seems to have energy to
> take care of it.

FWIW I have interest in this as well.


> Your contribution is welcomed.

What contributions are known to be needed at the moment?


Kind regards

//Peter

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Peter Stuge]

Kent Fredric wrote:
> > While services such as reCAPTCHA are (as said) massively intrusive, there
> > are other, much less intrusive and even terminal-compatible ways to 
> > construct
> > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
> > for a human above the response input line - that's not so bad.
> 
> Well, they kinda have to be,

I disagree with that, especially for this service, that was the point I
wanted to make. :)


> the state of AI is increasing so much that current captcha systems
> undoubtedly also develop their own adversarial AI to try beat their
> own captcha.
> 
> I don't think we have the sort of power to develop this.

In any case I don't think that's required.


> And the inherently low entropy of only having 80x23 with so few
> (compared to full RGB) bits per pixel,

A character doesn't compare too bad to RGB. See aalib, or if you
will risk exclusion of color-vision-impaired humans libcaca.


> this gives any would-be AI a substantial leg up.
> 
> Using text distortion is amateur hour these days.
> 
> (and there's always mechanical-turk anyway)

Except this isn't for some web-scale disruptive startup, it's a
statistics/reputation system for an advanced, super-nerdy Linux distribution.

Please think more about the threat model, and remember the rate limit knob.

The bar only needs to be raised high enough.


//Peter

Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel

[Peter Stuge]

Michał Górny wrote:
> Hence my question: do you find 'do not remove kernels listed
> in bootloader config' feature useful?  Do you think it should remain
> the default?  Do you think it is worthwhile to continue supporting it?

I continue to use LILO because simpler and more mature code is good,
especially in the boot code path. I used GRUB for a short while but when
I saw it fail to boot from one start to another (without any OS changes)
I ended that experiment. I also wasn't impressed by the GRUB2 code quality
and tendency to become a mini-OS, trendy as that is.

I don't use eclean-kernel, but FWIW I think there is clear value in
supporting the LILO-style approach with explicit installation/configuration
of the bootloader in advance.


//Peter

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Peter Stuge]

Stop motivated attackers or keep low barrier to entry; pick any one. :)

Michał Górny wrote:
> CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
> for one CAPTCHA).
> 
> The advantage of this method is that it requires a real human work to be
> performed, effectively limiting the ability to submit spam.
> The disadvantage is that it is cumbersome to users, so many of them will
> just resign from participating.

While services such as reCAPTCHA are (as said) massively intrusive, there
are other, much less intrusive and even terminal-compatible ways to construct
a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
for a human above the response input line - that's not so bad.

Attacking something like a server-generated maths challenge rendered in a
randomly chosen and maybe distorted font would require OCR and/or ML, which
is fairly annoying. The only real problem then would be with OCR packages. ;)

Combine with a rate limit that is increased manually as the service grows
more popular. It can be a soft limit which doesn't report failure but results
in queueing+maybe vetting of reports, to allow some elasticity for peaks.


//Peter

[gentoo-dev] user.eclass ignores ROOT/SYSROOT

[Peter Stuge]

Hi,

I'm trying something out over here and I'm surprised to find that
acct-group/* do not work with ROOT+SYSROOT != "/".

Should I file yet another bug about this?

I suppose the limitation is in user.eclass, but what about the 11 bugs
already filed about exactly this problem?

They are easy to see in the dup bug list at https://bugs.gentoo.org/53269

Unfortunately mgorny closed 53269 WONTFIX because GLEP-27 is Deferred,
causing all dup and dep bugs to be forgotten. Sad panda.


--8<-- reproduce
# export r=$(mktemp -d)
# ROOT=$r SYSROOT=$r strace -fe execve emerge baselayout acct-group/ftp 2>&1 | 
grep groupadd
[pid 13269] execve("/usr/sbin/groupadd", ["groupadd", "-r", "-g", "21", "ftp"], 
0x5d7e299e2340 /* 227 vars */) = 0
groupadd: cannot lock /etc/group; try again later.
 *   groupadd -r ${opts} "${egroup}" || die
 *   groupadd -r ${opts} "${egroup}" || die
-->8--

In my particular case -R $r would work just fine, but as can be seen
in several of those 11 dup bugs it is not a general solution.


Any ideas on how to solve this?


Thanks

//Peter

Re: [gentoo-dev] zoom concerns

[Peter Stuge]

Kent Fredric wrote:
> Syntax above not expected verbatim, just food for thought,

I think this is a really good and useful idea. I would love to see it.


> the nature of this metadata is that it SHOULD NOT be in the ebuild
> itself, as it is inherently "repo based", the installed values of
> these are worthless.

E.g. for auditing the installed values of these could be worth a lot.


Thanks!

//Peter

Re: [gentoo-dev] ceph's static-libs

[Peter Stuge]

James Le Cuirot wrote:
> Damn, I realised just as I hit send that there's a caveat here and
> that's sub-dependencies. If you're building a partially static binary
> then I think you're okay. A fully static binary obviously needs all its
> dependencies to be static and that includes any sub-dependencies.

Note that there isn't really a way to express "partially static" to the
toolchain when building a binary.

If you link a binary -static then that is always "fully static". No .so
will satisfy any -l options.

The only way a "partially static" binary gets created is when linking
*without* -static but some -l libraries only exist as static libraries,
or if a library/object archive is specified with full .a filename,
without using -l.

And "partially static" also only means that some dependencies were
included into the binary, but unlike "fully static" the binary is
not runnable without ld.so and a fitting libc.


> If an executable statically links libwebp.a with JPEG support but you
> don't have libjpeg.a then you'll end up with undefined references.

It's a bit more complicated..

Assume: ( note: without -static )

gcc -o binary source.c /usr/lib/libwebp.a

If libwebp requires libjpeg, and libwebp was not built to include
libjpeg.a then the above will not build. So we try:

gcc -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a

If both .a exist this builds, but binary is still *not* linked statically,
at a minimum, ld.so and libc are still required to run it.

If we do:

gcc -o binary source.c /usr/lib/libwebp.a -ljpeg

Then the compiler will pick any libjpeg that is available, preferably
.so but if that can't be found then it will also look for .a. binary is
still *not* static.


Finally consider:

gcc -static -o binary source.c -lwebp -ljpeg
gcc -static -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a

The above two are equivalent, but only thanks to -static. This fails
if either library .a is not found. When this succeeds, we have a static
binary, which runs anywhere regardless of ld.so and libc.


pkg-config .pc files for libraries are a very convenient solution to
the problem of sub-dependencies. In the above case, libwebp.pc would
perhaps have -lwebp in Libs and libjpeg in Requires.private (or maybe
-ljpeg in Libs.private).


> That probably explains why the ceph dependencies are as they are

I think USE=static-libs is nice to have, and ideally (IMHO) it would
be a global USE flag, respected by every package that installs a
library. The flag says nothing about consumers, it only promises
availability of the .a files, which I think is nice.

One technical reason for a consumer to DEPEND on libotherpackage[static-libs]
would be if an upstream Makefile has /usr/lib/libother.a instead of -lother,
arguably it would make more sense to apply a patch to the Makefile then.

Another technical reason would be that libotherpackage doesn't adhere to
common sense/best practice for library ABI/API compatibility, and make
the static library *different* from the shared object. If libotherpackage
maintainer heroines have made it possible to have one SLOT installed as
static library and another, incompatible, SLOT installed as shared object
and the consumer maintainer might know that only the static variant works.
This one is very hard to do anything about about in Gentoo, but it is also
a very construed case. The closest I've seen to this is giflib, which
changed API and ABI without bumping SONAME.


//Peter

Re: [gentoo-dev] Use acct-* for qmail users

[Peter Stuge]

Mike Gilbert wrote:
> Do the users actually need home directories?

Technically probably no, but ~qmail is easier to type than /var/qmail.

TBH I actually always type it out anyway.


Mike Gilbert wrote:
> If you don't want to maintain them, you'll need to find someone else
> to do it.

If noone else wants to take this then you can add me as proxied maintainer.


//Peter

Re: [gentoo-dev] Gentoo i486 support

[Peter Stuge]

Rich Freeman wrote:
> Is there a large population that actually runs x86 on modern
> hardware, or is ancient hardware a significant use case?

There are current products with pre-686 instruction sets.

Companies such as DM still produce 586-class SoCs for embedded and
industrial. These[1][2] are current products.

And Intel Quark[3] is another one.

I prefer option number 1 as suggested in the initial mail.


//Peter

[1] https://en.wikipedia.org/wiki/Vortex86
[2] http://www.vortex86.com/?p=264
[3] https://en.wikipedia.org/wiki/Intel_Quark

Re: [gentoo-dev] News item review: OpenSSH LDAP support

[Peter Stuge]

Hi Thomas, I suggest some improvements..

Thomas Deutschmann wrote:
> Title: OpenSSH LDAP support

Perhaps qualify this a bit, e.g. "Migration required for OpenSSH with LDAP"


> When your sshd authenticates against LDAP, you have to migrate your

s,When,If,

> current setup to a new one using sshd's "AuthorizedKeysCommand" option and
> use

s, use,,

> a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey
> because beginning with net-misc/openssh-7.7_p1, deprecated OpenSSH-LPK
> patch set no longer applies.

Maybe "because beginning with net-misc/openssh-7.7_p1 the OpenSSH-LPK
patch set is deprecated and no longer applies."


Thanks a lot!

//Peter

Re: [gentoo-dev] Adding USE=udev to linux profiles

[Peter Stuge]

Mart Raudsepp wrote:
> > * USE=udev means different things for different packages. You think
> >   it "makes udev work" or whatever, but nobody has any idea what it
> >   does for half of the packages that use it. The meaning is package-
> >   specific, so the default should be package-specific.
> 
> It makes hardware work without static configurations, including when
> hotplugged.

That's not really a complete description...

1. Linux always sends netlink messages on device changes.

2a. If running, udevd receives those messages and executes all udev rules.

2b. udevd then sends its own netlink messages, after executing rules.

3. libudev consumers receive messages from 2b.

libudev and udev in general is thus an abstraction of the kernel
information exposed in 1. It is possible, easy, and at times strongly
preferable to skip the udev stack and just consume 1. messages
directly. I know of at least one package which does exactly that
on USE=-udev, I can only emphasize that the meaning of USE=udev is
completely package-specific. There are several possibilities what to
do in an upstream package when libudev can or should not be used, and
I for one don't think profiles/ebuilds should neccessarily model them.


> It should be enable by default for all Linux users.

I disagree. Linux is used more widely than that.


> The default shouldn't be "nothing works, until you make it work".

I agree completely, but please don't assume that no Linux system will
work without USE=udev.


I think the viewpoint of rearranging profile inheritance makes a lot
of sense. Profiles are super powerful, expressive, and cheap! I think
it would be fine to add another level of inheritance for udev.

Maybe there is a clever trick with a profile for each desired USE flag?
Somehow dynamic profiles? Dunno - just an idea.


Thanks!

//Peter

Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

[Peter Stuge]

M. J. Everitt wrote:
> I'm thinking something along the lines of the following:
> - Line one is limited to / and some Key Word that defines the
> type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP,
> EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the
> issue of long package-names and/or overlays and other lengthy prefixes.

This would remove one of two information atoms in commit messages,
reducing human expression in commit messages to mere 50%,
or to 0% for --oneline output.

I think that's unacceptably poor usability.


> This should satisfy line length limitations,

My counter-proposal is to bup the repoman line length limitation.


//Peter

Re: [gentoo-dev] x11-terms/xterm up for grabs

[Peter Stuge]

Johannes Huber wrote:
> I will take it.

Thanks. I can help as proxy-maintainer if you like.


//Peter

Re: [gentoo-dev] newsitem: baselayout 2.5 changes (round 2)

[Peter Stuge]

William Hubbs wrote:
> The first change is that ROOTPATH is no longer set. This means all of
> the *sbin directories will be added to the default path for all users
> instead of just the root user.

Maybe add a sentence about why this is changing or even neccessary,
to avoid perception of weakened security.


//Peter

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Peter Stuge]

Maybe this is a discussion for -project, then?


Andreas K. Huettel wrote:
> a few outside trolls who
> * keep pushing their personal agenda in endless threads,
> * confuse their own inability to contribute with being a mistreated underdog,
> * and keep commenting opinionated on technical things they plainly have no 
>   clue about (while whining when are told they sprout bulls##t).
..
> Andreas K. Hüttel
..
> (council, toolchain, perl, libreoffice, comrel)

You Sir are IMHO neither fit for the office of council nor of comrel,
solely based on your communication style in that one mail.


I would not vote for you, and would vote against you if that's even possible.

//Peter

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

[Peter Stuge]

Andreas K. Huettel wrote:
> 
> Independent of whether William now unsubscribed or not, he's now enjoying a 
> lengthy (1 year until review) vacation from all Gentoo communication channels.
> 

I don't understand two things about Gentoo:

1. style: How can anyone consider "enjoying a vacation" to be
appropriate wording in this context? That is at a minimum tasteless.

2. substance: Why would William be blocked from Gentoo for a year?

How and/or where will these two points be clarified?


Thanks

//Peter

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[Peter Stuge]

Daniel Campbell wrote:
> On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote:
> > I'd like to establish the following changes to the mailing lists:
> > 
> > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> > initially restricted to active Gentoo developers.
> 
> I don't think this plan will have the effect you're going for,

I agree, and I'll double down on my previous comment on this proposal:

I consider the proposal to be the wrong solution.


> but let's be honest here: the "RFC" is just a formality; the decision's
> already been made.

I hope that a mere proposal doesn't automatically mean policy change.


> If the "real leaders" of Gentoo want to divide and fragment the
> community, it's their prerogative.

When there is a request for comments, there should also be comments. :)

Far too many fall into the simple trap that is tribalism, and I'd like
to encourage everyone on this list to not be that kind of person,
because there really is no "us and them", there is only "us".


> As we tell users who do something they're not supposed to: You get
> to keep the pieces.

Well, let's see what happens, now that both developers and
non-developers have clearly spoken out *against* this proposal.


Kind regards

//Peter

Re: [gentoo-dev] We Are All wltjr On This Blessed Day

[Peter Stuge]

William L. Thomson Jr. wrote:
> No one questions why I stepped down.

I have wondered what happened, but haven't felt able to investigate.

Please know that I wouldn't take sides without investigating, and I
think that an overwhelming majority is also like that. A problem is
that you'll only ever hear from those who do take sides, but I think
the vast majority doesn't.

In the end I think giving up any position comes down to one of two things:
either feeling that one can not sufficiently meet expectations, or feeling
that others do not meet one's own expectations. I've experienced both.

How those happen is probably always a sad story of personal differences. :\


> I let others convince me I was the problem so I went away. Yet things
> did not improve in my absence. Maybe I wasn't the problem

I hope that everyone always learns. I think almost everyone does.


William L. Thomson Jr. wrote:
> > doing whatever you did to get banned from  GitHub
> 
> You tell me does this make any sense to ban someone from Gentoo's Github?
> https://github.com/gentoo/gentoo/pull/1721#issuecomment-300178677

It doesn't make sense to me, because you're trying to help inform a
community contributor. But I also don't know any of the "Gentoo Java"
context - which I think also matters.

Reading the motivation for the ban "not the place to post comments and
recount how Gentoo Java is struggling with its staffing needs" and
"GitHub ..  [is] for code-centric feedback and technical discussions,
not about Gentoo-meta issues or the like" I can understand that someone
would feel that your comment was out of place, but I don't think that
a 14 day ban is an appropriate first response.

That said, expectations were clearly not met, all around.

The expectations of the community contributor were not met by Gentoo,
since (as is mentioned in the ban mail) Gentoo is not a typical GitHub
project, where a PR is the entire process into the repo. I think it is
perfectly fine to communicate about this in a PR, and I think a Gentoo
policy never to do so is a mistake.

The expectations of the Gentoo GitHub Project were not met by you,
since it seems a PR policy is "Everyone can review pull requests. 
However, please make sure that your comments are correct and on
topic." and your comment was also trying to inform about the larger
context, not strictly limited to technical details.

I personally disagree with such expectations in the GitHub team, but I
can't even be bothered to become a proper Gentoo developer, because the
threshold is just too high for me.


I would attribute the contributor's (very valid) disappointment to lack
of communication, ie. to Gentoo not having set accurate expectations.
It is probably true that Gentoo isn't equipped to do so at the moment,
so everyone has to learn on their own. Some will get burnt in the process. :\


> https://github.com/gentoo/gentoo/pull/6033
> I felt I should have responded to not be rude.

I agree with you, and you seem to always respond politely. While I
sometimes find it a bit difficult to understand what you intend to
say because of your writing style, it looks to me like you always
intend to equip others with useful information.


> I still do not respond in kind to others.

I think that shows good character. Please keep that up, no matter what
others do.


To the actual topic of Gentoo Java I think the best you can do is
essentially what you are already doing - work on solving your own
problems in your own overlay, if there is a kind of informal team
working mostly to provide life support. You can try to support them,
but you may have very different needs, and if communication doesn't
work so well then there can't be an actual team.

I rarely use Java, but what I do know about Java supports your
argument that Gentoo could need a lot of work for JDK 9, because
the expectations/assumptions of the Java ecosystem are quite far
apart from those of the Gentoo ecosystem, and if a great solution
is even achievable at all then it certainly requires mastering both
Java and Gentoo, which likely requires Java people to get into Gentoo
rather than the other way around, and both environments have long
learning curves, and until there is a critical mass of developers
mastering both, there can't really be a team. :\


Kind regards

//Peter

Re: [gentoo-dev] We Are All wltjr On This Blessed Day

[Peter Stuge]

I'm quite unimpressed by how mgorny and jstein behave there.

I wouldn't accept that, were I leading the project.


//Peter

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

[Peter Stuge]

Hi Michał,

Michał Górny wrote:
> major problems with some of the posters for more than a year.

Please believe me when I say that I know what this feels like.

I want to applaud and thank everyone who has been tackling/discussing
this issue in private, and I especially want to applaud taking action!

I however disagree with the proposal to move the problem.

I would like to encourage everyone, but in particular devs, to watch
this 18 min talk by Donnie Berkholz from 2012, about Gentoo actually:

Assholes are Ruining Your Project
https://www.youtube.com/watch?v=-ZSli7QW4rg

If you don't want to, then the most important take-away as stated by
Donnie and supported by my own experience having "my" project ruined
is:

Do not tolerate bad behavior by anyone!


> The problems of more abusive behavior from some of the mailing list
> members have been reported to ComRel numerous times. After the failure
> of initial enforcement, I'm not aware of ComRel doing anything to solve
> the problem.

While reading your message, I kept thinking to myself: "isn't this
the very purpose of ComRel?"

I only have a non-dev understanding of ComRel, but I agree with Matt that
inaction in this situation is a failure of ComRel, and that should not be
to the detriment of any constructive contributor on gentoo-dev.


> A. Bans can be trivially evaded
> B. People should be allowed to express their opinion

Mh, so-so. It is important to take action which clearly rejects
unacceptable behavior. Otherwise any behavior is per definition
implicitly accepted, which attracts assholes.


> C. The replies of Gentoo developers were worse

This should *also* not be accepted. Equal standards for what is
acceptable and what is not must apply to everyone.

It could be argued that different people deserve different sanctions.
I would agree with that only as far as there is a mentoring process in
place, requiring a third party to work on eliminating bad behavior.

I think that's the purpose of DevRel for developer<->developer, and
ComRel for developer<->non-developer.

Yes, such mentoring requires a non-negligable committment to
non-trivial work.

It is clearly not always possible to mentor bad behavior away. Then
that person must be shut out to save the environment, whether a
long-standing developer or not!


Coming back to the concrete proposal, I think a better course of
action is to demonstrate strong leadership, by speaking out in force
against bad behavior, every time.

In order to have something to lean on, it can be super helpful to
have a code-of-conduct in place, and was already mentioned.

I had to think about code-of-conduct for a long time, before my
mental model of them "clicked". I consider them to be about
explicitly stating the community expectations for good behavior,
and as an agreed-upon reference for (sometimes unpleasant, but
incredibly important) forceful action in reponse to bad behavior.


> The alternative suggested by ComRel pretty much boiled down to 'ignore
> the trolls'.

I find this highly inadequate.


I urge either ComRel or other leadership to take as forceful action
as is neccessary against bad behavior, to uphold a healthy
environment.

Selective moderation is a more technically sophisticated ban. If
possible that's cool. If not possible that's perfectly fine. Just
ban. Keep banning if the bad behavior resurfaces with another
identity.

Please do not relent. It is not fair to yourself or your colleagues.


Thank you and keep up the excellent effort everyone

//Peter

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[Peter Stuge]

William L. Thomson Jr. wrote:
> Or uber minimal, can't get much smaller still 5.20s
> https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
> https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac

Consider

AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman])

foreign in particular if you would like to skip the various UPPERCASE
files in the project root.


//Peter

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[Peter Stuge]

William L. Thomson Jr. wrote:
> Or uber minimal, can't get much smaller still 5.20s
> https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
> https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac

That takes 2.0s here, on quite old hardware, though with primed cache.


> #secondsmatter :)

Yeah! :)


> The dependency aspect I agree with 100%. I think even cmake has more.

cmake itself is the dependency. ;)


> Or who cares about end users, its all about saving devs time, no clue.
> #mesonbandwagon

End users generally consume behind a distribution build process, so
yes, it's all optimization for development time, which makes some sense.


//Peter

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[Peter Stuge]

William L. Thomson Jr. wrote:
> I cannot understand why systems get faster, yet configure seems to
> take the same amount of time and is super slow.

The generated configure scripts can be fork intensive, which is still
fairly expensive.

But I think the problem is more with poorly written configure source,
which is the argument about mastering..


> On small projects configure can take longer than compile... Configure
> is my main gripe against make/autotools. Plus all the other stuff,
> auto-reconf, autogen, etc.

configure having zero dependencies is the killer feature compared
to all other options. The tight integration between configure and
cross-toolchains is also a very strong point.


> The larger the project, the slower configure can be.

Doesn't have to be, but it's easy to write poor configure source and
difficult to write good source.


//Peter

Re: [gentoo-dev] Re: cmake + ninja vs autotools

[Peter Stuge]

Martin Vaeth wrote:
> > 1.  Doing a full clean build [..] the speed of make or ninja is hugely
> > offset by the compilation speed, and their overhead is negligible.
> 
> It depends on the definition of negligible. For huge projects like
> boost or chromium it is several minutes

It's arguably a bug that a projects gets huge.

The simplicity of configure+make is difficult to beat, but I also
agree that it's difficult or at least tedious to master autotools.

That is arguably reason enough to choose meson, but I think I will
stay with autotools for a while..


//Peter

Re: [gentoo-dev] Java 9 on Gentoo

[Peter Stuge]

William L. Thomson Jr. wrote:
> > If you have any suggestions as to what I should look at to better
> > understand the OpenJDK build system I would very much appreciate
> > them.
..
> Build OpenJDK stand alone. Get familiar with that.

It used to be that one could not build OpenJDK without already having a
working JDK. Has that changed with OpenJDK 9 (IIRC it was planned for
OpenJDK 7 :) or not yet, and that is a reason for having icedtea in the mix?


//Peter

Re: [gentoo-dev] Package up for grabs

[Peter Stuge]

Michał Górny wrote:
> W dniu nie, 23.07.2017 o godzinie 16∶13 +0200, użytkownik Manuel Rüger
> napisał:
> > dev-libs/libgit2
> 
> I'm going to co-maintain this with the full set (-glib, pygit2). I've
> used it in the past, and I think it'll still come in handy
> in the future.

I too have some interest in libgit2, but not much experience with
upstream. I'm thrilled that leio and mgorny are on it, I don't think
I can contribute much.


> > net-libs/libssh2
> 
> I'll co-maintain this as well as an important dep of libgit2.

FYI I'm part of upstream. The project mailing list is a perfect point
of contact, but you can reach out to me as well.


//Peter

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

[Peter Stuge]

Alexander Berntsen wrote:
> While the PMS perhaps hasn't been an unequivocal success, it's still a
> good effort with some success. I would be disappointed to see the
> proposed change, and view it as a bad sign for Gentoo.

As far as technical documentation about how ebuilds work (the core of
Gentoo, but also many other distributions; I have created several of
my own), PMS is an absolutely amazing document!

It comes down to whether Gentoo is a "meta-distribution" with
absolutely amazing generic tooling (including portage), or "simply" a
source-based distribution with an arbitrary package format.

PMS has tremendous value, and yes, EAPI is a process, and I am sure
that portage developers gnash their teeth at blockers stemming from
PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
all better off for it.

Without knowing specifics I guess I would suggest to the original
poster to create new tooling for the job that needs to be done. Maybe
even a fork of portage, at first only used in your (derivative)
Gentoo distribution? Just my idea for a possible solution.


//Peter

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

[Peter Stuge]

Michael Orlitzky wrote:
> All this is to say that "easy to read" is in the eye of the beholder.
> For ebuilds in the tree, the beholder is usually the maintainer, which
> is why I think the choice should be left up to him.

I think what mgorny says is that locality of ebuilds is an important factor.


> Our ebuilds are bash programs, and in source code, "as little
> duplication as possible" is a strong contributor to "easy to read."

Here's an idea: Could a little bit of automated (but obviously checked!)
de-duplication be made [an optional] part of adding an ebuild into the
tree, and please everyone?


//Peter

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Stuge]

Michael Palimaka wrote:
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.

So that's either because of an ebuild bug (incorrect DEPEND) or an
upstream bug (e.g. incorrect PKG_CONFIG_CHECK in configure.ac), right?

It seems to me that waiting (random()=30) days and then testing
against (random()=current-version) libbaz in stable isn't amazing. :)

The ebuild bug could be detected automatically for upstreams using
configure.ac and maybe also cmake.

The upstream bug, well, that's a bit more tricky.


I'll try to write a thoughtful response in the other part of this
thread later. Gotta run now. Thanks everyone for your insights!


//Peter

Re: [gentoo-dev] New eclass: opam.eclass

[Peter Stuge]

Good work on the refactoring!

Alexis Ballier wrote:
> > >   if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then  
> > 
> > It’s always been recommended to me that we should use the [[ … ]]
> > form.
> 
> Doesn't make much difference here

Some; you need neither quote nor {} in expansions within [[ ]]. So
instead of the above one could write:

if [[ -d $ED/usr/share/doc/$PF/$PN ]]; then


> and I've always been recommending the other way :p
..
> if you only do ebuilds or bash, then you don't care, but I definitely
> do other scripts

Be that as it may this is an eclass, and I think conforming to an
established coding style has significant value. I too have understood
that to be [[ ]].


Thanks

//Peter

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Stuge]

Thank you for working on this.

Sergei Trofimovich wrote:
> Can this proposal make a difference and make gentoo better and
> easier to work with?
> 
> Does it try to attack the right thing?
> 
> Does it completely miss the point?

I hold a perhaps radical view: I would like to simply remove stable.

I continue to feel that maintaining two worlds (stable+unstable)
carries with it an unneccessary cost.

Based solely on how excellently unstable (and similar approaches before
using Gentoo) works for me in practice, I believe that skipping stable
and instead focusing efforts on resolving problems reported in unstable
a little quicker would yield a much better end result - and would net
positive dev time.


> Does it sound fun?

Sorry, no, not to me. It sounds like "double" overhead. :\


I consider dev time a precious resource. Devs should need to do as
few things as possible, to keep things going, and should be able to
immediately reuse as much input from the wider community as possible.

More troubleshooting and fixing "hard" problems, less routine work.


//Peter

[gentoo-dev] Sanity check: enewuser in binpkg with portage-utils

[Peter Stuge]

Hi,

I have some ebuilds which use enewuser to create groups and users in
pkg_setup(), and make use of those groups and users in src_install()
in exeopts, insopts etc.

Is there any reason that this would not always work reliably with
binpkgs?

Ie. regardless of whether I am using portage or portage-utils to
install binpkgs with such pkg_setup() and src_install() combinations?

Should it matter if the groups and users already exist? I expect no.

I would expect it to always work reliably, because exeopts/insopts
user and group arguments are looked up by install at run time.

I think I had a problem with this yesterday, but I can't reproduce it.


Thanks

//Peter

Re: [gentoo-dev] Integrating Ada into toolchain.eclass, again

[Peter Stuge]

Luke A. Guest wrote:
> Thoughts?

I can't comment on your strategy, but I do agree with and support
your goals of being able to use more Ada in Gentoo.

Thanks to you and others for your work on this! :)


//Peter

Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize

[Peter Stuge]

Alexis Ballier wrote:
> > If elibtoolize results in different binaries being produced, then it's
> > done wrong in the first place. AFAIU the primary goal of elibtoolize
> > logic is to fix issues on recent systems with outdated build systems.
> > Which is certainly not something that needs to be done for every user
> > out there.
> 
> You probably didn't have a look at what the patches fix. Having a
> quick look at patches there,

Where are those patches you mention?


> I could fine one fixing relink to old libs (from / instead of $D),

I have an open bug for this for a package, both in Gentoo and
upstream. It seems to be a problem with libtool itself, is that
about right?


> another one fixing parallel install. The former produces broken
> binaries, the latter none at all.
> 
> I seriously doubt this shouldn't be fixed for every user.

What "this" do you refer to? Sorry for the confusion, I want to understand.


//Peter