Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Hanno Böck
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

2020-01-03 Thread Michał Górny
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

2020-01-03 Thread James Le Cuirot
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

2020-01-03 Thread Luca Barbato

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

2020-01-03 Thread Michael 'veremitz' Everitt
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

2020-01-03 Thread Michael 'veremitz' Everitt
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

2020-01-03 Thread Joonas Niilola

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

2020-01-03 Thread Aaron Bauman



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

2020-01-03 Thread Michael Orlitzky
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

2020-01-03 Thread Michael Orlitzky
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

2020-01-03 Thread Toralf Förster
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

2020-01-03 Thread Rich Freeman
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

2020-01-03 Thread Michael Orlitzky
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

2020-01-03 Thread Toralf Förster
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

2020-01-03 Thread Michael Orlitzky
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

2020-01-03 Thread Joerg Bornkessel

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

2020-01-03 Thread Joerg Bornkessel

# 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

2020-01-03 Thread Joerg Bornkessel

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

2020-01-03 Thread Jason A. Donenfeld
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

2020-01-03 Thread Jason A. Donenfeld
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

2020-01-03 Thread David Seifert
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

2020-01-03 Thread Rolf Eike Beer
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.