Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item v2
On 2024-02-27, andrewammerlaan wrote: > 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.[2]. As a result many users may find > that sys-apps/debianutils and therefore sys-kernel/installkernel are no > longer part of the dependency graph and will therefore be cleaned up by > "emerge --depclean". Sorry for speaking up late: I (mis)read the second sentence differently from others in this thread, apparently. "This is no longer the case." might apply to the first part of the previous sentence, "was in turn pulled in by". Or it might apply to the second part, "an essential package installed on many systems." I think what's meant is the former, it is no longer pulled in. But someone reading this cold could be forgiven for reading that as "ca-certificates is no longer an essential package". Unfortunately my recommendation would be to restore the mention of a dependency, in some form or fashion, which seems to be something that was removed due to earlier feedback in this thread. Maybe: Until recently, sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. That package no longer depends on sys-apps/debianutils. As a result many users may find that sys-apps/debianutils and therefore sys-kernel/installkernel are no longer part of the dependency graph and will therefore be cleaned up by "emerge --depclean". Thanks, Hank signature.asc Description: Digital signature
Re: [gentoo-dev] More packages up for grabs due to developer inactivity
On 2024-02-14, mgorny wrote: > The following packages are also left with no maintainer: ... > net-misc/proxychains I can p-m this. Thanks, -- Hank Leininger 8428 ED14 5268 C727 0C48 F454 846F 0637 5FEB 1612 signature.asc Description: Digital signature
Re: [gentoo-dev] More packages up for grabs due to developer inactivity
On 2024-02-14, mgorny said: > The following packages are also left with no maintainer: ... > app-misc/binwalk I use this, I can p-m it. However, upstream seems partly, if not mostly dead (last PR merged was a year ago, only 3 merged in the last ~2.5 years, 50+ outstanding PRs, 100+ outstanding issues). There's some more active forks, but none that has yet unambiguously taken over the project. I'd welcome guidance on when to decide to switch forks in SRC_URI vs carrying around cherry-picked patches in files/. If there's a GLEP covering this scenario I couldn't find it; offlist would be fine unless my inability to Google is a useful learning moment for others. Thanks, -- Hank Leininger 8428 ED14 5268 C727 0C48 F454 846F 0637 5FEB 1612 signature.asc Description: Digital signature
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open
On Thu, Jul 6, 2023 Zoltan Puskas wrote: > I've been following the EGO_SUM thread for quite some time now. One > other thing I did not see mentioned in favour of EGO_SUM so far: > reproducibility. > The problem with external tarballs is that they are gone once the > ebuild is dropped from the tree. Should a user ever want to roll back > to a previous version of an application, either by checking out on > older version of the portage tree or copying said ebuild into their > local overlay, they still cannot simply run an emerge on the it as > they have to somehow recreate the tarball itself too. > While upstream may not host everything forever, it's pretty much > guaranteed to be available for much longer than Gentoo's custom > tarball bundles of dependencies. I see this brought up every once in a while in these EGO_SUM threads, but I think reproducable tarballs are a solved problem, or at least, the tools exist and we just need to decide how to best equip people with them. thesamesam/sam-gentoo-scripts has maint/bump-go which builds these tarballs smartly and reproducably: - use --sort=name to order files inside in a consistent way - use consistent owner:group (portage:portage) - use consistent LC and TZ settings - set a standard timestamp (since 'go mod download' doesn't preserve upstream timestamps anyway, this loses no useful information) With that, multiple developers can independently generate a -deps tarball for a given Go package version with checksums that match. The main distro tarball's checksums are verified against Manifest, and then within it are the list and checksums of the individual downloads which would be verified by go mod download (right?) and the resulting -deps files should also match Manifest entries. So a similar approach could be used in the case of expired ::gentoo versions being installed, or overlays using -deps files without a way to host them. Set things up so this can be done easily on demand or perhaps automatically as needed (maybe through a variation on pkg_nofetch in a Go eclass; that part is not obvious to me). Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] Packages of zlogene up for grabs
On Fri, Jan 13, 2023 at 02:35:45PM +0100, mgorny wrote: > acct-group/squid > acct-user/squid > net-proxy/squid I have an interest in these so I could p-m them, but I would need adult supervision. Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 2021-09-28, Ulrich Mueller wrote: > >>>>> On Tue, 28 Sep 2021, Michał Górny wrote: > > On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote: > >> Markers: (--) probed, (**) from config file, (==) default > >> setting, > >> (++) from command line, (!!) notice, (II) informational, > >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >> > >> So, maybe change einfo from [--] to [II]? > > > Nah, the whole point is to avoid letters since it's not very > > important. > > Alternatively to '[--]' I could make it look down '[..]' or maybe even > > without eyes entirely '[ ]'. > > Yeah, anything but [--]. The version with the dots is nice. I think any change from only-color would be an improvement; mgorny's first version looks nice. I can see why symmetry with Xorg EE, WW, etc. has an appeal but also the downsides of a) since things don't actually line up 1:1 it could be misleading to try; b) it's also somewhat language-biased. Something a lot of tools have started doing is [?] prefixes to their output; I don't know if there's even a semi-formal spec on it, but what seems to me to map well would be: [!] fatal error (die / eerror?) [*] important but nonfatal (ewarn?) [+] info, maybe memorable, but not harmful (elog?) [.] status/verbose message (einfo?) Could double that if preserving a 4-char-wide tag is preferred. That doesn't cover all needed, like eqawarn, but there are more to choose from. It's unfortunate that many of these are regex metacharacters, making slightly more (human) overhead when grepping, but we already have that with the [] delimeters. > > or maybe even without eyes entirely '[ ]'. For no reason I can articulate, the empty one bugs me. I would get over it though ;) Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] Package up for grabs: sys-boot/lilo
On 2021-06-01, Mike Gilbert wrote: > The base system project is dropping LILO: it really needs to be > maintained by someone who actually uses it. I still use/prefer LILO; I'll take a look at the open bugs and consider submitting PRs for them & taking on p-m of it. An actual @gentoo.org dev is welcome to take it from me though. Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] sys-apps/firejail and sys-apps-firejail lts are up for grabs
On 2020-10-14, Sam James wrote: > > On 14 Oct 2020, at 18:40, Hank Leininger wrote: > > >> - sys-apps/firejail > > >> - sys-apps/firejail-lts > > > > I will proxy maintain both of these. Preparing a PR shortly... > > I think ajak is also working on this (spending time on getting tests > working), so coordinate with him if possible? Whoops, I saw this literally seconds after submitting https://github.com/gentoo/gentoo/pull/17929 ajak you are welcome to them if you prefer, either w/the updates I just submitted, or otherwise. I did zero work on getting tests working, only the issues in the b.g.o bugs I mentioned. I've looked over a couple other outstanding firejail bugs, I have thoughts but not done work on them yet. Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] sys-apps/firejail and sys-apps-firejail lts are up for grabs
On 2020-10-11, Dennis Lamm wrote: > the following packages are up for grabs: > > - sys-apps/firejail > - sys-apps/firejail-lts I will proxy maintain both of these. Preparing a PR shortly... Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] Last rites: x11-themes/fvwm-crystal
> # Aaron Bauman (2020-06-03) > # py2 only. dead upstream. m-n. > # Masked for removal in 15 days > x11-themes/fvwm-crystal I use fvwm-crystal, so I'll speak up on its behalf... fvwm-crystal has supported python3 since version 3.6.0. It is still active upstream; version 3.6.5 was released 2020-04-24: https://sourceforge.net/projects/fvwm-crystal/files/3.6.5/ There has been a PR by the x11-themes/fvwm-crystal proxy maintainer (also the upstream maintainer) to bump to v3.6.2 which switches to py3, and add acct-group/fvwm-crystal for GLEP 81 since Feb: https://github.com/gentoo/gentoo/pulls?q=is%3Apr+is%3Aopen+fvwm-crystal (Nevermind the typoes in the bump subject.) It looks like the PR got caught up in order-of-operations issues w/the switch to acct-group/fvwm-crystal, the PR for which got held up for other reasons. Dominique if you are no longer able to/interested in proxy-maintaining the Gentoo fvwm-crystal package and want to offload it, I can try, since otherwise I will keep it in a local overlay anyway. [If you are already subscribed to gentoo-dev, then sorry for the CC: spam] Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
Re: [gentoo-dev] crypto@ packages up for grabs
On 2020-01-08, Mikle Kolyada said: > These are up for grabs due to the crypto@ project being disbanded. ... > app-crypt/aespipe > app-crypt/loop-aes-losetup > sys-fs/loop-aes I use these, and currently proxy-maintain a couple of other packages. I also see there's version bumps for some available. I'll submit PRs to bump and sign up as proxy maintainer, unless someone more qualified jumps on the thread and wants them. Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
[gentoo-dev] RFC: UID/GID assignment for scponly (239)
This user and group is used when scponly is in chroot mode. Currently the ebuild uses user.eclass; requesting this so that I can update it to comply with GLEP 81. I can find no precedence from other distros for a specific favored UID. I picked 239 because if you squint real hard it looks like scp, and isn't taken by anybody but FreeBSD. I submitted a PR here: https://github.com/gentoo/gentoo/pull/14033 -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
