Re: [gentoo-dev] Pushing to distfiles?

2020-11-14 Thread Kent Fredric
On Wed, 11 Nov 2020 19:38:35 -0500
Rich Freeman  wrote:

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

Oh, yeah, and don't rely on github auto-tarball stuff.

History has demonstrated github sometimes "forgets" their cached copies
of those tarballs, and then later when requested, it will regenerate
them fresh ... but with different SHAsums.

If you're gonna use github for tarballs, roll that tarball yourself,
and attach it to a "release", manually and explicitly, and then use the
URL to the release asset.

Only then can you be sure: 

a) Of what the tarball actually contains
b) Of what the tarballs SHAsum will be

Description: OpenPGP digital signature

Re: [gentoo-dev] Pushing to distfiles?

2020-11-14 Thread Kent Fredric
On Wed, 11 Nov 2020 19:38:35 -0500
Rich Freeman  wrote:

> I thought that the whole mirror:// thing was discouraged.  For
> anything else you just stick SRC_URI in the ebuild and the mirrors
> should fetch it when they see it in the repo.
> I just host stuff like that on my dev webspace, or better yet on
> github or something else that will auto-tarball stuff.

In my last foray into building things from historical portage
snapshots, the use of "push stuff directly to mirror:// and then only
have mirror:// in SRC_URI" pattern was *the* leading cause of "oh noes,
patches and distfiles no longer exist".

Because naturally, once there is no longer an ebuild that requires the
distfile, it can be reaped from the mirror, and this leaves no fallback
fetch location.

I found myself reviling this so much I feel it apt that this pattern
should be more than discouraged, it should be banned outright and all
ebuilds that *only* have mirror://gentoo/ as a source for any file
should be shot repeatedly till it doesn't do that anymore.

The resilience of Gentoo-authored distfiles should be *as good* as
random 3rd parties we currently source from, not *exponentially worse*

Description: OpenPGP digital signature

Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-09 Thread Kent Fredric
On Mon, 9 Nov 2020 12:15:07 +0200
Jaco Kroon  wrote:

> You mentioned working raport with upstream?  Can we rely on that to at
> the very least get them to update that to "due to the way Gentoo
> functions we request that you first file issues with the Gentoo
> repository rather than directly with rxvt-unicode?  That is pure and
> outright slander, and whilst I "get" (to an extent) and GNU/Linux
> statement - he should then have the same issue with RedHat Enterprise
> GNU/Linux.  Or with "Debian" and "CentOS" for that matter which does not
> contain "GNU/Linux" in the name.  Alternatively if there is no issue
> with that then perhaps we should consider just being "Gentoo" ...

Historical context probably matters here.

That's a very old statement.

Partly from the era when Gentoo was "cool" and when "ricing" was a thing.

At the time, upstream was inundated with absurd requests like "oh noes,
I disabled CXX Exceptions, and the code broke, upstream is wrong!".

Whatever we did, or upstream did, the absurd complaints have gone away.

But I'll see what I can wrangle :)

Description: OpenPGP digital signature

Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-08 Thread Kent Fredric
On Wed, 4 Nov 2020 17:34:07 +0100
Marek Szuba  wrote:
>> x11-terms/rxvt-unicode 
> Will co-maintain this one with conikost, don't mind being listed as 
> primary maintainer.

If you strike an issue that you think should be followed upstream, rope
me in. (put me on the bottom of the maintainer list if you want)

I'm not interested in maintaining it directly, but I use it, and do
have workable rapport with upstream :)

Description: OpenPGP digital signature

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-11-01 23:59 UTC

2020-11-01 Thread Kent Fredric
On Mon, 02 Nov 2020 00:05:34 +
"Robin H. Johnson"  wrote:

> The attached list notes all of the packages that were added or removed
> from the tree, for the week ending 2020-11-01 23:59 UTC.
> Removals:
<3MB of data trimmed> 

It looks like you reported all added and removed packages for the last 4 years.

I think is might be a bug.

Description: OpenPGP digital signature

Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-17 Thread Kent Fredric
On Sun, 18 Oct 2020 11:41:38 +1300
Kent Fredric  wrote:

> Uh, do we need a new catagory for this one package?

Scratch that, my brain is disabled and my eixing failed the first time
and I jumped because it was a category with no recollection of seeing

Now I see there is one, I do still think "That's a bit weird", but
whatever, not adding a new category -> no issue.

Many apologies.

( Though I still find the choice of category very odd )

Description: OpenPGP digital signature

Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-17 Thread Kent Fredric
On Sat, 17 Oct 2020 18:05:40 -0400
Aisha Tammy  wrote:

>   gui-libs/display-manager-init

Uh, do we need a new catagory for this one package?

Description: OpenPGP digital signature

Re: [gentoo-dev] New customization options available on packages.g.o

2020-10-06 Thread Kent Fredric
On Tue, 6 Oct 2020 20:55:25 +
Max Magorsch  wrote:

> Further customization options are available on the preferences pages.
> Feel free to let me know if you are missing anything. Apart from that:
> Happy customizing.
> /M

This is awesome \o/

Though I may have spotted a bug or two.

When you toggle "Include packages of projects the maintainer is part
of", it doesn't change the displayed numbers on some of the relevant pages.

For instance, at the top of:

I see the number "13" on the number of bugs, and the union of "perl +
rust + kentnl" couldn't ever be that small.

Should be at least as large as 251, as per: 

And well

Should absolutely be greater than three.

More like: 221

As per:


Says 0 *and* gives a blank page, but surely, it should aggregate this?

Either way, great stuff :)

Description: OpenPGP digital signature

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

2020-09-16 Thread Kent Fredric
On Wed, 16 Sep 2020 16:05:49 -0600
Tim Harder  wrote:

> Speaking for myself, I avoid hosting most of my Gentoo-related work
> (outside of gentoo repo ebuild mangling) on since I prefer
> the services offered elsewhere in terms of usability, visibility, and
> project maintenance. Take this as constructive criticism of how Gentoo
> currently operates as an upstream host and see it as a call for putting
> more emphasis towards deploying GitLab, Gitea, or other similar service
> for Gentoo.

100%. Rich's suggestions with regards to documenting a "here's how you
build a container that can be air-dropped onto gentoo infra and booted,
and incrementally updated on request" process would possibly go a long
way with all of this.

Random devs can band together, build some GitFoo container, get it
working Gud(TM), and petition Infra to deploy it (probably in some
semi-official "this is just an 'speriment" namespace till it ossifies)

Making the Infra side DeadEasy(TM), and the contributor side
DeadEasy(TM) reduces all the real friction points beyond politics.

Description: OpenPGP digital signature

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

2020-09-16 Thread Kent Fredric
On Wed, 16 Sep 2020 19:47:35 -0400
Rich Freeman  wrote:

> Seems like a way to improve this would be better documentation and a
> DIY infra testing platform.
> First, document how to prepare a service for infra hosting.  Maybe
> provide an example service.
> Second, publish a tarball of a container/chroot that basically
> simulates an infra host for testing purposes.  Provide instructions on
> how to configure/run it.  Make it easy - edit this config file to
> point to your repo, put the name of your service/host here, etc.
> Anybody developing a service could then just follow the instructions
> and then test out their service in a similar environment to what infra
> uses.  Nobody needs to be trusted with any credentials.  Nobody needs
> access to any special repos.  They can run the container on their own
> host, and point it at their favorite git repo hosting service.
> Once it is working all they need to do is give the link to their
> repo/etc to infra.  Infra can then fork it and host it.  The
> maintainer can submit pull requests as needed to infra.

I'm in favour of all of this.

Description: OpenPGP digital signature

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

2020-09-16 Thread Kent Fredric
On Wed, 16 Sep 2020 07:11:12 -0400
Rich Freeman  wrote:

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

I agree on the "infra is a big SPOF", just to me, and my experience,
"single developers" are a much larger/more volatile SPOF.

Like, I can't even keep my own stuff running, so I'm using myself as an

But I know too many people who fall into this camp.

Individuals are much less likely to have the finances and ability to,
not only delegate others to work on their platforms, but are unlikely
to have the delegation itself delegated.

So as fragile as gentoo infra is, ... its still less fragile in the
long term view of things than random 3rd parties.

( This is where we cry about the loss of the original gentoo wiki, and
how long it took us to replace it, where I'd imagine if it had started
out with the full backing of gentoo infra, we'd have lost much less,
and we'd have not lost so much of our google juice and 'fountain of
arcane knowledge' to Arch )

Description: OpenPGP digital signature

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

2020-09-16 Thread Kent Fredric
On Mon, 14 Sep 2020 10:15:31 -0400
Rich Freeman  wrote:

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

For the situation of things that take life before being part of infra,
I think the least we can do is recognize their utility and importance,
and at least, have infra *offer* some sort of shared location to run a

That I think helps everyone, gives people a place to remove their own
bus factor, but without mandatory strongarming.

Description: OpenPGP digital signature

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

2020-09-15 Thread Kent Fredric
On Tue, 15 Sep 2020 09:12:58 +0200
Toralf Förster  wrote:

> However this doesn't cover bugs filed a while ago and are not be fixed in 
> current stable.

A mitigation would be it wouldn't file a stabilization req if there was
already one open.

Basically means as soon as there's one stable req, it reverts to
"manual mode", as you either fix the problem that blocked
stabilization, or you ship a new one and re-point the stabilization
request to that instead.

Description: OpenPGP digital signature

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

2020-09-13 Thread Kent Fredric
On Sun, 13 Sep 2020 12:04:39 -0700
Alec Warner  wrote:

> Is openrc critical to Gentoo? it doesn't live on our infra.
> Is pkgcore critical to Gentoo? it doesn't live on our infra.

Both those things are "things employed by users for their systems".

Neither of those things are integral to any workflow, and are entirely

But when you file a bug, you rely on bugzilla being maintained by
Gentoo Infra, not some 3rd party.

And when you file a keyword/stable request, you rely on a
bugzilla-integrated functionality through nattka to check and verify

Subsequently, whether or not you opted into this, nattka is now
critical to the workflow of everyone doing keywording/stable requests.

You can't really say that about pkgcore or openrc.

But you can say that about the QA Automated Testing service, which
mangles gentoo.git and creates sync/gentoo.git, and reports when people
broke the tree.

And that *uses* pkgcore.

But I'm pretty sure that infrastructure lives on gentoo "somewhere",
and if it doesn't, it should.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Kent Fredric
On Mon,  7 Sep 2020 08:14:52 +0200
Michał Górny  wrote:

> However, please
> +do not include it in the package.mask entry as users do not need
> +to be forced to proactively unmerge it.

I can think of a utilitarian value of doing this anyway.

Namely, it gives a window during `emerge -uD @world` where portage
tells you that they have a masked package installed, and the reason.

Ideally, people don't have virtuals in their world file, but they do
anyway, which means you can't guarantee the lack of dependents
resulting in a depclean directed purge.

And this can matter, as if its in your world file, or sometimes, if its
even still installed, portage can trip up during upgrades with a more
confusing error about the virtual not being installable.

Outdated overlays add to this problem somewhat. :/

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation

2020-09-03 Thread Kent Fredric
On Thu, 3 Sep 2020 14:49:25 +0100
Michael 'veremitz' Everitt  wrote:

> I know this is a much more onerous "solution" but I thought I would throw
> it out there, and see if any other interested parties (eg. kent\n and
> potentially graaff) may be able to share their thoughts..

Actually, the more I think about it, there are 2 major reasons not to do this:

1. Its a premature abstraction that centralises a point of failure, and
so any defects in this POF scale to all places, producing even more
places where changing one eclass requires regenerating the md5 cache
for the whole tree, and makes it *harder* to specify logic that only
occurs in one languages ecosystem.

2. What happens if two eclasses inherit this shared eclass, and
declares "which variables do I look into" via other variables that
define its API?, and then, one ebuild consumes *both*.

Presently, inheriting two eclasses, one for python, one for lua, and
taping together how they build inside the ebuild itself seems viable.

But if the logic is shoehorned into a common eclass, that will likely
go really fucking pear shaped, unless done with a very fucked
up/complicated API.

I don't think this is worth it.

Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: pgo - a command line interface for packages.g.o

2020-09-03 Thread Kent Fredric
On Tue, 1 Sep 2020 08:47:12 -0400
Michael Orlitzky  wrote:

> Here's a trick that bugzilla cannot do: show me the bugs that are
> assigned to me **or a project that I'm a member of**. Killer feature
> right there.

Something bugzilla also doesn't do:

Automatically search for "dev-foo/bar" in cf_statiblization_atoms or
whatever the hell its called or however its spelt when you search for:

"ALL dev-foo/bar"

This is one of my leading causes of oversight :/

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-perl/gnome2-vfs-perl

2020-08-17 Thread Kent Fredric
# Kent Fredric  (2020-08-17)
# No reverse dependencies, and Gtk support is becomming
# obsolete in Gentoo
# Removal in 30 days

Description: OpenPGP digital signature

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

2020-07-29 Thread Kent Fredric
On Tue, 28 Jul 2020 19:17:04 -0400
Aaron Bauman  wrote:

> net-irc/quasselgrep

Uh, what?

[I] net-irc/quasselgrep
 Installed versions:  0_p20190211(13:18:43 
18/07/20)(PYTHON_TARGETS="python3_7 -python3_6")

Maybe just the older version?

Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-perl/Data-Diver

2020-07-15 Thread Kent Fredric
# Kent Fredric  (15 Jul 2020)
# No LICENSE declaration by upstream, and no response from upstream
# since at least 2013 as to what license to use (bug #732710)
# Removal in 30 days.

Description: OpenPGP digital signature

[gentoo-dev] Last-rites: dev-perl/gnome2-perl

2020-07-09 Thread Kent Fredric
# Kent Fredric  (2020-07-10)
# No reverse dependencies, and Gtk2 support is becomming
# obsolete in Gentoo.
# Removal in 30 days

Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Kent Fredric
On Wed, 8 Jul 2020 20:48:44 +1200
Kent Fredric  wrote:

> The "easy" workaround is to use `dev-perl/Gentoo-PerlMod-Version`, and
> have it munch upstreams version into a "gentoo normalized version", and
> then use that version for comparison.

Actually, on that note, it *might* be of benefit to people to advertise
in the package page, what the "upstream version" is.

If we can also use this to feed however repology detects what versions
we have, then we'll look better on repology.

Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Kent Fredric
On Wed, 8 Jul 2020 09:40:17 +0100
Alexey Sokolov  wrote:

> Another comment, unrelated to the new features: RESTRICT="test?
> (test)" probably shouldn't trigger the T symbol the same way as
> RESTRICT="test" does.


This presently has bothered me, because it basically means with the
roll-out of RESTRICT="!test? ( test )", and the QA/Repoman changes that
complain if you have both USE="test" and not that RESTRICT=, that
basically every single package with tests now advertise that it is
test-restricted, which is both false, and not helpful to any consumer.

Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Kent Fredric
On Wed, 8 Jul 2020 02:57:57 +
Max Magorsch  wrote:

>   - all outdated packages (according to repology)

Unfortunately for Perl, repology can't be taken verbatim.

There's a really fun problem with Perl versions, so I'll link you to
our writeup to explain it:

This has some side effects visible in packagetest


Already up-to-date, it just can't tell because the versions don't match 


Already up-to-date, it just can't tell, because the versions don't match 

The "easy" workaround is to use `dev-perl/Gentoo-PerlMod-Version`, and
have it munch upstreams version into a "gentoo normalized version", and
then use that version for comparison.

But this is not itself going to remove the *whole* problem, just most of it.

Sometimes upstream do cute things, like:

- Ship 1.60
- Then ship 1.61
- Then ship 1.612
- Then ship 1.62

 This is legal in perl.

But many tools like repology get confused by this, and can think that
"1.612" is the "latest", when its really "1.62"

This gets even more confusing when you simply stick a "v" on the front
of those versions, which entirely changes things.

- Ship v1.60
- Then ship v1.61
- Then ship v1.62
- Then ship v1.612

^ This is also legal in perl.

And in this case, "v1.612" is in fact, the largest version.

But as-is, the logic used for perl stuff in packagetest will:

- Misreport packages as outdated when they're fine
- Possible fail to report needed updates

How to properly gate this to happen *only* for perl packages may be the
trickiest part.

Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Kent Fredric
On Wed, 8 Jul 2020 02:57:57 +
Max Magorsch  wrote:

> Additionally, there are new sites for all package maintainers, that is:
>   - Gentoo Projects (e.g.
>   - Gentoo Developers  (e.g.
>   - Proxied Maintainers (e.g.

Some other thoughts here, I've found it very helpful when working on
our *very* large set of responsibilities, to be able to cluster
problems alphabetically.

For instance, 


Is a bit of an unwieldy mountain to conquer, and it may be better to
paginate it by the first letter of ${PN}, or cluster it.

So you could have:

 dev-perl/A*: 4 packages 
 dev-perl/B*: 6 packages
 dev-perl/C*: 1234 packages

And expand each into their composites on demand.

Though it also helps to point out I generally approach this as:

  - Target dev-perl/A*:
- for each dev-perl/A*, enumerate everything, absolutely everything, 
  about each and every package that may warrant my attention, be it
  - being outdated
  - having open bugs
  - having keywording/stabilization bugs
  - having minor/major QA issues. ( for instance, one right now is
"no versions are >EAPI5" )

And I use this as my baseline, and then walk through them all
alphabetically, applying whatever local testing regimen required to
find various classes of bugs that are getting reported lately, applying
relevant local audits to find bugs that *could* be filed in future.

And its generally easier to tackle the problem when segmented this way.

Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-08 Thread Kent Fredric
On Wed, 8 Jul 2020 02:57:57 +
Max Magorsch  wrote:

> I am glad to announce further progress at (pgo in
> the following). Compared to previous work during the last months,
> which mostly addressed the back end, the new changes are rather
> comprehensive. That's why I am looking forward to feedback here.
> So the tl;dr is that the new pgo version now displays:
>   - dependencies
>   - reverse dependencies
>   - pkgcheck results
>   - data
>   - github pull requests
>   - stabilization bugs
>   - keywording bugs
>   - security bugs
>   - general bugs
> for each package.

Just sayin', this is nothing short of absolutely fantastic.


Description: OpenPGP digital signature

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

2020-06-28 Thread Kent Fredric
On Sun, 28 Jun 2020 08:18:23 -0400
Michael Orlitzky  wrote:

> With LD set to something libtooly in the
> environment, the pari build fails. We can solve that by unsetting LD in
> the ebuild, but for that to be The Right Thing To Do, we should be
> expecting LD to contain something libtooly, and thus something
> inappropriate to be passed to the pari build.
> To avoid these issues, I suggest creating a list of "Gentoo environment
> variables" in the devmanual with descriptions of how they should be used
> and pointers to the references (for why we chose that meaning). That way
> a user can export LD, for example, and know that it will be used how he
> thinks it will be used.

That LD problem is not unique to Pari, ftr. Its a problem in *all* Perl
things that involve C parts.

Because Perl code expects "LD" to be a "CCLD", and passes flags a CCLD
would expect, which LD can't handle.

Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Add caching to a few commonly used functions

2020-06-27 Thread Kent Fredric
On Sat, 27 Jun 2020 at 19:35, Fabian Groffen  wrote:
> Hi Chun-Yu,

> > arguments: catpkgsplit, use_reduce, and match_from_list.  In the first
> > two cases, it was simple to cache the results in dicts, while
> > match_from_list was a bit trickier, since it seems to be a requirement
> > that it return actual entries from the input "candidate_list".  I also
> > ran into some test failures if I did the caching after the
> > mydep.unevaluated_atom.use and mydep.repo checks towards the end of the
> > function, so the caching is only done up to just before that point.

You may also want to investigate the version aspect parsing logic
where it converts versions into a data structure, partly because the
last time I tried profiling portage, every sample seemed to turn up in

And I'd expect to see a lot of commonality in this.

# qlist -I --format "%{PV}" | wc -c
# qlist -I --format "%{PV}" | sort -u | wc -c

And given this version-parsing path is even handled for stuff *not*
installed, I suspect the real-world implications are worse

# find /usr/portage/ -name "*.ebuild"  | sed
's|/usr/portage/||;s|/[^/]*/|/|;s|[.]ebuild$||' | xargs qatom -CF
"%{PV}" | wc -l
# find /usr/portage/ -name "*.ebuild"  | sed
's|/usr/portage/||;s|/[^/]*/|/|;s|[.]ebuild$||' | xargs qatom -CF
"%{PVR}" | sort -u | wc -l
katipo2 ~ # find /usr/portage/ -name "*.ebuild"  | sed
's|/usr/portage/||;s|/[^/]*/|/|;s|[.]ebuild$||' | xargs qatom -CF
"%{PV}" | sort -u | wc -l

Obviously this is very crude analysis, but you see there's room to
potentially no-op half of all version parses. Though the speed/memory
tradeoff may not be worth it.

Note, that this is not just "parse the version on the ebuild", which
is fast, but my sampling seemed to indicate it was parsing the version
afresh for every version comparison, which means internally, it was
parsing the same version dozens of times over, which is much slower!



Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-13 Thread Kent Fredric
On Fri, 12 Jun 2020 09:24:11 -0700
Georgy Yakovlev  wrote:

> Not sure if --features=default  will activate default set and how it
> will react to being passed along.
> --no-default-features --features default
> IDK, looks kinda unnatural.
> I have a feeling that we'll get more boilerplate if we pass
> --no-default-features than if we don't.
> We can re-evaluate as time goes by, but for now I see no major benefit
> and only downsides.

One problem I stumbled onto is that while --no-default-features does
work generically regardless of defined features, --features default
does _NOT_ work generically, as it fails if there is no defined
"default" feature.

Another is some crates simply don't work with --no-default-features,
and they need --features=std or similar in order to work.

Hence, I don't think --no-default-features makes for a great default
mechanism for rust.

Its something you should only reach for when you know better.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Kent Fredric
On Fri, 12 Jun 2020 02:04:51 -0700
Georgy Yakovlev  wrote:

> +#cargo_src_configure --no-default-features

Looking at the source, I don't see how this is passed from this command to 

> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --features feature1 --features feature2 ...
> + readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )

Is this really necessary?

> cargo --features "feature1 feature2"

is perfectly legal.

Description: OpenPGP digital signature

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

2020-06-10 Thread Kent Fredric
On Wed, 10 Jun 2020 20:25:20 +0200
Michał Górny  wrote:

> The general purpose of codec project [2] is to maintain core libraries
> for various multimedia format encoder/decoder libraries.  It's like
> gfx+sound+video except only for core packages and not every possible
> single viewer, player, editor, frontend...  I believe that this specific
> focus make more sense than the wider projects, i.e. it is more likely
> than N people will actually co-maintain libraries used by many tools vs
> N people co-maintain 20 alternative sound players (when they are
> unlikely to use more than one at a time).

Somehow I get the impression that "codec" as a scope is still too general.

For instance, people well acquainted with audio codecs aren't
necessarily well acquainted with video codecs, or image codecs.

A package that only does audio-playback for instance, won't be of
interest to somebody who predominantly cares about video playback.

I'm not entirely against it as a concept as-is, I just suspect it will
reiterate the previous problem.

Description: OpenPGP digital signature

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

2020-06-07 Thread Kent Fredric
On Sun, 7 Jun 2020 06:43:19 -0400
Rich Freeman  wrote:

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

I was thinking perhaps instead of "group membership" oriented things,
we could instead have a "developer proficiency" oriented system.

Developers could choose skills from a defined list (like projects, but
finely grained)

Maybe with some WOT based proficiency rating thing.

Then maybe the project system becomes used mostly for "primary
ownership" of well maintained sets of things with great team structure,
and the proficiency system becomes a defacto fallback for everything

Packages are tagged with the sort of skills required to maintain them
effectively, and people who have registered with said proficiencies get
CC'd into the bug (somehow) and similar things.

Like, for instance, when a package uses perl stuff, but isn't
inherently owned by perl@, I still care, but registering that I care is

And then potentially packages with above "good maintainer-ship" could
indicate some sort of maintainer-ship grant to 
"people with proficiency > X in Y".

Yes, I'm likely over-thinking everything here too much, but I suspect
somebody could get some inspiration from something here :)

Description: OpenPGP digital signature

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

2020-05-24 Thread Kent Fredric
On Sun, 24 May 2020 13:05:35 +
Peter Stuge  wrote:

> The bar only needs to be raised high enough.

Sure. A lot of this is just "think about what could happen in the worst
case imaginable".

Its very unlikely our worst cases will happen.

But we should at least have the ability to easily add mitigations in
future if things do get worse.

Description: OpenPGP digital signature

Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-24 Thread Kent Fredric
On Sun, 24 May 2020 10:33:18 +0200
Michał Górny  wrote:

> If it creates an invalid environment that is known to break packages
> and is not QA-sanctioned, it should be masked.  Period.

Seems like yet another argument in favour of my initial position, that
it probably shouldn't be controlled by a USE flag, and should *only* be
controlled by the tool itself via local config persistence. (Where
presently, there's no config persistence, the USE flag is all there is)

Description: OpenPGP digital signature

Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-24 Thread Kent Fredric
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert  wrote:

> Could you please add this flag to package.use.force? I don't think we

Sounds more like a case for package.use.stable.force or something.

For non-stable, we don't give guarantees about well-supported, only
that there will be bugs, and they should probably be reported.

( It doesn't tend to 'break' your system, it just makes upgrades fail,
runtime itself seems unaffected in general )

Description: OpenPGP digital signature

Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config

2020-05-24 Thread Kent Fredric
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu"  wrote:

> Do we currently have (or is there a plan for) a mechanism to manage the 
> symbolic links and/or create them after merging the package when necessary?  
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.

There are (currently undocumented) methods that work regardless of the
USE flag:

 {binutils,gcc}-config  --enable-native-links
 {binutils,gcc}-config  --disable-native-links

All the use flag does is dictate which of those "---native-links"
behaviours occur when no "---native-links" flags are passed.

Description: OpenPGP digital signature

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

2020-05-23 Thread Kent Fredric
On Fri, 22 May 2020 21:58:54 +0200
Michał Górny  wrote:

> Let's put it like this.  This thing starts working.  Package X is
> broken, and we see that almost nobody is using it.  We remove that
> package.  Now somebody is angry.  He submits a lot of fake data to
> render the service useless so that we don't make any future decisions
> based on it.

Sure, and I agree that's a risk. But its not the "random users from the
internet fill your inbox with shallow promises of free money" sort of
risk, that's typically implied by "spam" ;).

The set of potential attackers seems much smaller in our case, and are
expressly likely to be actual consumers of Gentoo.

This attacker type seems to be the sort that mitigates well with:

- Make it so that end users can't forge custom IDs and can only be
  handed out by the server (but the ID doesn't actually add any
  tracking, its just a chunk of randomness with a signature that
  verifies its legitimacy)

- Make ID generation expensive.

- Limit submissions per ID the same way we do now.

That way it doesn't harm typical users beyond their --setup, but hurts
would be attackers.

If we get under attack, we can just suspend ID generation services, or
rate limit ID generation.

(And we can encode data in the ID about when it was generated, and the
strength of the challenge of the generation, and then block submissions
based on criteria when problems occur)

This means we don't need to keep track of what ID's are "valid", server
side, crypto bits do all the leg work.

Even if our private key doing the signing gets compromised, we can
change it, which triggers all users to need to re-id, and flush old

Description: OpenPGP digital signature

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

2020-05-23 Thread Kent Fredric
On Fri, 22 May 2020 22:13:11 +
Peter Stuge  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, 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.

And the inherently low entropy of only having 80x23 with so few
(compared to full RGB) bits per pixel, 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)

Description: OpenPGP digital signature

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

2020-05-23 Thread Kent Fredric
On Fri, 22 May 2020 12:53:03 -0700
Brian Dolbec  wrote:

> We cannot exclude overlays which will have cat/pkg not in the main
> gentoo repo.  So, we should not excludea submission that includes a few
> of these.  They would just become irrelevant outliers to our
> processesing of the data.  In fact some of these outlier pkgs could be
> relevant to our including that pkg into the main repo.

We *can* still validate them against entries in known overlays.

And even if we *cant* validate everything, we can de-weight and hide
from *default* reports items that can't be found in known overlays.

This would move the difficulty goal from "submit a spam record" to:

- write an overlay
- get it published somewhere
- get it included in the database of known overlays
- then publish a spam record relating to it

Which sounds like a slow and painful process if the risk of being
blacklisted burns down that whole stack.

Description: OpenPGP digital signature

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

2020-05-22 Thread Kent Fredric
On Thu, 21 May 2020 10:47:07 +0200
Michał Górny  wrote:

> Other ideas
> ===
> Do you have any other ideas on how we could resolve this?

And a question I'd like to revisit, because nobody responded to it:

- What are the incentives a would-be spammer has to spam this service.

Services that see spam *typically* have a definable objective.

*Typically* it revolves around the ability to submit /arbitrary text/,
which allows them to hawk something, and this becomes a profit motive.

If we implement data validation so that there's no way for them to
profit off what they spam, seems likely they'll be less motivated to
develop the necessary circumvention tools. ( as in, we shouldn't accept
arbitrary CAT/PN pairs as being valid until something can confirm those
pairs exist in reality )

There may be people trying to jack the data up, but ... it seems a less
worthy target.

So it seems the largest risk isn't so much "spam", but "denial of
service", or "data pollution".

Of course, we should still mitigate, but /how/ we mitigate seems to
pivot around this somewhat.

Description: OpenPGP digital signature

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

2020-05-21 Thread Kent Fredric
On Fri, 22 May 2020 01:38:02 +1200
Kent Fredric  wrote:

> So instead of the ID being generated locally, you'd send a request
> asking for an ID, it would send you the challenge math, you'd send the
> answer, and then you'd get your ID.

Additionally, you could even allow the client to pass a number, that
stipulates a desired level of trust, in exchange for a more expensive

If there was an ID generation option that allowed me to, once, request
a challenge that takes an hour to complete, in exchange for getting a
higher "trust" vector, I'd do that.

Then you could present reports and whittle the results down by minimum
trust level.

( And then after the fact, one can adjust the minimum trust level of a
UID key to submit, so if UID keys below a certian trust level become
problematic, you can easily start rejecting them, and demand they
re-key with a higher trust level )

Description: OpenPGP digital signature

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

2020-05-21 Thread Kent Fredric
On Thu, 21 May 2020 15:16:12 +0200
Michał Górny  wrote:

> Isn't the whole point of salted hash to use unique salts?

You'd thinik so, but I've seen too many piece of code where the salt
was a hardcoded string right there in the hash generation.

md5sum( "SeKrIt\0" + pass  )

So I've learned to never assume that salts were unique per entry.

Description: OpenPGP digital signature

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

2020-05-21 Thread Kent Fredric
On Thu, 21 May 2020 10:47:07 +0200
Michał Górny  wrote:

> An alternative of using a proof-of-work algorithm was suggested to me
> yesterday.  The idea is that every submission has to be accompanied with
> the result of some cumbersome calculation that can't be trivially run
> in parallel or optimized out to dedicated hardware.

If the proof of work mechanism was restricted to ID generation, then
the amoritized cost would be acceptable.

So instead of the ID being generated locally, you'd send a request
asking for an ID, it would send you the challenge math, you'd send the
answer, and then you'd get your ID.

And their ID would be an encoded copy of their input vectors and
responses, a random chunk, and chunk representing the signature of

Or something like that.

But the gist is it would be impossible to use ID's not generated by the

Then the spam factor to monitor wouldn't be submission rates, it would
be "New ID request" rates, as these should never be needed to be
generated in large volumes.

_And_ taking 5 minutes for ID generation wouldn't be a terrible thing.

( We could possibly collect anonymous stats on ID generation rates, and
average times to generate a response to a challenge, and use that to
determine what our challenge complexity should be )

Description: OpenPGP digital signature

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

2020-05-21 Thread Kent Fredric
On Thu, 21 May 2020 14:25:00 +0200
Ulrich Mueller  wrote:

> That's why I said salted hash.

Even a salted hash becomes a trivial joke when the input data you're
hashing has a *total* entropy of only 32bits.

You at very least need a unique salt per hash, or you only have to
expose the salt to create a rainbow table for the whole dataset.

Description: OpenPGP digital signature

Re: [gentoo-dev] Initial version of gander/goose statistics up for testing

2020-05-20 Thread Kent Fredric
On Tue, 19 May 2020 13:27:40 +0200
Michał Górny  wrote:

> gander --submit

The server replied (500):

  Server Error (500)

  Server Error (500)

Submission failed.

Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it

2020-05-09 Thread Kent Fredric
On Thu, 07 May 2020 09:29:36 +0200
Michał Górny  wrote:

> For example, if OCaml bindings on some package are broken and require
> a lot of work, I would find useful to know how likely it is that anyone
> is using it.  Or if a lot of people are enabling 'frobnicate' flag,
> I could consider employing USE defaults.

For normal reporting, I'd suggest "counts of users" have some default
presentation that encourages people to think of the data as incomplete.

For example, instead of "0", it might print "<10", or say, "10: +/- 10"

Or rank results in terms of relative numbers, "low", "high", etc.

Or maybe incorporate time bounds with the information:

   "0 this month"

Because even the people participating may not be participating
frequently for all the niche things to turn up in every sample.

Just working out a good way to calculate what the "error bars" should
be is the hard part.

Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it

2020-05-09 Thread Kent Fredric
On Sat, 09 May 2020 15:22:52 +0200
Gerion Entrup  wrote:

> I'm not sure, if Portage is capable of this, but a distinction in USE
> flags needed to fulfil some dependency of another package and USE flags
> actively activated by the user could be useful.

Presently impossible, as how portage implements the former, is by
churning that information via either "plz sir, set this use flag in
your config", or via auto-tweaking config to assert "I wanted this, you
now want it".

After that happens, the information as to /who/ specified that want is

At very best you can make some inferences based on the comments
that get injected, but that's not anywhere near 100%, esp in turn-key
approach, or, alternatively, assert that if a flag is specified in
configure *and* something depends on that flag being set, then its the
dependent, not the user  but that really isn't true on a regular

For instance, uh, USE="X" (global) -> install Foo (w/ USE="X")

Foo depends on Bar[X?]

So is "Bar:X" required by the user, or by "Foo", or both?

And does the answer to that question depend in any way on whether B (or
Foo) declares IUSE="+X" or IUSE="X" ?

Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it

2020-05-09 Thread Kent Fredric
On Fri, 8 May 2020 09:49:18 +0200
Jaco Kroon  wrote:

> So we do need the full list of packages installed, filtered to ::gentoo,
> but there needs to be an indicated whether it's installed because it's
> in @world, as a dep of something in @world (which is possibly not in
> ::gentoo), or is some form of no-longer needed dep.

A dedicated report of orphans that are installed, from ::gentoo, would
probably help here.

Because you can't directly assume orphans are "user wanted", but they
*can* be.

That's why its important during --depclean to read the output and
re-add any to @world you need kept.

If you never depclean, then you get to skip that step.

( And I have *many* times added -1 to installation of something I
wanted, out of habit, because I do so much manual hacking via emerge -1
that adding it is an impulse! )

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Adding potentially questionable license AcePerl-Indemnity

2020-05-06 Thread Kent Fredric
On Thu, 23 Apr 2020 10:32:41 +1200
Kent Fredric  wrote:

Ugh. I just discovered this approach is in use in multiple packages.

So most of my proposal would have to get re-thought anyway if we were
going to do something about this.

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-05-05 Thread Kent Fredric
On Tue, 5 May 2020 02:47:48 +0200
Thomas Deutschmann  wrote:

> Yes it would be a signal but a useless signal, not?

"There are no users reported using this dist, so we can nuke it" is
still far far superior to "there are no reverse dependencies, so we can
nuke it"

*Even* when the former is false information.

As presently, the "no reverse dependencies, therefore nuke" essentially
asserts there *are* no users to consider.

So the *worst* case scenario for decisions made with these statistics
is our *current* case.

Even if *nobody* uses the service and *all* results indicates "nobody
uses anything", then we'll just be reverting to what we currently do:
Remove things entirely on conjecture that they're not useful.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PSA] If you ssh interactively to (somehow) let me know.

2020-04-27 Thread Kent Fredric
On Mon, 27 Apr 2020 09:43:44 -0400
Mike Gilbert  wrote:

> He was replying to me. Your master connection will continue to work
> just fine, as I said in my previous message.

I must have lost something in grammar, because no matter how many times I read:

> If you are authenticating that master connection as the "git" user, I
> suspect it will not affect you. If you are using it to push to
> gentoo.git, that is almost certainly the case.

I interpret that as:

- Anonymous fetch is fine
- Authorised Push will fail

But I guess my mistake is in that we don't push with "user@git ...", we
push with "git@ ... ", and the SSH key is the gate keeper of "push will
work", not the UID.


So assuming you're using git@ for fetch *and* push, *then* it will
continue to work.


Forgive me for any potential idiocy, language and remembering the
details of everything all the time is hard.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PSA] If you ssh interactively to (somehow) let me know.

2020-04-27 Thread Kent Fredric
On Sun, 26 Apr 2020 18:00:19 -0700
Alec Warner  wrote:

> This is correct.

Surely then, this is a reduction in fuctionality.

That's a handy tool to put up your sleeve when you're trying to avoid
getting thrashed by slow network connects when some contributor is
pushing every 30 seconds :)

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-04-26 Thread Kent Fredric
On Sun, 26 Apr 2020 10:52:27 +0200
Michał Górny  wrote:

> Do you have any other idea for spam protection then?

What is the realistic risk here for spamming?

If the record is well formed, and pertains to known packages, the worst
I currently imagine is astroturfing: A single individual attempting to
make a package seem more popular than it is.

Just generally IME, spamming aims to make a buck somehow, but if
there's no fields in the data set that can be used for this, and abuse
of existing fields to fill with spam prose get filtered by not
correlating to any known possible values, then the entire record is
simply invalid, and can be removed on that basis.

Conceptually, you could have a report with
but for anybody to see that they'd have to be querying data about the
::nigeria-prince overlay, and that's assuming we even show data about
overlays we can't locate.

Trolling ::gentoo with packages that don't exist seems easy to eliminate.

I don't like that astroturfing could be a thing ... but like, I also
don't really care about that happening.

For instance, has per-crate and per-crate-version download

That's super easy to rig, you get lots of spiky noise in infrequently
used packages simply due to various automated services fetching things.

But at scale, the data still turns out to be quasi-useful, as it allows
you to chart adoption and migration... because as soon as a new version
gets shipped, if people are using it, then you'll start to see an
uptick in reports from the new version.

The "change" and "change response" information is very useful, and a
very odd target for astroturfing.

I for one would be greatly interested in "new perl version shipped,
explosion of results due to people upgrading", because then I can gauge
roughly how many people managed to upgrade perl without having to join
#gentoo and cry about it being broken.

(We could also designate a certain UUID flag for use by Gentoo infra,
possibly even a UUID-per-host, the results of which were invisible in
the public data, but still visible to people with approved perms,
because we really do value the ability to know which packages we have
to be careful about causing problems in, and where infra is at with
upgrading various things before we remove the versions infra is using,
whereas currently, working out what infra are currently running
requires lots of direct communication)

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-04-26 Thread Kent Fredric
On Sun, 26 Apr 2020 03:39:24 -0700
Brian Dolbec  wrote:

> We would need that
> person/team to only enable their test system for gentoostats/disabled
> for deployments. Repeated failure to do that could result in that uuid
> being blacklisted.   Part of the initial profile details for that
> vm/image would be some details about approx numbers of deployments
> (yes, subject to change. But useful to know whether it is 10-15 or
> 100-500.  type of deployment  ie: vm/docker/kubernetes/desktop/server...

If the UUID generation was how I proposed in my other reply: On a
voluntary basis, with ability for UUID's to have metadata about what
the information associated with them may be used for, one could also
have a metadata field indicating what /kind/ of user the UUID was
associated with.

Then people simply installing things for testing, and reporting results
from their test rig could have a "tester" flag associated with a UUID
used only for testing, and then we can exclude that data from the main
reports, while still using it as evidence that a thing may work for
some audience.

The submission rate for UUID's with the "tester" flag could be allowed
to be higher, because it no longer contributes to the overall

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-04-26 Thread Kent Fredric
On Sun, 26 Apr 2020 14:38:54 +0200
Thomas Deutschmann  wrote:

> Let's assume we will get reports that app-misc/foo is only installed 20
> times. If you are going to judge based on this data, "Obviously, nobody
> is using that package, it's stuck on ... safe to remove" your
> view is biased:

I see this as more like what bloom filters get you, but in reverse:

- You still have to factor for "what you don't know"

- But now, instead of having "we don't know if anybody uses this", you
  *can* have a "we know for sure somebody uses this".

The anonymization and uncorrelatable aspects are of course very useful
to encourage people who would otherwise be averse to participate to
participate, but its for sure not a sure thing.

It would certainly be an improvement over what currently happens "No
reverse dependencies, thus, nobody is using it".

Bad things will still happen, but the absence of this tool won't stop
the bad things happening, because presently, the existence of users is
entirely conjecture.

Description: OpenPGP digital signature

[gentoo-dev] {RFC} Package: namespace on ( for ex: Package:dev-perl/Foo )

2020-04-26 Thread Kent Fredric


- {{package}} template can link to this as well as the page on when it exists
- can link to this when it exists
- Serves as a good default place for "maintainer down" and
  inter-maintainer documentation.
- Good place to document the sorts of things that don't make sense to
  rely entirely on einfo and friends, or comments, to document
- Very easy to have automated functions in ebuilds for deriving a
  relevant link to point people to, eg: 
   einfo "See $(package-wiki Testing) for details on comprehensive

  Which would internally ingest ${CATEGORY}/${PN} and generate the full${CATEGORY}/${PN}#Testing link

I'm already employing a strategy similar to this for Perl stuff, but
stuffing it all in Project:Perl/maint-notes/ has a lot of downsides (
which I'll describe later ), and it makes more sense for each node here
to be in a top level heirarchy, only grouped as being "perl related"
via [[Category]] controls.

I believe its also possible that if the right section names and details
are used, a general purpose search with SMW #ask can be made that does:

- List all packges in Package: which
  1. Have [[Category:Perl Packages]]
  2. Have the heading "Testing"

And therein, generate a list of pages which are perl related and have
specific instructions for testers.

Even general purpose pages which testers could skim through could be
made that lists all packages in tree with special testing instructions,
so when doing testing, one just rips open that list and ^F for the
package in question and seeing if there's anything matching.

The hard thing, but also a desirable thing, would be to have some way
for such pages to automatically have SMW-usable tags extracted from
metadata.xml, so that all pages for packages maintained by a given
maintainer can be trivially listed.

NB: I can't do this myself as it requires patching the source code to
add the new namespace.

Some of the present downsides of my approach:

- Category listings are inherently based on the full path relative to
  the namespace, so they all index as "Perl/maint-notes/CAT/PN", which
  is terrible for category listings.

- You can hack around this by specifying a "sort key" in your
  [[Category]] statement, eg: [[Category:Foo|Bar]] in

... But SMW searches with #ask seem to have no way to make use of this
information, and you go back to every result being grouped as "P... " 

And the category pages themselves still list the individual *entries*
with the name in their namespace-relative path, so even if you use the
sort-key trick, the output itself is still filled with vast amounts of

Please Gentoo gods, let me have this thing.

I would propose at this point such pages should be gentoo-author
editable only, as they're intended to have the similar authority as
Project: and friends, and they're not intended to have the same scope
as the more general purpose top level pages that are more aimed at
general users, instead, these pages are more "internal", to solve the
sorts of problems that aren't suitable for stashing away on bugzilla.

Only sticky point would be getting edit perms for proxy-maintainers to
document their things.

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-04-26 Thread Kent Fredric
On Sun, 26 Apr 2020 10:08:32 +0200
Michał Górny  wrote:

> A proper solution to cluster problem would probably involve some way to
> internally collect and combine data data before submission.  If you have
> large clusters of similar systems, I think you'd want to have all
> packages used on different systems reported as one entry.

For this, I'd suggest the ability to have an overrideable
"STATS_SERVER" (or something) ENV var URI that tells the submission
clients where to send their reports to.

Then have some server shipped in gentoo people can deploy, and submit
aggregated as a cron job, or potentially hand review the aggregated
submission data before submission, and potentially have tools to
whittle data out you don't want to share at the org level.

Such a tool is potentially useful to an organisation even without its
"submit to gentoo" capacity, as being able to internally analyse what
your organisation is using seems to be useful.

(eg: provide an admin a single point of information showing what
packages they need to audit, if all the nodes in the org are not
entirely controlled at the top level)

Though I think the overall design of anonymity by design is useful, I
can see usecases, especially in the organisation model, where being
able to voluntarily self-identify a node could be useful without
inherently being a privacy concern.

And you'd configure your relay to suppress these node identities in the
submitted data, or map them to a different org-wide identity. 

  I need to find somebody who is using  so I can ask them if 
  works, or if  is important to this package.

  Data indicates somebody within my org is using , and I need to ask
  them not to use , as its licensing terms are not compatible with
  our org.

Though for cases of voluntary identification, you'd need an interface
on the server node somewhere that allows you to generate unique ident
tokens, and associate data with them, possibly with a list of flags
dictating what records associated with this identity may be used for
(eg: Contact [y/n] )

Description: OpenPGP digital signature

Re: [gentoo-dev] [PSA] If you ssh interactively to (somehow) let me know.

2020-04-26 Thread Kent Fredric
On Sat, 25 Apr 2020 14:12:02 -0700
Alec Warner  wrote:

> Thus I now plan to remove this access[0]. If you need access to ssh as
> something not-git to, let me know in the next week.

Will this affect people who set up no-op SSH connections for a
persistent connection master, so that following git actions don't have
to pay the SSH connection startup penalty?

Description: OpenPGP digital signature

[gentoo-dev] [RFC] Adding potentially questionable license AcePerl-Indemnity

2020-04-22 Thread Kent Fredric
I've just discovered dev-perl/Ace has some fun questionable licensing
which includes a lovely indemnity clause, which had previously gone
unnoticed, and it stipulates additional requests for research
publications, which is not something mentioned in any license currently
in tree other than Tinker

Following is the entire body of the license I plan to put in
licenses/AcePerl-Indemnity ( name chosen to specifically alert people
tempted to accept this license that Indemnification is an important
part they should actually read )

Current advice also says that due to the terms of this license, we have
to RESTRICT="mirror" this as well, unless the Trustees want to sign off
on potentially indemnifying CSHL

Also following up with CPAN because as its *currently* mirrored on
CPAN, and has been mirrored there for at *least* 12 years, its
potentially in a legal situation as well.

( But that's the fault of the uploader if true, because you can't
upload anything to CPAN without mirroring being something you didn't
expect )

Once this license is added, the plan is to rework Ace-*.ebuild to be under

LICENSE="|| ( Artistic GPL-1+ ) AcePerl-Indemnity" 


Text Body:


The package and all associated files are Copyright (c) 1998
Cold Spring Harbor Laboratory.
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.  See the Artistic License file
in the main Perl distribution for specific terms and conditions of
use.  In addition, the following disclaimers apply:
CSHL makes no representations whatsoever as to the SOFTWARE contained
herein.  It is experimental in nature and is provided WITHOUT WARRANTY
By downloading this SOFTWARE, your Institution hereby indemnifies CSHL
against any loss, claim, damage or liability, of whatsoever kind or
nature, which may arise from your Institution's respective use,
handling or storage of the SOFTWARE.
If publications result from research using this SOFTWARE, we ask that
CSHL be acknowledged and/or credit be given to CSHL scientists, as
scientifically appropriate.


Description: OpenPGP digital signature

Re: [gentoo-dev] ebuild life cycle review

2020-04-16 Thread Kent Fredric
On Sat, 11 Apr 2020 21:41:58 +0100
Samuel Bernardo  wrote:

>  loosing ebuilds (we
> wants it!... we needs it must!... my precious)

Ebuilds are never actually "lost".

If you use gentoo's git repo for /usr/portage, you can always wind back
the whole tree, or some subset thereof, to a state where the ebuild

It won't be well maintained, but that's the compromise one pays for.

( You don't even have to use git for /usr/portage if you don't want to,
  you can do what I do occasionally and have an otherwise empty overlay
  with symlinks to a copy of gentoo.git at the desired point )

Description: OpenPGP digital signature

Re: [gentoo-dev] Stabilizations and src_test

2020-04-16 Thread Kent Fredric
On Sun, 12 Apr 2020 10:43:07 +0200
Agostino Sarubbo  wrote:

> In case of 'yes', the arch team member must compile with FEATURE="test" and 
> he 
> is allowed to block the stabilization in case of test-failure.
> In case there will be a test-failure there are two choices:
> 1) The maintainer fixes the test failure;
> 2) The maintainer does not want to take care, so he can simply remove the 
> blocker and set "src_test pass" to no.
> Both of the above are fine for me.
> Obviously, if there are already test-failure bugs open, the flag "src_test 
> pass" should be set to 'no' when the stabilization bugs is filled.
> I'm sure that this way would help to avoid wasting time on both sides.
> What do you think about?

Agree mostly, but this problem is in two places.

Ebuilds themselves need more mechanisms to communicate this, as if an
ebuild has problematic tests, then they're likely to be problematic
every time, and remembering to set the appropriate bugzilla flags
becomes a weakness.

In this vein, there's lots of similar inadequacies you find if you
follow this thread.

Like for instance, I maintain a lot of packages where the ability for
the tests to work is *environment specific*, and there's ultimately
different *kinds* of testing, and the audiences who run each varies.

Take perl packages for instance. There's a few where the test suite
*cannot* work, because they need either network IO or access to
physical devices to function.

But simply disabling tests because of this produces a gross weakness,
because Perl code cannot even be considered to be compatible with the
target perl until you actually execute it, because those
incompatibilities are ultimately "compiler errors", and you only see
them when you spin up a runtime, unlike code with a dedicated compile

Subsequently, I've taken to bolting on ebuild-internal hacks that
simply enumerate the modules and forces a perl instance to try loading
them, to at least provide *some* degree of assurance that the code
*probably* works.

But ultimately this means the way I see it, every ebuild could have
*multiple* test targets, and could have a control variable indicating
which targets to execute by default, and consumer knobs could expand,
or reduce, the testing based on preference.

We could even have something like say:

TEST_TARGETS="+build integration"
TEST_RESTRICT="network-sandbox? ( !root? ( integration ))"

Things like say, mysql, which has a standard test suite that takes days
to run, might be well served by having controls like this, so consumers
who want to have *some* basic assurance code works, without paying the
price for a comprehensive smoke, can do so, instead of opting to choose
"tests are hard, lets not do them".

Just I've been cautious about talking about this, because this is such
a can of worms, and leads into the debate about TDEPEND, and how we
stuff everything into USE flags...

And I really would *hate* for testing control variables to be USE
flags, where --changed-use rampantly introduces unnecessary havoc

( And the eventual fact will be there will be code that tries to depend
on specific values of these test control flags, and code that wants to
omit dependencies based on them, and portage complexity goes cray cray )

Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Kent Fredric
On Sat, 11 Apr 2020 11:39:21 -0400
Michael Orlitzky  wrote:

> I've been setting them just in case someone has a workflow/automation
> involving the keywords that hasn't been updated in ten years. If you
> kill the keywords, I wouldn't have to worry about that, so +1.

And that's pretty much the same thing I've been doing.

I imagine if these keywords go, then people trying to rely on them in
clients of various descriptions will start hard-erroring when they use

Description: OpenPGP digital signature

Re: [gentoo-dev] ebuild life cycle review

2020-04-11 Thread Kent Fredric
On Fri, 10 Apr 2020 12:31:19 +0100
Samuel Bernardo  wrote:

> - if there is more then X new versions in upstream, get from a release
> feed associated with ebuild (X value defined by project leader with
> threshold set by CI)

This is probably the biggest difficult part really.

There's lots of different services that provide this, but none of them
are great for us, really.

The majority of the ones I've looked at have a very hard time as soon
as perl versions turn up.

Even our own project, euscan, had serious problems with this.

And evaluating this data in a notifiable way can be very expensive
depending on how you do it, when contacting a service.

( Most services I've seen don't have a 'bulk' query interface, so you
need a query-per-package... , and trying to get the service to work out
'what gentoo has' to work it out is even trickier )

I've been abusing release-monitoring for perl stuff, it was very time
consuming to get everything we use tracked there, and I'm the only
person who really adds new perl entries to it to track, so it only
covers a fraction of gentoo.

( And again, it has the query-rate limitations, and the "perl versions
are hard" problems as well )

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Kent Fredric
On Wed, 8 Apr 2020 17:39:54 +
Peter Stuge  wrote:

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

Only as far as analyising "why was this package installed, currently
the metadata says its un-audited!".

But for things like "affected by CVE/Bug", the very nature of those is
they're often post-install metadata, so one should not be required to
change an ebuild and reinstall the ebuild if that metadata has to

And say, if a currently installed package had its "audit check marker"
removed from the metadata, portage should react to that immediately and
treat the installed package as bad.

The "what was the metadata when this package was installed" would only
help portage clarify the output message.

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Kent Fredric
On Tue, 07 Apr 2020 14:44:04 +0100
Roy Bamford  wrote:

> Gentoo must not single out any package for special treatment.

Indeed. Cases like this just demonstrate that something about the way
we do things is somehow inadequate.

The idea that "what we have works" is something we get away with,
because people just exclude the things that would break things.

Sometimes you just need some case like this to make an example of us.

Like happened with Rust:

- It took a while and a bunch of legal threats for them to publish a
  GDPR compliance privacy notice.
- They ( still haven't made a clear definition of what legal
  conditions apply and what may or may not be uploaded (Some people are
  presently testing those waters by publishing code with copyright
  notices and "no distribution" clauses, in the hope they can get their
  ass into gear and make it clear )

And I've seen people "test the system" for CPAN too.

Its clear we need *something* in place, but I doubt that "something" is
something that can be achieved in an appropriate way with the way our
tooling currently works.

( In that, its basically an all-or-nothing scenario for the most part,
where finer grained and policy-based exlusions, like ACCEPT_LICENSE,
make sense to employ )

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Kent Fredric
On Tue, 7 Apr 2020 12:47:33 +0200
Thomas Deutschmann  wrote:

> Sure, that could have banal reasons like "No one audited the Linux
> version yet". But in security you don't issue warnings if you aren't
> sure. Because if you make false statements people will no longer trust
> you. But trust is everything.


In line with my other suggestions with exposing this via in-repo
meta-data, there probably should be a facility in a future EAPI that
allows one to both know about this /class/ of risk, and address it.

So for instance:

ACCEPT_ASPECTS="bug:45678 bug:14678 cve:COVID-19 trust:proprietary"

Or something.

The gist being that say, zoom could have:

 > net-im/zoom  trust:proprietary

As could anything that is both shipped as a binary blob, not produced
by somebody on gentoo staff, and has no source available. 

For instance, if the source is available, but its a 3rd party binary,
there could potentially be a step in shipping that puts unaudited code
in the binary, so its not smart to say its entirely as-bad as something
that is unaudited, but *some* caution should be taken.

If a user locally wants to, by policy, avoid all packages that are
either unaditable, or have some weaknesses around their auditabilty, we
should provide tools to do that.

Syntax above not expected verbatim, just food for thought, but its
worth mentioning that bug/cve/trust levels don't always map 1:1 with packages, 
and also, that 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.

Running with the idea a bit here: 

It would even be possible for a 3rd party overlay to contain *only* a
trove of these aspects, and then a controlled deployment could have a local

REQUIRED_ASPECTS="trust:team-sec" ( where team-sec is defined by said overlay )

Which requires all packages you install on your system have some sort
of metadata indicating that they've been signed off by team-sec. (
either the whole cat/pn, or some versions there of )

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-07 Thread Kent Fredric
On Mon, 6 Apr 2020 23:55:07 +0100
Samuel Bernardo  wrote:

> This is the kind of useful information that we could collect from the
> QA, extending the greatness of the best distro ever made. The
> availability of software from a distro is better than installing it
> standalone, allowing to share knowledge about relevant information such
> as security, maintenance, ...


I've long wanted some sort of capacity for:

- Portage to be capable of correlating packages and their versions
  with known bugs that affect those versions 

- Portage to be capable of correlating packages and relative CVE's.

Presently all we end up doing is:

- Oh no, it has a bug, remove it!
- Or in more careful conditions, P.Mask it with reasons

The best tool we have to solve even part of this problem is glsa-check,
but its not mainstream enough.

So we simply don't have the /tools/ required for general users to make
decisions about "should I upgrade?", "should I remove this?" beyond
"oh, its gone", or "oh, its package masked"

But utlimately, this is not a technology problem: Its a staffing problem.

We simply don't have the power to keep old things or vulnerable things
around for people to use "if they're clever"

( And every additional version aggregates to exponential complexity
creating more places for portage to get confused )

For top level binary things like zoom, its easier due to nothing
depending on it.

But handling such things for vulnerable or buggy dependencies, things
get tricky quickly.

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-06 Thread Kent Fredric
On Sun, 5 Apr 2020 17:11:01 +0100
Samuel Bernardo  wrote:

> Sorry about my comment, but couldn't that be solved choosing the right
> profile or opting for an official overlay, raking the assurance level of
> those?

If zoom is a binary only package, not opensource, we can't make any

Even if the source is available, if we're not shipping variations of it
compiled by our tools, there could be arbitrary un-evaluated extensions
hiding in it.

So no, nobody can actually make assurances of this software, we can
only stipulate which cautions we know are warranted.

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-04 Thread Kent Fredric
On Thu, 2 Apr 2020 10:01:57 +0200
Michal Prívozník  wrote:

> Alternatively, you can set up a VM that contains nothing but the bare
> minimum required to run app X and assign webcam to it, for instance.
> Having said that, I'd still love the packaging system to install the app
> as it resolves all the dependencies, etc.

Depends how concerned you are about VM busting exploits contaminating
the host.

( Maybe not Zoom in particular, but with regard to the general theme of
"risky apps on a valued system" )

Description: OpenPGP digital signature

Re: [gentoo-dev] zoom concerns

2020-04-04 Thread Kent Fredric
On Wed, 1 Apr 2020 17:53:39 -0700
Alec Warner  wrote:

> you cannot accept arbitrary long
> passwords

Sure you can, as long as you're not storing them anywhere, and are
instead, storing their checksum of some kind.

Then the only limitations really are how much memory and time you have
to locally buffer your password while the checksum computes it :)

Nobody stores passwords right? Right?

(/me then socially distances from the internet)

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-29 Thread Kent Fredric
On Mon, 23 Mar 2020 20:27:51 +0200
Joonas Niilola  wrote:

> AFAIK all major changes have been posted here and pushed with some delay.

In my experience, "Some delay" is usually short, as developers making
the change are eager to push it through.

But the people maintaining the overlays are much more likely to have a
bigger expectation of what that "delay" should be, because many of them
don't have the time to read -dev every day, and they have other things
to do than rework their overlay with regards to patches on ::gentoo.

So what's more likely to happen is the breakage isn't noticed till
users are affected and complaining, and that's not ideal.

( Though at the end of the day, this problem ends up being a "not
enough devs to man the pumps", I have stuff I've let rot because I've
got too many things to do, and nobody really is taking up the slack )

Description: OpenPGP digital signature

Re: [gentoo-dev] reduce load of tinderox' bug reprots to

2020-03-29 Thread Kent Fredric
On Sun, 22 Mar 2020 15:11:23 +0100
"Haelwenn (lanodan) Monnier"  wrote:

> I think it might be better to fix bugzilla to be able to send multiple 
> attachments at once. AWS S3 might be okay for the long term but I've often 
> seen paste services being used and most of them expire in a week/month, so 
> you can easily loose the content before it can be read or fixed and 
> absolutely no hope to have it be readable if it's an old bug that might have 
> appeared again.

Part of my objections to using Bugzilla for this is due to the
attachments frequently being unuseful.

Not that *all* of them are useless, but due to the pattern of
automation, no sentience evaluates if a given log is useful or not, so
there are usually many more to wade through that don't help.

Add to this the whole "bugzilla limits attachment sizes", and the
workaround being "upload compressed versions which are harder to read",
this creates a lot of attachments that can't even be read directly in
your browser (even though they're just text, the size demands
decompression first).

And due to the sizes involved, I worry about the burden it places on
the database to perform this at scale.

IMO, Databases are just not the tool to use for binary data storage. (
Though I suspect perhaps bugzilla has an out-of-database binary file
storage thing? idk ).

It feels like that mistake people make when they commit large binary
assets into git, where they really want something out-of-band more
optimized for it.

And like git, once its submitted, there's no "delete" as far as I know,
... which, given the ratio of useful data vs the size, seems silly.

So the net result is a lot of downsides due to silly limitations in the
choice of platform.

I don't want to discourage automated testing, but I do want to champion
a better platform to store this data (and more importantly, aggregate
this data).

Just so its clear, my dream is a system like CPAN Testers, where
anybody can submit results regardless of who they are, with no quality
requirements on the data submissions, ... without necessitating that
each and every failure be communicated to a bug report.

That way, the 3rd party platform collects information that indicates
where a bug *could* be, and once an actual bug is found in this
information set, the bug is opened, citing the relevant details.

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-21 Thread Kent Fredric
On Sat, 21 Mar 2020 11:03:19 +0300
Alexander Tsoy  wrote:

> Binary distros usually have separate repositories for each
> architecture.

One aspect: They don't have a package database that's a collection of
bash scripts that have to be routinely executed.

And they also don't have USE flags to complicate dependency analysis.

So their user-side interface can handle this "Can't satisfy dependency"
situation much more quickly. ( I have no recollection of apt taking
more than a few seconds to work out what it needs to do, or throwing an
error )

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-20 Thread Kent Fredric
On Thu, 19 Mar 2020 15:40:20 -0400
Mike Gilbert  wrote:

> I'm not sure what you mean by "stabilization graph". I'm guessing you
> mean the dependency graph for stable keywords?
> Valid dependency graphs are determined by whatever our tooling deems
> valid. The tooling could be updated to permit amd64 packages to depend
> on noarch packages, and vice-versa.

No, its worse than that :/

If X is "noarch" and its dependency Y is "amd64", then a user on "sparc"
will be able to install "X", but not its dependency "Y".

And thus, the error from portage will:

- Take longer to produce
- Be less clear

And any tooling that exposes "noarch" as "you can install this" will be
wrong, because instead of the KEYWORDS being an independent declaration
of usability, the entire dependency graph has to be checked for usability.

Thus, end users will have portage erroring that a no-arch package is
not available due to its dependencies being impossible to satisfy.

And, as a QA measure, we'd have to make that condition illegal.

And the only way to do that, would be for CI to reject packages that
are "noarch" and depend on things that are in turn, not "noarch".

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Kent Fredric
On Thu, 19 Mar 2020 14:52:08 +0100
Gerion Entrup  wrote:

> Maybe I misunderstand something but shouldn't that be the normal case?
> Every single Python package (candidates for noarch) for example depends
> on the Python interpreter, which must have non noarch keywords.

Yeah. So Basically, this pans out to being practically useless unless
you have no dependencies at all, or all your dependencies are
themselves noarch.

And that excludes all of python, and all of perl, because python and
perl cannot ever be noarch.

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Kent Fredric
On Thu, 19 Mar 2020 03:07:21 +0100
Thomas Deutschmann  wrote:

> Why can't we use "ALLARCHES" stabilization for that?

Because that experiment basically failed.

Bugs with that flag, basically were treated (repeatedly) like that flag
wasn't there.

And that approach still has the weakness of it being a conjecture of
stability, not an evidence of stability.

But worse, it /hides/ this distinction, so an end user can't
differentiate between "stable by conjecture" and "stable by evidence"

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Kent Fredric
On Wed, 18 Mar 2020 09:54:42 -0500
William Hubbs  wrote:

> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
> Thanks,

I'm just gonna say I disagree with this proposal as stated.

Stability and arch support, for the purposes of QA, should be based on
demonstrated evidence.

Not speculation ( which noarch inherently is ).

I'd be "OK" with a provisional flag that indicates a package /should/
be architecture independent, but it should be as an optional
enhancement for users on minor arches who want to minimize their
fussing with keywords.

But KEYWORDS imo, should be a graph of demonstrated evidence, otherwise
it pretty much makes the purpose of arch testing redundant.

And yes, even vanilla perl code can have arch dependent behaviour.

( I myself fell prey to pack() having some behavioural changes based on
the users 32 vs 64bitness )

However, what I propose isn't something you can "hack in" to an
existing EAPI's tree.

You'd likely need an EAPI enhancement to implement this the way I'd

In short:

- An Ebuild should still have KEYWORDS that indicate
  - What it has been tested to work on
  - What it has been evidentially supported on
- But an Ebuild *could* have a variable that indicates
  - That in the absence of good testing and evidence, it is
*expected* to work on all arches.
- End users could be provided tools to *permit* the latter class
  to be installed on their system based on the speculation
- But it would still be "out of scope" for users who want and demand
  a tested, predictable, quality, stable system.

Anything else is just weakening our quality assurance for our users,
in order to pander to developer ease.

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Kent Fredric
On Wed, 18 Mar 2020 17:52:25 +
James Le Cuirot  wrote:

> Not quite. Tools like repoman will need to be updated to understand
> that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> only KEYWORDS="noarch". I do think the idea has merit though.

But the inverse is _not_ true, an ebuild with KEYWORDS="noarch"
*cannot* depend on another ebuild with only KEYWORDS="amd64".

Otherwise it breaks the entire stabilization graph.

Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Kent Fredric
On Wed, 18 Mar 2020 11:59:25 -0500
William Hubbs  wrote:

>  Sure, but if you run into something like that you just don't use the
>  noarch keyword for those packages.

But as soon as this happens, all dependent packages that are noarch
will need to also transition to not using no-arch.

So it turns into a lot of busywork without benefit.

Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep

2020-03-11 Thread Kent Fredric
On Sat, 07 Mar 2020 17:28:53 +0100
Michał Górny  wrote:

> dev-python/fedmsg

Just to buck the trend: Thanks.

When I saw the PR for this with my name in it (due to comaint), I
initially reacted and was going to oppose this removal.

But, well, I thought about it, and the reason this was here in the
first place was to look after some future potential work with
release-monitoring that had stalled and never come to fruition.

So yes, its removal was satisfactory.

If the "work with release-monitoring" folk ever get around to actually
needing this, we can always reinstate it then anyway.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v3 2/2] metadata/qa-policy.conf: Include deprecated eclasses

2020-02-26 Thread Kent Fredric
On Wed, 26 Feb 2020 15:36:52 +0100
Michał Górny  wrote:

> +fdo-mime = xdg-utils
> +games = (none)

Some of these need to have more context. For instance, a comment for
the games one citing -ml discussions about why the eclass is
deprecated, and what you should be doing instead, might be useful

Description: OpenPGP digital signature

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

2020-02-03 Thread Kent Fredric
On Thu, 30 Jan 2020 08:19:08 -0500
Rich Freeman  wrote:

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

Its like we need some sort of statement people can use that says
something to the effect of:

- GPL versions published after this release may be used, but contingent
  on the author of this release verifying that newer GPL versions continue the
  intended spirit of GPL2

The idea that my code might be later under some other terms of license
that I've never read is about as bad as somebody updating EULA/TOS
without informing anybody it changed.

Its *probably* fine, but I'd want to have opportunity to read those
before rubber stamping it.

As they say: Trust, but Verify.

GPL terms changing after an authors death should not really apply
retroactively to the dead authors code.

Description: OpenPGP digital signature

Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Kent Fredric
On Sun, 19 Jan 2020 13:54:33 -0500
Rich Freeman  wrote:

> Nothing of importance should be stored on github.
> If you and I have a conversation at a bar, and as a result you decide
> to make a commit without any useful comments, and then we both retire
> from the project, just as much information is lost.

Its not that I'm saying that this should be forbidden, only that there
is a tangible risk of lost of useful information.

Having a discussion at a bar, and you making a commit as a result is
one thing, but if I discovered a bug, and then only told you about it
at the bar, that would be possibly bad, because there's no guarantee
that the bug is communicated sufficient to ensure it gets addressed,
and you may go home at the end of the night and entirely forget the bug
existed, and people could continue to suffer it, and potentially
neglect to report it as well. ( End users are substantially less likely
to file bugs, IME )

When I mention bugs to people on IRC, I often follow up with "Would you
like me to file a bug?".

Often, the answer is "yes".

The crux of the matter being bugs that exist, and are communicated
outside the core bug tracker, weaken the assurance that it will be seen
and fixed, which amounts to a negative thing.

I wouldn't forbid such a thing, just make it clear that doing so is a
lower standard of quality, has risks, and should come with a level of

Description: OpenPGP digital signature

Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Kent Fredric
On Sun, 19 Jan 2020 12:31:52 +0100
Michał Górny  wrote:

> Enjoy!

Many thanks for making this happen.

Description: OpenPGP digital signature

Re: [gentoo-dev] New QA Policy Guide

2020-01-19 Thread Kent Fredric
On Sun, 19 Jan 2020 07:08:30 -0500
Rich Freeman  wrote:

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

If github goes away after bugs and PR's are filed on github, then that
historical context is lost, and may include the loss of open bugs and
open PRs, which all may still be relevant.

Many people consider that to be a bad thing.

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 21:19:18 -0500
Aaron Bauman  wrote:

> Ah, you found the Achilles heel. It is much easier to postulate on the mailing
> list, use big words, and then say you just won't do that thing because
> tools/languages such.
> Perl though...

FTR: Even though I'm good at Perl, I wouldn't use it for this task.

There are a lot of reasons behind this.

But at least one of them would be if I wrote it in Perl, I'd have
nobody else contributing either.

And IME, that's fair enough.

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 11:40:08 +
James Le Cuirot  wrote:

> Unfortunately a3li used Elasticsearch, which no one understands, but
> it's a start.

And I've used ES enough to say I would rather never use it again.

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 11:35:49 +
Michael 'veremitz' Everitt  wrote:

> Note:  we're nnot acttually talking about replacing portage here, just
> creating a tool thiink php script web tthingy)) that will do some of
> the pre-screeninng wok that AT hate (eg what kensiington did  with
> stable-bbot)
> * with apologies for keyboard/remote-access la creating typo hell.

But, doing that requires viewing realised copies of ebuilds, which
requires interpreting eclasses and variable interpolation, which
requires bash sourcing, which requires a mountain of portage hell.

Yes, sharing the stable-bot logic would probably be fine.

But it doesn't use a database AFAIK, it would likely just be making use
of the MD5Cache (either directly, or indirectly via portage APIs)

But I won't be volunteering, because I won't touch python.

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 11:14:15 +
Michael 'veremitz' Everitt  wrote:

> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like .

Oh, and once upon a time, there was actually a trick you could do to
make portage keep its metadata caches in an SQLite database, which had
its benefits, and I even had a rough tool I wrote in ruby and shared on
the old (defunct) wiki that helped do quick database queries.

But the trick actually makes portage slower in multiple ways, and it
never really got widespread love.

( Though I would argue how the data was stored was also inadequate for
a lot of other tasks one might want to do with a database, like,
keeping DEPEND stored in its string format )

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 11:14:15 +
Michael 'veremitz' Everitt  wrote:

> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like ..
> Ok, let the flamewars begin ...

There's no real problem with a package database, however, the real
limitation is in the ebuild source format, which ultimately means any
such database needs a lot of bash-sourcing hell to simply stay
up-to-date ( any time an eclass changes, the interpretation of every
ebuild that uses it also changes, necessitating some pretty fun(1) code )

And that winds you up fighting with portage internals.

So simply, in order for somebody like me to actually implement such a
thing, a precursory step is to rewrite enough portage to do just that.

But I haven't (yet) gotten around to that.

1: Not actually fun.

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 10:35:09 +0100
Fabian Groffen  wrote:

> Hmmm, interested to hear what kind of things you're thinking about here.

A lot of the "Work" of filing a keyword request is modelling all the
consequential keywordings that have to take place.

If there was say, a web based UI, that:

- Automatically determined which packages are ready for stabilization
  due to all their dependencies already being stable (and maybe with
  automatic cooldown-from-testing detection )

- Automatically determined which packages can be keyworded without
  additional work due to all their dependencies being keyworded

- When requesting keywording/stabilization, automatically determined
  what all the consequences are and what else needs to be keyworded to
  satisfy it

- Allowed a simple "Add keyword(s)  for package " interface,
  that intelligently created an issue and a target list, and then once
  the list was built, constantly ensured the list to be valid, or
  determined automatically when sub-work was completed and reducing the
  published list automatically, and then responded to potential issues
  based on changes in git, ( as opposed to being only triggered when
  the bug was touched )

Most of the "pain" and legwork required by maintainers would go away.

As it is, I feel a lot of us are reproducing a lot of logic that is
rather routine and could be automated.

But the overall idea here is to orient the point of keyword-requests in
some way to focus on the primary objective, where the developer
indicates their intent, and the system's job is to facilitate that
intent coming to fruition, pointing out problems on its own.

( I have somewhat hacked together some perl scripts for myself for some
of these tasks, but the command-line interface is not ideal for this
workflow, and the code is not in a condition I can share it, and I
don't think perl is the right language to address this problem with )

Description: OpenPGP digital signature

Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Kent Fredric
On Sat, 28 Dec 2019 08:09:33 +0100
Michał Górny  wrote:

> How can we improve this?

Every time this kind of issue comes up, I can't help feeling we need
some sort of tool more advanced than what we currently have.

Something that maintains persistence of keyword demands similar to how
the current bot does, but more ... 

Its the sort of thing I get tempted to implement myself, but get too
horrified about the prospect of working with portage internals to do it.

Description: OpenPGP digital signature

Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies

2019-12-20 Thread Kent Fredric
On Fri, 20 Dec 2019 13:54:44 -0500
Mike Gilbert  wrote:

> Yes, I think you misunderstand something, but I'm not sure exactly how.

I think the missing part of my understanding might be that IDEPEND
needs to be satisfied by:

- Packages installing binpkg's ( which don't need src_fetch, unpack, etc )
- Package managers *removing* packages.

As in, if a package declares IDEPEND="foo"

And "foo" is not available when asking portage to "emerge -C bar"

Portage must demand that "foo" is reinstalled to allow "bar" to be
removed ( as foo needs to be there to complete pkg_*rm )

This probably gonna make package manager fun :)

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] virtualx.eclass: Append RESTRICT="!test? ( test )" by default

2019-12-20 Thread Kent Fredric
On Fri, 13 Dec 2019 12:50:00 +0100
Alexis Ballier  wrote:

> Seems a good candidate for a future EAPI

In theory, there are packages that can execute src_test when USE="test"
is not satisfied.

Just I don't tend to see this in practice.

Description: OpenPGP digital signature

Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies

2019-12-20 Thread Kent Fredric
On Thu, 19 Dec 2019 20:40:26 +0100
Michał Górny  wrote:

> The proposal is to add a new dependency type (codename: IDEPEND) which
> indicates dependencies used for pkg_*inst (and pkg_*rm?) phases

Given the nature of this, I somewhat expect this to cover dependencies
required for src_unpack and src_fetch, and possibly src_prepare

Am I misunderstanding?

Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs due to slis' retirement

2019-12-18 Thread Kent Fredric
On Wed, 18 Dec 2019 22:35:40 +
Michael 'veremitz' Everitt  wrote:

> There is some very strange wrapping/formatting in this message, was that
> intentional?

If I had to guess, I'd say the word-wrap length was accidentally set to
"8" instead of "80".

Description: OpenPGP digital signature

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

2019-12-18 Thread Kent Fredric
On Wed, 18 Dec 2019 23:58:22 +
Sergei Trofimovich  wrote:

> [c] would be nice to be solved at portage level if portage could schedule
> multiple merges for the same package with different USE flags.

Related bugs:

- Portage should be able to auto-flip USE="test" & FEATURES="test"

- Portage needs an extension to package.use specification to provide a
  level of discretion to portage to flip flags on its own

Description: OpenPGP digital signature

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

2019-12-14 Thread Kent Fredric
On Sat, 14 Dec 2019 08:16:03 +0100
Ulrich Mueller  wrote:

> These prevent NOCOLOR in make.conf or emerge --color=n from working
> correctly, and I guess they are also problematic from an accessibility
> point of view.
> Are there any objections against removing these sequences from strings?
> AFAICS, they are used by less than ten packages, and one eclass.

Maybe we can have some future EAPI feature, or special eclass, that
allows people to add escape codes while also respecting the

Sort of like what git has in its formatting codes, where they're turned
off when colours are turned off.

  hl 1 "${@}"  # because 'hl' inherently behaves like echo when not captures 
  einfo "Fetching $(hl "${r}" ) ..."

Or something along those lines?

I'd wager that a large body of things "not using it" is not because
it wouldn't be useful, but due to people knowing this problem exists?

-- Further Bikeshed --

Maybe it could even be thematic?

   "Fetching $(hl url )"


But < hl   > as a general concept works.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-07 Thread Kent Fredric
On Fri,  6 Dec 2019 12:09:31 -0800
Georgy Yakovlev  wrote:

> Default output just prints crate name.
> With -vv we can see all cargo options and rustc args.

On the overlay with rust-crate.eclass, I've not found the verbose
output very helpful for anything.

I would probably ask for a knob to tweak that disabled this.


   -j $(makeopts_jobs)
if [ "${ECARGO_VERBOSE:-1}" == 1 ]; then
  ECARGO_OPTS+=( -vv )


cargo build "${ECARGO_OPTS[@]}" ... 

or something along those lines.

I've also (often) had to invoke stuff like:

src_test() {
   RUSTFLAGS="${RUSTFLAGS} --cap-lints warn" rust-crate_src_test

Because well, upstream.

But I'm not entirely fond of that syntax.

Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-07 Thread Kent Fredric
On Fri, 06 Dec 2019 10:03:23 +0100
Alexis Ballier  wrote:

> (*) and force the use of some handy git options like only commit paths
> starting from cwd even if other files had been git added, which i never
> remember what is the git cli option for this

There isn't so much a CLI option, more, there's a parameter that "git
commit" takes which allows you to enumerate which paths to commit.


  git commit

Commits everything staged.

  git commit .

Commits only CWD

But, with one important caveat:

  git commit

Will only commit changes previously added with "git add" or whatever to
the index.

  git commit .

Will commit *any* changes to anything in "." as long as they're
"tracked" by git.

But this is what repoman does anyway ;)

The doc line for this in "git help commit" is:

   3. by listing files as arguments to the commit command (without
   --interactive or --patch switch), in which case the commit will
   ignore changes staged in the index, and instead record the current
   content of the listed files (which must already be known to Git);

Description: OpenPGP digital signature

  1   2   3   4   5   6   7   8   9   >