Re: [gentoo-dev] Vanilla sources
On Fri, 3 Jan 2020 15:48:54 +0100 Toralf Förster wrote: > # Restrict potential illegal access via links > # > fs.protected_hardlinks = 1 > fs.protected_symlinks = 1 Given the issues with openrc: Wouldn't it be a good idea to add these by default to Gentoo's sysctl.conf in baselayout? As far as I understand this from the thread by now, these are set by default by Gentoo Sources. So we shouldn't really expect much breakage if we set them via sysctl. -- Hanno Böck https://hboeck.de/ pgp0gbqf5JHKL.pgp Description: OpenPGP digital signature
[gentoo-dev] New project: Distribution kernel
Hi, I'd like to officially RFC establishing the 'Distribution kernel' project. As the project page [1] says, our goal is to maintain sys- kernel/*-kernel packages. The goals are: 1. Covering kernel maintenance wholly within packages (install via emerge, upgrade as part of @world upgrade), without requiring additional actions from the user or resorting to nonportable hacks. 2. Providing a default configuration that works for most of diverse systems, for users who are not interested in configuring their own kernel from scratch. 3. Supporting different bootloaders and /boot layouts (LILO, GRUB, systemd-boot, EFI stub…) with minimal effort, including deploying self- built kernel binary packages over a fleet of heterogeneous systems. [1] https://wiki.gentoo.org/wiki/Project:Distribution_Kernel -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies
On Fri, 3 Jan 2020 22:34:19 + Michael 'veremitz' Everitt wrote: > On 03/01/20 10:36, David Seifert wrote: > > On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote: > >> On 02/01/20 21:08, Michał Górny wrote: > >>> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote: > > On Thu, 02 Jan 2020, Michał Górny wrote: > > --- a/eclass/ruby-ng.eclass > > +++ b/eclass/ruby-ng.eclass > > @@ -137,7 +137,7 @@ ruby_samelib() { > > local res= > > for _ruby_implementation in $(_ruby_get_all_impls); do > > has -${_ruby_implementation} $@ || \ > > - res="${res}ruby_targets_${_ruby_impleme > > ntation}?," > > + res="${res}ruby_targets_${_ruby_impleme > > ntation}(-)?," > > done > > > > echo "[${res%,}]" > Hadn't we established that ruby_samelib() is dead code, no longer > used > since 2010? > > >>> You did. However, it isn't marked as private API and I'm not the > >>> eclass > >>> maintainer to take care of removing public API. I have no clue if > >>> Ruby > >>> project doesn't have some secret overlays using it. > >>> > >> You can't use QA super-powerz ?! BDFL + sub-BDFL ?! > >> * > >> > >> * Thought the tags probably worth making explicit > >> > > Can you please stop polluting the -dev mailing list with this senseless > > chatter? > > > > > Perhaps I should remind you that this is a public mailing list (or hasn't > successfully been censored Yet) and not a private communication channel for > developers (see -core for this). But I don't need to tell you this This may be a public list and I don't always expect threads to stay precisely on-topic but the posts should still have some value. This was just frivolous. You won't know this but I have defended your presence on this list multiple times in the past. Please respect that. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpxN8QOz1six.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies
On 03/01/2020 23:34, Michael 'veremitz' Everitt wrote: On 03/01/20 10:36, David Seifert wrote: On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote: On 02/01/20 21:08, Michał Górny wrote: On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote: On Thu, 02 Jan 2020, Michał Górny wrote: --- a/eclass/ruby-ng.eclass +++ b/eclass/ruby-ng.eclass @@ -137,7 +137,7 @@ ruby_samelib() { local res= for _ruby_implementation in $(_ruby_get_all_impls); do has -${_ruby_implementation} $@ || \ - res="${res}ruby_targets_${_ruby_impleme ntation}?," + res="${res}ruby_targets_${_ruby_impleme ntation}(-)?," done echo "[${res%,}]" Hadn't we established that ruby_samelib() is dead code, no longer used since 2010? You did. However, it isn't marked as private API and I'm not the eclass maintainer to take care of removing public API. I have no clue if Ruby project doesn't have some secret overlays using it. You can't use QA super-powerz ?! BDFL + sub-BDFL ?! * * Thought the tags probably worth making explicit Can you please stop polluting the -dev mailing list with this senseless chatter? Perhaps I should remind you that this is a public mailing list (or hasn't successfully been censored Yet) and not a private communication channel for developers (see -core for this). But I don't need to tell you this Hi, at least a person is displeased with your attempt at humor, could you please stop doing this? It does not add anything to the conversation and it is unpleasant. lu PS: This counts as friendly warning.
Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies
On 03/01/20 10:36, David Seifert wrote: > On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote: >> On 02/01/20 21:08, Michał Górny wrote: >>> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote: > On Thu, 02 Jan 2020, Michał Górny wrote: > --- a/eclass/ruby-ng.eclass > +++ b/eclass/ruby-ng.eclass > @@ -137,7 +137,7 @@ ruby_samelib() { > local res= > for _ruby_implementation in $(_ruby_get_all_impls); do > has -${_ruby_implementation} $@ || \ > - res="${res}ruby_targets_${_ruby_impleme > ntation}?," > + res="${res}ruby_targets_${_ruby_impleme > ntation}(-)?," > done > > echo "[${res%,}]" Hadn't we established that ruby_samelib() is dead code, no longer used since 2010? >>> You did. However, it isn't marked as private API and I'm not the >>> eclass >>> maintainer to take care of removing public API. I have no clue if >>> Ruby >>> project doesn't have some secret overlays using it. >>> >> You can't use QA super-powerz ?! BDFL + sub-BDFL ?! >> * >> >> * Thought the tags probably worth making explicit >> > Can you please stop polluting the -dev mailing list with this senseless > chatter? > > Perhaps I should remind you that this is a public mailing list (or hasn't successfully been censored Yet) and not a private communication channel for developers (see -core for this). But I don't need to tell you this signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources
On 03/01/20 14:48, Toralf Förster wrote: > On 1/3/20 3:46 PM, Rich Freeman wrote: >> If OpenRC contains a vulnerability wouldn't it make more sense to set >> this as part of OpenRC, > Indeed. > > Furthermore there's a nifty page > https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings > which yields for me to this /etc/sysctl.d/local.conf : > > > # Restrict potential illegal access via links > # > fs.protected_hardlinks = 1 > fs.protected_symlinks = 1 > > # > # https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#CONFIGs > # > > # Try to keep kernel address exposures out of various /proc files (kallsyms, > modules, etc). > kernel.kptr_restrict = 1 > > # Avoid kernel memory address exposures via dmesg. > kernel.dmesg_restrict = 1 > > # Block non-uid-0 profiling (needs distro patch, otherwise this is the same > as "= 2") > kernel.perf_event_paranoid = 3 > > # Turn off kexec, even if it's built in. > kernel.kexec_load_disabled = 1 > > # Avoid non-ancestor ptrace access to running processes and their credentials. > kernel.yama.ptrace_scope = 1 > > # Disable User Namespaces, as it opens up a large attack surface to > unprivileged users. > user.max_user_namespaces = 0 > > # Turn off unprivileged eBPF access. > kernel.unprivileged_bpf_disabled = 1 > > # Turn on BPF JIT hardening, if the JIT is enabled. > net.core.bpf_jit_harden = 2 > > FWIW, there is a move to add further hardening options to the Gentoo-sources kernel - bug 689154, based on the kernsec recommendations. Further details of proposals, and inspiration, are in the bug. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-print/cndrvcups* up for grabs
On 10/20/19 1:22 PM, Pacho Ramos wrote: > Hello > > I almost lost access to the unique printer that was relying on this driver. > Also, even if the current latest version was still working there, it will > need a > major update to newer cnRdrvcups driver sooner or later > https://aur.archlinux.org/packages/cnrdrvcups-lb/ > https://www.canon-europe.com/support/products/imagerunner/imagerunner-1730i.html?type=drivers=en=linux > > Hence, the following packages are up for grabs now > net-print/cndrvcups-common-lb > net-print/cndrvcups-lb > > Thanks Hey, Here's my attempt at updating it. I'd appreciate any kind of testing if you can before I (possibly) push it to the tree. It's based on current cndrvcups-lb ebuild, your work I guess? I posted my ebuild and some additional comments in a bug: https://bugs.gentoo.org/695896#c2 I could use some help decoding that QA notice too, mentioned in the bug... -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources
On January 3, 2020 9:55:31 AM EST, Michael Orlitzky wrote: >On 1/3/20 9:52 AM, Michael Orlitzky wrote: >> >> But here we are. Do we make OpenRC Linux-only and steal the fix from >> systemd? Or pretend to support other operating systems, but leave >them >> insecure? >> > >Or the gripping hand: rewrite opentmpfiles in C, so that it's only as >insecure as checkpath. > >Every option sucks. I was only trying to point out that vanilla-sources >gets no security support -- security@ has stated this, but it's on a >private bug, so I won't quote it -- and the risk is more than academic. This should be known. Security does not support vanilla-sources. This is one reason vanilla-sources are not stabilized. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Vanilla sources
On 1/3/20 9:52 AM, Michael Orlitzky wrote: > > But here we are. Do we make OpenRC Linux-only and steal the fix from > systemd? Or pretend to support other operating systems, but leave them > insecure? > Or the gripping hand: rewrite opentmpfiles in C, so that it's only as insecure as checkpath. Every option sucks. I was only trying to point out that vanilla-sources gets no security support -- security@ has stated this, but it's on a private bug, so I won't quote it -- and the risk is more than academic.
Re: [gentoo-dev] Vanilla sources
On 1/3/20 9:46 AM, Rich Freeman wrote: > > ... > > In any case this seems more like an OpenRC issue than a Gentoo issue. > It's a specification issue. There's no way to implement tmpfiles safely on a POSIX system, and opentmpfiles shouldn't exist if OpenRC wants to work on anything other than Linux. But here we are. Do we make OpenRC Linux-only and steal the fix from systemd? Or pretend to support other operating systems, but leave them insecure?
Re: [gentoo-dev] Vanilla sources
On 1/3/20 3:46 PM, Rich Freeman wrote: > If OpenRC contains a vulnerability wouldn't it make more sense to set > this as part of OpenRC, Indeed. Furthermore there's a nifty page https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings which yields for me to this /etc/sysctl.d/local.conf : # Restrict potential illegal access via links # fs.protected_hardlinks = 1 fs.protected_symlinks = 1 # # https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#CONFIGs # # Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc). kernel.kptr_restrict = 1 # Avoid kernel memory address exposures via dmesg. kernel.dmesg_restrict = 1 # Block non-uid-0 profiling (needs distro patch, otherwise this is the same as "= 2") kernel.perf_event_paranoid = 3 # Turn off kexec, even if it's built in. kernel.kexec_load_disabled = 1 # Avoid non-ancestor ptrace access to running processes and their credentials. kernel.yama.ptrace_scope = 1 # Disable User Namespaces, as it opens up a large attack surface to unprivileged users. user.max_user_namespaces = 0 # Turn off unprivileged eBPF access. kernel.unprivileged_bpf_disabled = 1 # Turn on BPF JIT hardening, if the JIT is enabled. net.core.bpf_jit_harden = 2 -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources
On Fri, Jan 3, 2020 at 9:41 AM Michael Orlitzky wrote: > > On 1/3/20 9:40 AM, Toralf Förster wrote: > > On 1/3/20 3:37 PM, Michael Orlitzky wrote: > >> The gentoo-sources aren't 100% safe either, but the exploitable scenario > >> is less common thanks to fs.protected_{hardlinks,symlinks}=1. > > > > But this can be easily achieved w/o installing gentoo-sources, or? > > > > Yes, if you know how to do it. And the hard part: if you know that you > *should* do it. > If OpenRC contains a vulnerability wouldn't it make more sense to set this as part of OpenRC, then to assume somebody is running a kernel patch that does it, especially since OpenRC doesn't in any way ensure that gentoo-sources is actually being used? Of course, fixing the vulnerability seems like a better option. At least on Linux based on your one bug description it sounds like systemd has a Linux-specific fix already. Obviously it would be best to secure this on all kernels but there is no reason not to at least use that fix on Linux. You could also try to convince the entire world not to use tmpfiles.d but since it is only a problem if you aren't using systemd I suspect you won't get much traction there. In any case this seems more like an OpenRC issue than a Gentoo issue. -- Rich
Re: [gentoo-dev] Vanilla sources
On 1/3/20 9:40 AM, Toralf Förster wrote: > On 1/3/20 3:37 PM, Michael Orlitzky wrote: >> The gentoo-sources aren't 100% safe either, but the exploitable scenario >> is less common thanks to fs.protected_{hardlinks,symlinks}=1. > > But this can be easily achieved w/o installing gentoo-sources, or? > Yes, if you know how to do it. And the hard part: if you know that you *should* do it.
Re: [gentoo-dev] Vanilla sources
On 1/3/20 3:37 PM, Michael Orlitzky wrote: > The gentoo-sources aren't 100% safe either, but the exploitable scenario > is less common thanks to fs.protected_{hardlinks,symlinks}=1. But this can be easily achieved w/o installing gentoo-sources, or? -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources
On 1/2/20 6:35 PM, Rolf Eike Beer wrote: > > I only run vanilla-sources since there are still lot of cache corruption > problems in hppa kernels, or whatever makes them flaky. The vanilla-sources are unsafe to use on Gentoo. Many services have stupid-easy root exploits, since we install tmpfiles entries by default and OpenRC runs them insecurely: * https://github.com/OpenRC/opentmpfiles/issues/3 * https://github.com/OpenRC/opentmpfiles/issues/4 I've fixed similar exploits when I've found them in /etc/init.d and pkg_postinst[0][1], but they continue to be added to the tree. And there is no fix for opentmpfiles. The gentoo-sources aren't 100% safe either, but the exploitable scenario is less common thanks to fs.protected_{hardlinks,symlinks}=1. [0] http://michael.orlitzky.com/articles/end_root_chowning_now_%28make_etc-init.d_great_again%29.xhtml [1] http://michael.orlitzky.com/articles/end_root_chowning_now_%28make_pkg_postinst_great_again%29.xhtml
Re: [gentoo-dev] Last rites: media-video/vdrtools-genindex
On 1/3/20 1:23 PM, Joerg Bornkessel wrote: media-video/vdrtools-genindex is an useless leftover from older media-video/vdr install this function is included in the core vdr use "vdr --genindex=REC" for this removal from tree ~31 Jan 2020 wrt bug 704692 reverted pmask, as it is still needed by media-plugins/vdr-burn sorry for the noise -- Joerg Bornkessel GnuPG Key: 0x93EB5F4DAA5832A1 Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1
[gentoo-dev] Last rites: media-plugins/vdr-skinenigmang
# Joerg Bornkessel # package is broken by all version of imagemagick # several open bugs on upstream # Upstream did not reply about project status # wrt bug 314315 # removal ~2020-01-31 media-plugins/vdr-skinenigmang -- Joerg Bornkessel GnuPG Key: 0x93EB5F4DAA5832A1 Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1
[gentoo-dev] Last rites: media-video/vdrtools-genindex
media-video/vdrtools-genindex is an useless leftover from older media-video/vdr install this function is included in the core vdr use "vdr --genindex=REC" for this removal from tree ~31 Jan 2020 wrt bug 704692 -- Joerg Bornkessel GnuPG Key: 0x93EB5F4DAA5832A1 Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5 21C2 93EB 5F4D AA58 32A1
[gentoo-dev] [PATCH] linux-mod.eclass: pass proper arch to kernel's build system
A user reported that when compiling modules for a system with a 64-bit kernel and a 32-bit userland, there were linker errors. This patch here is an attempt to fix that by making sure that we always use the kernel ABI when giving target build parameters. Signed-off-by: Jason A. Donenfeld Fixes: https://bugs.gentoo.org/704468 Cc: joakim.tjernl...@infinera.com Cc: ker...@gentoo.org --- eclass/linux-mod.eclass | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index b6dc2c84d09..60b0d88e9b9 100644 --- a/eclass/linux-mod.eclass +++ b/eclass/linux-mod.eclass @@ -671,13 +671,16 @@ linux-mod_src_compile() { # spaces that must be preserved. If don't do this, then the stuff # inside the variables gets used as targets for Make, which then # fails. - eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \ - CROSS_COMPILE=${CHOST}- \ - LDFLAGS=\"$(get_abi_LDFLAGS)\" \ + local KERNEL_CHOST="$(ABI=${KERNEL_ABI} get_abi_CHOST)" + local KERNEL_LDFLAGS="$(ABI=${KERNEL_ABI} get_abi_LDFLAGS)" + local HOST_CC="$(tc-getBUILD_CC)" + eval "emake HOSTCC=\"${HOST_CC}\" \ + CROSS_COMPILE=${KERNEL_CHOST}- \ + LDFLAGS=\"${KERNEL_LDFLAGS}\" \ ${BUILD_FIXES} \ ${BUILD_PARAMS} \ ${BUILD_TARGETS} " \ - || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}" + || die "Unable to emake HOSTCC="${HOST_CC}" CROSS_COMPILE=${KERNEL_CHOST}- LDFLAGS="${KERNEL_LDFLAGS}" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}" cd "${OLDPWD}" touch "${srcdir}"/.built fi -- 2.24.1
[gentoo-dev] [PATCH] linux-mod.eclass: pass proper arch to kernel's build system
A user reported that when compiling modules for a system with a 64-bit kernel and a 32-bit userland, there were linker errors. This patch here is an attempt to fix that by making sure that we always use the kernel ABI when giving target build parameters. Signed-off-by: Jason A. Donenfeld Fixes: https://bugs.gentoo.org/704468 Cc: joakim.tjernl...@infinera.com Cc: ker...@gentoo.org --- This is untested on the bug reporter's system, and I'd appreciate some review from an author of this eclass. eclass/linux-mod.eclass | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass index b6dc2c84d09..ecfce72a142 100644 --- a/eclass/linux-mod.eclass +++ b/eclass/linux-mod.eclass @@ -671,13 +671,16 @@ linux-mod_src_compile() { # spaces that must be preserved. If don't do this, then the stuff # inside the variables gets used as targets for Make, which then # fails. - eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" \ - CROSS_COMPILE=${CHOST}- \ - LDFLAGS=\"$(get_abi_LDFLAGS)\" \ + local KERNEL_CHOST="$(ABI=${KERNEL_ABI} get_abi_CHOST)" + local KERNEL_LDFLAGS="$(ABI=${KERNEL_ABI} get_abi_LDFLAGS)" + local HOST_CC="$(tc-getHOST_CC)" + eval "emake HOSTCC=\"${HOST_CC}\" \ + CROSS_COMPILE=${KERNEL_CHOST}- \ + LDFLAGS=\"${KERNEL_LDFLAGS}\" \ ${BUILD_FIXES} \ ${BUILD_PARAMS} \ ${BUILD_TARGETS} " \ - || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}" + || die "Unable to emake HOSTCC="${HOST_CC}" CROSS_COMPILE=${KERNEL_CHOST}- LDFLAGS="${KERNEL_LDFLAGS}" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}" cd "${OLDPWD}" touch "${srcdir}"/.built fi -- 2.24.1
Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies
On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote: > On 02/01/20 21:08, Michał Górny wrote: > > On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote: > > > > > > > > On Thu, 02 Jan 2020, Michał Górny wrote: > > > > --- a/eclass/ruby-ng.eclass > > > > +++ b/eclass/ruby-ng.eclass > > > > @@ -137,7 +137,7 @@ ruby_samelib() { > > > > local res= > > > > for _ruby_implementation in $(_ruby_get_all_impls); do > > > > has -${_ruby_implementation} $@ || \ > > > > - res="${res}ruby_targets_${_ruby_impleme > > > > ntation}?," > > > > + res="${res}ruby_targets_${_ruby_impleme > > > > ntation}(-)?," > > > > done > > > > > > > > echo "[${res%,}]" > > > Hadn't we established that ruby_samelib() is dead code, no longer > > > used > > > since 2010? > > > > > You did. However, it isn't marked as private API and I'm not the > > eclass > > maintainer to take care of removing public API. I have no clue if > > Ruby > > project doesn't have some secret overlays using it. > > > You can't use QA super-powerz ?! BDFL + sub-BDFL ?! > * > > * Thought the tags probably worth making explicit > Can you please stop polluting the -dev mailing list with this senseless chatter?
Re: [gentoo-dev] Keywordreqs and slacking arch teams
Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman: > On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer wrote: > >Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano: > >> hppa is making us keep old kernels around [1]. Should the kernel team be > >> doing more to get your attention then CC'ing hppa on all of the kernel > >> STABLEREQ bugs [2]? > > > >I only run vanilla-sources since there are still lot of cache > >corruption > >problems in hppa kernels, or whatever makes them flaky. > > > >Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64 > >PA8800 (Mako) 9000/785/C8000 GNU/Linux > >Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600 > >(PCX-W+) 9000/785/C3600 GNU/Linux > > > >So _I_ personally would say just drop old kernels, but that is in no > >way > >authorative. > Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel > sources of each stable and LTS version. If it's just that I could test them, but this still be no LTS version that I would look at. Just some background: these machines run CMake and some other software nightly builds, which starts ~3:00 and takes them until the afternoon. I have chroots for stabilization and keywording on them, and the tatt scripts will wait if any process of my buildbot user (that's just the name, not the software) is active. If the nightlies are done, then the tatt scripts will continue and hog the machine. I will do a kernel upgrade usually if the machine crashed anyway, which means every few weeks, and then I go to the most recent version. Eike signature.asc Description: This is a digitally signed message part.