Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On Tue, Mar 05, 2024 at 06:12:06 +, Robin H. Johnson wrote: > At the top, I noted that it will be possible in future for AI generation > to be used in a good, safe way, and we should provide some signals to > the researchers behind the AI industry on this matter. > > What should it have? > - The output has correct license & copyright attributions for portions that > are copyrightable. > - The output explicitly disclaims copyright for uncopyrightable portions > (yes, this is a higher bar than we set for humans today). > - The output is provably correct (QA checks, actually running tests etc) > - The output is free of non-functional/nonsense garbage. > - The output is free of hallucinations (aka don't invent dependencies that > don't exist). > > Can you please contribute other requirements that you feel "good" AI output > should have? > - The output is not overly clever even if correct. It should resemble something a reasonable human might write. For example, some contrived sequence of Bash parameter expansions vs using sed. - The output is succinct enough. This continues the "reasonable human" theme from above. For example, it should not first increment some value by 4, then 3, then 2, and finaly 1 when incrementing by 10 right off the bat makes more sense. - The output domain is able to be restricted in some form. Given a problem, some things are simply outside of the space of valid answers. For example, sudo rm -rf --no-preserve-root / should not be a line that can be generated in the context of ebuilds. - Simply enumerating restrictions should be considered intractable. While it may be trivial to create a list of forbidden words in the context of a basic family-friendly environment, how can you effectively guard against forbidden constructs when you might not know them all beforehand? For example, how do you define what constitutes "malicious output"? - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On Tue, Feb 27, 2024 at 15:45:17 +0100, Michał Górny wrote: > Hello, > > Given the recent spread of the "AI" bubble, I think we really need to > look into formally addressing the related concerns. In my opinion, > at this point the only reasonable course of action would be to safely > ban "AI"-backed contribution entirely. In other words, explicitly > forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to > create ebuilds, code, documentation, messages, bug reports and so on for > use in Gentoo. > > Just to be clear, I'm talking about our "original" content. We can't do > much about upstream projects using it. > I agree. But for the sake of discussion: What about cases where someone, say, doesn't have an excellent grasp of English and decides to use, for example, ChatGPT to aid in writing documentation/comments (not code) and puts a note somewhere explicitly mentioning what was AI-generated so that someone else can take a closer look? I'd personally not be the biggest fan of this if it wasn't in something like a PR or ml post where it could be reviewed before being made final. But the most impportant part IMO would be being up-front about it. > > Rationale: > > 1. Copyright concerns. At this point, the copyright situation around > generated content is still unclear. What's pretty clear is that pretty > much all LLMs are trained on huge corpora of copyrighted material, and > all fancy "AI" companies don't give shit about copyright violations. > In particular, there's a good risk that these tools would yield stuff we > can't legally use. > I really dislike the lack of audit trail for where the bits and pieces come from. Not to mention the examples from early on where Copilot was filling in incorrect attribution. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item
On Mon, Feb 26, 2024 at 22:39:13 +, Lucio Sauer wrote: > On Mon, Feb 26, 2024 at 06:13:32PM +0100, Andrew Nowa Ammerlaan wrote: > > Previously sys-kernel/installkernel was implicitly installed on many systems > > via a dependency in sys-apps/debianutils. This dependency was toggled > > by the "installkernel" USE flag, and enabled by default. > > > > sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, > > an essential package installed on many systems. However, this > > dependency was recently removed. > > In my opinion, the last sentence reads as if app-misc/ca-certificates was > recently removed. I suggest rewording the passage as follows: > > Until recently, sys-apps/debianutils was in turn pulled in by > app-misc/ca-certificates, an essential package installed on many systems. > This is no longer the case. > > > As a result many users may find that ... > Agreed. I was confused for a second reading it since it was the first I'd heard of ca-certificates being removed before I realized that was not the case at all. - Oskari signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] News item: LXD to lose access for its image server
On Mon, Dec 25, 2023 at 20:01:49 +0200, Joonas Niilola wrote: > ### Notes: Tried to keep this news item as concise as possible, > ### more information in #920527. > > > Title: LXD to lose access for its image server > Author: Joonas Niilola > Posted: 2023-12-28 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: app-containers/lxd > > Earlier this year Canonical took their LXD project from > community-hosted LinuxContainers under Canonical's own management. This first sentence is potentially a bit unclear. It could be read as meaning LinuxContainers is the one that is under Canonical. I'd write something like: Earlier this year Canonical took their LXD project away from the community-run LinuxContainers and brought it under their own management. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] use.desc: Make `native-extensions` flag global
On Sun, Nov 05, 2023 at 06:42:35 +0100, Michał Górny wrote: > Make the `native-extensions` flag global. It is used in 15 Python > packages to enable building optional C extensions, though the global > description also allows for other "native" and "pure" languages. > > In 9 cases, the flag description explicitly mentions "speedups", so this > is the primary case used in global description. There is one case > of the extension providing extra features, and the remaining cases > do not explain its role. > > Signed-off-by: Michał Górny > --- > profiles/use.desc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/profiles/use.desc b/profiles/use.desc > index d8f97958e900..01915ae78918 100644 > --- a/profiles/use.desc > +++ b/profiles/use.desc > @@ -212,6 +212,7 @@ musicbrainz - Lookup audio metadata using MusicBrainz > community service (musicbr > mysql - Add mySQL Database support > mysqli - Add support for the improved mySQL libraries > nas - Add support for network audio sound > +native-extensions - Build native (C, Rust) extensions in additional to pure > (e.g. Python) code (usually speedups) I'd say "(e.g. C, Rust)", similarly to what you did later, so that people don't think it means only C or Rust extensions get built. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file
On Mon, Sep 25, 2023 at 14:03:26 +0200, Ulrich Mueller wrote: > > On Sun, 24 Sep 2023, Jonas Stein wrote: > > >> # Removal on 2023-10-21. Bug #667687, #667689. > > > We should use "after" instead of "on": > > > # Removal after T > > I wonder if we even need to specify the wording in such detail. For any > tools parsing the file, it might be enough to say that the line must > contain, in this order: > > - "Removal" (case insensitive?) as the first word, > - exactly one date in -MM-DD format, > - optionally, the word "bug" followed by one or more bug numbers. > With the scheme above, the following would be valid (among other more nonsensical looking things): # Removal before -MM-DD. Bug #1, #2 IMO it definitely should require a word with similar meaning to "on" or "after". How exactly that gets worded in the end, IDK. Maybe it'll end up as "exactly one of 'on' or 'after'" or something like that. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Standard parsable format for profiles/package.mask file
On Thu, Sep 21, 2023 at 22:40:05 +0300, Arthur Zamarin wrote:
> = "Formal" format =
>
> Each entry is composed of 2 parts: "#"-prefixed explanation block and
> list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
> explanation block starts (meaning first "#"-prefixed line after packages
> list). You may add newlines between packages in packages list.
>
What about mandatory blank line(s) between entries? That way it ensures
they are visually separated when skimming through the file. Plus, you
can easily jump from entry to entry in editors that support
paragraph-wise movement.
- Oskari
signature.asc
Description: PGP signature
Re: [gentoo-dev] Standard parsable format for profiles/package.mask file
On Thu, Sep 21, 2023 at 23:22:27 +0200, Ulrich Mueller wrote:
> > On Thu, 21 Sep 2023, Arthur Zamarin wrote:
>
> > = "Formal" format =
>
> > Each entry is composed of 2 parts: "#"-prefixed explanation block and
> > list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
> > explanation block starts (meaning first "#"-prefixed line after packages
> > list). You may add newlines between packages in packages list.
>
> "Must" rather than "may" here? You certainly cannot list several
> packages in the same line.
>
I read it to mean something like this would be allowed:
# Blurb about package1, package2, and package3
category/package1
category/package2
category/package3
Whether it makes sense to allow that is a different question.
- Oskari
signature.asc
Description: PGP signature
Re: [gentoo-dev] last rites: sys-fs/eudev
On Wed, Sep 13, 2023 at 03:10:51 -0500, Dale wrote: > Andrew Ammerlaan wrote: > > > > And then another thing, how is it possible that so many people missed > > the news item? They are displayed quite prominently I think, and > > emerge will keep buggering you about it until it is marked as read. > > Just wondering if there is something that can be improved here. > > > > Best regards, > > Andrew > > > I'm pretty good at reading the news items. I seem to recall that you > see one only if it affects you, you have a package installed or > something. So, if it shows up, it is best to take notice. That said, I > don't recall seeing the news item either. I can't imagine me missing it > but I also can't imagine me not taking action either. After all, (eu)dev > is a important package. > > One thing is for sure, the name is rather obvious. The first word in > the title is eudev. I have yet to figure out how I missed it. Given > the number of people who did, could there have been a glitch and it > didn't show for some weird reason? Has someone who understands the code > checked to see if there was some typo that made it not show for most > users? > > I do think this is worth looking into. It just seems odd. > It's not impossible for a news item to have bugs. Somewhat recently, when the hardened toolchain changes were being made, a news item was sent out recommending an `-e @world`. I knew it was coming because I saw the drafts of the news item here (as well as discussion on irc), so I was surprised when I didn't see it on my laptop on the day of. But I did see it on my work machine. We managed to track it down to my work machine using the hardened profile whereas my laptop is using the hardened/selinux profile, and Portage didn't quite catch that as being relevant for both. - Oskari signature.asc Description: PGP signature
[gentoo-dev] [PATCH] verify-sig.eclass: replace app-crypt with sec-keys
Update the description and example to use the new sec-keys/ category
instead of the old app-crypt/ for openpgp-keys-* packages.
Signed-off-by: Oskari Pirhonen
---
GH PR: https://github.com/gentoo/gentoo/pull/32111
eclass/verify-sig.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/verify-sig.eclass b/eclass/verify-sig.eclass
index 6472e995e82..d99dc346185 100644
--- a/eclass/verify-sig.eclass
+++ b/eclass/verify-sig.eclass
@@ -16,7 +16,7 @@
# the developer's work.
#
# To use the eclass, start by packaging the upstream's key
-# as app-crypt/openpgp-keys-*. Then inherit the eclass, add detached
+# as sec-keys/openpgp-keys-*. Then inherit the eclass, add detached
# signatures to SRC_URI and set VERIFY_SIG_OPENPGP_KEY_PATH. The eclass
# provides verify-sig USE flag to toggle the verification.
#
@@ -35,7 +35,7 @@
# SRC_URI="https://example.org/${P}.tar.gz
# verify-sig? ( https://example.org/${P}.tar.gz.sig )"
# BDEPEND="
-# verify-sig? ( app-crypt/openpgp-keys-example )"
+# verify-sig? ( sec-keys/openpgp-keys-example )"
#
# VERIFY_SIG_OPENPGP_KEY_PATH=${BROOT}/usr/share/openpgp-keys/example.asc
# @CODE
--
2.41.0
Re: [gentoo-dev] Package stabilization groups
On Mon, Jul 17, 2023 at 19:39:30 +0300, Arthur Zamarin wrote:
> On 17/07/2023 16.50, Matt Turner wrote:
> > On Sun, Jul 16, 2023 at 2:04 PM Arthur Zamarin wrote:
> >> Now I'll speak from the point of implementer of `pkgdev bugs`. For me I
> >> think both approaches are good, but I would prefer the latter over the
> >> former. Nicer syntax, easy cache of all groups, easier to solve the
> >> "graph problems" in the tool.
> >
> > Sounds good to me. Should we have infra create a new git repo for us
> > for this purpose?
> >
>
> No. I think it should go under normal git repo, and not separate repo. I
> see no gains from it being under separate repository, only headache (how
> to sync between them).
>
> I think a main index files under
> "/metadata/${some_good_name}/${group_name}" would be best.
>
/metadata/stable-goups/${group_name} perhaps? Then you can adapt Ionen's
example as:
$ cat /path/to/repo/metadata/stable-groups/qt
dev-qt/package
dev-qt/package2
Easy to read, easy to write :)
- Oskari
signature.asc
Description: PGP signature
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On Wed, Jul 05, 2023 at 20:40:34 +0200, Gerion Entrup wrote: > Am Mittwoch, 5. Juli 2023, 01:09:30 CEST schrieb Oskari Pirhonen: > > On Tue, Jul 04, 2023 at 21:56:26 +, Robin H. Johnson wrote: > > > On Tue, Jul 04, 2023 at 12:44:39PM +0200, Gerion Entrup wrote: > > > > just to be curious about the whole discussion. I did not follow in the > > > > deepest detail but what I got is: > > > > - EGO_SUM blows up the Manifest file, since every little Go module needs > > > > to be respected. A lot of these Manifest files lead to a extremely > > > > increased Portage tree size. EGO_SUM is just one example (though the > > > > biggest one). Statically linked languages like Rust etc. have the same > > > > problem. > > > > - The current solution is to prepackage all modules, put it somewhere on > > > > a webserver and just manifest that file. This make the Portage tree > > > > small in size again, but requires a webserver/mirror and is thus > > > > unfriendly for overlay devs. > > > > > > > > I'm not sure if it was mentioned before but has anyone considered hash > > > > trees / Merkle trees for the manifest file? The idea would be to hash > > > > the standard manifest file a second time if it gets too big and write > > > > down that hash as new manifest file and leave EGO_SUM as is. > > > This is out-of-tree/indirect Manifests, that I proposed here, more than > > > a year ago: > > > https://marc.info/?l=gentoo-dev=168280762310716=2 > > > https://marc.info/?l=gentoo-dev=165472088822215=2 > > > > > > Developing it requires PMS work in addition to package manager > > > development, because it introduces phases. > > > > > > - primary fetch of $SRC_URI per ebuild, including indirect Manifest > > > - primary validation of distfiles > > > - secondary fetch of $SRC_URI per indirect Manifest > > > - secondary validation of additional distfiles > > > > > > A significantly impacted use case is "emerge -f", it now needs to run > > > downloads twice. > > > > > > > I'm not sure double downloading is required. Consider a flow similar to > > this: > > > > 1. distfiles are fetched as per the ebuild > > 2. distfiles are hashed into a temporary Manifest > > 3. temporary Manifest is hashed and compared with the hashes stored in > >the in-tree Manifest for the direct Manifest > > This is exactly, what I meant. A webstorage is not needed. A second > download process is also not needed. Just an additional Manifest format > is needed for ebuilds with more than n distfiles. > > > > A new Manifest format would be required in order to differentiate the > > current ones from an indirect one. This may require PMS changes, > > although I suspect ammending GLEP 74 may be enough since the PMS seems > > to just refer to the GLEP for a description of Manifests. > > > > This would also either rely on a stable ordering of Manifest contents > > when generating it or having a separate file listing in the indirect > > Manifest which corresponds to the order in the direct Manifest. For the > > latter, it should also have separate entries for different package > > versions so that every single distfile for every single version of said > > package does not need to be fetched in order to build the direct > > Manifest. > > > > I'm imagining something along these lines: > > > > INDIRECT true > > PACKAGE category/package-version distfile1 distfile2 ... ALGO1 hash1 > > ALGO2 hash2 ... > > PACKAGE ... > > Maybe it is reasonable to skip the distfile names at all (or just > provide a hash value of the concatenated file names). Then the manifest > would just contain two/three hashes (for as many distfiles as the ebuild > needs). Since these kind of indirect Manifests should be more rare than > the normal ones, a slightly longer processing time does not have much > impact I would say. > My reasoning behind having the list of files is so that the intermediat/direct Manifest can be accurately recreated. Consider the following (not-so-)hypothetical Manifest: DIST dist.tar.gz 84703 BLAKE2B ... SHA512 ... DIST dist.tar.gz.asc 228 BLAKE2B ... SHA512 ... EBUILD package-r1.ebuild 1535 BLAKE2B ... SHA512 ... EBUILD package.ebuild 1536 BLAKE2B ... SHA512 ... MISC metadata.xml 959 BLAKE2B ... SHA512 ... It is "well behaved" because pkgdev created it. My main concern is if $OTHER_TOOLING generates the Manifest in a different
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On Tue, Jul 04, 2023 at 21:56:26 +, Robin H. Johnson wrote: > On Tue, Jul 04, 2023 at 12:44:39PM +0200, Gerion Entrup wrote: > > just to be curious about the whole discussion. I did not follow in the > > deepest detail but what I got is: > > - EGO_SUM blows up the Manifest file, since every little Go module needs > > to be respected. A lot of these Manifest files lead to a extremely > > increased Portage tree size. EGO_SUM is just one example (though the > > biggest one). Statically linked languages like Rust etc. have the same > > problem. > > - The current solution is to prepackage all modules, put it somewhere on > > a webserver and just manifest that file. This make the Portage tree > > small in size again, but requires a webserver/mirror and is thus > > unfriendly for overlay devs. > > > > I'm not sure if it was mentioned before but has anyone considered hash > > trees / Merkle trees for the manifest file? The idea would be to hash > > the standard manifest file a second time if it gets too big and write > > down that hash as new manifest file and leave EGO_SUM as is. > This is out-of-tree/indirect Manifests, that I proposed here, more than > a year ago: > https://marc.info/?l=gentoo-dev=168280762310716=2 > https://marc.info/?l=gentoo-dev=165472088822215=2 > > Developing it requires PMS work in addition to package manager > development, because it introduces phases. > > - primary fetch of $SRC_URI per ebuild, including indirect Manifest > - primary validation of distfiles > - secondary fetch of $SRC_URI per indirect Manifest > - secondary validation of additional distfiles > > A significantly impacted use case is "emerge -f", it now needs to run > downloads twice. > I'm not sure double downloading is required. Consider a flow similar to this: 1. distfiles are fetched as per the ebuild 2. distfiles are hashed into a temporary Manifest 3. temporary Manifest is hashed and compared with the hashes stored in the in-tree Manifest for the direct Manifest A new Manifest format would be required in order to differentiate the current ones from an indirect one. This may require PMS changes, although I suspect ammending GLEP 74 may be enough since the PMS seems to just refer to the GLEP for a description of Manifests. This would also either rely on a stable ordering of Manifest contents when generating it or having a separate file listing in the indirect Manifest which corresponds to the order in the direct Manifest. For the latter, it should also have separate entries for different package versions so that every single distfile for every single version of said package does not need to be fetched in order to build the direct Manifest. I'm imagining something along these lines: INDIRECT true PACKAGE category/package-version distfile1 distfile2 ... ALGO1 hash1 ALGO2 hash2 ... PACKAGE ... Here `ALGO1` and `hash1` correspond to the hash of the direct Manifest containing the distfiles (and potentially other files if a repo does not have thin-manifests enabled) and their hashes in the order specified previously. The indirect Manifest as described above would be large-ish for a package that has lots of distfiles, but likely much smaller than if each distfile had its set of hashes stored directly. Please correct me if there's some detail I've overlooked. - Oskari > The rest of the posts also go into the matter of duplication within > EGO_SUM & the indirect Manifests: limiting the growth requires some form > of content-addressed layout. > > It's absolutely something we should get developed, but it's a lot of > work. > > The indirect Manifests still provide a hosting challenge for overlays. > > -- > Robin Hugh Johnson > Gentoo Linux: Dev, Infra Lead, Foundation Treasurer > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: include exit status in death message
On Sun, Jun 25, 2023 at 20:52:53 +0200, Michał Górny wrote: > I think a better approach would be to always include $? in die messages > in Portage. > I'm not sure the exit code is useful in the general case. Something like rm(1) seems to give the same exit code despite failing for different reasons: $ rm /tmp/root_owned rm: remove write-protected regular empty file '/tmp/root_owned'? y rm: cannot remove '/tmp/root_owned': Operation not permitted $ echo $? 1 $ rm /tmp/nonexistent rm: cannot remove '/tmp/nonexistent': No such file or directory $ echo $? 1 On the other hand, groupadd(8) (at least) seems to have useful exit codes. From the man page: EXIT VALUES The groupadd command exits with the following values: 0 success 2 invalid command syntax 3 invalid argument to option 4 GID is already used (when called without -o) 9 group name is already used 10 can't update group file - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EGO_SUM
On Tue, May 30, 2023 at 21:30:49 +0500, Anna (cybertailor) Vyalkova wrote: > On 2023-05-30 17:52, Florian Schmaus wrote: > > To prevent harm from Gentoo, we should reach an agreement that everyone > > can live with. To achieve a consensus, and since I can not rule out that > > I missed a post that includes specific numbers, please share your ideas > > on how EGO_SUM could be reinstated in ::gentoo by replying to this mail. > > Instate a policy to allow EGO_SUM in the gentoo tree: > > 1) from proxied maintainers I agree that allowing EGO_SUM in ::gentoo at least for proxy maintained packages would be a good idea. I don't have any Go packages, but I can see how it could be cumbersome to get a tarball hosted somewhere. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 9 feature proposal
On Wed, May 17, 2023 at 08:19:48 +0200, Michał Górny wrote: > On Wed, 2023-05-17 at 00:03 -0500, Oskari Pirhonen wrote: > > We agreed that it could potentially be useful as something that's > > available for general use > > We generally don't add something into EAPI unless it's either: > > 1) used widely, or > > 2) hard to implement outside the PM. > > I don't think this qualifies as either. I don't immediately see any use > case for it myself. > That's fine. Which is why I wanted to ask here first before opening an EAPI bug only for it to be closed right away as NOTINTERESTED or whatever. - Oskari signature.asc Description: PGP signature
[gentoo-dev] EAPI 9 feature proposal
Hi,
Matt recently made a PR to a QA check script in Portage [1] which
included the following function:
is_in() {
local needle=$1
shift
local x
for x in "$@"; do
[[ "${needle}" = ${x} ]] && return 0
done
return 1
}
It's more or less `has` but with Bash pattern matching support. The
difference is in how it handles the conditional. For reference, here is
the implementation of `has` in Portage:
has() {
local needle=$1
shift
local x
for x in "$@"; do
[[ "${x}" = "${needle}" ]] && return 0
done
return 1
}
We agreed that it could potentially be useful as something that's
available for general use, so I'd like to propose the idea of adding the
ability to query a list for something like "foo*" or "foob??". Here's
two possibilities for how I would go about implementing it:
1. Add Matt's function. Perhaps as `hasp` (for "has pattern") or
something.
2. Change `has` to support pattern matching in EAPI 9+
Thoughts?
- Oskari
[1]: https://github.com/gentoo/portage/pull/1034
signature.asc
Description: PGP signature
Re: [gentoo-dev] Packages up for grabs: sys-apps/bat, app-misc/physlock, dev-lang/crystal, dev-util/shards
On Sat, Feb 11, 2023 at 20:25:46 +, Conrad Kostecki wrote: > Am 11.02.2023 19:58:27, "Jonas Stein" schrieb: > > >https://packages.gentoo.org/packages/app-misc/physlock > > > > I suspect, that this could be last-rited, as upstream marked repo as > read-only on Github. > I actively use this, so I can proxy maint it. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/1] linux-info.eclass: Add /proc/config.gz as a valid src of CONFIG_* settings
On Sun, Jan 15, 2023 at 12:40:12 -0500, Mike Pagano wrote: > In the event that the linux src tree does not have > a valid .config, check for /proc/config.gz > What about checking /boot/config-[version] as a backup as well? Since the standard `make install` for the kernel drops the config used to build into there too. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Packages of zlogene up for grabs
On Fri, Jan 13, 2023 at 14:35:45 +0100, Michał Górny wrote: > Friends, > > Our dear friend zlogene has been inactive recently, and for this reason > the packages listed below are looking for new maintainers. Please take > a look and see if you're interested in a few of them. > > ... > app-text/wgetpaste > ... I've tinkered with wgetpaste a bit, so I'd be willing to proxy-maint it. - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Mon, Nov 07, 2022 at 08:26:15 +0200, Joonas Niilola wrote: > I _believe_ ago's tinderbox isn't being paid by the GF _anymore_ due to > this reason, but he keeps it running with his own expenses. I don't mind > this as long as the results are desirable and not phony. I still see a > lot of value in most of ago's work. > Don't get me wrong, I really appreaciate the work that all of you do to keep my favorite distro running. And maintaining the level of quality that I've grown to expect from Gentoo over the years too :) > It is unfortunate we don't get to see the engine behind and copy it, > since I'd be really interested in using his automated bug search / > report tool. Even tattoo (https://github.com/arthurzam/tattoo) lacks > that at the moment. > Perhaps he would be open to the idea of releasing some parts of it? (pun intended) - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
On Sun, Nov 06, 2022 at 11:37:24 +0100, Piotr Karbowski wrote: > I would be in favour of stepping up the social contract and actually > prohibiting this kind of things, we had that before too, the nattka you > mgorny wrote is replacement for old bugzilla bot that was ... > closedsource and perished, though nattka now have way more features than > the old thing ever had. As a user, I think it would be really cool if there was a requirement that all infra and infra-adjacent stuff was free software. I feel like I've read that Debian already has something like this. While doing some quick searches I didn't find a full-on requirement, but all their infra bits I did find were powered by free software. The most relevant ones being buildd [1] and debci [2]. Additionally, the debci docs has inctructions on reproducing tests yourself [3] which is a nice extra IMO. [1] https://buildd.debian.org [2] https://ci.debian.net [3] https://ci.debian.net/doc/file.MAINTAINERS.html - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] dist-kernel-utils.eclass: Add a PV → KV conversion function
On Sun, Oct 16, 2022 at 06:49:17 +0200, Michał Górny wrote:
> Signed-off-by: Michał Górny
> ---
> eclass/dist-kernel-utils.eclass | 16
> eclass/tests/dist-kernel-utils.sh | 28
> 2 files changed, 44 insertions(+)
> create mode 100755 eclass/tests/dist-kernel-utils.sh
>
> diff --git a/eclass/dist-kernel-utils.eclass b/eclass/dist-kernel-utils.eclass
> index 8c1b56f41506..439bdc87695d 100644
> --- a/eclass/dist-kernel-utils.eclass
> +++ b/eclass/dist-kernel-utils.eclass
> @@ -155,5 +155,21 @@ dist-kernel_reinstall_initramfs() {
> "${kernel_dir}/System.map"
> }
>
> +# @FUNCTION: dist-kernel_PV_to_KV
> +# @USAGE:
> +# @DESCRIPTION:
> +# Convert a Gentoo-style ebuild version to kernel "x.y.z[-rcN]" version.
> +dist-kernel_PV_to_KV() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + [[ ${#} -ne 1 ]] && die "${FUNCNAME}: invalid arguments"
> + local pv=${1}
> +
> + local kv=${pv%%_*}
> + [[ -z $(ver_cut 3- "${kv}") ]] && kv+=".0"
> + [[ ${pv} == *_* ]] && kv+=-${pv#*_}
> + echo "${kv}"
> +}
> +
> _DIST_KERNEL_UTILS=1
> fi
> diff --git a/eclass/tests/dist-kernel-utils.sh
> b/eclass/tests/dist-kernel-utils.sh
> new file mode 100755
> index ..82be706dc498
> --- /dev/null
> +++ b/eclass/tests/dist-kernel-utils.sh
> @@ -0,0 +1,28 @@
> +#!/usr/bin/env bash
> +# Copyright 2022 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=8
> +
> +source tests-common.sh || exit
> +
> +inherit dist-kernel-utils
> +# TODO: hack because tests-common don't implement ver_cut
> +EAPI=6 inherit eapi7-ver
> +
> +test_KV_to_PV() {
> + local kv=${1}
> + local exp_PV=${2}
> +
> + tbegin "dist-kernel_PV_to_KV ${kv} -> ${exp_PV}"
> + local val=$(dist-kernel_PV_to_KV "${kv}")
> + [[ ${val} == ${exp_PV} ]]
> + tend $?
> +}
Your test function is called `test_KV_to_PV` but the function you're
testing is `dist-kernel_PV_to_KV`. Is this correct, or am I just looking
at it wrong? The rest of the comments are under the assumption that the
`KV`/`kv` and `PV` are meant to be flipped in the test function.
> +
> +test_KV_to_PV 6.0_rc1 6.0.0-rc1
Shouldn't this become just 6.0-rc1? That's the name of the branch in
torvalds/linux.git (as well as what's in the name of the tarball and
what was reported on https://kernel.org ).
> +test_KV_to_PV 6.0 6.0.0
Similar to above.
> +test_KV_to_PV 6.0.1_rc1 6.0.1-rc1
Is there any point in converting x.y.z_rcN? To my knowledge, such a
version will never exist.
> +test_KV_to_PV 6.0.1 6.0.1
> +
> +texit
> --
> 2.38.0
>
>
- Oskari
signature.asc
Description: PGP signature
Re: [gentoo-dev] Global USE flags for sound notifications (libcanberra) and global hotkeys (keybinder)
On Fri, Sep 16, 2022 at 07:49:49 +0200, Michał Górny wrote: > Hi, > > I think we've passed the threshold for making two USE flags global: > > - sound notification support (usually via libcanberra) > > - global hotkey support (usually via keybinder) > > I don't have a strong opinion on flag names. > > > For sound notification, I've found that: > > - 7 packages use "libcanberra" as the name > > - 1 package uses "sound-notification" (and implements it using > libcanberra) > USE=sound-notification is nice and descriptive, but it feels a bit awkward being so long. Looking at some of the descriptions for the "libcanberra" flag on p.g.o, the most popular one seems to be: Enable sound event support using media-libs/libcanberra Perhaps USE=sound-events? It's a bit shorter but just as descriptive. > > For global hotkey support, I've found that: > > - 4 packages use "keybinder" > > - 1 package uses "hotkeys" but it doesn't use keybinder and I'm not 100% > sure it's the same feature > Maybe something like USE=keybind? These names are also nice and implementation-agnostic :) - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Mon, Jun 27, 2022 at 01:43:19 +0200, Zoltan Puskas wrote: > Hi, > > I've been working on adding a go based ebuild to Gentoo yesterday and I > got this warning form portage saying that EGO_SUM is deprecated and > should be avoided. Since I remember there was an intense discussion > about this on the ML I went back and have re-read the threads before > writing this piece. I'd like to provide my perspective as user, a > proxied maintainer, and overlay owner. I also run a private mirror on my > LAN to serve my hosts in order to reduce load on external mirrors. > > Before diving in I think it's worth reading mgorny's blog post "The > modern packager’s security nightmare"[1] as it's relevant to the > discussion, and something I deeply agree with. > > With all that being said, I feel that the tarball idea is a bad due to > many reasons. > > From security point of view, I understand that we still have to trust > maintainers not to do funky stuff, but I think this issue goes beyond > that. > > First of all one of the advantages of Gentoo is that it gets it's source > code from upstream (yes, I'm aware of mirrors acting as a cache layer), > which means that poisoning source code needs to be done at upstream > level (effectively means hacking GitHub, PyPi, or some standalone > project's Gitea/cgit/gitlab/etc. instance or similar), sources which > either have more scrutiny or have a limited blast radius. > > Additionally if an upstream dependency has a security issue it's easier > to scan all EGO_SUM content and find packages that potentially depend on > a broken dependency and force a re-pinning and rebuild. The tarball > magic hides this completely and makes searching very expensive. > > In fact using these vendor tarballs is the equivalent of "static > linking" in the packaging space. Why are we introducing the same issue > in the repository space? This kills the reusability of already > downloaded dependencies and bloats storage requirements. This is > especially bad on laptops, where SSD free space might be limited, in > case the user does not nuke their distfiles after each upgrade. > > Considering that BTRFS (and possibly other filesystems) support on the > fly compression the physical cost of a few inflated ebuilds and > Manifests is actually way smaller than the logical size would indicate. > Compare that to the huge incompressible tarballs that now we need to > store. > > As a proxied maintainer or overlay owner hosting these huge tarballs > also becomes problem (i.e. we need some public space with potentially > gigabytes of free space and enough bandwidth to push that to users). > Pushing toward vendor tarballs creates an extra expense on every level > (Gentoo infra, mirrors, proxy maintainers, overlay owners, users). > > If bloating portage is a big issue and we frown upon go stuff anyway (or > only a few users need these packages), why not consider moving all go > packages into an officially supported go packages only overlay? I > understand that this would not solve the kernel buffer issue where we > run out of environment variable space, but it would debloat the main > portage tree. > Rephrasing this just to ensure I'm understanding it correctly: you're suggesting to move _everything_ that uses Go into its own overlay. Let's call it gentoo-go for the sake of the example. If the above is accurate, then I hard disagree. The biggest package that I have that uses Go is docker (and accompanying tools). Personal distaste of docker aside, it's a very popular piece of software, and I don't think it's fair to require all the people who want to use it to first enable and sync gentoo-go before they can install it. And what about transitive dependencies? Suppose app-misc/cool-package is written in some language that isn't Go, but it has a dependency on sys-apps/cool-util which has a dependency on something written in Go. Should a user wanting to install cool-package have to enable the gentoo-go overlay now too? Even though app-misc/cool-package would look like it doesn't need the overlay unless you dig into the deps. Not a dev, just a user who really likes Gentoo :) - Oskari > It also breaks reproducibility. With EGO_SUM I can check out an older > version of portage tree (well to some extent) and rebuild packages since > dependency upstream is very likely to host old versions of their source. > With the tarballs this breaks since as soon as an ebuild is dropped from > mainline portage the vendor tarballs follow them too. There is no way > for the user to roll back a package a few weeks back (e.g. if new > version has bugs), unlike with EGO_SUM. > > In fact I feel this goes against the spirit of portage too, since now > instead of "just describing" how to obtain sources and build them, now > it now depends on essentially ephemeral blobs, which happens to be > externalized from the portage tree itself. I'm aware that we have > ebuilds that pull in
Re: [gentoo-dev] [PATCH v3 1/2] esed.eclass: new eclass
On Sun, Jun 05, 2022 at 14:42:55 -0500, Oskari Pirhonen wrote:
> On Sat, Jun 04, 2022 at 16:46:33 -0400, Ionen Wolkens wrote:
> > +# Where possible, it is also good to consider if using patches is more
> > +# suitable to ensure adequate changes. These functions are also unsafe
> > +# for binary files containing null bytes (erepl() will remove them).
>
> Some way to test for NULL in the file before reading might be useful.
> Possibly die if found? Although right now I can't think of a super
> elegant and/or efficient way to do so without writing a simple external
> helper.
>
I came up with _an_ idea. It feels kinda hacky, goes against my previous
statement wrt running sed on binary files, but it seems to work based on
some quick tests:
[ /tmp ]
oskari@dj3ntoo λ null_free() {
> [[ $(sed -ne '/\x00/{p;q}' "$1" | wc -c) -eq 0 ]]
> }
[ /tmp ]
oskari@dj3ntoo λ for f in test*.dat; do
> echo "${f}:"
> hd $f
> null_free $f || echo "has null"
> done
test1.dat:
61 62 0a 63 64 00 65 66 |ab.cd.ef|
0008
has null
test2.dat:
67 68 0a 69 6a 0a 6b 6c |gh.ij.kl|
0008
test3.dat:
00 0a 31 32 0a 33 34 |..12.34|
0007
has null
test4.dat:
61 61 00 61 61 0a 62 62 00 62 62 0a 63 63 00 63
|aa.aa.bb.bb.cc.c|
0010 63|c|
0011
has null
- Oskari
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH v3 1/2] esed.eclass: new eclass
On Sat, Jun 04, 2022 at 16:46:33 -0400, Ionen Wolkens wrote:
> Signed-off-by: Ionen Wolkens
> ---
> eclass/esed.eclass | 265 +
> 1 file changed, 265 insertions(+)
> create mode 100644 eclass/esed.eclass
>
> diff --git a/eclass/esed.eclass b/eclass/esed.eclass
> new file mode 100644
> index 000..414daceaf8b
> --- /dev/null
> +++ b/eclass/esed.eclass
> @@ -0,0 +1,265 @@
> +# Copyright 2022 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: esed.eclass
> +# @MAINTAINER:
> +# Ionen Wolkens
> +# @AUTHOR:
> +# Ionen Wolkens
> +# @SUPPORTED_EAPIS: 8
> +# @BLURB: sed(1) and alike wrappers that die if did not modify any files
> +# @EXAMPLE:
> +#
> +# @CODE
> +# # sed(1) wrappers, die if no changes
> +# esed s/a/b/ file.c # -i is default
> +# enewsed s/a/b/ project.pc.in "${T}"/project.pc
> +#
> +# # bash-only simple fixed string alternatives, also die if no changes
> +# erepl string replace file.c
> +# ereplp ^match string replace file.c # like /^match/s:string:replace:g
> +# erepld ^match file.c # deletes matching lines, like /^match/d
> +# use prefix && enewreplp ^prefix= /usr "${EPREFIX}"/usr pn.pc.in pn.pc
> +#
> +# # find(1) wrapper that sees shell functions, dies if no files found
> +# efind . -name '*.c' -erun esed s/a/b/ # dies if no files changed
> +# efind . -name '*.c' -erun sed s/a/b/ # only dies if no files found
> +# @CODE
> +#
> +# Migration notes: be wary of non-deterministic cases involving variables,
> +# e.g. s|lib|$(get_libdir)|, s|-O3|${CFLAGS}|, or s|/usr|${EPREFIX}/usr|.
> +# erepl/esed() die if these do nothing, like libdir being 'lib' on x86.
> +# Either verify, keep sed(1), or ensure a change (extra space, @libdir@).
> +#
> +# Where possible, it is also good to consider if using patches is more
> +# suitable to ensure adequate changes. These functions are also unsafe
> +# for binary files containing null bytes (erepl() will remove them).
Some way to test for NULL in the file before reading might be useful.
Possibly die if found? Although right now I can't think of a super
elegant and/or efficient way to do so without writing a simple external
helper.
> +
> +case ${EAPI} in
> + 8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ ! ${_ESED_ECLASS} ]]; then
> +_ESED_ECLASS=1
> +
> +# @ECLASS_VARIABLE: ESED_VERBOSE
> +# @DEFAULT_UNSET
> +# @USER_VARIABLE
> +# @DESCRIPTION:
> +# If set to a non-empty value, erepl/esed() and wrappers will use diff(1)
> +# to display file differences. Recommended for maintainers to easily
> +# confirm the changes being made.
> +
> +# @FUNCTION: esed
> +# @USAGE: [-E|-r|-n] [-e ]... [--] ...
> +# @DESCRIPTION:
> +# sed(1) wrapper that dies if any of the expressions did not modify any
> files.
> +# sed's -i/--in-place is forced, -e can be omitted if only one expression,
> and
> +# arguments must be passed in the listed order with files last. Each -e will
> +# be a separate sed(1) call to evaluate changes of each.
> +esed() {
> + (( ${#} >= 2 )) || die "too few arguments for
> ${_esed_cmd[0]:-${FUNCNAME[0]}}"
> +
> + local endopts=false args=() contents=() exps=() files=()
> + local -i i
> + for ((i=1; i<=${#}; i++)); do
> + if [[ ${!i} =~ ^- ]] && ! ${endopts}; then
> + case ${!i} in
> + --) endopts=true ;;
> + -E|-n|-r) args+=( ${!i} ) ;;
> + -e)
> + i+=1
> + [[ ${!i} ]] || die "missing argument to
> -e"
> + exps+=( "${!i}" )
> + ;;
> + *) die "unrecognized option for ${FUNCNAME[0]}"
> ;;
> + esac
> + elif (( ! ${#exps[@]} )); then
> + exps+=( "${!i}" ) # like sed, if no -e, first
> non-option is exp
> + else
> + [[ -f ${!i} ]] || die "not a file: ${!i}"
Somewhere here might be a good place for the hypothetical:
null_free ${!i} || die "file ${!i} contains NULL bytes"
> + files+=( "${!i}" )
> + contents+=( "$(<"${!i}")" ) || die "failed reading:
> ${!i}"
> + fi
> + done
> + (( ${#files[@]} )) || die "no files in ${FUNCNAME[0]} arguments"
> +
> + if [[ ${_esed_output} ]]; then
> + (( ${#files[@]} == 1 )) || die "${_esed_cmd[0]} needs exactly
> one input file"
> +
> + # swap file for output to simplify sequential sed'ing
> + cp -- "${files[0]}" "${_esed_output}" || die
> + files[0]=${_esed_output}
> + fi
> +
> + local changed exp newcontents sed
> + for exp in "${exps[@]}"; do
> + sed=( sed -i "${args[@]}" -e "${exp}" -- "${files[@]}" )
> + [[ ${ESED_VERBOSE} ]] &&
Re: [gentoo-dev] [PATCH v2 1/1] esed.eclass: new eclass
On Fri, Jun 03, 2022 at 07:36:46AM -0400, Ionen Wolkens wrote:
> ... snip ...
>
> + # Roughly attempt to find files in arguments by checking if it's a
> + # readable file (aka s/// is not a file) and does not start with -
> + # (unless after --), then store contents for comparing after sed.
> + local contents=() endopts files=()
> + for ((i=1; i<=${#}; i++)); do
> + if [[ ${!i} == -- && ! -v endopts ]]; then
> + endopts=1
> + elif [[ ${!i} =~ ^(-i|--in-place)$ && ! -v endopts ]]; then
> + # detect rushed sed -i -> esed -i, -i also silently
> breaks enewsed
> + die "passing ${!i} to ${FUNCNAME[0]} is invalid"
> + elif [[ ${!i} =~ ^(-f|--file)$ && ! -v endopts ]]; then
> + i+=1 # ignore script files
> + elif [[ ( ${!i} != -* || -v endopts ) && -f ${!i} && -r ${!i}
> ]]; then
> + files+=( "${!i}" )
> +
> + # 2>/dev/null to silence null byte warnings if sed
> binary files
> + { contents+=( "$(<"${!i}")" ); } 2>/dev/null \
> + || die "failed to read: ${!i}"
> + fi
> + done
> + (( ${#files[@]} )) || die "no readable files found from '${*}'
> arguments"
> +
> + local verbose
> + [[ ${ESED_VERBOSE} ]] && type diff &>/dev/null && verbose=1
> +
> + local changed newcontents
> + if [[ -v _esed_output ]]; then
> + [[ -v verbose ]] &&
> + einfo "${FUNCNAME[0]}: sed ${*} > ${_esed_output} ..."
> +
> + sed "${@}" > "${_esed_output}" \
> + || die "failed to run: sed ${*} > ${_esed_output}"
> +
> + { newcontents=$(<"${_esed_output}"); } 2>/dev/null \
> + || die "failed to read: ${_esed_output}"
> +
> + local IFS=$'\n' # sed concats with newline even if none at EOF
> + contents=${contents[*]}
> + unset IFS
> +
> + if [[ ${contents} != "${newcontents}" ]]; then
> + changed=1
> +
> + [[ -v verbose ]] &&
> + diff -u --color --label="${files[*]}"
> --label="${_esed_output}" \
> + <(echo "${contents}") <(echo
> "${newcontents}")
> + fi
>
> ... snip ...
I'm not 100% convinced that it will give you anything meaningful. The
warning about ignoring NULL is not so much noise as it is bash warning
you that you're probably not doing something correctly. In this case,
you're not pulling _all_ the contents of the file:
[ /tmp ]
oskari@dj3ntoo λ printf "ab\0cd" >test.dat
[ /tmp ]
oskari@dj3ntoo λ hd test.dat
61 62 00 63 64|ab.cd|
0005
[ /tmp ]
oskari@dj3ntoo λ var=$(< test.dat)
bash: warning: command substitution: ignored null byte in input
[ /tmp ]
oskari@dj3ntoo λ printf "$var" | hd
61 62 63 64 |abcd|
0004
If it's a binary file, there's a decent chance the NULL's are
significant. Now, consider the following hypothetical example where we
want to remove the NULL's:
[ /tmp ]
oskari@dj3ntoo λ printf "ab\0cd" | sed -e 's/\x00//' | hd
61 62 63 64 |abcd|
0004
Testing for (in)equality between pre- and post-sed contents is
reasonable enough in most cases. This time, though, it would fail to
detect anything has changed since the pre-sed contents have their NULL's
unintentionally stripped, whereas the post-sed contents have them
intentionally stripped.
While I personally don't think that running sed on binary files is a
good idea in the first place, it's still relevant since the end result
would be an incorrect answer to the question of "Did sed actually do
anything?".
On the other hand, saving a set of pre- and post-sed hashes like Ulrich
suggested would give the expected result.
- Oskari
signature.asc
Description: PGP signature
[gentoo-dev] No stable firejail
Hi, After updating my system and running `eclean-dist --deep`, I noticed the following output: The following unavailable installed packages were found sys-apps/firejail-0.9.64.4 Was removing the stable version of sys-apps/firejail intentional? The ebuild commit message says "Upstream released security bump", so it sounds plausible. I'm OK with manually keywording `=sys-apps/firejail-0.9.68`, but I generally prefer stable packages where I can. Also, I find it interesting that a package that previously had a stable version no longer does. I've used Gentoo since ~2016, and off the top of my head, I can't think of another instance of something like this occurring (with the set of packages I have installed). - Oskari signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI=5 must go -- final sprint! :)
On Sun, Oct 17, 2021 at 08:57:26PM +0200, Andreas K. Huettel wrote: > So, let's make that number go down further fast! :D Cheers! What is the best way to help with that? Should I just grep for "EAPI=5" in /var/db/repos/gentoo and submit a pr with an updated ebuild? Is the new target EAPI 8? - Oskari
Re: [gentoo-dev] app-misc/physlock: Upstream repo archived
On Sat, Oct 16, 2021 at 11:34:09AM +0300, Joonas Niilola wrote: > If you'd like we'd prefer a GitHub pull request where you modify the > ebuild adding this patch, and revbump the ebuild to -r2. Sure, I can do that. It should be relativiely straightforward since I already have the patch ready. Expect a pr either later tonight or tomorrow. > We should only switch upstreams if there's some clear development done > in a fork - are you aware of any other forks existing, with active > development happening? That makes sense, and in general, I agree with that. There are quite a few forks listed at https://github.com/muennich/physlock/network/members but most of them are either far behind upstream with no changes or are behind + a few commits of their own. Some of the commits were nothing more than code style changes, and some of them were from pull requests that were closed with some of them being closed without being accepted. There was one fork [1] which looked like it had some activity earlier this year, but looking at the pull requests on the upstream repo [2] it looks like the work was actually done towards the end of 2019 and it was just a rebase and force push that was done this year. [1] https://github.com/dexterlb/physlock [2] https://github.com/muennich/physlock/pull/79 So, from what I can tell, it doesn't really seem like there's a lot of development going on anywhere. - Oskari
[gentoo-dev] app-misc/physlock: Upstream repo archived
Hi, I sent a pull request to upstream earlier this year to fix a PAM related issue (see also: Gentoo bug #774729), but the repo has since been archived [1]. Looking at the commit history, I see that there's only been a single upstream commit since the beginning of 2020. What is the proper procedure, if there is one, to reclaim a package with a dead upstream? I use physlock on all my machines and have recommended it to my friends as a solid screen locker and would very much like to help keep it alive. I would be willing to maintain a fork [2] as well as help maintain the Gentoo package itself. I've already got a little bit of experience in working with Portage by creating packages into my overlay [3]. [1]: https://github.com/muennich/physlock [2]: https://github.com/xxc3nsoredxx/physlock [3]: https://github.com/xxc3nsoredxx/unc3nsored I've CC'ed the current proxy maintainer for app-misc/physlock as well as the main upstream developer in case they have any input. - Oskari
