Re: [gentoo-dev] Packages up for grabs due to jlec being MIA
Michał Górny writes: >> The following packages are looking for a new maintainer: >> > > + cuda.eclass I would like to adopt this eclass on behalf of the science project. Yours, Benda signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due to jlec being MIA
I'll take sys-kernel/kergen [1] and net-analyzer/zmap [2] [1] https://github.com/gentoo/gentoo/pull/17016 [2] https://github.com/gentoo/gentoo/pull/17017 On 8/5/20 9:24 AM, Michał Górny wrote: > Hello, > > The following packages are looking for a new maintainer: > > [vB] app-backup/cachedir > [vB] app-benchmarks/bootchart2 > [ B] app-benchmarks/ramspeed > [ B] app-office/scribus > [vB] dev-lua/luaposix > [ b] net-analyzer/zmap > [ ] net-libs/czmq > [ ] net-vpn/vpncwatch > [vB] sys-block/blocks > [ ] sys-boot/makebootfat > [v ] sys-fs/aufs-headers > [vB] sys-fs/aufs-util > [vB] sys-fs/bcache-tools > [v ] sys-kernel/aufs-sources > [vB] sys-kernel/kergen > > Legend: > > v - needs version bump > b - has trivial (QA) bug reported > B - has non-trivial bug reported > -- Best regards, Jakov Smolic
[gentoo-dev] News item: Multiple root kernel command-line arguments
Hi, please review the news item below: - I am not 100% happy with the title but the 50 char limit doesn't allow any more details. - No Display-If condition because it is neither a genkernel nor kexec-tools issue. We maybe even have additional packages which are appending to kernel command-line I am not aware of. - In theory this shouldn't be a news for anyone: If you don't use a persistent device name, you are basically asking for troubles like that. However, people just using kexec from kexec-tools package maybe unaware that auto-detection of ROOT device which is the default might cause trouble like that because it won't use persistent names. - Experiencing a boot failure is always bad -- especially for headless/remote systems so a warning shouldn't hurt. - Latest kexec-tools ebuild in repository now also warns user in pkg_postinst, see https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/kexec-tools/kexec-tools-2.0.20-r3.ebuild?id=61c03ffab76740c0420e3c8a3185d047d461f7a7#n111 --- Title: Multiple root kernel command-line arguments Author: Thomas Deutschmann Posted: 2020-08-05 Revision: 1 News-Item-Format: 2.0 Due to genkernel-4.1 development which is changing device manager from MDEV to (E)UDEV it was noticed that some tools like kexec append an additional root argument to kernel command-line. If these tools will set root to a non-persistent device name like root=/dev/dm-3, the next boot might fail if there is *no* root device named like that in start environment (i.e. initramfs). While kexec's runscript was changed in >=sys-apps/kexec-tools-2.0.20-r2 to no longer append root kernel command-line argument when an option like "--reuse-cmdline" (default) is used, a cold reboot *without* kexec maybe needed to restore kernel command-line. NOTE: This issue is *not* specific to kexec or genkernel usage. Kernel will always use last set root kernel command-line argument. Any tool which might be appending root argument without a persistent device name might cause a boot failure if system cannot find that referenced root device during boot. To avoid boot problems user should revise their current kernel command-line (/proc/cmdline) to ensure that only *one* root kernel command-line argument is set. The usage of persistent device names like root=UUID=<...> is highly recommended. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last-rites: dev-libs/liboobs
On Tuesday, 4 August 2020 01:27:17 CEST Jimi Huotari wrote: > I'd certainly be fine with this, and 'app-admin/system-tools-backends', > which is next on my list to go, to be assigned to maintainer-wanted > instead of being removed. Looking at the linked bug, the package was doomed in 2016, last-rites is inevitable. Regards signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last-rites: dev-libs/liboobs
On Tuesday, 4 August 2020 00:23:44 CEST Peter Stuge wrote: > Jimi Huotari wrote: > > # Jimi Huotari (2020-08-04) > > # No consumers since 2015, and no known stand-alone use. > > # Removal in 30 days. > > dev-libs/liboobs > > Wut - isn't that a really poor reason to remove from the tree? :\ > > Why not just keep it unless there is an actual technical problem? > (Security, maintainability, etc.) If there is, then please mention it. If you know a reason to keep it, please mention it. Otherwise, a non-high-profile library that had no consumers in 2015 has no business of staying in tree in 2020. I rather have the current maintainer, fully aware of its redundancy, send those last-rites instead of effectively asking a poor random dev in the future to completely unnecessarily waste time on maintenance or do the necessary research before removing it. Regards signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs due to jlec being MIA
On Wed, 2020-08-05 at 09:24 +0200, Michał Górny wrote: > Hello, > > The following packages are looking for a new maintainer: > + cuda.eclass -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due to jlec being MIA
Hello, The following packages are looking for a new maintainer: [vB] app-backup/cachedir [vB] app-benchmarks/bootchart2 [ B] app-benchmarks/ramspeed [ B] app-office/scribus [vB] dev-lua/luaposix [ b] net-analyzer/zmap [ ] net-libs/czmq [ ] net-vpn/vpncwatch [vB] sys-block/blocks [ ] sys-boot/makebootfat [v ] sys-fs/aufs-headers [vB] sys-fs/aufs-util [vB] sys-fs/bcache-tools [v ] sys-kernel/aufs-sources [vB] sys-kernel/kergen Legend: v - needs version bump b - has trivial (QA) bug reported B - has non-trivial bug reported -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
