Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Jaco Kroon]

Hi,

On 2024/09/13 12:22, Michael Orlitzky wrote:


On 2024-09-11 17:23:16, Jaco Kroon wrote:

1.  Let users (myself included) just download and use that.
2.  We package the phar file rather than the individual deps. Yes, this
is cheating.  Like using embedded libs, however, I've seen and observed
that in some cases this makes more sense than splitting them up (eg
clippy and frr).
3.  We go about figuring everything out again and bumping all those
individual packages and keeping them all up to date individually.  I
don't think this is worth our time and effort.

I honestly think in this case 2 may well be acceptable. Otherwise 1, but
I think 3 is not worth the effort based on your feedback and further
reading from when I originally posed the question to now.

I agree that (3) is probably too much trouble. It might be worth it if
someday people want to bring back other packages that would benefit
from the deps, like PHPUnit.

I don't like (2) because there's no way for the security team to know
what's inside composer.phar, and no way for users to tell that they've
got ~15 bundled dependencies in a tool that's extremely
sensitive. So... what I've been doing is putting composer.phar in
/usr/local/bin. (I also run it as a separate user because I don't
trust the code it's downloading but that has nothing to do with
Gentoo.)


I think, then let's stick with that.

I'm not able to edit https://wiki.gentoo.org/wiki/Composer_packaging in 
order to make reference of this dicussion there so others looking at it 
will understand what the motivation is.  In the meantime I'm sorted at 
least.


Thanks for the constructive discussion.

Kind regards,
Jaco

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Jaco Kroon]

Hi Michael,

Looks like we keep bumping into each other ... and not only on PHP packages.

n 2024/09/11 13:26, Michael Orlitzky wrote:

On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote:

Hi,

I missed this announcement, looking specifically for composer again.

If I make the effort of bumping to newest version, is this something
that would be re-added to the tree?

I'd re-commit if you're interested in keeping up with it. It brings a
lot of dependencies with it though. It was initially added in

   https://github.com/gentoo/gentoo/pull/2905

(where you can see the deps) and I'll bet the list is even longer now.

Updating them is more annoying than usual because they all want
autoload.php files that aren't in the source tarball:

   https://wiki.gentoo.org/wiki/Composer_packaging

IIRC the "classmap" format is particularly annoying because you have to
regenerate it with every release.



Right.  What I take away from this is that PHP trying to incorporate 
things that annoy me about other languages is a pain in the backside.


All I really need (and I think this is in line with something you 
mentioned in one of our other discussions) is that PHP source files are 
typically no longer packaged, because everyone uses composer now to just 
pull in dependencies from just about anywhere, and often poorly vetted, 
outdated versions.


What I really just need is a way to for a specific PHP deployed app be 
able to run composer to pull in those dependencies into a normal user 
account so that I can properly isolate the specific PHP app.


I think it's useful to have the composer command available on Gentoo, 
but I do agree with the principle of letting each deployment manage it's 
own rather.


Ie, my *opinion* is that Gentoo should package the interpreters and any 
pecl-* stuff which is compiled.  And let the apps handle their own sources.


composer I reckon is a bit of a tricky one here because it looks like it 
itself is a source-based thing, and pulls in a bunch of it's own deps then?


Looking at what one of our clients did is they have a versioned 
composer.phar ... which means deps are packaged.


https://getcomposer.org/download/ has these lower down, so IMHO three 
options here:


1.  Let users (myself included) just download and use that.
2.  We package the phar file rather than the individual deps. Yes, this 
is cheating.  Like using embedded libs, however, I've seen and observed 
that in some cases this makes more sense than splitting them up (eg 
clippy and frr).
3.  We go about figuring everything out again and bumping all those 
individual packages and keeping them all up to date individually.  I 
don't think this is worth our time and effort.


I honestly think in this case 2 may well be acceptable. Otherwise 1, but 
I think 3 is not worth the effort based on your feedback and further 
reading from when I originally posed the question to now.


Your opinion?

Kind regards,
Jaco

[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Jaco Kroon]

Hi,

I missed this announcement, looking specifically for composer again.

If I make the effort of bumping to newest version, is this something 
that would be re-added to the tree?


I note there were active security vulnerabilities under very specific 
conditions (composer.phar is exposed via http).


Or should I rather just deploy this into a local overlay?

Kind regards,
Jaco


On 2024/06/21 19:20, Arthur Zamarin wrote:

# Arthur Zamarin  (2024-06-21)
# Last dev-php/* EAPI=6 packages, and reverse dependencies of them.
# composer has active security vulnerabilities. Others are waiting
# for version bumps, and unbundling of dependencies.
# Removal on 2024-07-21.  Bugs #934666.
dev-php/phpDocumentor
dev-php/phpcov
dev-php/phpdepend
dev-php/phpdocumentor-reflection-common
dev-php/phpdocumentor-reflection-docblock
dev-php/phpdocumentor-type-resolver
dev-php/stringparser_bbcode
dev-php/symfony-config
dev-php/symfony-console
dev-php/symfony-dependency-injection
dev-php/symfony-event-dispatcher
dev-php/symfony-yaml
dev-php/composer

[gentoo-dev] Fwd: open pull requests [was on netifrc]

[Jaco Kroon]

Hi All,

I've got two PRs open on netifrc project, one of which is becoming more 
and more of a pain for us, I'd prefer to push it upstream into netifrc 
since more people can benefit from it than just us, but I'm struggling 
to get that done so may have to revert to pushing it into our local 
repositories and projects instead.


Hoping for some advise on how to proceed.

Kind regards,
Jaco



 Forwarded Message 
Subject:open pull requests
Date:   Thu, 22 Aug 2024 09:06:58 +0200
From:   Jaco Kroon 
Organization:   Ultimate Linux Solutions (Pty) Ltd
To: neti...@gentoo.org



Hi,

Would someone please be able to look at the open pull requests for netifrc?

I'm in more and more need of https://github.com/gentoo/netifrc/pull/56 
in particular, the other PR I'm much less worried about, and was a 
"simple" drive-by based on the suggestion from the referenced bug.


I've deployed same to one or two servers already, but we really want it 
more widespread.  Due to the way ipv6 routing works configuring that by 
hand is a massive PITA, thus the only effective solutions (which is 
really much more convenient than IPv4) is to:


1.  Rely on DHCPv6 (requires a dhcp client to be running, something I 
prefer to avoid in DC);
2.  Rely on RAs from the gateways (yea, plural), the host can then 
self-configure using EUI64 or the iptoken mechanism, MAC addresses can 
(and does) change, tokens can be configured which gives predictability.


Combined with other changes since last release may warrant a new point 
release as well (wireguard improvements, as well as non-device routes - 
something which we've done in a custom netifrc script for quite some 
time already, including routing rules, and specific to net.lo, so we 
loaded these as unreachable_routes=(...) and prohibit_routes=(...), and 
route[46]_rules=(...) in conf.d/net, happy to share these, they'll 
conflict a bit with [1] as in it's providing multiple mechanisms to get 
the same job done.  I think it would be good for Gentoo to standardise 
the mechanisms.  I do like the idea of just adding non-device routes to 
routes_lo=, that said, I've often wondered about just externalising 
non-devices routes and routing rules out of netifrc handling completely 
into it's own init script which does depend() { before net.lo; }.  This 
is a separate discussion though.


Kind regards,
Jaco

1. 
https://github.com/gentoo/netifrc/commit/7c6a8de0c521ea474bccb0dbda4338ff293cdfc6

Re: [gentoo-dev] [PATCH] php-ext-source-r3.eclass: Rebuild exts should dev-lang/php[threads,debug] change.

[Jaco Kroon]

Based on no feedback I proceeded to push a PR available here: 
https://github.com/gentoo/gentoo/pull/37712


On 2024/07/23 12:42, Jaco Kroon wrote:


If these use flags change then the extension dir changes too, requiring
extensions to be rebuilt.

The downside of this change is that different versions of PHP can no
longer have different USE values for threads and debug.

Signed-off-by: Jaco Kroon 
---
  eclass/php-ext-source-r3.eclass | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index 0d58db5031c9..771481ca7d3d 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -100,6 +100,11 @@ esac
  # php_targets_php7-0? ( dev-lang/php:7.0[mysql?,pdo,pcre(+)] )
  # @CODE
  
+# Whenever certain PHP USE flags change, we need to also rebuild all

+# extensions.
+IUSE+="threads debug"
+[ -n "${PHP_EXT_NEEDED_USE}" ] && PHP_EXT_NEEDED_USE+=,
+PHP_EXT_NEEDED_USE+=threads=,debug=
  
  # Make sure at least one target is installed. First, start a USE

  # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
@@ -113,9 +118,7 @@ for _php_target in ${USE_PHP}; do
REQUIRED_USE+="php_targets_${_php_target} "
_php_slot=${_php_target/php}
_php_slot=${_php_slot/-/.}
-   if [[ ${PHP_EXT_NEEDED_USE} ]] ; then
-   _php_slot+=[${PHP_EXT_NEEDED_USE}]
-   fi
+   _php_slot+=[${PHP_EXT_NEEDED_USE}]
PHPDEPEND+=" php_targets_${_php_target}? ( dev-lang/php:${_php_slot} )"
  done
  

[gentoo-dev] [PATCH] php-ext-source-r3.eclass: Rebuild exts should dev-lang/php[threads,debug] change.

[Jaco Kroon]

If these use flags change then the extension dir changes too, requiring
extensions to be rebuilt.

The downside of this change is that different versions of PHP can no
longer have different USE values for threads and debug.

Signed-off-by: Jaco Kroon 
---
 eclass/php-ext-source-r3.eclass | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index 0d58db5031c9..771481ca7d3d 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -100,6 +100,11 @@ esac
 # php_targets_php7-0? ( dev-lang/php:7.0[mysql?,pdo,pcre(+)] )
 # @CODE
 
+# Whenever certain PHP USE flags change, we need to also rebuild all
+# extensions.
+IUSE+="threads debug"
+[ -n "${PHP_EXT_NEEDED_USE}" ] && PHP_EXT_NEEDED_USE+=,
+PHP_EXT_NEEDED_USE+=threads=,debug=
 
 # Make sure at least one target is installed. First, start a USE
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
@@ -113,9 +118,7 @@ for _php_target in ${USE_PHP}; do
REQUIRED_USE+="php_targets_${_php_target} "
_php_slot=${_php_target/php}
_php_slot=${_php_slot/-/.}
-   if [[ ${PHP_EXT_NEEDED_USE} ]] ; then
-   _php_slot+=[${PHP_EXT_NEEDED_USE}]
-   fi
+   _php_slot+=[${PHP_EXT_NEEDED_USE}]
PHPDEPEND+=" php_targets_${_php_target}? ( dev-lang/php:${_php_slot} )"
 done
 
-- 
2.44.2

[gentoo-dev] last-rite: net-dialup/openl2tp

[Jaco Kroon]

# Jaco Kroon  (2024-07-11)
# Superseded by xl2tpd, this no longer has any operational advantage over
# xl2tpd.  If you need help you're welcome to contact me (jkroon on
# libera.chat).
# Removal on 2024-08-11. bugs: #414901, #768075, #919269
net-dialup/openl2tp

[gentoo-dev] recommendation to last-rite openl2tp

[Jaco Kroon]

Hi All,

I noted there has been a recent push to deprecate and clean up the tree 
as much as possible.


Another possible candidate is net-dialup/openl2tp.

We've been using this for a while now, with some recent patches we've 
added against xl2tpd (mostly myself) we now believe there is no longer 
any need for openl2tp.  We've just discontinued it's use on the last two 
sites where we still used it in preference of xl2tpd after patching 
xl2tpd to add the functionality we needed for those two sites (which 
incidentally also wasn't present in openl2tp, from a code perspective 
xl2tp is also simpler to work on, PR will be created on xl2tpd github's 
shortly and update for ::gentoo made).


With this I no longer see any need to carry openl2tp in the tree, and 
happy to file the relevant PRs to last-rite and purge (it's already 
maintainer-wanted) it from the tree entirely.


It has two bugs open, and it does not look like there is any interest to 
fix those (looks like automated reporting).  It would also directly 
close at least one bug on ppp itself (https://bugs.gentoo.org/414901).


Kind regards,
Jaco

Re: [gentoo-dev] Reviewing ebuilds with git

[Jaco Kroon]

Hi,

Is there a way to make this work with github PR reviews?

Kind regards,
Jaco

On 2024/06/30 19:38, Sam James wrote:


Hi,

I've mentioned this on IRC a bunch of times to people but I figure I'll
mention it here in case anyone finds it useful.

Our use of git doesn't lend itself well to the default mode `git diff`
and friends operate in, as we create many new files rather than solely
changing existing ones.

git can be coerced into checking for copies (and doing so "harder" too)
but there's no configuration option for this, and it's a pain to
remember.

You can use the attached patch for dev-vcs/git and then set:
$ git config diff.renames copies-harder
in gentoo.git to make `git log -p`, `git diff`, etc default to this
mode.

IME, it makes reviewing much easier. Be warned that it does make git log
a bit slower though if the config option is enabled for a repo -- but
maybe only noticeably if your repo is grafted with the pre-2015 CVS history.


thanks,
sam

Re: [gentoo-dev] [PATCH 1/3] profiles/desc: add curl_quic

[Jaco Kroon]

Hi,

On 2024/06/21 15:15, kan...@gentoo.org wrote:


From: Matt Jolly 

The CURL_QUIC USE_EXPAND enables us to sanely manage QUIC (RFC 9000)
backends as they are added to cURL in the future: currently there are
two supported implementations, OpenSSL and ngtcp2,  however it's likely
that other popular TLS libraries will expose QUIC APIs over time,
and that these will be eventually be supported by cURL (see CURL_SSL
for examples of TLS libraries that we support) - we may as well
get ahead of the curve here.

There are already a number of other small players (i.e. OpenSSL Forks)
exposing QUIC support for quite a while, however these have not been
available in ::gentoo and we've only needed the one USE to enable
for HTTP/3 and QUIC to this point.

Signed-off-by: Matt Jolly 
---
  profiles/desc/curl_quic.desc | 7 +++
  1 file changed, 7 insertions(+)
  create mode 100644 profiles/desc/curl_quic.desc

diff --git a/profiles/desc/curl_quic.desc b/profiles/desc/curl_quic.desc
new file mode 100644
index ..372bb9ce8f83
--- /dev/null
+++ b/profiles/desc/curl_quic.desc
@@ -0,0 +1,7 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# This file contains descriptions of CURL_QUIC USE_EXPAND flags for 
net-misc/curl
+
+openssl - Use OpenSSL
+ngtcp2 - Use ngtcp2


May I suggest simply calling this USE_EXPAND QUIC_IMPL so that other 
packages can potentially re-use as well?


looking through ::gentoo at least net-dns/dnsdist and net-dns/knot also 
has a quic support, using ngtcp2 and/or net-libs/quiche.


With openssl 3.2 hopefully approaching stable at some point I suspect 
the number of projects that will be adding quic support via one or 
another channel (possibly with alternative implementations) will only 
increase, thus pinning the USE_EXPAND on a single package seems 
potentially short-sighted.


Kind regards,
Jaco

Re: [gentoo-dev] Imminent Python 3.12 switch reminder

[Jaco Kroon]

On 2024/05/30 17:56, orbea wrote:

On Thu, 30 May 2024 17:54:32 +0200
Michał Górny  wrote:


On Thu, 2024-05-30 at 08:09 -0700, orbea wrote:

This is a reoccurring theme and its driving away contributors. The
PR queue really should be taken care of.

Talk is cheap.


If I had the power to do it myself I would of already started to try to
reduce the load, but I don't. Do you want to grant me that power?


+1.

Realising even my own ebuilds can do with some work, but yes, as a PR 
this is the part of the process that I most look up to.  Even if PR 
maintainers that have been around can just be given rights to commit to 
their own (long maintained) packages, that would already help alleviate 
the queue.


Kind regards,
Jaco

Re: [gentoo-dev] default php-ext status

[Jaco Kroon]

Hi,

On 2024/04/22 18:49, Michael Orlitzky wrote:

On Mon, 2024-04-22 at 16:46 +0200, Jaco Kroon wrote:

Which in my *opinion* is not desirable behaviour, but I'm open for
discussion.

xdebug.mode = off by default, but the extension still gets loaded.

Not sure if there is a sensible "solution", further expanding USE flags
certainly is not a desirable option, so perhaps INSTALL_MASK
(per-package env) is the best solution ... ?

You can replace the symlinks with empty files. The package manager
should then refuse to overwrite them. It _looks_ wrong (why are these
non-active extensions in ext-active?), but it's the easiest solution.

I think the default should be for the extensions to be per-SAPI
disabled and for users to enable them by creating the symlinks. (The
"ext" and "ext-active" design screams this.) That would be an easy
change to php-ext-source-r3.eclass but risks breaking everyone's web
servers if we do it without news items and/or ewarnings.


eselect php-ext perhaps?Both to configure the defaults for new 
modules/sapi/version kind of thing (perhaps layered), and then hook into 
that from the eclass?



There's nobody in the PHP project at the moment. If you want to make an
-r4 of the eclass and handle the paperwork, by all means...


What?!?

Surprise!  Wish I had capacity for volunteering more time.  Happy to do 
drive-by's for PHP stuff we use, but definitely not in a position to "be 
the project" kind of thing.


Perhaps I can start off on an eselect-php-extensions package (or expand 
eselect-php?), and once at least one other party is happy with the *UI* 
component and how that works, we can update the eclass to use that 
rather than blindly installing the symlinks?


eselect php-ext list [version]
eselect php-ext enable {extension} [version] [sapi]
eselect php-ext disable {extension} [version] [sapi]

Where we have one "special extention" called _default_ and one special 
version called "all" (and sapi "all").  These shall be used for any 
tuple for which there is no explicit configuration, so for any specific 
(pkg, version, sapi) tuple we check in this order for available configs:


1. (pkg, version, sapi)
2. (pkg, all, sapi)
3. (pkg, version, all)
4. (pkg, all, all)
5-8. repeat of 1-4 but with _default_.

It's unclear what the preferred order for 2,3 should be, however, based 
on our requirements sapi should take priority over version as this will 
be the most common enable/disable in my experience.


Once that works, then eclass updates such that eclass doesn't install 
any symlinks for ext-active/ as part of pkg_install.


postinstall in eclass enumerates the relevant php versions for which the 
package was installed, along with sapi's and check which symlinks should 
be created.
prerm does opposite (assuming we're not replacing a version, since I 
believe postinstall would invoke prior to the old version's prerm?).


Possibly easier to just not remove symlinks in prerm but provide a 
eselect php-ext cleanup which will cleanup broken symlinks in /etc/php 
in postrm?


Also, a way to cleanup the stored configuration for enabled/disabled.

eclass maintains current behaviour if eselect-php-extensions is not 
installed (which may become a requirement later, but how do we handle 
users making manual additions/modifications to /etc/php/ or have some 
form of "fsck" for that?)


SLOT'ing here may require some careful handling since for example 
pecl-parallel had a version for php7* (pecl-parallel 1.1.*) and another 
fo php8* (1.2.*).


Don't think this is undo-able but it'll be a first for me so may be a 
few rounds of back&forth.


Kind regards,
Jaco

[gentoo-dev] default php-ext status

[Jaco Kroon]

Hi All,

For PHP modules that's getting installed, by default they all link 
ext/${modulename}.ini into ext-active/ such that all modules by default 
is active for all SAPIs.


Short of INSTALL_MASK, is there way to better control for sysadmins?

If I rm the symlinks, on next remerge they restore themselves:

plastiekpoot [16:43:09] /etc/php (master) # ls -lah */ext-active/xdebug.ini
lrwxrwxrwx 1 root root 17 Apr 22 15:36 
apache2-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini
lrwxrwxrwx 1 root root 17 Apr 22 15:36 cli-php8.1/ext-active/xdebug.ini 
-> ../ext/xdebug.ini
lrwxrwxrwx 1 root root 17 Apr 22 15:36 fpm-php8.1/ext-active/xdebug.ini 
-> ../ext/xdebug.ini
plastiekpoot [16:43:15] /etc/php (master) # rm 
apache2-php8.1/ext-active/xdebug.ini

plastiekpoot [16:43:21] /etc/php (master) # emerge -av xdebug
...
plastiekpoot [16:43:52] /etc/php (master) # ls -lah */ext-active/xdebug.ini
lrwxrwxrwx 1 root root 17 Apr 22 16:43 
apache2-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini
lrwxrwxrwx 1 root root 17 Apr 22 16:43 cli-php8.1/ext-active/xdebug.ini 
-> ../ext/xdebug.ini
lrwxrwxrwx 1 root root 17 Apr 22 16:43 fpm-php8.1/ext-active/xdebug.ini 
-> ../ext/xdebug.ini


Which in my *opinion* is not desirable behaviour, but I'm open for 
discussion.


xdebug.mode = off by default, but the extension still gets loaded.

Not sure if there is a sensible "solution", further expanding USE flags 
certainly is not a desirable option, so perhaps INSTALL_MASK 
(per-package env) is the best solution ... ?


Kind regards,
Jaco

Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management

[Jaco Kroon]

Hi Joonas,

On 2024/04/11 12:02, Joonas Niilola wrote:

Hey,

On 11.4.2024 9.14, Jaco Kroon wrote:

The latter can certainly be done and makes sense (only required if
you're using the fuse mount, so if USE=fuse at least).

The former doesn't make sense to do blindly in /etc/init.d/netmount
(which belongs to sys-apps/openrc, not glusterfs).


well I was thinking about putting that into glusterfs's init file.


Well, that's an obvious assumption now that I think about it, but 
incorrect for what I'm looking at.


There's two init scripts for glusterfs, glusterd and glusterfsd.

glusterfsd init script is being dragged along for historic purposes and 
comes from before I got involved, and I believe this was the way bricks 
were brought up prior to glusterfs version 3.0, and it does look like 
there is (u)mount stuff in there too.  This init script already has 
stuff for "need fuse" if it's mounting a glusterfs filesystem.  It looks 
interesting even now for *mounting* file systems, but in my opinion not 
for managing volumes.


IMHO the more modern/better way is to bring up glusterd on nodes that 
*host* the volumes, ie, where bricks reside, and to then mount 
filesystems from /etc/fstab using netmount as part of mounting all 
network filesystem.  Otherwise you need to duplicate the init config for 
every mountpoint and specify a large number of arguments in those ... in 
my opinion it just gets messy quite quickly.


glusterd then manages starting/stopping of brick, shd and other 
processes related to any volumes.


netmount handles mounting of network (including glusterfs) filesystems.

In many scenarios the storage nodes and those that consume them are 
independent.  In this scenario glusterd (along with bricks and shd's) 
will run on the storage nodes but not on the "compute" nodes, and there 
is no dependency between glusterd and netmount.


glusterd does need to start before netmount if (and only if) there are 
glusterfs mounts in /etc/fstab that depends on the local glusterd for 
finding volume information.  This is hard(ish) to determine (reliably), 
but given "fstabinfo" in openrc-run I could amend /etc/init.d/glusterd's 
depend to do "before netmount" iff there are filesystems in /etc/fstab 
that's relevant.  We don't (currently) have such deployments, and we 
generally do have glusterfs mounts where we run bricks, even if only to 
be able to inspect what's going on in the "constructed" filesystem, so 
the explicit "before netmount" in glusterd doesn't bother me too much 
personally (even if it starts before netmount and it's not needed, who 
cares?  So lots of effort for little gain).


glusterfs and fuse.glusterfs has already been added into 
/lib/rc/rc-functions.sh.  So technically I no longer need to flag my 
mounts with _netdev.


Incidentally:  I *suspect* the noauto detection in netmount's depend 
will only work if noauto is the *first* option for any given nfs mountpoint.


Anyway, I would thus like to suggest two "tweaks" to openrc here:

1.  net_fs_list needs to become more dynamic such that other packages 
(such as glusterfs) can add to the list dynamically.

2.  packages should be allowed to hook into netmount's depend() phase.

If 2 isn't acceptable, I'll just send the desired changes for 2 directly 
into openrc as a PR, and that kinda makes point 1 pointless as well.


Kind regards,
Jaco

Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management

[Jaco Kroon]

Hi Joonas,

Thanks for the below.  Further comments there.

On 2024/04/11 07:11, Joonas Niilola wrote:


On 8.4.2024 12.51, Jaco Kroon wrote:

In order for glusterfs to mount successfully the fuse module needs to be
available when mount.glusterfs is invoked.  This can be achieved in one
of two ways:

1.  Compile the module statically into the kernel.
2.  Arrange for fuse service to be started prior to netmount (using say
/etc/conf.d/netmount rc_need="fuse")


3. Add "/sbin/modprobe -q fuse" to the init.d file's start_pre()
function, ExecStartPre with systemd, and make the ebuild warn about
CONFIG_FUSE_FS with linux-info.eclass.


The latter can certainly be done and makes sense (only required if 
you're using the fuse mount, so if USE=fuse at least).


The former doesn't make sense to do blindly in /etc/init.d/netmount 
(which belongs to sys-apps/openrc, not glusterfs).


If you look at /etc/init.d/netmount it has some special logic in 
depend() to want nfsclient if (and only if) there is at least one 
filesystem with fs type nfs or nfs4.


The logic for depending on /etc/init.d/fuse should be similar, but I 
don't think it makes sense to keep indefinitely expanding that depend() 
for every possible future filesystem that may have some special need 
like this.  So I think what we should rather do is find all fstab 
entries with _netdev and !noauto's fstype, and iterate those and add the 
relevant want's from there (for openrc at least), in some mechanisms 
where packages other than openrc can *supply* the relevant dependency 
list (eg, glusterfs package would say that it want's net, dns and fuse).


Something similar for systemd would be great, but I'd have to study up 
on systemd a bit before I can comment in greater detail.


At an absolute minimum I think we should amend netmount to add "use 
fuse" such that if fuse is added to the relevant runlevels it will start 
before netmount (and then I an arrange that  message be added to the 
glusterfs ebuild that fuse should be added to the default (where 
netmount is) runlevel).  As it is one can rc_need=fuse in 
/etc/conf.d/netmount, or rc_use=fuse and add fuse to default runlevel, 
but I believe we can do better than either of these options.


Kind regards,
Jaco

[gentoo-dev] netmount and glusterfs (fuse) dependency management

[Jaco Kroon]

Hi All,

I was hoping for some advise regarding how I could improve the glusterfs 
package for users (and myself).  At least those using openrc, but I 
suspect similar may be applicable to systemd, but I have no idea how 
systemd handles network mounts so perhaps someone could chip in here on 
that front too.


Specifically the mounting of glusterfs file systems currently has a few 
problems (glusterd if server=localhost, network, dns(?) and fuse 
availability).  For now the focus is on the fuse aspect since that's the 
biggest annoyance by far.


Mounting happens via the netmount service.

In order for glusterfs to mount successfully the fuse module needs to be 
available when mount.glusterfs is invoked.  This can be achieved in one 
of two ways:


1.  Compile the module statically into the kernel.
2.  Arrange for fuse service to be started prior to netmount (using say 
/etc/conf.d/netmount rc_need="fuse")


I make note that there is specific code in /etc/init.d/netmount in 
depend() to handle nfsclient (if there are any nfs and nfs4 mounts it 
automatically (unless if the filesystems are also labaled noauto) to 
want nfsclient.


Two questions:

1.  Would a PR against https://github.com/openrc/openrc/ to add special 
case code for glusterfs into netmount have a reasonable chance of being 
accepted?  I don't like this, it just pushes towards an ever-growing 
list of special cases, but it's possibly preferable to having users to 
figure out they need to edit /etc/conf.d/netmount to add rc_need="fuse" ?


2.  Would it not be an improvement to consider having a more generic 
mechanism for other packages to add dependency requirements for 
netmount, for example:


/etc/netmound.depend.d/glusterfs(.sh?) could contain a function called 
depend_glusterfs() { } which gets invoked if a glusterfs filesystem will 
want to be mounted, which I would suggest would have something like:


depend_glusterfs()
{
    use glusterd
    need net fuse
}

Then if the answer to 2 is yes (which I feel it would be), then a few 
implementation details (Will attempt a PR):


What would be the best location for having these files dropped? 
Generally I'd say let's stay out of /etc/ for this since these are 
system-controlled dependencies, however, some users may have things 
rigged and may want to be able to edit or even outright ignore these 
dependencies ... ?


/lib/netmount.dependencies.d/ being over-shadowed by 
/etc/netmount.dependencies.d?


So any file for which an equivalent in /etc/netmount.dependencies.d/ 
exist is ignored in /lib/ (similar to udev/rules.d)?


Source all files in those locations, or try them based on filesystem 
types to be mounted only (first /etc then /lib variants)?


Kind regards,
Jaco

[gentoo-dev] mirror storage growth rate

[Jaco Kroon]

Hi All,

I was messing with some storage related caching on some of our hosts 
this morning when I wondered about how much storage the gentoo mirrors 
were consuming.  I'm not too worried about the current storage, but I am 
noticing that the storage requirements are creeping quite a bit (as per 
attached), and if that growth rate continues it may become a problem 
*eventually*.


Can this growth be explained?

Is it expected to continue at this rate?

Kind regards,
Jaco

Re: [gentoo-dev] Last rites: app-admin/fluentd

[Jaco Kroon]

Hi Sam,

On 2024/01/10 13:02, Sam James wrote:

Jaco Kroon  writes:


How critical is it that they do?
Even for the bump PR they do not, they fail with the below, and
frankly my knowledge of ruby is outright scary.  The below to me
indicates that the tests are designed specifically to run from a git
checkout, there are two possible "fixes":

1.  patch the code to not require this.
2.  disable tests.


Looking at the code it's simply looking for the .git folder, so mkdir 
/.git may circumvent this problem if we can solve the below.





Test phase: app-admin/fluentd-1.16.3

  * Running test phase for ruby31
[...]
[...]
:85:in
`require': cannot load such file -- rr (LoadError)

Try adding a test dep on dev-ruby/rr.


Tests are busy running now.  Seem to be slow.  Updated ebuild pushed to 
the PR.  Will advise test outcome on the PR.


Someone will probably need/want to look at this circular dependency at 
some point.


 * Error: circular dependencies:

(dev-ruby/rspec-expectations-3.12.3:3/3::gentoo, ebuild scheduled for 
merge) depends on
 (dev-ruby/rspec-3.12.0:3/3::gentoo, ebuild scheduled for merge) 
(buildtime)
  (dev-ruby/rspec-expectations-3.12.3:3/3::gentoo, ebuild scheduled for 
merge) (buildtime)


[test] for each depends on the other, so setting a global FEATURES=test 
breaks things.  I don't think this is a critical issue.




Anyway, if it works for you in production, and you're willing to
(reluctantly) adopt it, then we can work on the tests later.


"no choice", so please do proceed to merge the PR.

Kind regards,
Jaco

Re: [gentoo-dev] Last rites: app-admin/fluentd

[Jaco Kroon]

Hi,

On 2024/01/09 13:42, Michał Górny wrote:

On Tue, 2024-01-09 at 12:54 +0200, Jaco Kroon wrote:

https://github.com/gentoo/gentoo/pull/34126 ??

Perhaps I'm missing something if you say it's non-trivial but we're
using that on 9 hosts currently.


Do tests pass for you?  https://bugs.gentoo.org/879181#c2 indicated that
they do not.


How critical is it that they do?

Even for the bump PR they do not, they fail with the below, and frankly 
my knowledge of ruby is outright scary.  The below to me indicates that 
the tests are designed specifically to run from a git checkout, there 
are two possible "fixes":


1.  patch the code to not require this.
2.  disable tests.

>>> Test phase: app-admin/fluentd-1.16.3
 * Running test phase for ruby31
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
/usr/bin/ruby31 -w -I"lib:test" -Eascii-8bit:ascii-8bit 
/usr/lib64/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/command/test_binlog_reader.rb" "test/command/test_ca_generate.rb" 
"test/command/test_cap_ctl.rb" "test/command/test_cat.rb" 
"test/command/test_ctl.rb" "test/command/test_fluentd.rb" 
"test/command/test_plugin_config_formatter.rb" 
"test/command/test_plugin_generator.rb" 
"test/compat/test_calls_super.rb" "test/compat/test_parser.rb" 
"test/config/test_config_parser.rb" "test/config/test_configurable.rb" 
"test/config/test_configure_proxy.rb" "test/config/test_dsl.rb" 
"test/config/test_element.rb" "test/config/test_literal_parser.rb" 
"test/config/test_plugin_configuration.rb" "test/config/test_section.rb" 
"test/config/test_system_config.rb" "test/config/test_types.rb" 
"test/counter/test_client.rb" "test/counter/test_error.rb" 
"test/counter/test_mutex_hash.rb" "test/counter/test_server.rb" 
"test/counter/test_store.rb" "test/counter/test_validator.rb" 
"test/log/test_console_adapter.rb" "test/plugin/in_tail/test_fifo.rb" 
"test/plugin/in_tail/test_io_handler.rb" 
"test/plugin/in_tail/test_position_file.rb" 
"test/plugin/out_forward/test_ack_handler.rb" 
"test/plugin/out_forward/test_connection_manager.rb" 
"test/plugin/out_forward/test_handshake_protocol.rb" 
"test/plugin/out_forward/test_load_balancer.rb" 
"test/plugin/out_forward/test_socket_cache.rb" 
"test/plugin/test_bare_output.rb" "test/plugin/test_base.rb" 
"test/plugin/test_buf_file.rb" "test/plugin/test_buf_file_single.rb" 
"test/plugin/test_buf_memory.rb" "test/plugin/test_buffer.rb" 
"test/plugin/test_buffer_chunk.rb" 
"test/plugin/test_buffer_file_chunk.rb" 
"test/plugin/test_buffer_file_single_chunk.rb" 
"test/plugin/test_buffer_memory_chunk.rb" 
"test/plugin/test_compressable.rb" "test/plugin/test_file_util.rb" 
"test/plugin/test_filter.rb" "test/plugin/test_filter_grep.rb" 
"test/plugin/test_filter_parser.rb" 
"test/plugin/test_filter_record_transformer.rb" 
"test/plugin/test_filter_stdout.rb" "test/plugin/test_formatter_csv.rb" 
"test/plugin/test_formatter_hash.rb" 
"test/plugin/test_formatter_json.rb" 
"test/plugin/test_formatter_ltsv.rb" 
"test/plugin/test_formatter_msgpack.rb" 
"test/plugin/test_formatter_out_file.rb" 
"test/plugin/test_formatter_single_value.rb" 
"test/plugin/test_formatter_tsv.rb" "test/plugin/test_in_debug_agent.rb" 
"test/plugin/test_in_exec.rb" "test/plugin/test_in_forward.rb" 
"test/plugin/test_in_gc_stat.rb" "test/plugin/test_in_http.rb" 
"test/plugin/test_in_monitor_agent.rb" 
"test/plugin/test_in_object_space.rb" "test/plugin/test_in_sample.rb" 
"test/plugin/test_in_syslog.rb" "test/plugin/test_in_tail.rb" 
"test/plugin/test_in_tcp.rb" "test/plugin/test_in_udp.rb" 
"test/plugin/test_in_unix.rb" "test/plugin/test_input.rb" 
"test/plugin/test_metadata.rb" "test/plugin/test_metrics.rb" 
"test/plugin/test_metrics_local.rb" "test/plugin/test_multi_output.rb" 
"test/plugin/test_out_copy.rb" "test/plugin/test_out_exec.rb" 
"test/plugin/test_out_exec_filter.rb" "test/plugin/test_out_file.rb" 
"test/plugin/test_out_forward.rb" "test/plugin/test_out_http.rb" 
"test/plugin/test_out_null.rb" "test/plugin/test_out_re

Re: [gentoo-dev] Last rites: app-admin/fluentd

[Jaco Kroon]

https://github.com/gentoo/gentoo/pull/34126 ??

Perhaps I'm missing something if you say it's non-trivial but we're 
using that on 9 hosts currently.


On 2023/12/31 12:34, Michał Górny wrote:


# Michał Górny  (2023-12-31)
# Unresolved vulnerability.  The current version is from 2022-03,
# and the bump is non-trivial.
# Removal on 2024-01-30.  Bug #879181.
app-admin/fluentd

[gentoo-dev] Re: Last rites: net-misc/drive

[Jaco Kroon]

Hi,

net-misc/insync::ppfeufer-gentoo-overlay is a sensible albeit 
proprietary alternative.


Kind regards,
Jaco

On 2023/11/13 00:08, Zac Medico wrote:


commit ba6f1c6fd9b9434bd2c07cf7233ee38cb6ab430a
Author: Brian Harring 
AuthorDate: 2023-11-09 20:51:11 -0800
Commit: Zac Medico 
CommitDate: 2023-11-09 21:59:23 -0800

    net-misc/drive: treeclean

    Dead upstream and fully broken since 2023-02 due to google
    auth changes.

    Closes: https://bugs.gentoo.org/658028
    Closes: https://bugs.gentoo.org/903862
    Signed-off-by: Brian Harring 
    Closes: https://github.com/gentoo/gentoo/pull/33751
    Signed-off-by: Zac Medico 

[gentoo-dev] Re: Standard parsable format for profiles/package.mask file

[Jaco Kroon]

Hi,

On 2023/09/22 13:16, Florian Schmaus wrote:

On 21/09/2023 21.40, Arthur Zamarin wrote:

If this is a last-rite message, the last line must list the last-rite
last date (removal date) and the last-rite bug number. You can also list


FWIW, I would assume the last-rite date to be the date where the 
package's last rites where initiated, i.e., where it was p.masked. The 
removal date would be the date on which the packages was cleaned from 
the tree.



other bugs relevant to the last-rite. So I think a format of: "Removal
on ${REMOVAL_DATE}.


I now we, myself included, often wrote "Removal on…", however, I 
wonder if we should reflect reality and write "Removal after…" instead.


+1

"on or after" would probably be most accurate though but gets very wordy.

Kind regards,
Jaco

Re: [gentoo-dev] Help wanted with net-misc/frr maintenance

[Jaco Kroon]

Hi Alarig,

On 2023/07/12 15:18, Alarig Le Lay wrote:

Hello Jakov,

On Wed 12 Jul 2023 10:54:47 GMT, Jakov Smolić wrote:

Hi all,
I was recently left as the sole maintainer of net-misc/frr and given I'm
not actively using the package anymore it would be good if someone who
is an active user could take over. There are several open bugs and a new
upstream release.

I can stay as a secondary maintainer and help out (non-Gentoo developers
are also welcome, I can proxy for you), otherwise if no one is
interested I'll drop the package to maintainer-needed soon.

Regards,

I’m already maintaining bird, so I could happily step in for frr as
well!
Happy to assist where I can.  For the most part frr "just works" for us 
though.  Also not something we like to upgrade on a frequent basis 
unless there is a specific reason to.


Kind Regards,
Jaco

Re: [gentoo-dev] [PATCH] cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR}

[Jaco Kroon]

Hi,

On 2023/06/26 12:36, Ulrich Mueller wrote:

On Mon, 26 Jun 2023, Sam James wrote:

+
+   # Avoid creating ${WORKDIR}_build (which is above WORKDIR).
+   # TODO: For EAPI > 8, we should ban S=WORKDIR for CMake.
+   # See bug #889420.
+   if [[ ${S} == ${WORKDIR} && ${BUILD_DIR} == ${WORKDIR}_build ]] 
; then

I'd suggest adding quotes to the RHS of the expression, to prevent
globbing.

But I think what you really want is to check whether ${BUILD_DIR}
(whatever its name is) is a subdirectory of ${WORKDIR}? Maybe a test
like this would make that intent clearer:

 if [[ ${BUILD_DIR} != "${WORKDIR}"/* ]]; then


BUILD_DIR="${WORKDIR}/../build"

I know it's pathological ... but still.  readlink -f should be 
considered here unless it can be guaranteed that BUILD_DIR will not 
contain .. components at this stage.


Kind Regards,
Jaco

Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm-mini-greeter and x11-misc/xautolock

[Jaco Kroon]

Hi Orbea,

My time availability is somewhat constrained at the moment, but, also 
given Hans's response to my email, happy to assist or even co-maintain.


Kind regards,
Jaco

On 2023/06/21 18:36, orbea wrote:

On Wed, 21 Jun 2023 16:23:38 +0200
Jaco Kroon  wrote:


Hi Hans,

On 2023/06/17 10:12, Hans de Graaff wrote:

After migrating to Wayland I no longer have a need for these X
packages. I have already removed myself as maintainer.

x11-misc/xautolock

Has one open bug that should be addressed upstream, but upstream is
pretty much dead: https://bugs.gentoo.org/634766

I refer to an email 2022/07/19 where you took over xautolock from
Jonas, now you're dropping it.  Doesn't look like much work was
required since

I use xautolock and am willing to look at any pressing build issues if
they arise.


I'm still using this - you have moved to wayland so no longer a
problem for you.

  From the referenced bug report it looks like there isn't much "care"
for the package any more?

Assuming m...@scarlet.be is no longer responsive either?

  From commit 0da382f0a5c38cce6e70a3724471a6c7981730d7 it looks like
there's some possible compile/build issues.

This commit talks about how using imake is problematic and while I
entirely agree with that, it may not be trivial to write a new build
system. I'll take a look later if I find time and motivation.


Kind regards,
Jaco

Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm-mini-greeter and x11-misc/xautolock

[Jaco Kroon]

Hi Hans,

On 2023/06/17 10:12, Hans de Graaff wrote:

After migrating to Wayland I no longer have a need for these X
packages. I have already removed myself as maintainer.

x11-misc/xautolock

Has one open bug that should be addressed upstream, but upstream is
pretty much dead: https://bugs.gentoo.org/634766


I refer to an email 2022/07/19 where you took over xautolock from Jonas, 
now you're dropping it.  Doesn't look like much work was required since


I'm still using this - you have moved to wayland so no longer a problem 
for you.


From the referenced bug report it looks like there isn't much "care" 
for the package any more?


Assuming m...@scarlet.be is no longer responsive either?

From commit 0da382f0a5c38cce6e70a3724471a6c7981730d7 it looks like 
there's some possible compile/build issues.


Kind regards,
Jaco

[gentoo-dev] last-rite: net-voip/captagent

[Jaco Kroon]

# Jaco Kroon  (2022-12-14)
# Multiple open bugs (bug #870910, bug #877731, bug #884815), only one 
of which

# is trivial to solve.
# With more and more SIP traffic using TLS rather than plaintext UDP or TCP
# this is fast becoming less and less useful.  You should rather use
# asterisk's res_hep which can also report encrypted SIP and RTP to any HEP
# compatible reporting tool (including Homer).
# I'm no longer using this and don't recommend it's use, if you want 
this to be
# unmasked again, please contact me so that we can figure out how to 
approach

# maintenance thereof.
# Removal on 2023-01-31.
net-voip/captagent

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

Hi,

On 2022/11/10 16:24, John Helmert III wrote:

On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon wrote:

Hi,

On 2022/11/10 06:13, John Helmert III wrote:

   - Drop synopsis and description fields. These fields contain the same
     information and will be superceded by the existing impact field.

Well, I'm not saying "no" but it feels a bit weird reading a GLSA that
doesn't say a word what the problem is but specifies impact.

You're right, but with 19 CVEs (for example), is anyone really
interested in hearing about the problem that caused each of the 19
issues? In the current format we've resorted to writing descriptions
like...

Actually yes!  Also a way to check whether my specific configuration is
vulnerable for this specific CVE, something like "If you're setting
foo=bar in /etc/pkg.conf your system is vulnerable, if you've got
foo=phew you're most likely fine".  Obviously we could rely a bit more
on package maintainers (myself included) to provide these.

That would greatly increase the care necessary for us to release a
GLSA. It's already a big pain (even with the new GLSAMaker being a
huge improvement over the old one), and I'd like to make it less of a
pain. Maybe a proxy for this information for you would be the "type"
field of the impact?


Fair enough at pain.  Limited people, limited resources.  I do think 
that package maintainers should get involved in the process though, to 
help provide this information, but this should not cause delays in 
getting the GLSAs released.  Even if the GLSA gets updated on a future 
iteration to add some of this information.


What I'm after is being able to quickly decide (since we sometimes see a 
fair number of of GLSAs coming in around the same time, affecting 
different systems, with variable degrees of "exposedness" and need to be 
able to prioritise which systems to update first) whether we can 
(relatively) safely ignore a GLSA (at least temporarily).





I don't think I've seen a single "workaround" and usually the text here
just says "No known workaround", where the reality is that for something
like asterisk just not using the affected module is good enough.  So
workaround:  "Don't use chan_sip, use chan_pjsip instead" would be
perfectly fine here.

One could thus also link GLSA issues to specific USE flags, taking
asterisk again, let's say the problem is with the http web server having
a buffer overflow in the http basic authenticator, then if that embedded
server isn't even compiled in, how can the package be vulnerable?  So
here vulnerable would be something like

The "atom" attribute of each constraint is using atom syntax, so along
with that we get the ability to specify USE exactly like
"asterisk-16.X.Y:16[http]".


A mechanism to QUERY which installed packages are affected by known
GLSA's would also be tremendously helpful.

Like glsa-check?
We currently use that, but it really just says which GLSAs are 
applicable to the system, it doesn't tell me net-misc/asterisk-16.0.1:16 
- we've got ways of working from the glsa-check output to that.  Of 
particular annoyance if a GLSA lists multiple packages, of which you 
have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I can 
quite quickly determine that emerge -1av net-misc/asterisk:16 will 
resolve the problem with the lowest possible risk of breakage to other 
components on the system, and without having to perform a full update.

Multiple vulnerabilities have been discovered in $PACKAGE. Please
review the CVE identifiers referenced below for details.

... simply because it's infeasible (and in my opinion, not really
necessary) for us to enumerate the issues in this way. Also, I note
that the section being called "impact" doesn't preclude us from
incorporating text that we would currently put in the "description" or
"synopsis" fields.

Of course giving the full details in the GLSA is a pain in the backside,
is there a way to retrieve this information automatically from the CVE
database?  In other words, just get the blurp from there and include it
here.  It won't give full details, but at least it will give some extra
details not currently available.  Effectively we choose to ignore
certain GLSAs if we consider their impact to be low.

We could import CVE descriptions, but then we'd end up with a huge
wall of mostly useless text, such as CVE-2021-35648's:

Vulnerability in the MySQL Server product of Oracle MySQL (component:
Server: FTS). Supported versions that are affected are 8.0.26 and
prior. Easily exploitable vulnerability allows high privileged
attacker with network access via multiple protocols to compromise
MySQL Server. Successful attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently rep

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

Hi Sam,

On 2022/11/10 12:19, Sam James wrote:


One could thus also link GLSA issues to specific USE flags, taking asterisk again, let's say the problem is with 
the http web server having a buffer overflow in the http basic authenticator, then if that embedded server isn't 
even compiled in, how can the package be vulnerable?  So here vulnerable would be something like 

The problem with this is, there's a high cost associated with getting it wrong. A 
"workaround" is accepted to have some level of fuzziness (we always try to be 
accurate, but it's not the same as saying something is absolutely not vulnerable with 
USE=-foo).

But I guess if a library totally isn't used then we can be sure sometimes. Not 
sure now! I welcome more thoughts on this.


In the specific example I can most certainly make that assertion, 
assuming of course I verify that the code is in fact in that library, as 
you say.  So if res_http in this case creates the buffer instead of 
dynamically allocating it, or performing bounds checks, and not the 
common digest code, then I can state that with 100% certainty.  But yes, 
this may or may not be a good idea, it's an idea/concept.  Michał 
suggested just using the ebuild syntax, which would imply this becomes 
available.



A mechanism to QUERY which installed packages are affected by known GLSA's 
would also be tremendously helpful.


Multiple vulnerabilities have been discovered in $PACKAGE. Please
review the CVE identifiers referenced below for details.

... simply because it's infeasible (and in my opinion, not really
necessary) for us to enumerate the issues in this way. Also, I note
that the section being called "impact" doesn't preclude us from
incorporating text that we would currently put in the "description" or
"synopsis" fields.

Of course giving the full details in the GLSA is a pain in the backside, is 
there a way to retrieve this information automatically from the CVE database?  
In other words, just get the blurp from there and include it here.  It won't 
give full details, but at least it will give some extra details not currently 
available.  Effectively we choose to ignore certain GLSAs if we consider their 
impact to be low.

1. I really welcome your input here, as we're trying to figure out what people 
actually want from GLSAs vs what is just noise for both them & us.

My pleasure.  Really enjoy having these discussions.


2. I think this should be possible, but is it substantially more valuable than 
doing the reference links like we do now? What if there's absolutely tonnes 
like 20+?


Then I'd be following 20+ links :).  I'd rather get that information in 
one place, even if it is a longer read.  Perhaps pointless to put this 
in the GLSA XML structure, but glsa-check can perhaps just get an option 
extra to -d to "retrieve and display CVE information additionally".  
Re-use the -c that's currently used with -l.  That way even with 20+ 
CVEs I can get glsa-check to fetch the information rather than having to 
follow the links and decoding the usually cryptic information there on a 
case-by-case basis.  Or an option to pass the url's to a command, eg "-u 
firefox" which will then execute "firefox ${url}" for every referenced URL.


-d and -l could perhaps learn to output xml and/or json and/or the other 
format Michał mentioned.



It would also help a great deal to automate that if the CVE scores and the 
"inputs" into that could be made available, eg, CVE score 7.0, remote=yes/no, 
 (And I'm fairly certain importing this from the CVE database should be possible).


Yeah, we've talked about this before as well.

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

Hi,

On 2022/11/10 11:40, Matthew Smith wrote:


Hi,

On 10/11/2022 08:43, Jaco Kroon wrote:
A mechanism to QUERY which installed packages are affected by known 
GLSA's would also be tremendously helpful.


You can use glsa-check for this, which comes with portage: 
https://wiki.gentoo.org/wiki/Portage#glsa-check


Very useful for human-readable, not so much for integration into other 
systems :).


We currently parse a lot of that using things like awk etc ... but 
thinking about it now, one could probably dig into the xml stuff 
directly, so use glsa-check -l to get the list, then find the xml files 
and query those using tools more suited for that.


Thank you :).

Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

Hi,

On 2022/11/10 06:13, John Helmert III wrote:

  - Drop synopsis and description fields. These fields contain the same
    information and will be superceded by the existing impact field.

Well, I'm not saying "no" but it feels a bit weird reading a GLSA that
doesn't say a word what the problem is but specifies impact.

You're right, but with 19 CVEs (for example), is anyone really
interested in hearing about the problem that caused each of the 19
issues? In the current format we've resorted to writing descriptions
like...
Actually yes!  Also a way to check whether my specific configuration is 
vulnerable for this specific CVE, something like "If you're setting 
foo=bar in /etc/pkg.conf your system is vulnerable, if you've got 
foo=phew you're most likely fine".  Obviously we could rely a bit more 
on package maintainers (myself included) to provide these.


I don't think I've seen a single "workaround" and usually the text here 
just says "No known workaround", where the reality is that for something 
like asterisk just not using the affected module is good enough.  So 
workaround:  "Don't use chan_sip, use chan_pjsip instead" would be 
perfectly fine here.


One could thus also link GLSA issues to specific USE flags, taking 
asterisk again, let's say the problem is with the http web server having 
a buffer overflow in the http basic authenticator, then if that embedded 
server isn't even compiled in, how can the package be vulnerable?  So 
here vulnerable would be something like 
which then also indicates the "fixed" versions, as has been pointed out 
"affected" and "not affected" are inverses.


A mechanism to QUERY which installed packages are affected by known 
GLSA's would also be tremendously helpful.




Multiple vulnerabilities have been discovered in $PACKAGE. Please
review the CVE identifiers referenced below for details.

... simply because it's infeasible (and in my opinion, not really
necessary) for us to enumerate the issues in this way. Also, I note
that the section being called "impact" doesn't preclude us from
incorporating text that we would currently put in the "description" or
"synopsis" fields.


Of course giving the full details in the GLSA is a pain in the backside, 
is there a way to retrieve this information automatically from the CVE 
database?  In other words, just get the blurp from there and include it 
here.  It won't give full details, but at least it will give some extra 
details not currently available.  Effectively we choose to ignore 
certain GLSAs if we consider their impact to be low.


It would also help a great deal to automate that if the CVE scores and 
the "inputs" into that could be made available, eg, CVE score 7.0, 
remote=yes/no,  (And I'm fairly certain importing this from the CVE 
database should be possible).


Of course, someone has to do the work, and the current status quo 
doesn't irritate me enough to free up cycles to fix it, but if the above 
could be (partially) accommodated that would be really, really great, if 
not, no harm done.


Much appreciate that there is work being done in this area.

Kind Regards,
Jaco

Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

[Jaco Kroon]

Hi,

On 2022/09/30 16:53, Florian Schmaus wrote:
> jkroon@plastiekpoot ~ $ du -sh /var/db/repos/gentoo/
>> 644M    /var/db/repos/gentoo/
>>
>> I'm not against exploding this by another 200 or even 300 MB personally,
>> but I do agree that pointless bloat is bad, and ideally we want to
>> shrink the size requirements of the portage tree rather than enlarge.
>
> What is the problem if it is 400 MB more? ? What if we double the
> size? Would something break for you? Does that mean we should not add
> more packages to ::gentoo? Where do you draw the line? Would you
> rather have interested persons contribute to Gentoo or drive them away
> due the struggle that the EGO_SUM deprecation causes?
How long is a piece of string?

I agree with you entirely.  But if the tree gets to 10GB?

At some point it may be worthwhile to split the tree similar to what
Debian does (or did, haven't checked in a while) where there is a core,
non-core repo etc ... except I suspect it may be better to split into
classes of packages, eg, x11 (aka desktop) style packages etc, and keep
::gentoo primarily to system stuff (which is also getting harder and
harder to define).  And this also makes it harder for maintainers.  And
this is really already what separate overlays does except the don't (as
far as I know) have the rigorous QA that ::gentoo has.

But again - at what point do you do this - and this also adds extra
burden on maintainers and developers alike.

And of course I could set a filter to not even --sync say /x11-* at
all.  For example.  Or /dev-go or /dev-php etc ...

So perhaps you're right, this is a moot discussion.  Perhaps we should
just say let's solve the problem when (if?) people complain the tree is
too big.  No, I'm not being sarcastic, just blunt (;

The majority of Gentoo users (in my experience) are probably of the
developer oriented mindset either way, or have very specific itches that
need scratching that's hard to scratch with other distributions.  Let's
face it, Gentoo to begin with should probably not be considered an
"easy" distribution.  But it is a highly flexible, pro-choice, extremely
customizable, rolling release distribution.  Which scratches my itch.

Incidentally, the only categories currently to individually exceed 10MB
are these:

11M    media-libs
11M    net-misc
12M    dev-util
13M    dev-ruby
16M    dev-libs
30M    dev-perl
31M    dev-python

And by far the biggest consumer of space:

124M    metadata

Kind Regards,
Jaco

Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

[Jaco Kroon]

Hi All,

This doesn't directly affect me. Nor am I familiar with the mechanisms.

Perhaps it's worthwhile to suggest that EGO_SUM itself may be
externalized.  I don't know what goes in here, and this will likely
require help from portage itself, so may not be directly viable.

What if portage had a feature whereby a SRC_URI list could be downloaded
as a SRC_URI itself?  In other words:

SRC_URI_INDIRECT="https://wherever/lists_for_some_go_package.txt";

Where that file itself contains lines for entries that would normally go
into SRC_URI (directly or indirectly via EGO_SUM from what I can
deduce).  Something like:

https://www.upstream.com/downloads/package-version.tar.gz =>
fneh.tar.gz|manifest portion goes here

Where manifest portion would assume DIST and fneh.tar.gz, so would start
with the filesize in bytes, followed by checksum value pairs as per
current Manifest files.

Since users may want to know how big the downloads for a specific ebuild
is, some process to generate these external manifests may be in order,
and to subsequently store the size of these indirect downloads
themselves in the local manifest, so in the local Manifest, something like:

IDIST lists_for_some_go_package.txt direct_size indirect_size CHECKSUM
value CHECKSUM value.

I realise this idea isn't immediately feasible, and perhaps not at all,
presented here since perhaps it could spark an idea for someone else. 
It sounds like this is the problem that the vendor tarball tries to
solve, but that that introduces a trust issue - not sure this exactly
goes away but at a minimum we're now verifying download locations again
(as per EGO_SUM or just SRC_URI in general) rather than code tarballs
containing many many times more code than download locations.

Given:

jkroon@plastiekpoot ~ $ du -sh /var/db/repos/gentoo/
644M    /var/db/repos/gentoo/

I'm not against exploding this by another 200 or even 300 MB personally,
but I do agree that pointless bloat is bad, and ideally we want to
shrink the size requirements of the portage tree rather than enlarge.

Kind Regards,
Jaco

On 2022/09/30 15:57, Florian Schmaus wrote:

> On 28/09/2022 23.23, John Helmert III wrote:
>> On Wed, Sep 28, 2022 at 05:28:00PM +0200, Florian Schmaus wrote:
>>> I would like to continue discussing whether we should entirely
>>> deprecate
>>> EGO_SUM without the desire to offend anyone.
>>>
>>> We now have a pending GitHub PR that bumps restic to 0.14 [1].
>>> Restic is
>>> a very popular backup software written in Go. The PR drops EGO_SUM in
>>> favor of a vendor tarball created by the proxied maintainer. However, I
>>> am unaware of any tool that lets you practically audit the 35 MiB
>>> source
>>> contained in the tarball. And even if such a tool exists, this would
>>> mean another manual step is required, which is, potentially, skipped
>>> most of the time, weakening our user's security. This is because I
>>> believe neither our tooling, e.g., go-mod.eclass, nor any Golang
>>> tooling, does authenticate the contents of the vendor tarball against
>>> upstream's go.sum. But please correct me if I am wrong.
>>>
>>> I wonder if we can reach consensus around un-depreacting EGO_SUM, but
>>> discouraging its usage in certain situations. That is, provide EGO_SUM
>>> as option but disallow its use if
>>> 1.) *upstream* provides a vendor tarball
>>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer
>>> maintains the package
>>> 3.) the number of EGO_SUM entries exceeds 1500 and a proxied maintainer
>>> maintains the package
>>
>> I'm not sure I agree on these limits, given the authenticity problem
>> exists regardless of how many dependencies there are.
>
> It's not really about authentication, you always have to trust
> upstream to some degree (unless you audit every line of code). But I
> believe that code distributed via official channels is viewed by more
> eyes and significantly more secure.
>
> EGO_SUM entries are directly fetched from the official distribution
> channels of Golang. Hence, there is a higher chance that malicious
> code in one of those is detected faster, simply because they are
> consumed by more entities. Compared to the dependency tarball that is
> just used by Gentoo. In contrast to the official sources, "nobody" is
> looking at the code inside the tarball.
>
> For proxied packages, where the dependency tarball is published by the
> proxied maintainer, the tarball also allows another entity to inject
> code into the final result of the package. And compared to a few small
> patches in FILESDIR, such a dependency tarball requires more effort to
> review. This further weakens security in comparison to EGO_SUM.
>
> - Flow

Re: [gentoo-dev] Add systemd/merged-usr profiles

[Jaco Kroon]

Hi,

On 2022/08/31 19:38, Mike Gilbert wrote:
> On Wed, Aug 31, 2022 at 12:29 PM Jaco Kroon  wrote:
>> Hi,
>>
>> That really depends.
>>
>> If the expectation is that everything in /usr/{bin,sbin,lib*} needs to now 
>> fit on / rather than /usr we're queued to re-install a very, very large 
>> number of hosts.
> You have that reversed: the expectation is that everything in
> /{bin,sbin,lib} will fit in /usr. In other words, we move files from /
> into /usr.

That's a relieve, but as per Sam this is only relevant to systemd
profiles, which for some reason I also completely overlooked as per the
subject.  However, these things do have a tendency to filter through to
non-systemd systems eventually.

Sorry for the noise.

Kind Regards,
Jaco

Re: [gentoo-dev] Add systemd/merged-usr profiles

[Jaco Kroon]

Hi,

That really depends.

If the expectation is that everything in /usr/{bin,sbin,lib*} needs to
now fit on / rather than /usr we're queued to re-install a very, very
large number of hosts.

Kind Regards,
Jaco

On 2022/08/31 18:01, Jeff Gazso wrote:

> Just out of curiosity, how much pain is this likely to cause existing
> installations that will need to migrate from a split-usr setup to a
> merged-usr setup?
>
> On Tue, Aug 30, 2022 at 2:28 PM Mike Gilbert  wrote:
>
> This patch series adds a "merged-usr" feature profile, and subprofiles
> for each systemd profile.
>
> As background: systemd upstream is preparing to drop support for
> split-usr systems soon. All systemd users on Gentoo will eventually
> need to migrate to a merged-usr system.
>
>

Re: [gentoo-dev] Last rites: sys-fs/eudev

[Jaco Kroon]

Hi Arve,

On 2022/08/30 12:27, Arve Barsnes wrote:

> On Tue, 30 Aug 2022 at 11:52, Jaco Kroon  wrote:
>> I note that the default provider for the virtual is systemd-utils[udev],
>> followed by sys-fs/udev, sys-fs/eudev and finally sys-apps/systemd.
>> This contradicts the wiki page which states that sys-fs/udev is the
>> default (https://wiki.gentoo.org/wiki/Udev).
>>
>> Is there more comprehensive documentation around about this, and which
>> should be preferred when?
> sys-fs/udev is also just a virtual now, which pulls in
> systemd-utils[udev], so using either works exactly the same.

Thanks, I missed that.  That does help to clear things up.

This leaves three implementations, systemd-utils[udev], eudev and systemd.

We don't use systemd so that eliminates that, can I safely assume that
systemd-utils[udev] is "extracted" from systemd and really the same
thing?  Ie, it's the udevd without the associated systemd environment? 
So really only two implementations.

eudev then is the wild horse in that it was forked from the days when
sys-fs/udev got incorporated into systemd, and have been following a
parallel but somewhat independent path?  It doesn't contain many of the
newer systemd-udev "features" and "lags behind"?

Which, assuming then my understanding is now improved (which I believe
it is), then the selection should be based as follows:

1.  If you're using systemd, use the embedded udevd.
2.  If you're using openrc, you should prefer sys-fs/udev aka
systemd-utils[udev] unless you have a specific reason to rather use eudev?

eudev has served me very well for very long, and avoided a fair number
of LVM related deadlock issues we experienced with sys-fs/udev at the
time.  We've been moving back, and I'm not convinced those have been
eliminated, but I could not yet prove any of the recent system deadlocks
we've seen relates to systemd-udev.

(The one deadlock we did manage to trap was without a doubt something
with the linux kernel IO scheduler, possibly related to raid6, however,
lvm is also involved in that path, which does involve udev.  Also the
system that most frequently runs into problems - only one with software
raid6, but it also by far makes the most aggressive use of lvm
snapshots.  Thus no definitive patterns.)

Being a creature of habit based on experience I am sceptical.  I am
contemplating throwing that one host back to eudev and seeing if that
"solves" the problem ... but how long is a piece of string.

Thanks for the information, I'll let the above simmer a good long while.

Kind Regards,
Jaco

Re: [gentoo-dev] Last rites: sys-fs/eudev

[Jaco Kroon]

Hi Mike, Sam

This is the last I saw on the ML regarding eudev - has there been a
change of strategy regarding eudev since?

I note that the default provider for the virtual is systemd-utils[udev],
followed by sys-fs/udev, sys-fs/eudev and finally sys-apps/systemd. 
This contradicts the wiki page which states that sys-fs/udev is the
default (https://wiki.gentoo.org/wiki/Udev).

Is there more comprehensive documentation around about this, and which
should be preferred when?

The commit to un-last-rite this is the only information I can find, and
I don't see major releases since.

commit e170e1bb4c9ac1f63267298aa8eaab0d8f03c5e4
Author: Sam James 
Date:   Mon Dec 20 23:13:58 2021 +

    profiles: unmask/un-last-rite eudev
    
    It's now being maintained by a new upstream. I still recommend users
    use sys-fs/udev as sys-fs/eudev has not been rebased on newer
    upstream (yet?) but this allows choice for people who feel
    strongly about this, I suppose.
    
    Boot-tested and e.g. udevadm seems to work correctly with new
    hwdb bits.
    
    Thanks-to: kurly
    Signed-off-by: Sam James 


Kind Regards,
Jaco

[gentoo-dev] Last rites: net-misc/bgpq3

[Jaco Kroon]

# Jaco Kroon  (2022-08-22)
# Superceded by bgpq4 (already in tree).  Non-co-operative upstream. 
Removal
# in 30 days.  Open bugs, already fixed in bgpq4.  Please convert your
usage to
# bgpq4.  Mostly you just need to drop the -3 argument.
net-misc/bgpq3

Related PR:  https://github.com/gentoo/gentoo/pull/26923

Re: [gentoo-dev] Up for grabs: net-misc/anydesk, net-misc/vde

[Jaco Kroon]

On 2022/07/24 18:36, Sam James wrote:
> The following packages are up for grabs b/c of inactivity:
> net-misc/anydesk

https://github.com/gentoo/gentoo/pull/26587

Kind Regards,
Jaco

Re: [gentoo-dev] proposal

[Jaco Kroon]

Hi All,

On 2022/07/06 15:50, Michał Górny wrote:

> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
>> I'd like to propose a new metadata XML element for packages:
>>
>>  
>>
>> Maintainers can signal to other developers (and of course contributors 
>> in general) that they are happy with others to make changes to the 
>> ebuilds without prior consultation of the maintainer.
> I don't think adding such an element is a good idea.  In my opinion,
> this will strengthen the assumption that "unless otherwise noted, you
> don't dare touch anything" (even though that's not your goal).  "Common
> sense" should really be good enough for almost everything.

I agree, but also note that what I consider to be "common sense" isn't
always "your common sense".

I also agree that having some way to indicate the preference on the
specific package may be a good thing.  With various possible levels of
sensitivity.

For example, net-misc/asterisk and net-libs/pjproject is very sensitive
for me.  net-misc/dahdi{,-tools} and x11-wm/evilwm less so.  In all
cases I'd still prefer to be kept in the loop at a minimum.

As such, it looks like there is multiple options, and there are
suggestions for various tags, this is a sensible way to indicate
preference.  Eg, also, what kind of fixes don't require communication,
eg, I've seen drive-by's on the above packages to fix dependencies based
on slots because depended on packages changed their structure, or
because LUA became slotted, or adding := etc ...  This makes sense to
allow these, but if you're going to mess with my ./configure on asterisk
or pjproject without consulting with me I'm going to be upset.  A simple
code fix to fix some compile error (specific to say llvm), probably
fine, but I'd still appreciate communication as I'd like to submit that
upstream kind of thing as well.

If this does go live, then there should be a single tag where the value
indicates the level of "sensitivity", or multiple tags of which only one
is allowed.  Since some of these options may be orthogonal to each
other, a single tag with multiple attributes may be more appropriate, I
don't know, nor do I personally care that much, so far I've been
respected, and the drive-by's that has been made were all either part of
global fixes, or in the one or two cases where it was specific, was put
into the tree as ~ so were all just fine.  In one particular case it was
also masked specifically because the change depended on another change
to happen simultaneously/close together (lua slotting) - the experience
of which was most refreshing.  Obviously nothing is set in stone w.r.t.
specifics, but if the initial course is at least somewhat in the right
direction it's easier to course-correct.

I thus have no strong opinion one way or the other, but just wanted to
state the above.


Kind Regards,
Jaco

Re: [gentoo-dev] linux-mod - moving checks to pkg_pretend

[Jaco Kroon]

Hi,

On 2022/06/10 12:07, Ionen Wolkens wrote:

> On Fri, Jun 10, 2022 at 06:03:28AM -0400, Ionen Wolkens wrote:
>> On Fri, Jun 10, 2022 at 11:41:01AM +0200, Jaco Kroon wrote:
>>> Hi All,
>>>
>>> Currently checks for kernel options etc happen in pkg_setup, would it be
>>> possible to move this to pkg_pretend?
>> One problem with pkg_pretend is that it may not even be the right
>> kernel, e.g. it could be using a new gentoo-kernel that was just
>> emerged in the process. There's also USE=symlink which may lead
>> to an entirely non-configured kernel. So pkg_setup check is
>> essential and "moving" wouldn't be right.
>>
>> Copying can "somewhat" work, albeit it could check against different
>> kernels and also cause duplicated messages (former nvidia-drivers
> Actually, also need to consider the case where there's not even
> a kernel yet.
>
> e.g. `emerge gentoo-kernel-bin nvidia-drivers` would fail with
> pkg_pretend and work with pkg_setup
>
> So, if used, pretend would need to be (at least) non-fatal and
> just a warning.

Hmm.  So a newly installed kernel would probably always fail all checks.

Ok, I'm going to leave this as is, but move the DAHDI checks to
pkg_setup regardless just to be more in line with what I now understand
the INTENDED use was.

Kind Regards,
Jaco

Re: [gentoo-dev] linux-mod - moving checks to pkg_pretend

[Jaco Kroon]

Hi Ionen,

On 2022/06/10 12:03, Ionen Wolkens wrote:
> On Fri, Jun 10, 2022 at 11:41:01AM +0200, Jaco Kroon wrote:
>> Hi All,
>>
>> Currently checks for kernel options etc happen in pkg_setup, would it be
>> possible to move this to pkg_pretend?
> One problem with pkg_pretend is that it may not even be the right
> kernel, e.g. it could be using a new gentoo-kernel that was just
> emerged in the process. There's also USE=symlink which may lead
> to an entirely non-configured kernel. So pkg_setup check is
> essential and "moving" wouldn't be right.
>
> Copying can "somewhat" work, albeit it could check against different
> kernels and also cause duplicated messages (former nvidia-drivers
> ebuild used to even repeat messages /3/ times when some were fine
> to ignore (aka, just a warning) -- but 3 rather than 2 was due to
> the ebuild doing it wrong though).
This makes sense.  But would then absolutely require a syntax like
use?option to be supported so that CHECK_CONFIG can just be set globally
once.  And that brings another can of worms ... unless there is a common
mechanism to "resolve" that using a syntax similar to elsewhere, eg, a
mechanism to reduce something like:

CONFIG_CHECK="MODULES PCI ~CRC_CCITT oslec? ( ECHO )"

to "MODULES PCI ~CRC_CCITT ECHO" if USE=oslec, and "MODULES PCI
~CRC_CCITT" if USE=-oslec.
>> Motivation:  pkg_setup executes just prior to unpack, so if it fails
>> here it could be after a lot of other work has already gone into other
>> packages, breaking the full merge, it would thus be better to break early.
>>
>> A couple of packages (dahdi included, although, in-prep commit changes
>> that to match the eclass) invoke special cases for CHECK_CONFIG,
>> depending on USE flags, so for example this is going into dahdi now
>> (variation of what was in pkg_pretend)
>>
>> use oslec && CHECK_CONFIG+=" ECHO"
>> linux-mod_pkg_setup
>>
>> Most of the checks in linux-mod_pkg_setup (like ensuring kernel sources
>> are prepped) makes sense to perform in pretend rather so that we know
>> it's sorted prior to the first packages starting to merge, thus reducing
>> risk of breakage once merges have initiated.
>>
>> There are a fair number of consumers in-tree that would need to be
>> validated, but from a quick grep I did this morning looking for examples
>> I *suspect* most of the consumers will not require any changes.
> Ideally changing EXPORT_FUNCTIONS should be done on EAPI bumps rather
> than trying to update every ebuilds. Lot of overlays use linux-mod
> too and don't expect sudden API breakage assuming not using the eclass
> in a way they weren't supposed to.

I suspect the usage isn't as well defined as it could be, and as such
(postgress, dahdi and qemu - to name but those I looked at this morning)
are all using it in slightly different ways, all of them makes sense,
and all of them suffers different shortcomings.  It seems the majority
of uses are in pkg_pretend with an explicit check_extra_config call,
given what you said above ...

Kind Regard,
Jaco

[gentoo-dev] linux-mod - moving checks to pkg_pretend

[Jaco Kroon]

Hi All,

Currently checks for kernel options etc happen in pkg_setup, would it be
possible to move this to pkg_pretend?

Motivation:  pkg_setup executes just prior to unpack, so if it fails
here it could be after a lot of other work has already gone into other
packages, breaking the full merge, it would thus be better to break early.

A couple of packages (dahdi included, although, in-prep commit changes
that to match the eclass) invoke special cases for CHECK_CONFIG,
depending on USE flags, so for example this is going into dahdi now
(variation of what was in pkg_pretend)

use oslec && CHECK_CONFIG+=" ECHO"
linux-mod_pkg_setup

Most of the checks in linux-mod_pkg_setup (like ensuring kernel sources
are prepped) makes sense to perform in pretend rather so that we know
it's sorted prior to the first packages starting to merge, thus reducing
risk of breakage once merges have initiated.

There are a fair number of consumers in-tree that would need to be
validated, but from a quick grep I did this morning looking for examples
I *suspect* most of the consumers will not require any changes.

If there are no objections, and time permitting, I could take a shot at
this and file a PR.

Kind Regards,
Jaco

[gentoo-dev] Re: [PATCH] linux-mod.eclass: Support module compression

[Jaco Kroon]

Hi,

On 2022/06/10 00:11, Mike Pagano wrote:

> The Linux kernel supports the compression of modules utilizing GZIP, XZ
> and ZSTD.  Add code into linux-mod.eclass to support this for out of
> tree modules utilizing the compression binary specified in the kernel
> config.
>
> Note that if the binary which provides the compression is not present on
> the system the kernel would have failed to build with an error
> indicating the missing binaries name.

LGTM.

Thanks for your work on this.

Kind Regards,
Jaco


>
> Signed-off-by: Mike Pagano 
> ---
>  eclass/linux-mod.eclass | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> index 6a820371b..b7c13cbf7 100644
> --- a/eclass/linux-mod.eclass
> +++ b/eclass/linux-mod.eclass
> @@ -711,7 +711,22 @@ linux-mod_src_install() {
>  einfo "Installing ${modulename} module"
>  cd "${objdir}" || die "${objdir} does not exist"
>  insinto "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> -    doins ${modulename}.${KV_OBJ} || die "doins
> ${modulename}.${KV_OBJ} failed"
> +
> +    # check here for CONFIG_MODULE_COMPRESS_
> (NONE, GZIP, XZ, ZSTD)
> +    # and similarily compress the module being built if != NONE.
> +
> +    if linux_chkconfig_present MODULE_COMPRESS_XZ; then
> +    xz ${modulename}.${KV_OBJ}
> +    doins ${modulename}.${KV_OBJ}.xz || die "doins
> ${modulename}.${KV_OBJ}.xz failed"
> +    elif linux_chkconfig_present MODULE_COMPRESS_GZIP; then
> +    gzip ${modulename}.${KV_OBJ}
> +    doins ${modulename}.${KV_OBJ}.gz || die "doins
> ${modulename}.${KV_OBJ}.gz failed"
> +    elif linux_chkconfig_present MODULE_COMPRESS_ZSTD; then
> +    zstd ${modulename}.${KV_OBJ}
> +    doins ${modulename}.${KV_OBJ}.zst || die "doins
> ${modulename}.${KV_OBJ}.zst failed"
> +    else
> +    doins ${modulename}.${KV_OBJ} || die "doins
> ${modulename}.${KV_OBJ} failed"
> +    fi
>  cd "${OLDPWD}"
>  
>  generate_modulesd "${objdir}/${modulename}"

Re: [gentoo-dev] [PATCH 0/2] Add esed.eclass for sed that dies if caused no changes

[Jaco Kroon]

Hi,

On 2022/05/31 16:29, Ionen Wolkens wrote:
> esed does bring back the -i/die skipping but that's not its inherent
> purpose and GNU sed currently does not support a mean to report if
> changes occurred (if this happens, esed may well become obsolete too).
>
Haven't checked the code to validate.  But I'm in support of esed eclass
for the sole reason it ensures the sed actually still changes
something.  Not that it verifies the change is actually intended mind
you, so it doesn't completely take away the due diligence checks, but
the verbose options should help devs to ensure the changes are the
intended at testing time.

One *could* also add a change-counter check, eg, count the number of
lines starting with + and - (but not +++ and ---) from diff, and ensure
they match the expected count.  Just to catch further possible cases.

Kind Regards,
Jaco

Re: [gentoo-dev] Packages up for grabs: net-mail/mailman and everything that belongs to it

[Jaco Kroon]

Hi Hanno,

We've decided to for the time being shelf Mailman completely.  We're
just about done (should go live with test clients this afternoon)
implementing an alternative that we've built in-house to more accurately
accommodate for our use-case in any case.

I would recommend proceeding to last-rite Mailman and related packages.

Kind Regards,
Jaco

On 2021/12/25 00:30, Jaco Kroon wrote:
> Hi Hanno,
>
> I've started looking at this mess.  And a mess it is.  To the point,
> where for our somewhat "subset of what mailman provides" requirements
> I'm contemplating rather cooking an in-house solution (have done similar
> in the past, but none of these really provide everything we require),
> but will get back to you.
>
> In the current state mailman3 as it is in tree I don't think it's usable
> in any sensible way (Unless I'm really missing something), so if I go
> another route I recommend we last-rite it and move on.  If I do pick it
> up on it, then the problem is solved either way.
>
> Kind Regards,
> Jaco
>
> On 2021/12/21 13:23, Hanno Böck wrote:
>> Hi,
>>
>> I'm no longer using mailman personally, thus I'm not interested in
>> maintaining it any more.
>>
>> The mailman packages currently in portage are the mailman 3 split
>> packages, which involve multiple packages providing the functionality,
>> plus a large number of dependencies. (Unfortunately with the switch
>> from mailman 2 to 3 upstream decided not only to move from python 2 to
>> 3, but also to make the whole thing far more complicated and involve
>> far more dependencies...)
>>
>> If you're interested in maintaining this please add yourself to the
>> metadata.xml of these packages:
>>
>> dev-python/django-allauth
>> dev-python/django-appconf
>> dev-python/django-compressor
>> dev-python/django-extensions
>> dev-python/django-gravatar2
>> dev-python/django-haystack
>> dev-python/django-picklefield
>> dev-python/django-q
>> dev-python/python3-openid
>> dev-python/rcssmin
>> dev-python/robot-detection
>> net-mail/django-mailman3
>> net-mail/hyperkitty
>> net-mail/mailmanclient
>> net-mail/mailman
>> net-mail/mailman-meta
>> net-mail/postorius
>>
>> If noone steps up maintaining this I'n not entirely sure what to do
>> with it, maybe just remove everything? (Including the python
>> dependencies that aren't used by any other package I guess.)
>>

Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

[Jaco Kroon]

Hi,

On 2022/01/18 04:58, Ionen Wolkens wrote:

>
> Unsure what I like best, I generally agree should default to sources
> but I do see new users complaining about building rust every few days.
> Not that the step of telling them that rust-bin exists is that bad
> (part of the issue is that they don't know it's an option).
>
Perhaps output a notice in rust's pkg_setup() that you're using the
source version and that it takes a long time to build, and consumes lots
of resources and you may want to consider rust-bin?  Possibly with some
variable in make.conf or some USE to turn that off?

Kind Regards,
Jaco

Re: [gentoo-dev] Packages up for grabs: net-mail/mailman and everything that belongs to it

[Jaco Kroon]

Hi Hanno,

I've started looking at this mess.  And a mess it is.  To the point,
where for our somewhat "subset of what mailman provides" requirements
I'm contemplating rather cooking an in-house solution (have done similar
in the past, but none of these really provide everything we require),
but will get back to you.

In the current state mailman3 as it is in tree I don't think it's usable
in any sensible way (Unless I'm really missing something), so if I go
another route I recommend we last-rite it and move on.  If I do pick it
up on it, then the problem is solved either way.

Kind Regards,
Jaco

On 2021/12/21 13:23, Hanno Böck wrote:
> Hi,
>
> I'm no longer using mailman personally, thus I'm not interested in
> maintaining it any more.
>
> The mailman packages currently in portage are the mailman 3 split
> packages, which involve multiple packages providing the functionality,
> plus a large number of dependencies. (Unfortunately with the switch
> from mailman 2 to 3 upstream decided not only to move from python 2 to
> 3, but also to make the whole thing far more complicated and involve
> far more dependencies...)
>
> If you're interested in maintaining this please add yourself to the
> metadata.xml of these packages:
>
> dev-python/django-allauth
> dev-python/django-appconf
> dev-python/django-compressor
> dev-python/django-extensions
> dev-python/django-gravatar2
> dev-python/django-haystack
> dev-python/django-picklefield
> dev-python/django-q
> dev-python/python3-openid
> dev-python/rcssmin
> dev-python/robot-detection
> net-mail/django-mailman3
> net-mail/hyperkitty
> net-mail/mailmanclient
> net-mail/mailman
> net-mail/mailman-meta
> net-mail/postorius
>
> If noone steps up maintaining this I'n not entirely sure what to do
> with it, maybe just remove everything? (Including the python
> dependencies that aren't used by any other package I guess.)
>

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Jaco Kroon]

Hi,

On 2021/12/01 08:45, Alec Warner wrote:

> On Tue, Nov 30, 2021 at 10:16 PM Jaco Kroon  wrote:
>> Hi,
>>
>> On 2021/12/01 03:32, William Hubbs wrote:
>>> This is the part of this that I don't understand. If we aren't enforcing
>>> an ID, why do we care which ID to try first? It seems to be an
>>> unnecessary step since users can pick the IDs they want by putting
>>> settings in make.conf.
>> Because when running clusters of hosts it's useful to have the UIDs for
>> "system" users match.  Yes, I know this won't match in a multi-distro
>> setup, but at least for those of us with clusters consisting only of
>> Gentoo hosts it will *usually* match.  Changing these are possible, but
>> a nuisance, so having it "just work" for the usual case is great IMHO.
> So questions from my side are:
> Does your cluster not have human users?
In this case none.  So no need for centralized database otherwise.
> Do the userids for the human users also not have to match between
> hosts in the cluster?

In certain environments we do need that, which is where nss_ldap and
friends come in.  In those environments the system ids doesn't matter
though, because only /home is shared :).

Kind Regards,
Jaco

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Jaco Kroon]

Hi,

On 2021/12/01 03:32, William Hubbs wrote:
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.

Because when running clusters of hosts it's useful to have the UIDs for
"system" users match.  Yes, I know this won't match in a multi-distro
setup, but at least for those of us with clusters consisting only of
Gentoo hosts it will *usually* match.  Changing these are possible, but
a nuisance, so having it "just work" for the usual case is great IMHO.

If I'm not mistaken there is a setting to REQUIRE the ID, and that could
even be set from make.conf, or env/ so for those packages that we care
about that (eg, mailman running on top of glusterfs) we use that.

Kind Regards,
Jaco

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Jaco Kroon]

Hi,

On 2021/11/11 14:10, Pacho Ramos wrote:
> In any case, 300 additional IDs may not be future proof at the rate
>> we're currently allocating them. So I wonder if we shouldn't move to
>> above 6 immediately, or alternatively, give up the whole concept.
>>
>> Ulrich
> Personally I would move to >6 and keep the 300 additional IDs for the case
> some software really really needs them 

# getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3
37945
37946
65534 <-- this happens to be nobody.

>6 up to where?  65533?  I'll need to make a "hole" in our
allocations but that's perfectly do-able.  Others may run into similar
issues and be caught unawares (especially if UID/GID values are
allocated from some other system which may not be aware of UID/GID
values on specific servers).  Might be worth the trouble to head to
>=2^31, but that will again fail on systems that still use 16-bit
UID/GID values (I'm not aware that we still support kernels older than 2.4).

https://systemd.io/UIDS-GIDS/ basically says system users (which we're
discussing here) is <1000.  systemd also already violates this statement
itself just a few paragraphs down with special systemd UID and GID
ranges.  And already >6 ranges listed here (most of 6 to 65533
is reserved by systemd).

Kind Regards,
Jaco

[gentoo-dev] Re: Last rites: net-misc/clusterssh

[Jaco Kroon]

Whow!  I'll bump this.  We depend heavily on this.


On 2021/11/10 20:08, Jakov Smolić wrote:

> # Jakov Smolić  (2021-11-10)
> # Current version is outdated, uses EAPI 5, has multiple
> # bug reported. No revdeps.
> # Removal on 2021-12-10. Bug #819306.
> net-misc/clusterssh

Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list

[Jaco Kroon]

Hi Michał,

I do agree with the gist of what you're saying, and in absence of a
better solution I'm in support.

I also make a disclaimer:  I only use amd64 so none of this really
affects me, so at the end of the day - I don't really care.

We have tinderboxes already running that does all kinds of testing for
amd64 and specifically, both musl and glibc as far as I'm aware.  This
could be trivially extended to x86 by way of chroot I believe.

Given emulators I believe it's also possible to extend this to other
arches at somewhat crazy CPU overhead costs, and I'm not convinced of
the reliability of these emulators vs real hardware but for the purposes
of this discussion it may be a moot point (if it works on the emulator
it's more likely to work on real hardware than the other way around).

Given the work on nattka, is it possible that nattka could be extended,
in collaboration with he tinder hosts to submit a specific package for
compile testing?  Specifically for security (and possibly stablereq)
bugs I'm thinking have the tinderboxes do the compile tests, as
requested by nattka, and then once amd64 and possibly x86 has confirmed,
give the security team the option to force stable on the other arches?

This may seem to be more controversial than dropping stable for those
arches, however, consider that ~arch just gets marked anyway, so
frankly, we're no worse off than with dropping stable for these arches. 
The point of controversy is that we're taking out a testing point for
packages, and by implication, control as well as responsibility away
from the arch teams.

I'm also wondering about the overall stabilisation process.  To be
frank:  A LOT of work is being handed over to the arch teams.  I'm not
against this, but could we possibly come up with a better way? 
Specifically, if anyone can request a stable request for an arch, and
the package maintainer can OK that within certain rules and constraints
(system enforced, with arch teams allowed to violate that, so if a
package manager can motivate why then arch can overrule).  So in essence:

1.  Anyone can request stable for an arch on a package.
2.  Package maintainer does first ACK (or automatic after a time delay
and additional parties has requested?)
3.  Tinderbox for compile tests (At least -* and * on the package
itself, ideally with "-* single" as well, and any other USE flags as
required by single ... this will burn a lot of CPU, which is arguably
better than developer time).
4.  If there are tests, run these too, and if they all pass, proceed to
stable.
5.  If there are not tests ... ?

Anyway, just some thoughts, hoping to spark some ideas.  At the end of
the day I agree with Michał (as I read his message) - differentiation
between stable supported and security supported doesn't make sense.

Kind Regards,
Jaco

On 2021/10/21 10:05, Michał Górny wrote:

> Hello,
>
> Splitting from the discussion in [1] (moving more arhitectures to
> ~arch), I'd like to propose that we remove the "security supported"
> architecture list from [2] and instead level security support with
> the general architecture support in Gentoo, e.g. by having all
> architectures with stable profiles be "security supported".
>
> Rationale:
>
> 1. The architecture list seems to date way back and doesn't seem to have
> been maintained properly.  According to CVS history, the last time a new
> architecture was marked "supported" was in 2005; since then,
> architectures were only removed.  After the migration to new website,
> the points of contact for architectures aren't even listed anymore.
> The presence of 'ppc' on the list is doubtful at best.  At the same
> time, 'arm64' is not supported.
>
> 2. Keeping a separate list can cause confusion, if not make users of
> architectures such as arm64 feel belittled.  I don't really see why
> the Security team should be overriding the overall Gentoo architecture
> support status.
>
> 3. Per the policy, Security team "will not wait for a stable fix on
> these arches before issuing the GLSA and closing the bug".  The former
> I don't have a problem with but how could you close the bug before
> cleaning up old versions, and how would you clean up the old versions
> when the new ones aren't stable yet everywhere?
>
> 4. In the end, Security team isn't really respecting this policy.
> In the end, this leads to absurdities like GLSA being released before
> a package is stable on amd64, and confusing the users [4].
>
> While I agree we could probably establish some criteria when GLSAs
> should be released, the current policy is incorrect and obsolete.  In my
> opinion removing the list is the first step towards cleaning stuff up.
>
>
> [1] 
> https://archives.gentoo.org/gentoo-dev/message/fd18905401a1aec78aa6af7238f5ca1c
> [2] 
> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
> [3] 
> https://gitweb.gentoo.org/archive/proj/gentoo.git/log/xml/htdocs/proj/en/security/index.xml
> [4] https://bugs.gentoo.org/789240#c2
>

Re: [gentoo-dev] Packages up for grabs: misc packages from chainsaw@

[Jaco Kroon]

Hi,

On 2021/10/05 05:04, Sam James wrote:

> Hi all,
>
> Chainsaw asked retirement@ to drop him to maintainer-needed on his packages, 
> so here's the resultant
> packages with no maintainers left:
That's a shame.  Big loss.
> app-arch/rpm

createrepo_c depends on this, willing to grab it purely for that. 
rpmdevtools is the other big consumer - kensington - you willing to
handle this one?

> net-libs/iax

I believe this can be last rited.  This is a voice package but I can't
find consumers, nor does it look useful as is (no .so being installed,
and otherwise it's just a pkg-config style iax-config, but references
not-installed libiax).  I thus believe the package looks to be broken.
Adding last-rite.

> net-misc/astmanproxy
Potentially useful.  Will look into this.  For now I'll mark myself as
proxymaintainer.  If someone else wants to grab instead, please feel
free to do so.  I may end up last-riting this, so if there are users of
this, please let me know, or just grab the package.
> net-misc/bgpq3
> net-misc/stuntman

Will take these.  May want to consider replacing bgpq3 with bgpq4
regardless.

https://github.com/gentoo/gentoo/pull/22494

Kind Regards,
Jaco

[gentoo-dev] https://packages.gentoo.org/ - lag

[Jaco Kroon]

Hi,

Example:  https://packages.gentoo.org/packages/net-misc/asterisk is
stating "Version 18.6.0 is available upstream. Please consider updating!"

However:

jkroon@plastiekpoot ~ $ equery list -ipo asterisk
 * Searching for asterisk ...
[-P-] [  ] net-misc/asterisk-13.38.3:0/13
[-P-] [  ] net-misc/asterisk-16.19.1:0/16
[IP-] [  ] net-misc/asterisk-16.20.0:0/16
[-P-] [  ] net-misc/asterisk-18.5.1:0/18
*[-P-] [  ] net-misc/asterisk-18.6.0:0/18*

commit fb9357dc075d6d0e8803b36a7bbd82ae2ad01954
Author: Jaco Kroon 
Date:   *Mon Aug 30 10:04:31 2021 +0200*

Added it, there was a few days lag through the PR to get it merged
(https://github.com/gentoo/gentoo/pull/22156, merged 6 days ago).

So just wondering how frequently packages.gentoo.org updates?

Also, is it possible to make the available upstream versions track
multiple branches?  Eg, in the asterisk case here to list {13,16,18}.*
versions separately?

Kind Regards,
Jaco

Re: [gentoo-dev] News item for eudev deprecation

[Jaco Kroon]

Hi All,

We run glibc based systems.  No musl.  But we don't use systemd.

As little as a year back we still ran into issues with systemd-udev
variant breaking systems, the fix of course was to nuke it and install
eudev.  Are we certain there is nothing (eg, LVM integration was our
biggest problem resulting in really crazy impossible to debug since we
can't log in due to lvn snapshot creation/removal deadlocking with
systemd-udev - no ask me not how, all I can tell you is that eudev never
exhibited this behaviour) will break?

Whilst I fully appreciate the difficult of all the various e* packages
(elogind, eudev etc ..) and I most certainly do not have the capacity to
maintain, and therefore I'm in full support of the concept of
deprecating eudev, I'm very, very worried about us suddenly being back
into the reboot-a-server-a-week scenario.  In the worst case we've lost
some large filesystems almost certainly due to systemd-udev (we've had a
number of filesystem crashes which was recovered with fsck, but after
ditching systemd-udev and moving to eudev about two years back on this
specific host we've had ZERO further problems other than a failed drive
or two, none of which required a hard-reset to get back to a sane state).

Kind Regards,
Jaco

On 2021/08/22 22:14, Anthony G. Basile wrote:
> Hi everyone,
>
> Yes!  It is time to finally deprecate eudev!  sys-fs/udev now builds
> under musl!  My original purpose for maintaining eudev was because
> systemd + musl did not play well together when udev was absorbed into
> the sytemd repo.  Now thanks to patches from openembedded, they do, and
> my original reason for maintaining eudev is no longer valid.  So its
> time to retire eudev.  It has served its purpose as a stop-gap.
>
> To me, this is a success for musl, and I would like to thank all the
> developers who have taken musl seriously enough to make this happen :)
>
> I am willing to transfer the eudev repo to another organization, but I
> will not maintain it anymore and Base System doesn't want to either.
> Let me warn people, to maintain it correctly you MUST become familiar
> with its internals and watch what systemd is doing upstream to keep up.
>  This is not trivial.  I learned a lot from eudev, and it did save musl
> on gentoo, but there was a period there when it was taking up almost all
> of my time.  If you don't know what you're getting into, you don't want
> to take on its maintenance.
>
>
>
> Title: eudev retirement on 2022-01-01
> Author: Anthony G. Basile 
> Posted: 2021-08-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-fs/eudev
>
> sys-fs/udev is becoming the standard provider of udev on non-systemd
> (e.g. OpenRC) systems. Users of systemd will continue to use the udev
> services provided by the sys-apps/systemd package itself.
>
> The transition should be uneventful in most cases, but please read this
> item in full to understand some possible corner cases.
>
> eudev will be retired and removed from Gentoo on 2022-01-01. We will
> start masking eudev on 2021-10-01 and give people 3 months to prepare
> their transition. You should ensure that sys-fs/eudev is not in your
> world file by running
>
>   emerge --deselect sys-fs/eudev
>
> in order for Portage to replace eudev with sys-fs/udev once the
> package.mask is in place. We fully support udev on musl, whereas uclibc
> will still have to rely on eudev before also being removed on 2022-01-01.
>
>   **WARNING**
>
> If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob,
> you will inevitably break your system. sys-fs/udev contains "systemd" in
> some of its filenames, hence a blanket filter rule will likely lead to a
> non-functional udev installation.
>
>   Rationale
>
> The integration of udev into the systemd git repo introduced numerous
> problems for none-glibc systems, such as musl and uclibc. Several
> options were considered, and the one chosen was to fork and maintain
> udev independant of the rest of systemd. This was meant as a stop-gap
> solution until such time as the problems with systemd on musl had been
> resolved. This is now the case with patches provided by openembedded,
> and my original reason for maintaining eudev is no longer relevant.
>
> I am willing to transfer eudev to another umbrella organisation or Linux
> distribution that is willing to continue its maintenance, but
> maintaining eudev cannot be done purely through proxy-maintaining and
> requires an understanding of its internals. This is a steep learning
> curve and must be an earnest effort. For this reason, the Base System
> project has decided not to support euev as an option going forward.
>

Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs

[Jaco Kroon]

Hi,

>> It would be nice to be able to resolve the security@-assigned but
>> before non-security-supported architectures are handled.
>>
>> To do that, I think we'd want to change what's required for the "clean
>> up" step. Since today the "clean up" step is dropping the vulnerable
>> package versions from the tree, it is dependent on
>> non-security-supported architectures completing the stabilization bug.
>> I think we'd like to break that dependence.
>>
>> I suggest that we redefine the "clean up" step to be: drop
>> security-supported architectures' keywords from vulnerable versions.
>> That would allow the security@-assigned bug to be resolved before
>> non-security-supported architectures are finished with stabilization.
>>
> To be honest, this sounds like doubling the effort for little benefit. 
> After all, removing the old version of the package doesn't resolve any
> problems on the end user systems -- upgrading does, and upgrading
> usually happens entirely independently of whether we've cleaned up or
> not.
>
> Maybe it'd easier to release GLSAs before cleanup happens?  We can
> always go the dekeywording way if arch teams are actually slacking.
>
I agree with both of you.  In particular, cleaning old versions should
not be a requirement for releasing the GLSA.  The faster the GLSA can
get out the better.  Removing the keywords is a novel idea, but honestly
not sure it's worth the effort.

Kind Regards,
Jaco

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[Jaco Kroon]

Hi Andreas,

On 2021/03/23 00:54, Andreas K. Huettel wrote:
>>> Council decided years ago that we don't support separate /usr without
>>> an initramfs, but we haven't completed that transition yet.
>> Which doesn't imply that we deliberately break things.
> That's right. Though we should at some point start thinking about an end of 
> support for separate usr without initramfs.
>
> Why? Because the number of required hacks and complexity will only increase, 
> as will the number of uncooperative upstreams. It's called a strategic 
> retreat. :D
>
> My suggestion would be that the next profile version (21? 22?) declares 
> separate /usr a broken configuration, and explicitly encourages devs to 
> introduce all ebuild simplifications that are made possible by this. (Like 
> this symlink - no more conditional code.) No more discussions about "not 
> breaking things" at that point.

Why was it ever copied in the first place?  For as long as I can recall
(been using Gentoo since 2003) I've always been using a symlink here,
not to mention a separate /usr (which has only been in the last year or
so mounted from initrd along with /lib/firmware - which was the trigger
point when it became too big to be contained on our normal / partition,
the other fix would have been to be more selective in which firmware to
install but that would be a higher administrative overhead).

To this day I still believe that / should contain a minimal viable
bootable system (give me a shell and just enough to perform basic tasks
like activating LVM, repairing and mounting filesystems, and ideally
some or another editor such as busybox vi is good enough, mostly
everything else can go to /usr even with it being "split").

I still don't see why a split /usr is a bad thing.  In fact, there are a
significant number cases where I've had FS corruption which I was able
to recover without the need for additional bootable media (which when
working remotely via IP KVMs can be difficult at best) due to "living in
the past" as you say.

There is no reason a symbolic link can't cross a filesystem boundary ...
it's hard links that can't.

Kind Regards,
Jaco

> (Or to put it another way, I think we should stop wasting time and effort 
> here just to be able to live in the past.)
>

Re: [gentoo-dev] Packages up for grabs: x11-misc/xbindkeys

[Jaco Kroon]

Hi,

Done.

Thank you for the feedback.

Already filed stable request as well for the updated version.  Looks
like a low-touch package fortunately.

Kind Regards,
Jaco

On 2021/02/22 09:35, Fabian Groffen wrote:

> Jeroen was sadly removed from the project.
>
> You go ahead and take it.
>
> Fabian
>
> On 22-02-2021 07:49:55 +0200, Jaco Kroon wrote:
>> Hi,
>>
>> Looks like Jeroen was the person mostly committing on this, Jeroen - are
>> you intending to keep maintaining this?
>>
>> The PR is legit but incomplete (it merely adds the patch, not use it).
>>
>> The patch has been merged upstream in 2014 already, instead we should
>> stable 1.8.7.
>>
>> I'll adjust the referenced bug referenced by the PR accordingly.
>>
>> Kind Regards,
>> Jaco
>>
>> On 2021/02/21 05:08, Jonas Stein wrote:
>>> Dear all
>>>
>>> the following packages are up for grabs after dropping
>>> desktop-misc:
>>>
>>> x11-misc/xbindkeys
>>> https://packages.gentoo.org/packages/x11-misc/xbindkeys
>>>
>>> There is an open PR
>>> https://github.com/gentoo/gentoo/pull/14706
>>>
>>

Re: [gentoo-dev] Packages up for grabs: x11-misc/xbindkeys

[Jaco Kroon]

Hi,

Looks like Jeroen was the person mostly committing on this, Jeroen - are
you intending to keep maintaining this?

The PR is legit but incomplete (it merely adds the patch, not use it).

The patch has been merged upstream in 2014 already, instead we should
stable 1.8.7.

I'll adjust the referenced bug referenced by the PR accordingly.

Kind Regards,
Jaco

On 2021/02/21 05:08, Jonas Stein wrote:
> Dear all
>
> the following packages are up for grabs after dropping
> desktop-misc:
>
> x11-misc/xbindkeys
> https://packages.gentoo.org/packages/x11-misc/xbindkeys
>
> There is an open PR
> https://github.com/gentoo/gentoo/pull/14706
>

Re: [gentoo-dev] New project: binhost

[Jaco Kroon]

Hi,

> Binpkg performance is acceptable albeit not blazing fast for machines
> with 500-800 packages (usually server) while for desktops which easily
> have 2000 packages the time to update can be hours.
I take from this that the binpkg process really should be optimized
somehow.  Without looking at the code it looks like binpkg is
significantly less efficient than without.

I think Michał also hinted at this.  Essentially, from the sounds of the
above I suspect we're at "we're probably burning more CPU on calculating
the dependency tree than merely recompiling".

Which to me defeats the purpose.  This may be a single-core use vs
multiple cores though, so whilst it may take similar amount of time it's
possible that we end up consuming less energy overall.

Kind Regards,
Jaco

[gentoo-dev] feature request: packages.gentoo.org

[Jaco Kroon]

Hi,

Firstly:  I was aware of packages.gentoo.org - but only really
discovered it in the week - THANK YOU VERY MUCH FOR THIS.

Not sure whether this is the best place for my request, so if not,
please feel free to bat me in the right direction.

https://packages.gentoo.org/packages/net-misc/asterisk (example) refers.

I'm the (proxy) maintainer.

The above URL merely states:

It seems that version 18.2.0 is available upstream, while the latest
version in the Gentoo tree is 16.15.1.

This is correct.  Just looking a little down, it's noted there are two
versions currently in tree:

*16.15.1-r2
*
 : 0
*13.38.1-r2
*
 : 0

What's not indicated, there are subslots (13 and 16 respectively).

eshowkw (app-portage/gentoolkit) shows:

Keywords for net-misc/asterisk:
  | |   u  | 
  | a   a p s a   r |   n  | 
  | m   r h   p p   s l i i m m | e u s    | r
  | d a m p p c a x 3 p a s 6 i | a s l    | e
  | 6 r 6 p p 6 r 8 9 h 6 c 8 p | p e o    | p
  | 4 m 4 a c 4 c 6 0 a 4 v k s | i d t    | o
--+-+--+---
   13.38.1-r2 | + ~ ~ o ~ ~ o + o o o o o o | 7 o 0/13 | gentoo
--+-+--+---
[I]16.15.1-r2 | ~ ~ ~ o ~ ~ o ~ o o o o o o | 7 o 0/16 | gentoo

Which is currently as intended (yea, I'm behind the times - stable and
working in this case over bleeding edge - and nobody other than me is
yet pushing me to stable /16, although I have a bug request to package
18 which I intend to start work on today hopefully since I'm working on
asterisk stuff for business purposes today anyway).

13 is security only release now, and 16 and 18 are the primary branches
where 16 is more intended as stable and more fluctuations on 18 still
(which precludes me from using it for our company just yet).

Point being, it would be great if packages.gentoo.org could indicate
that in above cases as follows:

18.2.0 is available, which is correct, and desired, but if it could also
indicate that for the 16 branch there is currently a version of 16.16.0
available, and for 13 things are up to date.

Would be useful too to indicate that certain branches (eg, 17 in the
asterisk case will not be packaged due to being primarily development
branches, or at the very least, will not be considered for stabling)

In other words, guessing I'm looking for some form of "branched
versions" support here.

I know security already has some work around subslots as it was the sec
team that requested me to add subslots to net-misc/asterisk.

And yes ... looks like repology does have a few issues around branches
too:  https://repology.org/project/asterisk/cves?version=13.38.1

So I would completely understand if it's not possible to deal with
this.  As per
https://archives.gentoo.org/gentoo-dev/message/b793f4da5a5b5e20a063ea431500a820
there are certain configs that can go into
https://gitweb.gentoo.org/sites/soko-metadata.git/ - however, not being
a core developer, I don't have (nor am I requesting) access here.  May I
suggest that in-package metadata (ie, metadata.xml, or even inside the
ebuilds) might be a better location for some of this configuration if
possible, and if it makes sense?  For me the advantage is that as a PM I
can submit the required information via PR.

A description of the branch structure may be more suitable here anyway,
because that way other tools can leverage it too?

Then again, perhaps just looking at the subslots as already available is
good enough, in the case of the packages I work on this would indeed be
adequate, but it may not be for other packages.

Looking at repology.org itself, I'm not sure my request is trivial, and
I'm not going to ask tons of effort be put into this, but perhaps an
interesting challenge for someone at some point.

Kind Regards,
Jaco

Re: [gentoo-dev] New project: binhost

[Jaco Kroon]

Hi,

+1 - love the idea, def joining.

However, I suspect the op was aiming at a publicly hosted binpkg
server.  Given the below it becomes one server/host, we care only about
the build parameters, and I suspect profile then has less of an effect
on the built packages.

For publicly *available* infrastructure I do however not recommend that
arbitrary people be able to upload.  We can however from attempted
download logs try to determine which combinations of USE flags are
required (with hashes of stuff this becomes tricky as even only 16 USE
flags are already 65536 potential hashes, and 20 clocks in at over 16
million, still perfectly reversable, but once we start getting to 30+
USE flags ...).  So perhaps a way to feedback "Hey, I looked for this
combo/hash" so we don't need to reverse hashes.

Would definitely join such a project, and it would be greatly beneficial
if we can improve the infra to have a form of distributed build ... ie,
for private infrastucture, improve the mechanisms used to "check for
binpkg availability, i not available, build it and submit back to binary
host", obviously all such nodes would need to be considered "trusted".

Kind Regards,
Jaco

On 2021/02/10 21:11, Rich Freeman wrote:
> On Wed, Feb 10, 2021 at 12:57 PM Andreas K. Hüttel  
> wrote:
>> * what portage features are still needed or need improvements (e.g. binpkg
>> signing and verification)
>> * how should hosting look like
> Some ideas for portage enhancements:
>
> 1.  Ability to fetch binary packages from some kind of repo.
> 2.  Ability to have multiple binary packages co-exist in a repo (local
> or remote) with different build attributes (arch, USE, CFLAGS,
> DEPENDS, whatever).
> 3.  Ability to pick the most appropriate binary packages to use based
> on user preferences (with a mix of hard and soft preferences).
>
> One idea I've had around how #2-3 might be implemented is:
> 1.  Binary packages already contain data on how they were built (USE
> flags, dependencies, etc).  Place this in a file using a deterministic
> sorting/etc order so that two builds with the same settings will have
> the same results.
> 2.  Generate a hash of the file contents - this can go in the filename
> so that the file can co-exist with other files, and be located
> assuming you have a full matching set of metadata.
> 3.  Start dropping attributes from the file based on a list of
> priorities and generate additional hashes.  Create symlinked files to
> the original file using these hashes (overwriting or not existing
> symlinks based on policy).  This allows the binary package to be found
> using either an exact set of attributes or a subset of higher-priority
> attributes.  This is analogous to shared object symlinking.
> 4.  The package manager will look for a binary package first using the
> user's full config, and then by dropping optional elements of the
> config (so maybe it does the search without CFLAGs, then without USE
> flags).  Eventually it aborts based on user prefs (maybe the user only
> wants an exact match, or is willing to accept alternate CFLAGs but not
> USE flags, or maybe anything for the arch is selected.
> 5.  As always the final selected binary package still gets evaluated
> like any other binary package to ensure it is usable.
>
> Such a system can identify whether a potentially usable file exists
> using only filename, cutting down on fetching.  In the interests of
> avoiding useless fetches we would only carry step 3 reasonably far -
> packages would have to match based on architecture and any dynamic
> linking requirements.  So we wouldn't generate hashes that didn't
> include at least those minimums, and the package manager wouldn't
> search for them.
>
> Obviously you could do more (if you have 5 combinations of use flags,
> look for the set that matches most closely).  That couldn't be done
> using hashes alone in an efficient way.  You could have a small
> manifest file alongside the binary package that could be fetched
> separately if the package manager wants to narrow things down and
> fetch a few of those to narrow it down further.
>
> Or you could skip the hash searching and just fetch all the manifests
> for a particular package/arch and just search all of those, but that
> is more data to transfer just to do a query.  A metadata cache of some
> kind of might be another solution.  Content hashes would probably
> still be useful just to allow co-existence of alternate builds.
>

Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

[Jaco Kroon]

Hi Peter,

On 2021/02/09 19:51, Peter Stuge wrote:

> Joonas Niilola wrote:
>> There's a script by jkroon in data/api.git
>> (https://gitweb.gentoo.org/data/api.git/) that prints the next available
>> UID/GID pair for new acct-* packages.
> This is super nice! Thanks a lot jkroon!
You're most welcome.
>> It is not forbidden to mix and mash UID/GID between different packages,
>> but I'd still suggest to find a new "pair" even if you push just an UID
>> or GID. Since we don't seem to be in danger of running out any time soon.
> Mh - so the obvious first feature request for the script is to also output
> Free UID+GID pairs. Counting them manually in your screenshot I get 36.

https://github.com/gentoo/api-gentoo-org/pull/367

>
> That's not a whole lot; just 7% of 500.
Recommended GID only: 460
Recommended UID only: 458
Recommended UID+GID both: 326
Free UIDs: 200
Free GIDs: 177
Free UID+GID pairs: 160

Full count of 32% looks a tad better than 7%.

Re always picking a pair (raised in original email), my recommedation
would be:

Pick a pair if there is any chance that you might want the other
eventually too, else pick free uid/gid.

The problem with that is, if you don't take BOTH right now, someone else
might take the other, so perhaps the strategy of always picking a pair
is better ...

Then again, there are packages that need one UID and multiple GIDs, and
probably the other way around too, so not always picking pairs in such
cases makes a lot of sense too.

Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

[Jaco Kroon]

Hi Michał,

On 2021/01/10 15:34, Michał Górny wrote:
> Hi,
>
> The vast majority of libtool-based programs use configure script to
> generate libtool.  However, a few non-autoconf packages also use libtool
> by calling system-installed /usr/bin/libtool.  The problem is that this
> libtool hardcodes the values of CC/CXX at its' build time, so unless it
> is rebuilt frequently, packages end up using the stale values.
> The problem is known since 2005 [1] and hasn't been resolved yet.
>
> I can think of two ways of solving it:
>
> 1. We could patch system-installed libtool to respect environment
> variables such as CC, CXX, etc.  This will probably require carrying
> a (possibly non-trivial) patch forever.  On the bright side, libtool is
> not exactly a package seeing frequent releases.  I mean, the current
> version is from 2015.
>
> 2. We could regenerate libtool and force local instance of libtool
> in the packages needing it.  The main advantage of this is that it's
> a no-brainer.  I could make a quick eclass that does configure a local
> instance and prepends it into PATH.
>
> WDYT?

3.  Have it always use some fixed compiler somewhere (ie, compile it
with CC=/usr/bin/cc-libtool-wrapper CXX=/usr/bin/cxx-libtool-wrapper
which quite literally is just scripts that does):

exec "${CC}" "$@"

and

exec "${CXX}" "$@"

(with some added logic that if those variables points to itself it needs
to do a bit of extra work, or use "${LIBTOOL_CC:-${CC}}" style and
compile libtool with LIBTOOL_CC=${CC} CC=/usr/bin/cc-libtool-wrapper ...
I'd still add logic to detect the infinite recursion of CC=$0 though ...).

Would be happy to supply a suitable script if you're interested that you
can then just symlink the variants to
(libtool-tool-wrapper-{cc,cxx,ld,ar,...})

Kind Regards,
Jaco

[gentoo-dev] migration of "default" folders and fixups of exitsing installed folders

[Jaco Kroon]

Hi,

In some ways not unlike the discussion around users being installed and
later updated ... so I'm guessing I'm going to have varied opinions and
feedback on this potentially.  Ironically, asterisk was one of those
users that had it's home folder (correctly) adjusted from
/var/lib/asterisk to /dev/null.

In this case:

1.  I would like to update where asterisk stores astdb (partially for
security reasons);
2.  And on existing installs, /var/{lib,spool}/asterisk may well have
what I consider to be insecure ownership and permissions.

I have some ideas about the former (below), the latter I have no ideas
about.

There used to be a "fix permissions" script in the asterisk init script
(that was considered to be a security vulnerability, and was removed,
not to mention that it didn't exactly set same to be as secure as it can
be, and there are legitimate reasons to not use the strictest possible
permissions on *some* of the folders beneath both these locations, but
most of them should be root:root, and root:asterisk in specific cases,
and only in a very few cases asterisk:root possibly).  Suggestions on
fixing these permissions if (and only if) they were unmodified by the
user.  And making sure the user is aware of these.

Re the former:  https://bugs.gentoo.org/761442 relates.

History:

asterisk project simply used to install everything as
asterisk:asterisk.  Config files, resource files, everything,
irrespective of whether or not runtime required write access or not (I
think the exception was the binary and module libraries).  This was from
upstream project.  Myself and a few others started upsetting the apple
cart with things like "why are audio files installed writeable by
asterisk?".  Upstream caught onto this and started fixing some things up
(I don't have references, but things have definitely changed).

Bottom line:

/var/lib/asterisk used to be installed as asterisk:root, 750.

It's now being installed as root:root 755 (I'd prefer root:asterisk 750
personally)

There are only two pieces of information inside /var/lib/asterisk that
needs to (potentially) be writeable by asterisk.

1.  astdb.sqlite3 (and it's -journal file which doesn't always exist)
2. coredump/ folder (only required if configured to core dump).

The latter is a non-issue since this folder is specifically installed
asterisk:root.

astdb is a problem, since in order to create the -journal file I need to
give write access to asterisk to the folder (which I'd prefer to not do).

Disclaimer:  Depending on what you're doing there might be motivation to
have a few extra specific locations writeable by asterisk beneath
/var/lib/asterisk (we do have that, but this should be an explicit
action by the administrator in my opinion, if I could I'd install
everything there as root:root - which is just about the case currently).

What I'd rather prefer to do is to create an additional asterisk:root
astdb folder beneath /var/lib/asterisk and have asterisk use that for
astdb.  This is easy enough to configure, and even to update the default
config files.

But what to do with existing installations?  A person would need to "opt
in" to this change by way of etc-update I guess (I'll keep a ::gentoo
patch to basically enable the [directories] section, and to set astdbdir
= /var/lib/asterisk/astdb by default).  But unless the person modified
asterisk.conf (entirely possible, generally you don't need to customize
this config file) that will auto update this file.  And on next asterisk
restart the person will lose his existing astdb.sqlite3 file.

So ... I could check for /var/lib/asterisk/astdb.sqlite3 in init script
... but if the user opted out of te config update ... moving the file
here (which is a bad idea in my opinion anyway) is a terrible idea.  Not
moving the file will simply result in asterisk creating a new
astdb.sqlite3 file in the new folder - which carries risk if (and only
if) the user cares about persistence in astdb (which my systems
specifically don't, but some others do).  By *default* nothing that
asterisk itself stores into astdb requires persistence (but it is
preferred, for example, if I REGISTER to asterisk, it is nice that it
doesn't "forget" my registration over restarts or even reboots).

At this point I'm inclined to put a big ewarn in the updated ebuilds in
pkg_pretend, warning of this default config change (if you're updating
from an older asterisk where the default was /var/lib/asterisk),
installing the new folder and moving on with my life.  Since all my
installs already has /var/lib/asterisk/astdb on a ramdisk, I'm not
affected, but I really would prefer to not catch users off guard.

Currently new installs of asterisk is semi broken by default, easy to
fix either by chown asterisk:root /var/lib/asterisk, or by install -d
-oasterisk -groot -m0750 /var/lib/asterisk/astdb and simple (2 lines)
config change to /etc/asterisk/asterisk.conf.

Just looking for other possible approaches here.

Migration is also easy enough:  updat

Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih

[Jaco Kroon]

Hi,

On 2021/01/08 15:39, Andreas Sturmlechner wrote:
> On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote:
>> Would it be possible to point at alternatives?  pm-utils worked well for
>> me until now, and I'm fairly certain this won't be abandoned unless
>> there are other (better?) alternatives available.
>>
> It is replaced by elogind or systemd builtin functions.

Thank you.

Kind Regards,
Jaco

Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih

[Jaco Kroon]

Hi,

On 2021/01/06 23:08, Andreas Sturmlechner wrote:

> # Andreas Sturmlechner  (2021-01-06)
> # Abandoned upstream, countless bugs. Removal in 30 days. Bug #659616.
> sys-power/pm-utils
> sys-power/pm-quirks

Would it be possible to point at alternatives?  pm-utils worked well for
me until now, and I'm fairly certain this won't be abandoned unless
there are other (better?) alternatives available.

Kind Regards,
Jaco

Re: [gentoo-dev] RFC: dropping support for uclibc-ng

[Jaco Kroon]

Hi Thomas,

On 2021/01/05 13:08, Thomas Mueller wrote:
>> I'd like feedback from people about the possibility of dropping support
>> for uclibc-ng.  If you are unfamiliar, its the successor to uclibc as a
>> C Standard Library for embedded systems, ie a replacement for glibc
>> bloat.  However, it is inferior to musl which serves the same purpose
>> and which has now well supported in Gentoo.
>> I know people want musl support, but does anyone even care about
>> uclibc-ng?  If not, I can work towards deprecating it and putting what
>> little time I have towards musl.
>> Anthony G. Basile, Ph.D.
>> Gentoo Linux Developer [Hardened]
> Are you the only Gentoo developer working on musl and uclibc-ng?
>
> One thing I might try with a Gentoo uclibc-ng system is convert to musl or 
> glibc using crossdev.
>
> From what I see on the internet, there is more support for musl than 
> uclibc-ng, and more people working with musl than with uclibc-ng.
>
> There is a musl-cross-make cross-toolchain that can be built from non-musl or 
> even non-Linux.
>
> https://github.com/richfelker/musl-cross-make

I've used crossdev in the past.  It was a nasty experience, but I
believe crossdev in Gentoo is getting better and better, and it supports
many more targets.

> From what I have seen, musl looks more promising than uclibc-ng, and more 
> user- and developer-friendly.
>
> Unless somebody wants to take over uclibc-ng for Gentoo, I say better for 
> you, with your limited time, to drop uclibc-ng in favor of musl.

Not doing embedded work at the moment, but just out of hand as of right
now if I had to make a choice I'd definitely look at MUSL as first
choice.  So +1 for that suggestion.

Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

[Jaco Kroon]

Hi Peter,

I believe that as a maintainer I stated same in a previous email, and
based on what I've read it seems very few maintainers/developers would
object to it if someone was willing to do the work to enable things to
co-exist.  So a few points that I picked up during this discussion.

1.  Nobody is AGAINST libressl per sé,
2.  A number of people are AGAINTS the effort involved to make libressl
work for various packages.

Without the latter, libressl is dead since it can't install concurrently
with openssl.  Which is why someone needs to make the effort.  My
earlier suggestion for openssl-provider being an eclass I still think is
the best way to go, but this will require someone to write it.

With dubious benefits, I don't see a great many number of people jumping
at the opportunity, but I'm sure that if someone can manage the basis
for this, then sure.  Again, this will mean for libraries that they will
need to have multi-implementation installations again, consider the case
where package A links both package B and open/libressl, and package B
also links open/libressl.  In such a case package B would need to
install both variants if required.  Similar to x86_32 vs x86_64, or the
various different python versions if you will.  So we'd need
openssl-impl-multi and openssl-impl-single to accomodate these cases. 
So how do you deal with package-b-libressl vs package-b-openssl in terms
of dependencies?  Or must all libraries now that links one or both of
those also pull the same stunts (ie, install into
/usr/lib{,32,64}/{open,libre}ssl/) in order to not have conflicting linkage?

There are possibly cases where the consumer of package b can link
openssl where the library links libressl, but this would have name space
issues probably (you can refer to https://bugs.gentoo.org/649924 for the
kind of really hard to diagnose and fix bugs this results in).

Alternatively a virtual/libssl ... but these really only work where
there are COMPATIBLE APIs, which it's clear openssl and libressl is not.

There are other nuances involved too (ie, a -lssl without an explicitly
-L/usr/lib{,lib64}/sslimpl should fail, ditto for #includes without
specific -I) - it's going to be very involved (or at the very least the
DEFAULT implementation should be openssl).  Lots of very finicky risks
that needs to be eliminated wih installing both openssl and libressl
concurrently.

Which means:

3.  Very few people (if any) are going to be willing to put in the
effort to make the above happen.
4.  Even if you can make that happen, it now means that as a maintainer,
I still need to at least compile-test every package release that I
maintain against both openssl and libressl - and either ban one
implementation or the other or patch it, again ... which is exactly what
developers/maintainers are complaining about.

So, if you are offering to put in the work required to make this happen,
sure, I'm sure the patches would be welcome, and I'm sure a number of
people would be willing to help you test and provide suggestions even.

If you want to drive libressl, the way musl and the like are driven,
filing bugs against packages that doesn't work well, and assisting with
patching, I'm fairly certain most developers won't mind, however, myself
included, would want to do as little as humanly possible around it.  Of
course I'm fortunate in that my primary upstream is very supportive and
welcomes patches (of which I've submitted a number of over the last
decade), which means I don't have to carry patches in gentoo.git for the
most part.

Unless you, or someone else, is willing to put in that effort I'm afraid
I have to agree with most other devs:  libressl is a novel idea and
concept, but it's dead.  Someone (Michał?) mentioned it's more pain than
gain currently.  And unless someone is willing to change that, I
seriously doubt anything you say is going to carry much weight.  What
people are asking for is the motivation that you have whereby you feel
the gain is worth the (significant) pain.  I too like the concept of
alternative choices, but each choice comes with a cost, and if the user
isn't paying that cost, a developer somewhere is.  And having written my
fair share of code - the level of ask that you're asking for is much,
much larger than I think you realise.

mysql and mariadb started out very similar, and now there are two major
projects, and parts of it are installable separately (client libs).  I
believe there was even work done to be able to install multiple server
versions concurrently (But since I don't have a requirement for this, I
haven't followed in detail).  Needless to say, it's a LOT of work for
even the basics of what you're requesting.

To the best of my knowledge most Gentoo devs aren't getting paid to just
sit and do this work.  If we get paid for doing work on Gentoo at all
(or rather, sanctioned to as part of our employment duties) we are
fortunate, I believe it's usually an employer that has vested interest
in Gentoo, and then

Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Jaco Kroon]

Hi Peter,

On 2020/12/29 13:29, Peter Stuge wrote:
> Michał Górny wrote:
>>> I'm sure that there are numerous cases where libressl doesn't work,
>>> but that's no reason to dismiss cases where it *does*.
>> Are you asking people to put an effort into maintaining something that
>> can't be practically installed?
> No, I'm rather asking to change the level of commitment.
>
> I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> to continuosly patch the entire world for libressel.
>
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where that is possible without patches, even
> if that's only openntpd and one other package.

Are you willing to put in the work to allow installing openssl and
libressl concurrently on the same system?

And I raise this, because as others have insinuated, currently it's one
or the other, they can't co-exist, and there are a great many number of
packages that doesn't work with libressl.  The only real solution then
to make libressl viable is to make it co-exist with openssl reliably.

Of course there are various strategies (or combination of), to mention
but a few:

1.  Use a virtual/??? (but since the APIs aren't compatible despite the
libressl promise thereto ...)
2.  Install them into different prefixes (eg /usr/lib/openssl +
/usr/lib/libressl and have the linker link to a specific version,
/usr/include/{openssl,libressl} too).
3.  Make ssl USE flag another single-choice USE_EXPAND, posibly by way
of openssl.eclass.

My personal support currently goes towards at the very least masking
libressl, but removal unless someone is going to put in the effort
towards the above.  Happy to help with patching on my own packages, but
without concurrent install of libre+openssl it's a massive workload to
test for me, so not happy with current state either.

+1 for removal given current state, but would be in willing and in
support of updating the packages I maintain to assist with libressl
support if the eco system can be improved.

Kind Regards,
Jaco

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

[Jaco Kroon]

Hi,
>> Hmm, how would that work?
>> I have package A with a binary /usr/bin/binA linked to liblua51.so (which in 
>> your suggestion would change to /usr/lib64/lua5.1/liblua.so) and
>> and /usr/bin/binB linked to liblua52.so (or /usr/lib64/lua5.2/liblua.so).
>> I don't see any ordering of /usr/lib64/lua5.1/ and /usr/lib64/lua5.2/ 
>> that allows for binA and binB to find their correct lua libraries.
>> (This doesn't need to be for binaries, other shared libraries even)
>>
>> Admittedly, I am not a lua or linker expert...
>>
>> Aisha
>>
>>
> My intention with the suggestion was that the actual library be stored
> in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a
> symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so.  When
> you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the
> file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it.
> That will cause the linker to store "liblua52.so" as a DT_NEEDED entry
> in the executable.  At runtime, the runtime linker ld.so
> (/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to
> find the library liblua52.so, which is in /usr/lib64, so it will be
> found without any ld.so.conf tricks.  This requires no special runtime
> support, as the actual name the compiler/linker will end up storing in
> the output contains the proper version.  This means that if
> /usr/bin/binA linked to liblua51.so (via the linker finding
> /usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so
> (likewise), they would both be able to find the correct libraries, as
> the DT_SONAMEs are different.
net-misc/asterisk don't need this (any more,
https://gerrit.asterisk.org/c/asterisk/+/15234), but I'd be in support
of something like this as a general "pattern", both for lua as well as
other SLOT'ed libs.  I might suggest that /usr/lib64/lua5.x/ is perhaps
not the most ideal location, since include headers needs to match too
... and most of these ./configure type things just take --with-lua=PATH
and I think assume $PATH/include + $PATH/lib{,32,64} ... granted they
also allow for additional LUA_INCLUDE environment variables in *some* cases.

So perhaps something we can learn from the "scripting" world ...

/usr/pkgslots/${pkgname}/${version}/{include,lib64,lib32} kind of thing,
with as few as possible actual directories, preferring symlinks and
definitely no files ever.

So for lua5.1, this would be something like:

/usr/pkgslots/lua/5.1/
   include => /usr/include/lua5.1
   for X in so{,.0,.0.0.0} a la:
   lib{32,64}/liblua.$X => /usr/lib{32,64}/liblua5.1.$X

This might be worth an eclass (which I'd love to take a shot at,
probably with LOADS of help) if there is general interest in making this
a kind of pattern.

Having said all of that, I tend to agree that ./configure should as a
rule try to use pkgconfig whenever and wherever possible.

Kind Regards,
Jaco

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

[Jaco Kroon]

Michael,

I'm busy disecting what Marek has done for asterisk as I need to make
that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
merely the one he did it for - perhaps that would be helpful for you as
well?

I don't know lua at all.

Anyway, I'm on IRC as jkroon if you'd like to exchange notes.  I don't
particularly like the patch Marek did as I'll NEVER be able to push that
upstream.  The patch will work for us, but as a policy I highly prefer
patches which I can get unstreamed such that we don't need to carry them
more than one or two versions.

I'd prefer to patch upstream to keep it's behaviour of detecting a lua
version, but have a --with-lua(version)? type argument that can take an
optional argument which will then be the version, but --with-* generally
takes a prefix where the include and lib folders can be found ... and
I'd prefer to depend on pkg-config as primary and fallback to the
./configure mess which tries to guess at things ...

Kind Regards,
Jaco

On 2020/12/23 14:49, Michael Orlitzky wrote:

> On 12/23/20 4:09 AM, Marek Szuba wrote:
>>
>> I think what you are looking for is lua_get_shared_lib() from
>> lua-utils.eclass. We have already got ebuilds in the tree which use
>> it.
>>
>
> Knowing the library name only helps if I patch the build system;
> that's what I'm getting at. The few packages where this works use
> CMake, and CMake already tries to guess[0] the name of the lua library
> (thanks Debian) and so it has a pre-defined variable to store the result.
>
> Not all build systems are going to work like that. Suppose I know that
> the name of the lua library is "lua5.2". An autotools build system is
> going to run something like,
>
>   AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"])
>
> How do I pass the name "lua5.2" to that, without hacking configure.ac
> and running autoreconf? The only option that comes to mind is to build
> the entire project with LIBS="-llua5.2", but that's not right if only
> some of the executables are supposed to be linked with lua.
>
> For contrast, if the lua library was stored in /usr/lib64/lua5.2, then
> I could just set LIBS="-L/usr/lib64/lua5.2" and let ./configure do its
> thing.
>
>
> [0] https://github.com/Kitware/CMake/blob/master/Modules/FindLua.cmake
>

[gentoo-dev] possible additional tag for GLEP66: Pending

[Jaco Kroon]

Hi All,

When bumping for security updates, the requirement is that the
replacement ebuild be stabilized (the GLSA be issued), and then to clean
up the tree of vulnerable versions.

As a proxy maintainer, the addition of a tag to queue a PR pending a
specific Bug be closed first would in this scenario be potentially
beneficial.

Specifically, what I suggest is to flag the PR that fixes the issues
(ie, ebuild bump) with the usual Bug: tag, but to then at the same time
be able to pre-emptively file a PR removing the vulnerable versions, but
only once the security bug has been handled (closed).

Towards this end, I'd suggest a tag such as:

Pending: https://bugs.gentoo.org/NN — to reference a bug; the bug
needs to be closed before this PR will be considered for merging.

Obviously it's also possible to file a second bug that depends on the
security bug, but this doesn't block merging.  QA checks doesn't make
sense to run (since this remove commit will mostly likely remove all
current stable versions).

Ideas and thoughts around this?

Kind Regards,
Jaco

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Jaco Kroon]

Hi Ulrich,

On 2020/11/09 12:59, Ulrich Mueller wrote:
>>>>>> On Mon, 09 Nov 2020, Jaco Kroon wrote:
>> What is the actual "target" objective with the change?  I would have
>> expected (not being one to follow this too closely):
>> lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
>> lib32/ - 32-bit specific stuff (libs for 32-bit).
>> lib64/ - 64-bit specific stuff (libs for 64-bit).
> It is explained here:
> https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale

Thank you, that makes a lot of sense and answers all my questions
...just wondering where the lib32 => lib symlink comes from now.

So if anybody else ends up wondering:

jkroon@plastiekpoot ~ $ ls -lah /lib32 /usr/lib32 /usr/local/lib32
ls: cannot access '/usr/local/lib32': No such file or directory
lrwxrwxrwx 1 root root 3 Nov  9 10:02 /lib32 -> lib
lrwxrwxrwx 1 root root 3 Nov  9 10:02 /usr/lib32 -> lib

equery has some answers that there are still stuff installed into
/usr/lib32 (which will likely clear over time, and the symlink will be
unmerged).  There is this one potential pitfall down the line that I'm
seeing, fairly certain this would have been covered and that a remerge
of glibc will fix this:

jkroon@plastiekpoot ~ $ equery belongs /lib32 /usr/lib32
...
sys-libs/glibc-2.32-r2 (/lib -> lib64)

So job well done to the implementation team!!  Great work thank you!

Kind Regards,
Jaco

Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

[Jaco Kroon]

Hi,

Having just completed the migration on two systems I found some things
which concerns me:

1.  A default/linux/amd64/17.0/desktop to
default/linux/amd64/17.1/desktop.  This differs from the no-multilib in
that there are symlinks now for the various lib32 to lib.  No such
symlinks on the no-mulilib systems (this makes sense, but why is lib32 a
symlink back to lib/)

2.  If /usr/local/lib* doesn't exist the script bails out.  This only
happened on one of the two systems I did now, specifically the
default/linux/amd64/17.0/no-multilib =>
default/linux/amd64/17.1/no-multilib one.  Other systems I've just
checked seems to already have this by virtue of
/usr/local/lib{64,32}/.keep existing, but no owners of the files, so
this could be sheer dump luck.  Which is never good.  Sorted by manually
creating lib32 and creating the symlink as instructed.  Post migrate
there is a lib/ and lib64/ folder.  The complaint on this was about
/usr/local/lib32 if I recall correctly

What is the actual "target" objective with the change?  I would have
expected (not being one to follow this too closely):

lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
lib32/ - 32-bit specific stuff (libs for 32-bit).
lib64/ - 64-bit specific stuff (libs for 64-bit).

What am I missing?

Kind Regards,
Jaco

On 2020/10/22 21:16, Andreas K. Hüttel wrote:

> Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny:
>> On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote:
>>> Users frequently are choosing the wrong profile versions in new installs
>>> and accidentally downgrading to 17.0 with some saying they see it first.
>>>
>>> A simple reordering could help new installs.
> Independent of this useful change, it's probably time to deprecate the amd64 
> 17.0 profiles!
>

Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

[Jaco Kroon]

Hi,

On 2020/11/09 08:46, Joonas Niilola wrote:

>
> On 11/9/20 12:17 AM, Kent Fredric wrote:
>> On Wed, 4 Nov 2020 17:34:07 +0100
>> Marek Szuba  wrote:
 x11-terms/rxvt-unicode 
>>> Will co-maintain this one with conikost, don't mind being listed as 
>>> primary maintainer.
>> If you strike an issue that you think should be followed upstream, rope
>> me in. (put me on the bottom of the maintainer list if you want)
>>
>> I'm not interested in maintaining it directly, but I use it, and do
>> have workable rapport with upstream :)
> http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.man.in?revision=1.130&view=markup#l176
>
> I find this an issue WITH the upstream...

Whilst I use rxvt-unicode myself I can't help but agree with Joonas.

You mentioned working raport with upstream?  Can we rely on that to at
the very least get them to update that to "due to the way Gentoo
functions we request that you first file issues with the Gentoo
repository rather than directly with rxvt-unicode?  That is pure and
outright slander, and whilst I "get" (to an extent) and GNU/Linux
statement - he should then have the same issue with RedHat Enterprise
GNU/Linux.  Or with "Debian" and "CentOS" for that matter which does not
contain "GNU/Linux" in the name.  Alternatively if there is no issue
with that then perhaps we should consider just being "Gentoo" ...

Also happy to help with solving issues if/when they occur, granted the
only X development experience I've got is via Qt3 at the time ... so
happy to help, so not sure how much help I'll be, but happy to help with
testing.  Welcome to CC me on bugs.

Kind Regards,
Jaco

Re: [gentoo-dev] [PATCH] glep-0068: Add new element

[Jaco Kroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2020/09/16 11:39, Michał Górny wrote:

> On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
>>
>>> +- at most one  element containing
version
>>> +  constraints used to determine stabilization candidates, as detailed
>>> +  in `Stabilization candidates`_.
>>> +
>> At most one ...
>
> Do you mean capatilization?  It's following suit with other items here.
Sorry, was unclear, this correlates with the second comment below.
>>>  - zero or more  elements, possibly restricted
>>>    to specific package versions (at most one for each version) whose
presence
>>>    indicates that the appropriate ebuilds are suitable for
simultaneously
>>> @@ -199,6 +203,25 @@ The  element can contain the
following elements:
>>>  - at most one  element describing the role of
subslots (all
>>>    of them) as text.
>>>  
>>> +Stabilization candidates
>>> +
>>> +Each  element describes version
>>
>> vs each (implies any number).  I'd simply say, "If present, the
``
> Again, this follows suit with other descriptions.

If this is the standard, this is the standard, was just trying to point
out that this could be considered a conflict.

>>> +constraints used to determine package versions eligible
>>> +for stabilization.  Should this element be missing, the tooling assumes
>>> +a default of any version with any keywords present (i.e. the equivalent
>>> +of ``>=0``).
>>> +
>>> +The  element can contain the following
>>> +elements:
>>> +
>>> +- one or more  elements, each containing a version
>>> +  constraint in the format matching EAPI 0 dependency specification
>>> +  with the package category and name parts omitted, e.g. ``<1.7``.
>>> +  The tooling considers any ebuild version that satisfies the
constraint
>>> +  and has any keywords.  If multiple constraints are provided,
every one
>>> +  of them is matched separately, and multiple stabilization candidates
>>> +  can be reported.
>>
>> I think it's clear from context that there should be one or more, but
>> the language ("can contain" in the leading paragraph) implies all sub
>> elements are optional.  Perhaps:
>>
>> The ... element:
>>
>> - must contain one or more ...
>>
>> Which also allows for future "may contain" sub elements.
>>
>
> To be honest, I'm not sure if we should permit or prohibit empty element
> in the spec.

pick one.  But I'd use the word may (clearly optional) or must (clearly
compulsory) rather than can.

Kind Regards,
Jaco


-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl9h9YMACgkQCC3Esa/3
7p5XtQf9H6kcStCzBz75rOVhoswzhIafZWXJnurAYHvEvM3vrWrMzh46Bc3aZZLo
fo2+lg7Z9lw0iBxJjub/nexBR9D8XwCa3aW/G75Hgd5XcC54LfKRFGqGKHS9Zu9z
GT96Ijqo4aS2PlepD0Qk8jVTnngzB5opasH3nNgR2u6WSEQHtkCE8lg2A1Z0hr3i
PmO/kzvHnZxsais9wp7kkZn+ftGbI1Wuq6Gus3Yy3qWp2k6KTwD49VdN3y7Skk3s
T3ULl/+ui/FqwGGDjlQw0MW8o2mJ76VrQoMTiMG7IErFz9BzJ3djf/bgXg8YjHc5
kjo/h1tLcj7WvLphz9gdhGt4Sk85Sw==
=WdPf
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH] glep-0068: Add new element

[Jaco Kroon]

Hi Michał,

Thanks for your efforts.  This looks interesting at the very least, and
whilst in many cases on posts on this ML I'm on the "don't care" stance,
this one looks like it could solve some problems for me. 
net-misc/asterisk + friends will definitely make use of this.

Two nitpicks below that doesn't really carry significant meaning.

On 2020/09/16 07:48, Michał Górny wrote:

> Signed-off-by: Michał Górny 
> ---
>  glep-0068.rst | 62 ---
>  1 file changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/glep-0068.rst b/glep-0068.rst
> index d8fc379..5b7e2b9 100644
> --- a/glep-0068.rst
> +++ b/glep-0068.rst
> @@ -4,10 +4,10 @@ Title: Package and category metadata
>  Author: Michał Górny 
>  Type: Standards Track
>  Status: Final
> -Version: 1.1
> +Version: 1.2
>  Created: 2016-03-14
> -Last-Modified: 2020-05-06
> -Post-History: 2016-03-16, 2018-02-20
> +Last-Modified: 2020-09-16
> +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
>  Content-Type: text/x-rst
>  Requires: 67
>  Replaces: 34, 46, 56
> @@ -149,6 +149,10 @@ element can contain, in any order:
>languages (at most one for each language), as detailed
>in `Slot descriptions`_.
>  
> +- at most one  element containing version
> +  constraints used to determine stabilization candidates, as detailed
> +  in `Stabilization candidates`_.
> +
At most one ...
>  - zero or more  elements, possibly restricted
>to specific package versions (at most one for each version) whose presence
>indicates that the appropriate ebuilds are suitable for simultaneously
> @@ -199,6 +203,25 @@ The  element can contain the following 
> elements:
>  - at most one  element describing the role of subslots (all
>of them) as text.
>  
> +Stabilization candidates
> +
> +Each  element describes version

vs each (implies any number).  I'd simply say, "If present, the `` +constraints used to determine package versions eligible
> +for stabilization.  Should this element be missing, the tooling assumes
> +a default of any version with any keywords present (i.e. the equivalent
> +of ``>=0``).
> +
> +The  element can contain the following
> +elements:
> +
> +- one or more  elements, each containing a version
> +  constraint in the format matching EAPI 0 dependency specification
> +  with the package category and name parts omitted, e.g. ``<1.7``.
> +  The tooling considers any ebuild version that satisfies the constraint
> +  and has any keywords.  If multiple constraints are provided, every one
> +  of them is matched separately, and multiple stabilization candidates
> +  can be reported.

I think it's clear from context that there should be one or more, but
the language ("can contain" in the leading paragraph) implies all sub
elements are optional.  Perhaps:

The ... element:

- must contain one or more ...

Which also allows for future "may contain" sub elements.

Kind Regards,
Jaco

[gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280

[Jaco Kroon]

Hi All,

https://bugs.gentoo.org/731280

Summary:

This machine uses a clang/LLVM toolchain.
Asterisk fails to compile, ./configure fails with:

checking for RAII support... checking for clang -fblocks...
configure: error: BlocksRuntime is required for clang, please install
libblocksruntime

I suspect this explains the issue:

https://github.com/mackyle/blocksruntime

I have no idea how to actually solve this.

If someone can help that would be great, else I have no choice but to
mark as CANTFIX.

Kind Regards,
Jaco

Re: [gentoo-dev] Packages up for grabs: sys-fs/fuseiso

[Jaco Kroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2020/08/13 22:30, Jonas Stein wrote:

> Dear all
>
> the following packages are up for grabs after retirement
> of the proxied maintainer:
>
> sys-fs/fuseiso
> https://packages.gentoo.org/packages/sys-fs/fuseiso
>
What's wrong with mount -o loop /path/to/iso /path/to/mount/point?

Based on version this looks like an abandoned project ...

and on SF at least ... last commit in on 2008-02-29?

The ebuild itself (other thank a single sec update thanks to Sam who
seems to be tracking everything security related out there) there has
been no real work (other than dragging it along, changes probably
suggested by automated checks for the most part) done since dist tree
migration from CVS to git.  The only "major" commit other than Sam's
security update to add a patch was to update the syntax for dependencies.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl81pxMACgkQCC3Esa/3
7p7rggf/VuEVBp+jymxdrJUeMhL3hKta+5fIXjyt2WJ3BjcGYzWX9VOIfc/kDEP8
ZNoaNNlL+1KrtzWE6pDfSTODljd9mCZFwsicmbrn1hXyqeg0/vMkUoT/l7tD+0t0
DsdLWXVCm1sG26S54VZ9bHbakGiQZZgD7kAXfJkfR0TsaAXS93zS+EFuYza1EcaT
D8epEQvkTc82Zy8NHzlpzjk+G01VMbl9NEsWX6lHInYmFBM+9k4PRoJd0RE1ISXd
0Idypn+Giz5nZ7gWFAz2CUlNVJzHqhiHlPPlF26OznQ2ZgMPd7cbr/atJe7CQ9BR
iCZw2o98tYEZDxg362iyk4kcTxPeSg==
=JPT6
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

[Jaco Kroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

> As I have said earlier on the thread, we should look at udev and seee if
> it breaks things in relation to eudev. That would take some folks
> migrating their systems and reporting issues.

And I've already provided you one use case where udev doesn't work well
but eudev does.  I've also mentioned some historic issues I believe
should already be fixed but which did bit me in systemd-udev which was
never a problem in eudev.

But then again, with past experience I'm now one of those that refuse to
install systemd-udev and give it a twirl on production systems to see if
it's still an issue whereby I end up rebooting servers on a weekly basis.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8yWHEACgkQCC3Esa/3
7p6w1wf/clHZuUn3KgCheQQvEyBSBf3IEmXgN+ejtxGNn+cyK4p6A7j3dU6n9ain
aPcL4zGOkixHpEwhz2bQAIljEtHI2wYhBYBv7+c9mUEmbSp7xhwZUvZd1a69YUk1
cEclzHGlKQwcRFqyrGIOLk6/iuwr8REavd1EwcLsrXeuCI7xukFRdHeOideGCztI
4ziK6QZaN/BZ1ZPV1yzdheBq2E0tAiMRG2gKiuNopBEETc+PpegUPsk6T4dnmEZV
EGG3LlzpufgPUF+qymzyRiT94i7azebfO17hOzJ4cZJXi7Lz9dzUTrxJvpYknbzp
XruDKuoRBSPp5OQ2ZeO/0Q0L8WILZg==
=Q6Bl
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

[Jaco Kroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It actually works is enough reason for me.  Was forced to migrate a
> bunch of systems not six months back from systemd-udev to eudev because
> systemd-udev is absolutely terrible w.r.t. race conditions resulting in
> lockups that kept forcing us into manual intervention situations.
> Mostly on systems with LVM.
>
> > I don't exactly know what your situation is, but as I said, this
> > proposal wouldn't affect your systems. I'm not talking about lastrites
> > for eudev, just making it the default for new installs.

It would affect new installations.  But yes, we can switch it back to
eudev post install.

>
> I'm completely against the proposal.
>
>  I would want some convincing that it was not another step on the road
>  to Gentoo being assimilated by systemd.
> 
>  We had this discussion several years ago when the default became
>  eudev. What's changed?
> >>>
> >>> If systemd folks do make udev inseparable from systemd, then we would
> >>> need eudev to be the default, but as I see it right now, there is not
> >>> a case for it being the default.
>
> Other than that it works and the systemd version does not.  Might be
> configuration dependent, but I don't expect a default udev
> configuration/system side to not cause LVM breakages when running
> commands as simple as "lvs".  eudev in coparison just works.
>
> >  I don't know what is going on with your systems, but I suspect possible
> >  configuration dependence.

Ok, simplest mechanism we've found:

Install a system with at least one LV partition and leave some space
available in the VG, then do:

term 1:  watch lvs

term 2:  while true; do lvcreate -L1G -s -ntemp_snap /dev/${vg}/${lv} &&
lvremove /dev/${vg}/temp_snap; done

Give it anywhere from two two five minutes.  Can be hours sometimes. 
But eventually it does die.  Can't say the same for eudev.

>
> > When are the breakages happening-- just at random or during bootup?

In some cases rebooting is the only way to recover.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8vJyEACgkQCC3Esa/3
7p4eewf/bOXgnx4n30HUZnTmvhyjC4F2MTc8bOwYj45t+UMeGoIN8C+GMHxWMGvG
NQpoK2hkY8egykCbuO4rSBwV9YS/naAiAZEcEXCPdcAUgV2FxJSGWKCLDLfTiflg
vXCLpd8ybxVbVhEO5XU8K4jTc9fc4peY/4ZVK0Lhl80rzWLf/yrc9+IurBZE+0g0
GXpHxNa6e2AZWPFyNXMu83fatlyOZpy/WXE7owb+yLPwTJPs30W9OLFQ6lWXSLdx
FGyLBh8vFn9BExF3IS1ZgKYIBRrH45AazMNV3+fvO+aZX/6UfXDID/JDjXHdq3bl
awMSVX40kYbgskCkOwf5DreCrs7nBw==
=ROIf
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

[Jaco Kroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2020/08/08 22:57, William Hubbs wrote:
> On Sat, Aug 08, 2020 at 09:17:20PM +0100, Roy Bamford wrote:
>> On 2020.08.08 19:51, William Hubbs wrote:
>>> All,
>>>
>>> I would like to propose that we switch the default udev provider on
>>> new
>>> systems from eudev to udev.
>>>
>>> This is not a lastrites, and it will not affect current systems since
>>> they have to migrate manually. Also, this change can be overridden at
>>> the profile level if some profile needs eudev (the last time I
>>> checked,
>>> this applies to non-glibc configurations).
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> William
>>>
>>>
>>
>> William,
>>
>> With the declared aim from upstream of making udev inseparable from
>> systemd, its not something to be done lightly.
>> That's the entire reason that eudev was necessary.
>  
> Eudev never became necessary unless you are using a non-glibc system,
> and as I said, this can be handled in the profiles.
> Udev  runs completely fine without systemd, so I fail to see how eudev
> is necessary for most of Gentoo.

It actually works is enough reason for me.  Was forced to migrate a
bunch of systems not six months back from systemd-udev to eudev because
systemd-udev is absolutely terrible w.r.t. race conditions resulting in
lockups that kept forcing us into manual intervention situations. 
Mostly on systems with LVM.

I'm completely against the proposal.

>> I would want some convincing that it was not another step on the road
>> to Gentoo being assimilated by systemd.
>>
>> We had this discussion several years ago when the default became
>> eudev. What's changed?
>
> If systemd folks do make udev inseparable from systemd, then we would
> need eudev to be the default, but as I see it right now, there is not
> a case for it being the default.

Other than that it works and the systemd version does not.  Might be
configuration dependent, but I don't expect a default udev
configuration/system side to not cause LVM breakages when running
commands as simple as "lvs".  eudev in coparison just works.

>
> Another thing to consider is bus factor (eudev is maintained by one
> person primarily, so I have doubts about its viability as the default.

Yes, this is a problem.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8vG1AACgkQCC3Esa/3
7p7Yvgf6Apoi1oCUKSyLEvH8fAEgbMIODULJAZx5+/C1dbROdjkWEzTTp3pNjWiQ
u8S2qz3xmh9QmKBwTAxB38U/gqXVRpF+xYfSF7K/CDUVcfAg5ViTL3W7YeJMPFNa
Jk8BgrarAc1Ln8OXCJ37Gf0eeuyBTsQQQ5qqubzNjdLBhrZegWY57gElrItE0Ywb
IjVBUO4QX3PSoOpZ5UlIo8Ioh+8ANXc/ADg7wASVQkd3dciyewZasZho/q6cNn6W
c44aMNFRTeiUfcK4+bpGMslq70y7D7JITkjkP+9e68e8wkh93L8fVs4BszBYEtUY
G6IXc4QtJ5Jf3bQRbyCnGcFYXrSLgg==
=rF5/
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

[Jaco Kroon]

Hi,

On 2020/08/06 21:45, Thomas Deutschmann wrote:
> On 2020-08-06 20:56, Rich Freeman wrote:
>> Has anything even changed with kexec?  Or is this an issue that has
>> been an issue for many years in kexec, that will suddenly become an
>> issue in genkernel?  In that case it is news from a genkernel
>> perspective, and something anybody with a correctly-booting system
>> fixed a long time ago if they're using kexec.
> Well, first it was an annoyance I became aware of myself when I noticed
> a system having dozen of root arguments in kernel command-line. I think
> we even talked about this in #gentoo-base a while ago:
>
>> # cat /proc/cmdline
>> domdadm dolvm dosshd crypt_root=UUID=a-b-c-d root=UUID=e-f-g-h rootfs=xfs 
>> scandelay=3 root_trim=yes vga=0x317 gk.log.keep=/var/log/genkernel-boot.log 
>> root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  
>> root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  
>> root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  
>> root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  
>> root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  
>> root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2  root=/dev/dm-2
> ...you can count how often the system was rebooted using kexec ;)
>
> This week I also received a bug report from a user who upgraded to
> genkernel-4.1 where first reboot failed but everything was working after
> a reset (cold boot).
>
> During my investigation I was able to trigger this by myself, for
> example when I close and re-open LVM volume and trigger new symlink for
> re-opened root volume (this sounds like a non-typical use case for some
> people but when dealing LVM backups/snapshots it's not that uncommon).
>
> So this became a bug for me in our kexec runscript which I fixed
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4860fce5434f46d90e913ff10515a9a256fc6c6a
> and already warn about
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61c03ffab76740c0420e3c8a3185d047d461f7a7

Can you detect in the runscript that this will trigger and issue a cold
reboot instead if this would trigger?

Having never used kexec before ... I may well be missing the point.  But
I'd rather have the system issue a cold reboot if kexec (which sounds
really cool in principle) stands any chance of failing.

Kind Regards,
Jaco

[gentoo-dev] Re: Last rites: net-libs/osptoolkit

[Jaco Kroon]

Thanks for sending this.


Kind Regards,
Jaco Kroon
CEO

*T:* +27 (0)12 021  | *F:* +27 86 648 8561 | *E:* j...@iewc.co.za
*W:* iewc.co.za <https://www.iewc.co.za/> | *A:* Unit 201, Building 2B,
Sunwood Park, Queen's Crescent Lynnwood, Pretoria


    

Facebook <https://www.facebook.com/Interexcel/> Twitter
<https://twitter.com/Interexcel/> Google+
<https://plus.google.com/+InterexcelCoZaPTA/posts> LinkedIn
<https://www.linkedin.com/company/interexcel-world-connection/>

IEWC <https://www.iewc.co.za/> ULS Group <http://www.uls.co.za/>

On 2020/07/20 23:46, Sam James wrote:
> Hi all,
>
> net-libs/osptoolkit is masked for removal:
>
> # Jaco Kroon  (2020-07-20)
> # net-misc/asterisk was only consumer, dependency now removed (due to failures
> # in osptoolkit build). No known users of USE=osplookup in net-misc/asterisk,
> # and unknown usefulness. bugs #674346, #731250
> # Removal in 30 days.
> net-libs/osptoolkit
>
> Thanks,
> Sam

Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode

[Jaco Kroon]

Hi,

On 2020/06/30 16:19, Max Magorsch wrote:

> Hi Aaron,
>
> Thanks for your suggestion.
>
> On Tue, Jun 30, 2020 at 1:16 AM Aaron Bauman  wrote:
>> Hi, Max. A couple thoughts... Just let me know if they are too crazy.
>>
>> 1. Could you enable the backend to ping devs/projects via email when a new 
>> release is available for their respective package(s)? Maybe make it optional 
>> for the dev/project to enroll?
>>
> I could imagine packages.g.o to provide different feeds (e.g. about
> new releases of package(s) on a per maintainer/project basis).
> Following this idea:
>
> 1. Everyone might directly subscribe to the packages.g.o feeds he is
> interested in, to get notified
>
> 2. We might additionally create a sidecar application which consumes
> the feeds and notifies developers/projects. This might be configurable
> so that developers and projects can choose the warnings they would
> like to receive.
This would be great.
>> 2. What about a setting to allow the Python team to deprecate a particular 
>> interpreter then notify respective pkg owners that their ebuild needs 
>> updated?
>>
>> This would possibly workaround the issues mgorny brought up regarding 
>> package.deprecated and noise for CI checks. Also, not sure if this is best 
>> implemented somewhere else first (e.g. pkgcheck) then leveraged by your work.
>>
> Same goes for your second idea. The sidecar application might also
> handle notifications like that in this scenario.
>
> By splitting this into two applications, packages.g.o would continue
> to focus on providing the package data while we might get a second
> application which handles all of the notifications.
>
> What do you think?

Anything that'll help avoid the python dependency hell the next time
round there are python changes.  perl used to be the bane of my
existence but for the last few years that dubious honour has gone to
python.  Not as a developer.  As a user.

texlive is the other one that annoys me from time to time but an emerge
-C $(qlist -IC dev-texlive/*) + remerge generally fixes that.  For
python that's a death sentence.

For that matter, if a CI check gets introduced and one of my packages
are now affected this would be helpful too to get a notification, eg,
let's say EAPI=6 now gets deprecated, getting a notification that
packages x/y for which I'm responsible would be helpful, rather than
being caugh off guard when next I bump, or worse, if there is no new
version, EAPI=6 just going away completely before I notice.  Bad example
since EAPI's remain very long past deprecation, but you get the point.

Kind Regards,
Jaco

Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug

[Jaco Kroon]

Hi Aisha,

On 2020/06/12 13:44, Aisha Tammy wrote:
> On 6/12/20 6:55 AM, Jaco Kroon wrote:
>> Hi,
>>
>> Can we possibly include the concept of "helping to file bug reports" here?
>>
>> For example, I've got an issue (which hasn't annoyed me just quite
>> enough yet to put effort in) where on bootup after xdm init script
>> starts it takes ~2 minutes before slim login is displayed.  But I don't
>> know enough of the workings of that to even understand if this is an
>> Xorg or slim (or dbus) bug ...
>>
> BugDay is not for creating bugs, its for squashing them.
>
> You can create the bugs today and then if it is in one of the top voted 
> categories (old bugs, in this case) you might be able to convince interested 
> devs to target your specific ones.

Fair enough.

In this case I've no idea where to start with filing a sensible bug
though :).  So what it really boils down to is that I think we need to
provide a way to help users help us by providing the ability to interact
with people (Yea, #gentoo works up to a point) that can assist with
basic trouble-shooting to point people towards that which could be the
problem to help with filing better bug reports.

I've been hunting a graphics terminal corruption issue with urxvt now,
and in the man page you get this:

   [Please note that many X servers (and libXft) are buggy with
respect to "-depth 32"
   and/or alpha channels, and will cause all sorts of graphical
corruption. This is
   harmless, but we can't do anything about this, so watch out]

So where to from here?  Researching that it seems most other similar
reports relate to 4th-gen intel graphics ... heck, this was even
attributed to pango at some point, and some other dock launcher which
name I can't remember now.  I've now explicitly set depth to 24 so I'll
know soon enough if this is the issue.  To confuse the matter even more,
I've had the same corruption using aterm, and in xterm as well.  But it
*only* seems to happen with terminal emulators.

Then there is the issue I described above.

Currently I have another two or three *desktop* related issues that
plague me, none of which are easy to point where the bug may actually
be, so to file a bug given this is hard.

Anyway, count me in on bugday if I can be there at all.  This should be
interesting.

Looking at the previous bug day there is one thing I don't see:

How does this approach work?  In oher words, the lead-up and
organization seems to be fairly well spelt out - but how does it work on
the day?  When does it actually start? Or is this a world-wide rolling
time GMT+12 starts waking up until GMT-12 starts heading to bed?  This
is the opportunity to market the event.

Kind Regards,
Jaco

>
> Aisha
>
>> Guessing #gentoo may also be of help in regards to the above, so this is
>> really just a suggestion.  Yes, it will generate more bugs, but
>> hopefully the concept will allow for creating targeted bugs rather than
>> overly generic difficult to trouble-shoot bugs.
>>
>> Kind Regards,
>> Jaco
>>
>> On 2020/06/11 14:41, Aisha Tammy wrote:
>>
>>> # Gentoo BugDay
>>>
>>>
>>>
>>>
>>> Come join us over at #gentoo-bugday on freenode IRC on the first Saturday 
>>> of every month
>>>
>>>
>>> to squash bugs and make Gentoo a bit more awesome.
>>>
>>>
>>>
>>>
>>> You don't need to be a Gentoo developer or even a coder to help us on 
>>> BugDay.
>>>
>>>
>>> Our next BugDay is on 4th July 2020 and we have started making preparations 
>>> for
>>> selecting and prioritizing bug categories for that day.
>>>
>>>
>>>
>>> ## Bug categories
>>>
>>>
>>>
>>>
>>> The bug categories should be broad enough that there will be a lot of bugs 
>>> being
>>>
>>> targeted.
>>>
>>>
>>>
>>>
>>> We keep a option poll open to everybody to help us narrow down the 
>>> categories of bugs to focus.
>>>
>>>
>>> The opinion poll is there to get an input from everyone about how to best 
>>> tackle the
>>>
>>>
>>> current bug situation and get an understanding of the community and 
>>> developer priorities.
>>>
>>>
>>>
>>>
>>> The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/
>>>
>>>
>>> Be sure to vote in the poll to get your opinion heard.
>>>
>>>
>>>
>>> ## For developers
&g

Re: [gentoo-dev] Revival of Gentoo BugDay: everyone is welcome to come debug

[Jaco Kroon]

Hi,

Can we possibly include the concept of "helping to file bug reports" here?

For example, I've got an issue (which hasn't annoyed me just quite
enough yet to put effort in) where on bootup after xdm init script
starts it takes ~2 minutes before slim login is displayed.  But I don't
know enough of the workings of that to even understand if this is an
Xorg or slim (or dbus) bug ...

Guessing #gentoo may also be of help in regards to the above, so this is
really just a suggestion.  Yes, it will generate more bugs, but
hopefully the concept will allow for creating targeted bugs rather than
overly generic difficult to trouble-shoot bugs.

Kind Regards,
Jaco

On 2020/06/11 14:41, Aisha Tammy wrote:

> # Gentoo BugDay
>
>
>
>
> Come join us over at #gentoo-bugday on freenode IRC on the first Saturday of 
> every month
>
>
> to squash bugs and make Gentoo a bit more awesome.
>
>
>
>
> You don't need to be a Gentoo developer or even a coder to help us on BugDay.
>
>
> Our next BugDay is on 4th July 2020 and we have started making preparations 
> for
> selecting and prioritizing bug categories for that day.
>
>
>
> ## Bug categories
>
>
>
>
> The bug categories should be broad enough that there will be a lot of bugs 
> being
>
> targeted.
>
>
>
>
> We keep a option poll open to everybody to help us narrow down the categories 
> of bugs to focus.
>
>
> The opinion poll is there to get an input from everyone about how to best 
> tackle the
>
>
> current bug situation and get an understanding of the community and developer 
> priorities.
>
>
>
>
> The poll is open at https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/
>
>
> Be sure to vote in the poll to get your opinion heard.
>
>
>
> ## For developers
>
>
>
>
> Even if you have never coded for Gentoo you can help us with your experience.
>
> It's always valuable to have your experience to guide us.
>
>
>
>
> Things to help with
>
>
> - Find a related bug that piques your interest.
>
>
> - Look at upstream if this has been reported to them.
>
>
> - If not, make a bug report to the upstream developers.
>
>
> - If they have already seen it, check if they have managed to patch it.
>
>
> - If not, try to gather as much information as you can about the bug so that
>
>
>   it may help the developer tackling it.
>
>
> - Alert us at #gentoo-bugday and interact with us to see if this can be 
> squashed.
>
>
>
>
> ## For users
>
>
>
>
> Users are one of the most important part of Gentoo and this is the occasion 
> for
>
>
> them to talk the developers and make your bugs looked at.
>
>
>
>
> Take a look at the categories for BugDay at the poll link and the final BugDay
>
>
> wiki page
>
>
> - Find a related bug that you have experienced and has not been fixed yet
>
>
> - Try to see how it can be reproduced.Gnome not doing proper logins on you 
> laptop?
>
>
> - The related bug reports have been ignored for months you say?
>
>
>
>
> Come poke us about these bugs at #gentoo-bugday on the freenode IRC and we 
> will
> begin squashing any of
>  
> those that are pending.
>
>
>
>
> ## Whats in it for me?
>
>
>
>
> Bragging rights, permanently being listed on the charts of BugDay, sense of 
> entitlement.
>
>
>
> Any person who helps us solve valid problems will be given the honor of being 
> listed on
>
> the page.
>
> Even users who help related bugs and find links which make our problem 
> solving easier
>
> will be put on a pedestal.
>
>
>
> ## Contributors
>
>
>
>
> Thanks a lot to jstein@ for being the gracious organizer and making sure 
> everything
>
>
> goes smoothly.
>
>
>
>
> And special thanks to contributors who have worked on our previous BugDays.
>
> Past contributors:
>
>
> - https://wiki.gentoo.org/wiki/Bugday_2020-06-06
>

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Jaco Kroon]

Hi Michał,

On 2020/05/21 13:02, Michał Górny wrote:
> On Thu, 2020-05-21 at 12:45 +0200, Jaco Kroon wrote:
>> Even for v4, as an attacker ... well, as I'm sitting here right now I've
>> got direct access to almost a /20 (4096 addresses).  I know a number of
>> people with larger scopes than that.  Use bot-nets and the scope goes up
>> even more.
> See how unfair the world is!  You are filling your bathtub with IP
> addresses, and my ISP has taken mine only recently.
I must admit, I work for an ISP :$
>>> Option 3: explicit CAPTCHA
>>> ==
>>> A traditional way of dealing with spam -- require every new system
>>> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
>>> for one CAPTCHA).
>>>
>>> The advantage of this method is that it requires a real human work
>>> to be
>>> performed, effectively limiting the ability to submit spam.
>>>
>> Yea.  One would think.  CAPTCHAs are massively intrusive and in my
>> opinion more effort than they're worth.
>>
>> This may be beneficial to *generate* a token.  In other words - when
>> generating a token, that token needs to be registered by way of capthca.
>>
>>> Other ideas
>>> ===
>>> Do you have any other ideas on how we could resolve this?
>>>
>> Generated token + hardware based hash.
> How are you going to verify that the hardware-based hash is real,
> and not just a random value created to circumvent the protection?

So the generation of the hash is more to validate that it's still on the
same installation (ie, not a cloned token).  Sorry if that wasn't clear,
so trying to solve two possible problems in one go.

>
>>   Rate limit the combination to 1/day.
>>
>> Don't use included results until it's been kept up to date for a minimum
>> period.  Say updated at least 20 times 30 days.
> For privacy reasons, we don't correlate the results.  So this is
> impossible to implement.

Ok, but a token cannot (unless we issue it based on an email based
account) be linked back to a specific user, so does it matter if we
associate uploads with a token?

>> The downside here is that many machines are not powered up at least once
>> a day to be able to perform that initial submission sequence.  So
>> perhaps it's a bit stringent.
> Exactly.  Even once a week is a bit risky but once a day is too narrow
> a period.
>
> To some degree, we could decide we don't care about exact numbers
> as much as some degree of weighed proportions.  This would mean that,
> say, people who submit daily get the count of 7, at the loss of people
> who don't run their machines that much.  It would effectively put more
> emphasis on more active users.  It's debatable whether this is desirable
> or not.
Decaying averages.  Simple to implement, don't need all historic data.
>
> Both the token and hardware hash can of course be tainted and is under
>> "attacker control".
> Exactly.  So it really looks like exercise for the sake of exercise.

Unless tokens are *issued* as per the rest of my email you snipped
away.  Wherein I proposed an issuing of both anonymous and non-anonymous
tokens.

Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] Anti-spam for goose

[Jaco Kroon]

Hi,

On 2020/05/21 11:48, Tomas Mozes wrote:
>
>
> On Thu, May 21, 2020 at 10:47 AM Michał Górny  > wrote:
>
> Hi,
>
> TL;DR: I'm looking for opinions on how to protect goose from spam,
> i.e. mass fake submissions.
> Option 1: IP-based limiting
> ===
> The original idea was to set a hard limit of submissions per week
> based
> on IP address of the submitter.  This has (at least as far as IPv4 is
> concerned) the advantages that:
>
> - submitted has limited control of his IP address (i.e. he can't just
> submit stuff using arbitrary data)
>
> - IP address range is naturally limited
>
> - IP addresses have non-zero cost
>
> This method could strongly reduce the number of fake submissions one
> attacker could devise.  However, it has a few problems too:
>
> - a low limit would harm legitimate submitters sharing IP address
> (i.e. behind NAT)
>
> - it actively favors people with access to large number of IP
> addresses
>
> - it doesn't map cleanly to IPv6 (where some people may have just
> one IP
> address, and others may have whole /64 or /48 ranges)
>
So this gets tricky.  A single host could as you say either have a /128
or possibly a whole /64.  ISPs are "encouraged" to use a single /64 per
connecting user on the access layer (can be link-local technically, but
it seems to be frowned upon).  Generally then you're encourages to
delegate a /56 to the router, but at the very least a /60.  Some
recommendations even state to delegate a /48 at this point.  That's
outright crazy seeing that a /48 essentially boils down to 65536
individual LANs behind the router, /56 is 256 LANs which frankly I
reckon is adequate.  The only advantage of /48 is cleaner boudary
mapping onto : separators.  This is OPINION.  I also use "encouraged"
since these are

Short version:  If you're willing to rate limit on larger blocks it
could work.  /64s are probably OK, but most hosts will typically have a
/128, so you'll be limiting LANs, and switching IPs is trivial as you'd
have access to at least a /64 (or ~18.45 * 10^18).

You could have multiple layers ... ie:

each /128 gets 1 or 2 submissions per day
each /64 gets 200/day
each /56 gets 400/day
each /48 gets 600/day

But now you need to keep bucket loads of data ... so DOS on the rate
limiting mechanism itself becomes possible unless you're happy to limit
the size of the tables and discard "low risk of exceeding entries" somehow.

Even for v4, as an attacker ... well, as I'm sitting here right now I've
got direct access to almost a /20 (4096 addresses).  I know a number of
people with larger scopes than that.  Use bot-nets and the scope goes up
even more.

>
>
> Option 2: proof-of-work
> ===
> An alternative of using a proof-of-work algorithm was suggested to me
> yesterday.  The idea is that every submission has to be
> accompanied with
> the result of some cumbersome calculation that can't be trivially run
> in parallel or optimized out to dedicated hardware.
>
> On the plus side, it would rely more on actual physical hardware
> than IP
> addresses provided by ISPs.  While it would be a waste of CPU time
> and memory, doing it just once a week wouldn't be that much harm.
>
> On the minus side, it would penalize people with weak hardware.
>
> For example, 'time hashcash -m -b 28 -r test' gives:
>
> - 34 s (-s estimated 38 s) on Ryzen 5 3600
>
> - 3 minutes (estimated 92 s) on some old 32-bit Celeron M
>
> At the same time, it would still permit a lot of fake
> submissions.  For
> example, randomx [1] claims to require 2G of memory in fast mode. 
> This
> would still allow me to use 7 threads.  If we adjusted the
> algorithm to
> take ~30 seconds, that means 7 submissions every 30 s, i.e. 20k
> submissions a day.
>
> So in the end, while this is interesting, it doesn't seem like
> a workable anti-spam measure.
>
Indeed.  This was considered for email SPAM protection as well about two
decades back.  Amongst other proposals.

Perhaps some crazy proof-of-work for registration of a token, but given
how cheap it is to lease CPU cycles you'd need to balance the effects. 
And given bot nets ... using other people's hardware for proof-of-work
doesn't seem inconceivable (bitcoin miners embedded on web pages being
an example of the stuff that people pull).

>
>
> Option 3: explicit CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
> for one CAPTCHA).
>
> The advantage of this method is that it requires a real human work
> to be
> performed, effectively limiting the ability to submit spam.
>
Yea.  One would think.  CAPTCHAs are massively intrusive and in my
opinion more effort than

Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it

[Jaco Kroon]

Hi,

On 2020/05/08 08:17, Hans de Graaff wrote:
> On Thu, 2020-05-07 at 09:29 +0200, Michał Górny wrote:
>>
>> 1) list of selected packages (@world)
>>
>> We would use this to determine the popularity of individual packages,
>> plus by scanning their dependencies we would be able to make combined
>> statistics for direct usage + dependencies of other selected
>> packages. 
>> This would allow us to judge which packages need more of our
>> attention.
> At work we install a lot of dependencies through a few company-specific 
> virtual packages, e.g. company/developer for all stuff useful for our
> developers. These packages would then be missed in the statistics. I'm
> not sure how prevalent this is and to what extend it wills skew the
> statistics.

You raise a valid point.

The company/developer package itself I don't think is relevant.

The fact that some/package::gentoo is installed as a dependency of
company/developer may carry some relevance.

So we do need the full list of packages installed, filtered to ::gentoo,
but there needs to be an indicated whether it's installed because it's
in @world, as a dep of something in @world (which is possibly not in
::gentoo), or is some form of no-longer needed dep.

Otherwise I agree with Michał on the four items to be taken.

I do still think that the ability to define additional information sets
would be useful for building more invasive functionality sets, not
necessarily supported by Gentoo.  For an organization if they can define
a set that grabs a certain amount of hardware details for example that
could help with inventory management.

Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

[Jaco Kroon]

Hi Michał, and the rest of the Gentoo devs,

I've been patiently sitting and watching this discussion.

I raised some ideas with another developer (Not Michał) just days before
he raised this thread to the ML.

I believe all points raised to this point is valid, I'll try to summarise:

1.  This must be completely *opt in*.
2.  Anonymity was discussed by various parties (privacy).
3.  "spam" protection (ie, preventing bogus data from entering).
4.  Trustworthiness of data.
5.  Acceptance of some form of privacy policy.

In my opinion, points 2 and 3 works against each other, in that if
registration is compulsory if you would like to submit stats, then we
can control the spam more easily (not foolproof), but requiring
registration also raises the entry barrier.  I'd be completely willing
to provide at least an email address as part of a submission.

All of the replies seems to have focused purely on yes/no, do it or
don't.  Not many have addressed the benefits to end users/system
administrators.  It seems to focus is on what we as developers can get
out of this.

Regarding the above points:

1.  I fully agree.  This should not be forced on anyone.
2.  Happy to concede that some people may wish to submit anonymously. 
Let them.
3.  I'll address this below.
4.  A lot of the discussion has been around the usefulness of the data,
and I concede to Thomas that this may (or may not) generate "decision
blind spots" or as per "artificially increase decision certainty".  I
don't see how this is worse than what we've got now.
5.  We have the infrastructure for this already by way of licenses.  So
we ship with "GPLv2/3/whatever + GentooPrivacy", and users have to first
take explicit action to accept GentooPrivacy.

I have some other ideas around this, which will tread even further on
privacy, but again, all of this should be a kind of opt-in, and building
on the ideas by Kent where he suggested a form of submission proxy
(STATS_SERVER), we could potentially give the full benefit of the code
to such entities, but then still allow them to submit "upstream" in a
more filtered manner.

Bottom line, in my opinion:  Any data is better than no data!

Whilst we can't say "no one is using xyz", we will at least be able to
say "hey, some people are using xyz", and whilst this may generate some
blinds it at least enables us to test known use cases during
test-builds, eg, we know for a fact a thousand users are using package X
with USE flags "-* a b c", so we should definitely run that as a compile
test.  Your build breaks frequently?  Would you mind submitting stats? 
Great thank you.  You not willing to do that, then my stance becomes one
of "ok, I'll help where I can, but really, please consider us to help
you, if you submit stats we can pre-emptively at least include build
tests for your specific USE flags." - and again, this means we can
actually have our tooling use these stats to generate build tests for
the "known popular" configs.

I point you to RHEL - why are people willing to pay for for RHEL?  What
do they get for that buck?  Because I promise you, the support I get
from fellow Gentoo'ers FAR outweigh the support I have ever gotten from
(paid for) RHEL.  Most of the time.

I myself used to run 500+ Gentoo hosts more than 15 years back.  It was
fun.  I was also a student back then so had much more time on my hands
than I do now.  It was challenging, and fun to try and get things to
work exactly the way we envisioned it should.  I promise you, if what
Michał proposes was available for me back then to firstly keep track of
my own internal assets, and to submit stats upstream to help improve
Gentoo I would not have hesitated for 10 seconds.

And there I touch on a point I'm trying to make - this should be
something that not only helps devs, but brings benefit to users.  I'll
say more on this at the end of the email (possibly force users to run
some of their own infra for this at least, but these stats form the
framework for a multi-system management system too, potentially).  First
I'd like to pay more attention to the individual points raised by Michał.

On 2020/04/26 10:08, Michał Górny wrote:

> Hi,
>
> The topic of rebooting gentoostats comes here from time to time.  Unless
> I'm mistaken, all the efforts so far were superficial, lacking a clear
> plan and unwilling to research the problems.  I'd like to start
> a serious discussion focused on the issues we need to solve, and propose
> some ideas how we could solve them.
>
> I can't promise I'll find time to implement it.  However, I'd like to
> get a clear plan on how it should be done if someone actually does it.

My time is also limited, but I would love to be involved in some way or
another.

> The big questions
> =
> The way I see it, the primary goal of the project would be to gather
> statistics on popularity of packages, in order to help us prioritize our
> attention and make decisions on what to keep and what to remove.  Unlike
> Debian's popco

Re: [gentoo-dev] stabilization requests not making progress

[Jaco Kroon]

Hi Mart,

On 2020/03/28 18:07, Mart Raudsepp wrote:

> Ühel kenal päeval, L, 28.03.2020 kell 17:24, kirjutas Jaco Kroon:
>> Hi All,
>> https://bugs.gentoo.org/705754
>> Not sure if this is the only one.  This is becoming problematic. 
>> This specific one is blocking a security issue.  x86 and amd64 both
>> needs an updated stable.  I'd prefer 13.32.0 but it's not been in
>> tree for a month yet.  But we can do 13.31.0 by now ...
> You should stabilize on the security bug, not an extra one that blocks
> the security bug.
> Security bugs typically gets more immediate attention by arch teams,
> but often not those that are blocked by a dependent non-security bug,
> as it doesn't show up in the tooling then as such.

Thank you.  I flagged the stabilization bug as obsolute and added the
package list to the security bug and added the two related arch teams
there instead.

It still worries me that stabilization takes this long.  Is this perhaps
a process which we can automate in some way?

Kind Regards,
Jaco

[gentoo-dev] stabilization requests not making progress

[Jaco Kroon]

Hi All,

https://bugs.gentoo.org/705754

Not sure if this is the only one.  This is becoming problematic.  This
specific one is blocking a security issue.  x86 and amd64 both needs an
updated stable.  I'd prefer 13.32.0 but it's not been in tree for a
month yet.  But we can do 13.31.0 by now ...


Kind Regards,
Jaco Kroon
C.E.O.

*T:* +27 (0)12 021  | *F:* +27 86 648 8561 | *E:* j...@iewc.co.za
*W:* iewc.co.za <https://www.iewc.co.za/> | *A:* Unit 201, Building 2B,
Sunwood Park, Queen's Crescent Lynnwood, Pretoria


    

Facebook <https://www.facebook.com/Interexcel/> Twitter
<https://twitter.com/Interexcel/> Google+
<https://plus.google.com/+InterexcelCoZaPTA/posts> LinkedIn
<https://www.linkedin.com/company/interexcel-world-connection/>

IEWC <https://www.iewc.co.za/> ULS Group <http://www.uls.co.za/>

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

Hi,

So I figured I better write the patch for dahdi-tools against musl ...
so I proceed to download a stage3 tar from
http://distfiles.gentoo.org/experimental/amd64/musl/ (vanilla).

I extract it, and mount --rebind /dev, /proc and /sys, and copy in
/etc/resolve.conf ...

chroot ... and so far so good.

emerge --sync
emerge -uDNav @world.

And this blows up on pam-1.3.1-r2.  Looks like
https://bugs.gentoo.org/687234.

I've seen mention of a musl overlay?

What's the best way to proceed?

As it stands I can't "make prepare" gentoo-sources (which 4.19.X) is
apparently the newest available for musl profile.  Reports seems to
indicate that this be related to "old linux-headers" (which is at ).

Kind Regards,
Jaco

On 2020/03/27 07:43, Jaco Kroon wrote:
> Hi,
>
> On 2020/03/27 03:25, Joshua Kinard wrote:
>> On 3/23/2020 04:21, Jaco Kroon wrote:
>>> Hi,
>>>
>>> https://bugs.gentoo.org/713668 relates.
>>>
>>>  * Searching for /usr/include/execinfo.h ...
>>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>>
>>> As I see I can either add an explicit depend on glibc which I'd prefer
>>> not to.  Or someone from the musl team could possibly assist on how to
>>> get the backtrace() set of calls on musl please?
>>>
>>> Alternatively I need to add a test and simply path debug.c to only
>>> provide stub function for print_backtrace(FILE *fp) that just does
>>> fprintf(fp, "No backtrace() available to print a backtrace.\n");
>>>
>>> Suggestions?
>>>
>>> Kind Regards,
>>> Jaco
>> Some quick searching on google, it looks like the cleanest fix for that bug
>> is dahdi-tools needs to be patched to only include execinfo.h or only use
>> backtrace() on glibc-based systems, and that patch then sent to the
>> dahdi-tools upstream developers for inclusion in a future release.  That
>> way, we're not dragging that patch around forever in the tree or in the musl
>> overlay.
> Thanks.  I'll see action accordingly.
>
>> It also doesn't look like musl itself will ever implement execinfo.h or
>> backtrace(), per this message in 2015 from the lead musl developer:
>> https://www.openwall.com/lists/musl/2015/04/09/3
>>
> Implementing libunwind is overkill for my needs, I'll be happy to help
> push things upstream if somebody else cares enough to implement.
>
> Kind Regards,
> Jaco
>
>

Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

[Jaco Kroon]

Hi,

On 2020/03/26 23:48, Jaco Kroon wrote:

> Hi,
>
> On 2020/03/26 23:34, Andreas K. Huettel wrote:
>
>> # Andreas K. Hüttel  (2020-03-26)
>> # Fail to build with glibc-2.30; no maintainer. Removal in 30days.
>> # Bugs 691756, 691710
>> x11-terms/aterm
> I'll take this via proxy-maint.

After using aterm for nearly two decades this has now finally convinced
me to move on.  So sorry if there are other users of aterm, but I'm
going to go back on the above.

Additional information from http://www.afterstep.org/aterm.php

aterm is deprecated and in a maintenance mode only; there will be no
further updates. Use rxvt-unicode
<http://software.schmorp.de/pkg/rxvt-unicode.html> instead.

It took minor changes to my .Xresources file and that seems to work just
as well as aterm, so my out of hand recommendation is to use that.

Andreas, perhaps this should be added to the mask comment?  Happy to
push a PR or simply add this information to the bug report, at the very
least I thing the bug report should be closed with WONTFIX, may I
proceed with that?  I'll same comments there if in order.

Kind Regards,
Jaco

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

Hi,

On 2020/03/27 03:25, Joshua Kinard wrote:
> On 3/23/2020 04:21, Jaco Kroon wrote:
>> Hi,
>>
>> https://bugs.gentoo.org/713668 relates.
>>
>>  * Searching for /usr/include/execinfo.h ...
>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>
>> As I see I can either add an explicit depend on glibc which I'd prefer
>> not to.  Or someone from the musl team could possibly assist on how to
>> get the backtrace() set of calls on musl please?
>>
>> Alternatively I need to add a test and simply path debug.c to only
>> provide stub function for print_backtrace(FILE *fp) that just does
>> fprintf(fp, "No backtrace() available to print a backtrace.\n");
>>
>> Suggestions?
>>
>> Kind Regards,
>> Jaco
> Some quick searching on google, it looks like the cleanest fix for that bug
> is dahdi-tools needs to be patched to only include execinfo.h or only use
> backtrace() on glibc-based systems, and that patch then sent to the
> dahdi-tools upstream developers for inclusion in a future release.  That
> way, we're not dragging that patch around forever in the tree or in the musl
> overlay.

Thanks.  I'll see action accordingly.

>
> It also doesn't look like musl itself will ever implement execinfo.h or
> backtrace(), per this message in 2015 from the lead musl developer:
> https://www.openwall.com/lists/musl/2015/04/09/3
>
Implementing libunwind is overkill for my needs, I'll be happy to help
push things upstream if somebody else cares enough to implement.

Kind Regards,
Jaco

Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

[Jaco Kroon]

Hi,

On 2020/03/26 23:34, Andreas K. Huettel wrote:

> # Andreas K. Hüttel  (2020-03-26)
> # Fail to build with glibc-2.30; no maintainer. Removal in 30days.
> # Bugs 691756, 691710
> x11-terms/aterm

I'll take this via proxy-maint.

Kind Regards,
Jaco

Re: [gentoo-dev] musl doesn't provide execinfo.h

[Jaco Kroon]

Hi Michał,

On 2020/03/23 18:25, Michał Górny wrote:

> On Mon, 2020-03-23 at 10:21 +0200, Jaco Kroon wrote:
>> Hi,
>>
>> https://bugs.gentoo.org/713668 relates.
>>
>>  * Searching for /usr/include/execinfo.h ...
>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>
>> As I see I can either add an explicit depend on glibc which I'd prefer
>> not to.  Or someone from the musl team could possibly assist on how to
>> get the backtrace() set of calls on musl please?
>>
> As someone not on musl team, I think libunwind provides
> an implementation of backtrace().
>
Thanks.  That indeed looks interesting.

Let's say I do go that route rather than simply no-opping it, would I
add a BDEPEND + RDEPEND of the form:

|| ( sys-libs/glibc sys-libs/libunwind )

To the ebuild?

The code (./configure and actual "C" I'll manage).

Kind Regards,
Jaco