Re: [gentoo-dev] Pushing to distfiles?
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 pgpCIlFNyOlsy.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Pushing to distfiles?
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* pgprFimAdzw3k.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
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 :) pgpfy7l8eNo37.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
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 :) pgpLz6jEcf9n6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-11-01 23:59 UTC
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. pgpCAtb1BSYaD.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
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 before. 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 ) pgpi6mrAJek5K.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init
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? pgp0al5IKutdA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New customization options available on packages.g.o
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: https://packages.gentoo.org/maintainer/ken...@gentoo.org/bugs 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: https://packages.gentoo.org/maintainer/p...@gentoo.org/bugs And well https://packages.gentoo.org/maintainer/ken...@gentoo.org/stabilization Should absolutely be greater than three. More like: 221 As per: https://packages.gentoo.org/maintainer/p...@gentoo.org/bugs And https://packages.gentoo.org/maintainer/ken...@gentoo.org/security Says 0 *and* gives a blank page, but surely, it should aggregate this? https://packages.gentoo.org/maintainer/p...@gentoo.org/security Either way, great stuff :) pgpODFuHN_VMd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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 gentoo.org 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. pgpw5PItQheYQ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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. pgpR_IjvewA8t.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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 example. 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 ) pgpqoOko22Ei0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
On Mon, 14 Sep 2020 10:15:31 -0400 Rich Freeman wrote: > It might be easier to take smaller steps, such as having a policy that > "any call for devs to use/test a new tool/service, or any service that > automatically performs transactions on bugzilla, must be FOSS, and the > link to the source must be included in the initial communication, and > it must be clear what version of the code is operating at any time." > That is a pretty low barrier to those creating tools, though it > doesn't address the infra concern. However, it does mean that infra > is now free to fork the service at any time, and reduces the bus > factor greatly. For the situation of things that take life before being part of infra, I think the least we can do is recognize their utility and importance, and at least, have infra *offer* some sort of shared location to run a deployment. That I think helps everyone, gives people a place to remove their own bus factor, but without mandatory strongarming. pgpJ3wCEsqaTS.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
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. pgpFSehgOrpfp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
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 optional. 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 keywords. 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. pgpGWwZcOK06b.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
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. :/ pgpsytvtxUHNq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
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. pgpDDuuC_8O8A.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: pgo - a command line interface for packages.g.o
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 :/ pgpwkgYKNTqOh.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-perl/gnome2-vfs-perl
# Kent Fredric (2020-08-17) # No reverse dependencies, and Gtk support is becomming # obsolete in Gentoo # Removal in 30 days dev-perl/gnome2-vfs-perl pgpZCAMkQcO9D.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
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? pgpZibCoYPFgd.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-perl/Data-Diver
# 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. dev-perl/Data-Diver pgp9YHMIAr5i9.pgp Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-perl/gnome2-perl
# Kent Fredric (2020-07-10) # No reverse dependencies, and Gtk2 support is becomming # obsolete in Gentoo. # Removal in 30 days pgpqlJgLDz9hL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: packages.g.o: new features available
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. pgplxiMl5NPIx.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: packages.g.o: new features available
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. +1. 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. pgp_8Cjru6j8f.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: packages.g.o: new features available
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: https://wiki.gentoo.org/wiki/Project:Perl/Version-Scheme This has some side effects visible in packagetest - https://packagestest.gentoo.org/packages/dev-perl/App-FatPacker Already up-to-date, it just can't tell because the versions don't match upstream. - https://packagestest.gentoo.org/packages/dev-perl/Alien-Build Already up-to-date, it just can't tell, because the versions don't match upstream. 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. pgprSV2qKCpBo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: packages.g.o: new features available
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. pyt...@gentoo.org)
> - Gentoo Developers (e.g. la...@gentoo.org
> - Proxied Maintainers (e.g. la...@the-cow.de)
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,
> https://packagestest.gentoo.org/maintainer/p...@gentoo.org/outdated
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:
Outdated:
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.
pgpnQ8o2A2HC1.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: packages.g.o: new features available
On Wed, 8 Jul 2020 02:57:57 + Max Magorsch wrote: > I am glad to announce further progress at packages.gentoo.org (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 > - repology.org data > - github pull requests > - stabilization bugs > - keywording bugs > - security bugs > - general bugs > for each package. Just sayin', this is nothing short of absolutely fantastic. Thanks. pgpY4TESQMl4V.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Standard build environment variables
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. pgpasaW8H6QqH.pgp Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Add caching to a few commonly used functions
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
there.
And I'd expect to see a lot of commonality in this.
# qlist -I --format "%{PV}" | wc -c
14678
# qlist -I --format "%{PV}" | sort -u | wc -c
8811
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
32604
# find /usr/portage/ -name "*.ebuild" | sed
's|/usr/portage/||;s|/[^/]*/|/|;s|[.]ebuild$||' | xargs qatom -CF
"%{PVR}" | sort -u | wc -l
10362
katipo2 ~ # find /usr/portage/ -name "*.ebuild" | sed
's|/usr/portage/||;s|/[^/]*/|/|;s|[.]ebuild$||' | xargs qatom -CF
"%{PV}" | sort -u | wc -l
7515
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!
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
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. pgpgZywecqaW5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure
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
anything.
> + # 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.
pgpryNPG16yA7.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Codec project
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. pgpt1MEfgzDTX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
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 else. 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 tricky. 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 :) pgpGDBplJU7XL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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. pgpL037xJyqxw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
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) pgpTzObm8wd4R.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
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 ) pgpMHrGzi7ALn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
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.
pgp3N70arox5C.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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 data. pgp2bPAtbKLWn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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) pgpAEpbsuoP1P.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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. pgp3S6X2G8lWc.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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. pgpsx5km9Qpj3.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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 computation. 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 ) pgpVo9Hg2tlvb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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. pgpVY__tDhm5i.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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 IV/RESPONSE/RAND. Or something like that. But the gist is it would be impossible to use ID's not generated by the server. 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 ) pgpRtdZuRbfZX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Anti-spam for goose
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. pgp6cCemO_pkT.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Initial version of gander/goose statistics up for testing
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. pgpLOndd9Coih.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it
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. pgpUKxGN_q6U5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it
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 lost. 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 basis. 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" ? pgpIoRLoR5lPw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it
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! ) pgpbZvnrigLQ0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Adding potentially questionable license AcePerl-Indemnity
On Thu, 23 Apr 2020 10:32:41 +1200 Kent Fredric wrote: Ugh. I just discovered this approach is in use in multiple packages. https://metacpan.org/source/LDS/AcePerl-1.92/DISCLAIMER.txt https://metacpan.org/source/LDS/Bio-SamTools-1.00/DISCLAIMER https://metacpan.org/source/AVULLO/Bio-DB-HTS-3.01/DISCLAIMER So most of my proposal would have to get re-thought anyway if we were going to do something about this. pgpr8nPzWwjWt.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
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. pgpocHsjWcN5y.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
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. Right? So assuming you're using git@ for fetch *and* push, *then* it will continue to work. Right? Forgive me for any potential idiocy, language and remembering the details of everything all the time is hard. pgpIucuM6gDEB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
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 :) pgp6Hvdpu0Q9i.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
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 "dev-foo/plz-sir-halp-me-I-have-money-and-an-a-nigerian-prince::nigeria-prince", 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, crates.io has per-crate and per-crate-version download statistics. 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) pgpd35R8sKJD6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
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 statistics. pgpNs50CPKG9p.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
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. pgpgPoUjIyApz.pgp Description: OpenPGP digital signature
[gentoo-dev] {RFC} Package: namespace on wiki.gentoo.org ( for ex: Package:dev-perl/Foo )
Advantages:
- {{package}} template can link to this as well as the page on
packages.gentoo.org when it exists
- packages.gentoo.org 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
testing"
Which would internally ingest ${CATEGORY}/${PN} and generate the full
https://wiki.gentoo.org/wiki/Package:${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
Project:Perl/maint-notes/Bar
... 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
redundancy.
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.
pgpCSk5Sk4Yur.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
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. Example: I need to find somebody who is using so I can ask them if works, or if is important to this package. Example: 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] ) pgpZ0SD8p685S.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PSA] If you ssh interactively to git.gentoo.org (somehow) let me know.
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 git.gentoo.org, 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? pgporZU0A4eKl.pgp Description: OpenPGP digital signature
[gentoo-dev] [RFC] Adding potentially questionable license AcePerl-Indemnity
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" Upstream: https://metacpan.org/source/LDS/AcePerl-1.92/DISCLAIMER.txt Text Body: == The Ace.pm 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 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR ANY OTHER WARRANTY, EXPRESS OR IMPLIED. CSHL MAKES NO REPRESENTATION OR WARRANTY THAT THE USE OF THIS SOFTWARE WILL NOT INFRINGE ANY PATENT OR OTHER PROPRIETARY RIGHT. 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. == pgpCbXKnT7hY3.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
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 existed. 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 ) pgp6yBauaZw01.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilizations and src_test
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 stage. 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 ) pgpctmi0XWqfF.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords
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 them. pgpc4aSGDNUcA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
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 ) pgpxsEjxTVsqt.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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 change. 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. pgpSNSjOkuiFo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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 (crates.io) 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 ) pgpsQPxoI_VM5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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. Agree. 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 ) pgpFBOb9vl43a.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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, ... Indeed. 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. pgps5Ss0y7dMe.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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 assurances. 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. pgpfoL9I88gm7.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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" ) pgpZUwFC4DHyF.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] zoom concerns
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) pgprEtA_hfOHJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
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 ) pgpesSaDiTHDG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] reduce load of tinderox' bug reprots to bugs.gentoo.org
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. pgpIDnhVOyqAA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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 ) pgpNbcY7W7SqS.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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". pgpihB4EjbGxi.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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. pgpyMLaHnyTwp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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" pgp5BCddCL9Eh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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 imagine. 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. pgp1kAuQMVnfp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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. pgp8cyeSL99l5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: noarch keyword
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. pgpBRNZUkAp83.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep
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. pgpc1y3bKH_ZG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 2/2] metadata/qa-policy.conf: Include deprecated eclasses
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 pgpdiOx7LiMUz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
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. pgppHmDJ7BLMD.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New QA Policy Guide
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 discouragement. pgp5dvxl_ePUz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New QA Policy Guide
On Sun, 19 Jan 2020 12:31:52 +0100 Michał Górny wrote: > Enjoy! Many thanks for making this happen. pgpkU6bOR1NU6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New QA Policy Guide
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. pgpRfe3TY4eJv.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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. pgpqWSZPaxxWp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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. pgp7mS3HF7Z2A.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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. pgphawvJwBwAU.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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 ) pgpG_kX027cdJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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. pgppjeYD2_M91.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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 ) pgpBgVetvsNaY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Keywordreqs and slacking arch teams
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. pgpRWoCmPMaBI.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
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 :) pgpF1V5i90ZMq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] virtualx.eclass: Append RESTRICT="!test? ( test )" by default
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. pgpOyg14m2iTZ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [EAPI 8 RFC] Install-time dependencies
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? pgp0Q3rMWHAxO.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due to slis' retirement
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". pgpHbspqNJkzy.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
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" https://bugs.gentoo.org/697914#c0 - Portage needs an extension to package.use specification to provide a level of discretion to portage to flip flags on its own https://bugs.gentoo.org/698920#c0 pgp4qmLQa8qhA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds
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
configuration.
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 https://path.to/whatever )"
Nah.
But < hl > as a general concept works.
pgpVJJDyXL5IW.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations
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.
...
ECARGO_OPTS=(
-j $(makeopts_jobs)
"${ECARGO_OPTS[@]}"
)
if [ "${ECARGO_VERBOSE:-1}" == 1 ]; then
ECARGO_OPTS+=( -vv )
fi
...
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.
pgpDgKtQkdfkU.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
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. So: 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); pgpBfsc68hFk_.pgp Description: OpenPGP digital signature
