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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uhds9ACdRHG9hjhhDYAqLPI1WaYlQe6ME
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 15.10.2021 9.33, Oskari Pirhonen wrote:

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

Hey,

so far it seems there's just a single commits difference. I think for
now we can just apply the patch you provided into our current ebuild file, https://gitweb.gentoo.org/repo/gentoo.git/tree/app-misc/physlock/physlock-13-r1.ebuild

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. 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? Since I saw the original upstream had some issues open before
the project was archived. You should collaborate all efforts into one fork.

Let me know if you need help with these tasks, or pop by in
#gentoo-dev-help @ libera.chat IRC network.

-- juippis


--uhds9ACdRHG9hjhhDYAqLPI1WaYlQe6ME--

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAmFqjoFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjIACgkQc4OUK43A aWLnuAgAj0DzonhfPcIDFJQqCRXhdopbSSxfAmr9Ebo+i7i4DwA4k6WjqjIUmy/5 /nl6QwC6LO4lrW8Qf2cK6JtlqtDD6H8ithl6FaKkRM+33jDy+3Y7Qo5VlHnAyRUo FTi6jENyee8LDwyk4axxPWAiLuU+OmXxvwHuvyNjSdiZm6eh5CQHErc3Vo5SK0b2 pKuAXRFWkxu/PEB79vxtVW9U9IQAqNdOV7fVZpZAYdUlqEgYDxCDpnTnO04x9EW/ VQ/BvBoDFKfe6aoNxKADqqPd+YyCEufCbfXkL/ExcaM/RurmS9Hn813aereK6G42 T5yF8el+lsQ3tei1hCCPMBylrtziqQ==
=yZnZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)