[gentoo-dev] Last rites: app-text/htmlc
# Sam James (2021-10-16) # Fails to compile with modern OCaml # bug #704464, bug #780090 # Removal on 2021-11-16. app-text/htmlc signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: dev-cpp/rttr
# Sam James (2021-10-17) # Fails to build with glibc 2.34 and no reverse dependencies. # bug #806508 # Removal on 2021-11-17. dev-cpp/rttr signature.asc Description: Message signed with OpenPGP
[gentoo-dev] last rites: virtual/perl-Pod-Parser
# Andreas K. Hüttel (2021-10-16) # Outdated virtual; the respective module was removed # from core Perl with Perl 5.32. Use dev-perl/Pod-Parser # instead. Removal in 30days. virtual/perl-Pod-Parser -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: net-im/webex
# Andreas K. Hüttel (2021-10-16) # Binary-only package, cannot be distributed, download # is an unversioned URL which changes content. In brief, # a pain. Unmaintained from now on. If you pick it up, # you'll have to watch it closely. Removal in 30 days # otherwise. Bug 794700. net-im/webex -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
On Thu, Oct 14, 2021 at 03:40:02PM +0200, Marek Szuba wrote: > Dear everyone, > > Following some private discussions, I feel quite strongly now that it > would both considerably improve certain processes and make our use of > limited manpower more efficient were we to further reduce the number of > stable arches in Gentoo Linux. Specifically, I propose to drop > - hppa, > - ppc, > - sparc, > - x86 > to ~arch-only status. > > Note that this does NOT mean we intend to drop support for those arches > altogether. > > There are IMHO several good reasons for this: > - most of the arches from this list are quite dated and either aren't > really developed upstream any more or got superseded by newer ones (for > the record, it's been 18 years since the first amd64 CPUs came out) > - we have got very few people actually supporting these arches, and in > case of hppa there is also the hardware bottleneck. Subsequently, > stabilisation requests often take a long time to resolve > - feedback we receive, e.g. by Bugzilla, suggests that Gentoo on at > least some of these arches have got very, very few users > - last but by no means least, my personal experience from the last > several years suggests that running ~arch is reasonably trouble-free > these days > > WDYT? For the record, I'm fine with this. x86 being on the list sort of caught my attention, but it does seem to fall into the superceeded category, so it should be fine. Even though running ~arch may be mostly trouble-free, this isn't really relevant to the discussion imo. If you run ~arch, you should be prepared for possible breakage at any time and be able to recover from it. William signature.asc Description: PGP signature
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] Last rites: x11-themes/gtk-engines-flat
# David Seifert (2021-10-16) # EAPI 5, open bugs, practically maintainer-needed, # abandoned upstream, no other distro carries this. # Bug #632237, bug #656818, removal in 30 days. x11-themes/gtk-engines-flat signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-dotnet/dbus-sharp{,-glib}
# David Seifert (2021-10-16) # EAPI 5, fails to compile, QA issues, .NET team is # abandoned, bug #643452, bug #688404. # Removal in 30 days. dev-dotnet/dbus-sharp dev-dotnet/dbus-sharp-glib signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-java/netty-tcnative
# David Seifert (2021-10-16) # EAPI 5, fails to compile with OpenSSL 1.1, bug #674242. # Removal in 30 days. dev-java/netty-tcnative signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: mail-filter/spamdyke
# David Seifert (2021-10-16) # EAPI 5, fails to compile with OpenSSL 1.1, bug #719974. # Removal in 30 days. mail-filter/spamdyke signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] app-misc/physlock: Upstream repo archived
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 OpenPGP_signature Description: OpenPGP digital signature
