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

2021-02-10 Thread 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

2021-02-10 Thread 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

2021-02-09 Thread 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

2021-02-08 Thread 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

2021-02-08 Thread 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

2021-02-08 Thread 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

2021-02-08 Thread 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.

2021-01-11 Thread 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

2020-12-31 Thread 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?

2020-12-31 Thread 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?

2020-12-31 Thread 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?

2020-12-30 Thread 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?

2020-12-30 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-29 Thread 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?

2020-12-28 Thread 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?

2020-12-28 Thread 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

2020-12-11 Thread 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

2020-11-26 Thread 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?

2020-11-09 Thread 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

2020-08-18 Thread 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

2020-08-18 Thread 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

2020-08-03 Thread 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

2020-07-21 Thread 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

2020-06-01 Thread 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

2020-05-24 Thread 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

2020-05-24 Thread 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

2020-05-22 Thread 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

2020-05-05 Thread 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

2020-04-08 Thread 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

2020-04-05 Thread 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

2019-09-15 Thread 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

2018-08-22 Thread 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

2018-08-06 Thread 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

2018-07-20 Thread 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?

2018-07-18 Thread 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

2018-06-25 Thread 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)

2018-02-13 Thread 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

2018-01-11 Thread 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)

2017-12-08 Thread 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

2017-12-05 Thread 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

2017-12-05 Thread 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

2017-12-04 Thread 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

2017-12-03 Thread 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

2017-11-24 Thread 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

2017-11-24 Thread 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

2017-11-24 Thread 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

2017-11-23 Thread 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

2017-11-17 Thread 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

2017-08-23 Thread 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

2017-08-14 Thread 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

2017-08-04 Thread 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?

2017-07-25 Thread 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

2017-07-25 Thread 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?

2017-07-24 Thread 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

2017-07-20 Thread 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

2017-05-20 Thread 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

2017-03-18 Thread 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



Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-11 Thread Peter Stuge
Anthony G. Basile wrote:
> >> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> >> against the bitcoin eclass.  The following is his proposed change.
> >> I'll commit it after review.
> > 
> > Please do not do that, Anthony.
> 
> I don't have time nor the familiarity to properly maintain bitcoins
> myself.

Understood, and no problem. I think it's especially important to be a
bit conservative under those circumstances.


> I will ignore all negative advice regarding this package unless it is
> balanced with positive advice.

That's cool. I tried to also be constructive in my mail - sorry if
that didn't get through. I was saying that the patched version should
probably be a separate ebuild.

But Mathy's (sorry for the mistype in my last mail Mathy) suggestion
to go ahead with renaming the USE flag but *not* flipping it to
default on is also a good step.


> Please point out what lines of the patch should be changed and what
> they should be changed to, else I will commit the patch as
> provided.

All lines containing +knots should say knots instead.


Thanks!

//Peter



Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-07 Thread Peter Stuge
Anthony G. Basile wrote:
> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> against the bitcoin eclass.  The following is his proposed change.
> I'll commit it after review.

Please do not do that, Anthony.


> Bitcoin Knots includes a number of enhancements users may find useful. I
> think  it would be a good idea to make it the default for Bitcoin
> ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).

I can only interpret this patch one way: sshole takeover attempt

I disagree very strongly. >:( Matt's suggested approach (separate
bitcoin-knots ebuild) seems like the right thing to do. I assume
there is no binary incompatiblity between the two packages?


Luke-Jr: I hope you're not maintaining a patchset, but a separate
project. A patchset would be utterly silly, since it causes
completely unneccessary user confusion.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Peter Stuge wrote:
> --8<-- mount(8)
..
>   portable. The mount(8) command internally uses udev symlinks
> -->8--

That's of course only the mount in util-linux.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Ian Stakenvicius wrote:
> > WilliamH wants everyone using /dev/disk/by-label/
> > paths in fstab to instead use LABEL= , to avoid issues if udev
> > doesn't create the symlinks before localmount tries to use them.
..
> UUID is the same situation in this case -- in fstab you can do it by
> UUID= or you can do it by /dev/disk/by-uuid/.  The latter
> form depends on udev finishing up and would have the same issue.

It seems that the former form may also depend on udev having settled.

--8<-- mount(8)
   The device indication.
..
  The recommended setup is to use tags (e.g. LABEL=) rather
  than  /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks
  in the /etc/fstab file. The tags are more readable,  robust  and
  portable. The mount(8) command internally uses udev symlinks, so
  use the symlinks in /etc/fstab has no advantage over  the  tags.
  For more details see libblkid(3).
-->8--

Oops. Let's look further:

--8<-- libblkid(3)
   The  high-level  part  of  the library supports two methods to evaluate
   LABEL/UUID.  It reads information directly from a block device or  read
   information  from  /dev/disk/by-*  udev symlinks. The udev is preferred
   method by default.
-->8--

..so when is the non-default method (querying devices) used?


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Peter Stuge
Rich Freeman wrote:
> We give you the tools when you install your system, and we give you
> the tools when it is time for renovations...

On that note - thank you very much to everyone who contributes to Gentoo!

<3


//Peter



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

2016-10-26 Thread Peter Stuge
waltd...@waltdnes.org wrote:
> For a build-from-source distro like Gentoo, gcc and associated
> tools are a vital part of the distro.

A stage4 created (and updated) on a catalyst build farm doesn't need
to have gcc, but may still need libstdc++.


//Peter



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

2016-10-26 Thread Peter Stuge
Rich Freeman wrote:
> I think you could make an argument that voluntarily placing that
> header on your work is an assignment of copyright.
> You could also argue otherwise.

Especially in jurisdictions where copyright can not be assigned.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Peter Stuge
Ian Stakenvicius wrote:
> by mount and works regardless of device manager, therefore removing
> the the dependency of having udev-settle before mounting these paths.

the the


Looks good. Thanks.


//Peter



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

2016-10-26 Thread Peter Stuge
Raymond Jennings wrote:
> Why exactly isn't libstdc++ a separate package anyway?

I guess because it has no separate upstream.

I think a separate package would be a fantastic improvement though.


//Peter



Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

2016-10-18 Thread Peter Stuge
Patrice Clement wrote:
> We should strive for keeping a clean and linear history.

I agree with you.


> Cherry-picking is not my go-to solution as far as I'm concerned.
> It requires a bit of setup and is clearly tedious: you must know
> in advance the full SHA-1 of commit(s) you want to cherry-pick.

git cherry-pick master..pr1234 # picks all commits on pr1234 not on master

This is essentially a "manual" rebase of pr1234 onto master.

Demo time. Preparations:

$ git config --global alias.la 'log --oneline --graph --decorate --all'
$ export PAGER=cat


Assume the following repo:
$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

git cherry-pick master..pr1234 would apply b2 and c onto master:

$ git cherry-pick master..pr1234
[master 305532b] b2
 1 file changed, 1 insertion(+)
 create mode 100644 b2
[master d18f1ac] c
 1 file changed, 1 insertion(+)
 create mode 100644 c
$ git la
* d18f1ac (HEAD, master) c
* 305532b b2
* ccbc288 d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

If the pr1234 branch has some value once b2 and c are in master then
this is a good way to do it, the main drawback IMO that it leaves a
repetitive and redundant pr1234 branch behind.


Another way would be to simply rebase the pr1234 branch. Disclaimer: I
don't know GitHub processes and assumptions, so rebase might suck for this.

If noone cares about the PR branches once they have been merged/closed
(I got that impression from your mail) then rebase may be a good choice.

$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ git rebase master pr1234
First, rewinding head to replay your work on top of it...
Applying: b2
Applying: c
$ git la
* 92417d4 (HEAD, pr1234) c
* 385ca8c b2
* ccbc288 (master) d
* d33a95b b
* 2dfcb95 a
$ 

At this point, pr1234 can be fast-forward merged into master:

$ git checkout master
Switched to branch 'master'
$ git merge --ff-only pr1234
Updating ccbc288..0565e44
Fast-forward
 b2 | 1 +
 c  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 b2
 create mode 100644 c
$ git la
* 0565e44 (HEAD, pr1234, master) c
* 0dbfdf8 b2
* ccbc288 d
* d33a95b b
* 2dfcb95 a
$ 


> You may or may not know about it but a PR can be fetched as a git
> am-compatible patch.
..
> https://github.com/gentoo/gentoo/pull/1234.patch

Didn't know - that's pretty handy!


> $ cd /home/patrice/gentoo
> $ pram 1234

Nice work! I might have made a git pr alias instead, but pram seems
way more flexible than that would be.


Finally, while I do agree with you, the one and only reason IMO to
live with merge commits is that they implicitly preserve the branching
point. For source code that can be useful, but for ebuilds less so.


//Peter



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Peter Stuge wrote:
> How can I help improve ..?

Michał Górny wrote:
> people focused on preaching and/or implementing random crap-based
> solutions without even stopping for a few minutes to consider what
> we exactly need.

You could interpret my question as "what exactly do we need" ?


> GitHub works for us. GitHub works for our contributors. GitHub
> boosts our productivity, unlike those vain discussions.

Windows works for me. Windows works for my customers. Windows
boosts my business, unlike vain discussions about open source
and free software. ;) Maybe you get my point?


> We don't have time for all this tin foil hat nonsense.

I think we have all the time in the world, and I think it's important
for us to innovate also in this field if neccessary, as we have and
continue to do in other distro-development-related fields.


Thanks

//Peter



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Michał Górny wrote:
> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> That's the most convenient solution for most of proxy-maint team members.

How can I help improve that problematic situation?

It's not cool to gravitate the project towards GitHub Inc.


//Peter



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Felix Janda wrote:
> I'd like become a proxy-maintainer for app-editors/nvi.

Sweet! If there are some open bugs then please upload patched ebuilds
and other neccessary files to the bugtracker, ideally as output by
git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
to get someone to proxy them into the tree for you.

https://anongit.gentoo.org/git/repo/gentoo.git


//Peter



Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Andrew Savchenko wrote:
> On Sat, 6 Aug 2016 13:37:19 +0000 Peter Stuge wrote:
> > Hi Pacho, many thanks for your work, but..
..
> > ..do you think you can arrange to post everything in one mail,
> > instead of 14 different ones in a single day?
> 
> I suppose these posts are automated (at least partially), since
> each of them is linked to a different retirement bug.

That would explain the many emails - then it will probably be halfway
straightforward to also bundle the bugs and send one email at say 2:00 am
or whenever is a likely time that Pacho is not doing retiring. :)


> So you shouldn't blame Pacho for his work.

I don't think I was - I wanted to nudge to improve the output of his work.

I like to follow what gets retired, in case I want to pick something up,
but I don't like to read 14 emails in one day with a few packages in each.


Another, maybe simpler, approach would be to have a stateless cronjob
instead of a queue, the job would just look at what retirement bugs
were changed (opened?) in the last while (day?), and send one email
listing all packages. Maybe it could also set some status in the bug,
to avoid duplicates because of DST or whatever.


Thanks a lot

//Peter



Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Hi Pacho, many thanks for your work, but..

Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
Pacho Ramos wrote:
> Date: Sat, 06 Aug 2016 15:22:22 +0200

..do you think you can arrange to post everything in one mail,
instead of 14 different ones in a single day?


Thank you

//Peter



Re: [gentoo-dev] Package up for grab

2016-08-03 Thread Peter Stuge
Daniel Campbell wrote:
> Tox
..
> All it needs is feature parity with video, voice, and file sharing.

And a new name. :)


//Peter



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-05 Thread Peter Stuge
Rich Freeman wrote:
> > do not be shy to suggest reading materials
..
> Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc.
> If you don't understand the data model, you'll never get it.

I have an intro here:

http://peter.stuge.se/git-data-model


//Peter



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Peter Stuge
Consus wrote:
> This is how overlays work right now. What are suggesting to change?

Technically not a lot in terms of how packages get installed.

It's more about offering support and/or visibility for overlays.

So technically it's about hosting user repos, making the ebuilds
within easily discoverable, and simplifying their consumption.

I would personally be super happy to have my overlay hosted at Gentoo -
not because I can't host it myself - but because that would be a lovely
recognition and a great way to get more visibility and thus more help
with the packages that I've made more or less serious attempts at
packaging.

Usually they are less seriuos attemps, otherwise I would proxymaint
them, but they are good enough for me, so maybe for someone else as
well, even though they may be totally incomplete e.g. as far as USE
flags go.

(This is true for ebuilds in gentoo too, but I would never want my
name on something like that for the actual tree; I want to deliver
higher quality there, and until I have time to do so the half-assed
ebuilds stay in my overlay. They wouldn't get included anyway, and
they shouldn't.)


//Peter



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Peter Stuge
Alexander Berntsen wrote:
> It would be fruitful to encourage every single Gentoo user to have
> their own repository. And this repository should be publicly available.
..
> What are your thoughts?

Genius.

This is exactly what I have been doing for many years, but I couldn't
have expressed it as well as you just did. Thank you.

IMO, this should be a high priority. It is the ability to work this
way that makes Gentoo so valuable to me.


> Users could also review each other's ebuilds to ensure better
> quality ebuilds.
..
> Parallel to all this, we should work on tooling.
..
> It would also be good to offer hosting

I will argue that these are actually one. Tooling and hosting are the
only things that Gentoo needs to work on to get users to race each
other up the ebuild curve.

Make "user repos" a first-class Gentoo "thing", something that people
talk about and work with, simply because it enables them to solve
their specific problems in a painless way.

Most of the tooling is there - layman works fine - but just make
overlays (the way they work now is fine!) a first-class citizen,
and encourage their use.


> insofar as possible to a set of curated repositories we consider to
> be of high quality.

GitHub Inc. is successful because they host a central location with
"all the code on the Internet"; convenient for consumers and
producers alike. Of course it is a fallacy, but it's convenient
when it works.

Ensure that Gentoo accomplishes the same for Gentoo.

Do NOT - I repeat NOT - tie "user repos" to GitHub Inc., please do
not even bother working on a prototype there (looking at you James),
because if it is good enough it will stick, and as the social
contract rightfully states, it's important to remain independent,
so that Gentoo and Gentoo only can decide what it will offer.


This is a wonderful idea which would benefit the community
tremendously. I wish I had time to implement all of it immediately.


Kind regards

//Peter



Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

2016-05-18 Thread Peter Stuge
Cool!

aide...@gentoo.org wrote:
> +_find_dep_version() {
> + local pn="$1"
> + local p
> +
> + pushd "${EPREFIX}$(get_erl_libs)" >/dev/null
> + for p in ${pn} ${pn}-*; do
> + if [[ -d ${p} ]]; then
> + echo "${p#${pn}-}"
> + return 0

No popd on success?

> + fi
> + done
> + popd >/dev/null
> +
> + return 1
> +}



> +# @FUNCTION: eawk
> +# @USAGE:  
> +# @DESCRIPTION:
> +# Edit file  in place with awk. Pass all arguments following  to
> +# awk.
> +eawk() {
> + local f="$1"; shift
> + local tmpf="$(emktemp)"
> +
> + cat "${f}" >"${tmpf}" || return 1
> + awk "$@" "${tmpf}" >"${f}"
> +}

Wouldn't it be nicer to cut cat, awk > $tmpf && mv $tmpf $f ?


//Peter



Re: [gentoo-dev] Reminder: ALLARCHES

2016-05-04 Thread Peter Stuge
Mike Gilbert wrote:
> "doing your job"

Remember that everyone is a volunteer.


> dropping stable keywords on everything but the bare necessities

Gentoo magically does a number of things which upstream never
intended and do not intentionally support. It is amazing, and
thank you so much to everyone who makes it possible!

At the same time all the upstream crap is pretty tragic.

I am absolutely in favor of exposing users to it, rather than the
happy Gentoo garden full of magic patches :) and fast-path:ing bugs
upstream when things do not work. In an ideal world, upstream would
care. Of course many don't, and patches may still end up in Gentoo,
but then at least users would know, and might get involved upstream,
where they can actually help improve the package. Gentoo is the wrong
place for that, so it doesn't make sense for them to get involved in
Gentoo.

I think unstable on (most) everything would be a great thing.


Again: Thanks to everyone who contributes to Gentoo! :)


//Peter



Re: [gentoo-dev] Last rites: app-cdr/webcdwriter

2016-01-26 Thread Peter Stuge
James Le Cuirot wrote:
> # James Le Cuirot  (26 Jan 2016)
> # No new release since 2008. Removal in 30 days.
> app-cdr/webcdwriter

Is there a problem with it? I don't use it and have no interest in
this particular package but merely lack of release is not a valid
reason to remove the ebuild if everything else is all right. If it
isn't, then maybe that needs to be added to the lastrite comment?


Thanks

//Peter


pgprQTyDGc8bT.pgp
Description: PGP signature


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

2016-01-06 Thread Peter Stuge
Rich Freeman wrote:
> I'm not sure it is really worth trying to control this via a USE flag
> for such a light dependency.

I don't care how light dependencies are - I want to be able to choose
every single one that is optional. That is Gentoo's killer feature,
and I am thoroughly disappointed whenever I come across a dependency
which is not absolutely neccessary but hard in ebuild. It's rare, but
happens. :( I consider it a bug. I still have to file the last one I
found.


//Peter



Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Peter Stuge
Michael Orlitzky wrote:
> If anyone has a concrete idea that works better, it's not too late to
> change it.

Add code to init script and service file to check the config before
starting the program, and react if PHP5 is still set.


//Peter



Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Peter Stuge
Kristian Fiskerstrand wrote:
> Maybe I'm thinking things too difficult, why not just define both -D
> PHP and -D PHP5 in the transition period and suggest this config for
> any change?

Because it mostly just defers the problem.

If the desire is to move away from PHP5 then I would suggest to force
a failure when starting Apache, if PHP5 is defined when PHP is required.

Ie. fail closed.

I can be talked into supporting the idea to only print a warning when
PHP5 is set and to not fail (no source served) for some period of
time until which the forced failure starts, if PHP5 is still set.

Don't fail open, fail closed. Since manual interaction is required
some people will forget or overlook it, and will get a failure.

I would introduce the failure right away, but maybe a warning will
make some happy who would otherwise have gotten a failure.


//Peter



Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Peter Stuge
Michael Orlitzky wrote:
> >> If anyone has a concrete idea that works better, it's not too late to
> >> change it.
> > 
> > Add code to init script and service file to check the config before
> > starting the program, and react if PHP5 is still set.
> 
> Which init script?

For Apache.

> It's only "bad" to have PHP5 set if the user has installed
> >=eselect-php-0.8.1, and run it at least once.

So pkg_postinst for >=eselect-php-0.8.1 should say something, but
ideally also the invocation - but I don't know if eselect-php is also
code or only data managed by eselect?


> You don't want to e.g. kill working php-5.x installations for people
> who have apache keyworded ~arch.

IMO that would be a much lesser evil than serving source in another
case, as long as it is clear how to unkill (sed s,PHP5,PHP,) the setup.


//Peter



Re: [gentoo-dev] [PATCH 0/5] python-r1 suite: python_gen_impl_dep() function

2015-12-24 Thread Peter Stuge
Michał Górny wrote:
> Please review the patches sent in reply.

The changes look good to me, but maybe the function should have
'use' in its name; it's not obvious that the parameter is about
USE as opposed to PN.


//Peter



Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging

2015-12-22 Thread Peter Stuge
Patrick Lauer wrote:
> my time, spent to work around deficiencies I shouldn't even see -
> if other people had done their job.

Ah but that's the thing - it *isn't* their job.

They are volunteering. That's a very different construct.

And yes, you do have to work around deficiencies created by others.
That's pretty much the essence of volunteer-based collaboration. So fun!


Thank you very much for volunteering time to document and improve
automatic GLEP63-compliant key generation! Sweet! You deserve to
publish it somewhere. Anything gentoo.org please. :)


//Peter



Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging

2015-12-21 Thread Peter Stuge
Ryan Hill wrote:
> You want me to use a potentially unstable live ebuild instead?
> Well, no, that's not gonna happen.

Are you demanding that someone else produces for you, and refusing to
do anything but consume?

If the stable version is broken and if needing to use ~ or live is
not up to your standards then why not help roll the next stable version?

Help solve the problem instead of complaining.

Everyone will benefit.


Thanks for your contributions to Gentoo - past and future!

//Peter


pgpPjFwTn4HmV.pgp
Description: PGP signature


Re: [gentoo-dev] repo/gentoo.git, or how committing is challenging

2015-12-14 Thread Peter Stuge
Patrick,

Patrick Lauer wrote:
> Like seriously, every time I try to approach this set of problems I
> run into enough stupidity

Stop the silly complaining and help work on solving the problem instead.

If you can contribute then do so. If not, your options are to hire
someone who is, or await the day when a fix to your problem magically
appears. :) It really is that simple.

You mentioned that you use Gentoo professionally. This means that you
have already invested in Gentoo and have probably planned to
contribute to Gentoo. It seems that you have come across an
area where you could contribute.

If you choose not to that's perfectly fine, but since there is no
warranty you really do not get to complain that it's broken if you're
not helping fix it, and the tone you are using is certainly not
acceptable.


> why do we have documentation then when it's not adequate

Because you haven't helped make it adequate for your needs.


> why do we have a helper tool when it doesn't work?

Because you haven't helped make it work the way you need.


> ... and now I walk away for another week, in the hope that things
> maybe are saner then.

In my opinion that is the very last thing you should be doing.

Open source only works when you take ownership of the problems you have.

You are on the contrary saying that you refuse to own your problems,
that you only want to consume perfect solutions that someone else has
provided you.

It sounds like something a spoiled teenager might say, and it is
really not acceptable behavior in any open source project.

Help fix the problem instead - as you initially offered to do. That's
the very best approach! Everyone will be thankful and the world will
be a happier place.

You need to work on communication. Nobody will want anything to do
with you as long as you continue to sound like a spoiled teenager,
and once you change your communication style plenty will still
remember you for how you used to be, but you have to start somewhere.

It's simple. Stop complaining, be concrete and specific, and send
patches.


Thanks for your contributions to Gentoo, past and future!

//Peter



Re: [gentoo-dev] Breakage and frustration

2015-12-14 Thread Peter Stuge
Rich Freeman wrote:
> a big question is how to make it happen without just throwing
> complaints on the folks who are trying their best to keep it all going.

The answer to this is the same as it has always been:

Demonstrate that you are capable and reliable and given social
compatibility then after some time you too can become a part of
the team.

This is the way most open source projects, actually most human
projects work. Maintainers are not picked at random when there
is high load, but trusted long-time contributors are promoted
to maintainers when they shine.

The more you complain instead of send patches, the less likely you
are to ever become part of the solution.


The key point to remember is that it is NOT neccessary to be part of
the team in order to contribute solutions. You *first* contribute
solutions and only *then* have a chance of becoming part of the team.

I for one am working in my non-existant spare time on a fast
ChangeLog generator.


//Peter



Re: [gentoo-dev] Use GLEP27!

2015-12-14 Thread Peter Stuge
Ulrich Mueller wrote:
> (If directories are really needed, we could use the scheme foreseen
> in [1] for package.* and use.* files.)

So package.{users,group} ?


> Also a mechanism how a subprofile could undefine a user or group
> defined in its parent seems to be missing.

Maybe set the id to -1 ?


//Peter


pgp8mbHAFECAQ.pgp
Description: PGP signature


Re: [gentoo-dev] git update hook: detecting missing Manifest DIST entries

2015-12-07 Thread Peter Stuge
Robin H. Johnson wrote:
> 1. Script #1 (helper), that given an ebuild, spits out the filenames of the
>distfiles. 
>- Use an explicitly specified PORTDIR for eclasses.
>- Must NOT rely on the ebuild directory structure (i'd love to give
>it the ebuild via stdin and tell it the path).
..
> we just need script #1.

something FETCHCOMMAND=/bin/echo emerge --fetch-all-uri something something


//Peter


pgpzDEbBlZ8uI.pgp
Description: PGP signature


Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

2015-11-29 Thread Peter Stuge
Ulrich Mueller wrote:
> 1. Will these three functions be sufficient, or have we overlooked
>anything important?

Something that comes to mind as probably being semi-frequent is to
transform a version number component into a Gentoo -p number.

Or do you suggest doing that by replacing the separator?


//Peter


pgpFYZNEct92Z.pgp
Description: PGP signature


  1   2   3   4   5   >