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

2020-11-09 Thread 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?

2020-11-09 Thread 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

2020-11-09 Thread 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=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

2020-09-16 Thread 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

2020-09-16 Thread 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

2020-08-28 Thread 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

2020-08-13 Thread 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

2020-08-11 Thread 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

2020-08-08 Thread 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

2020-08-08 Thread 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

2020-08-06 Thread 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

2020-07-21 Thread 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

2020-06-30 Thread 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

2020-06-12 Thread 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

2020-06-12 Thread 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

2020-05-21 Thread 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

2020-05-21 Thread 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 

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

2020-05-08 Thread 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

2020-05-05 Thread 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 

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

2020-03-28 Thread 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

2020-03-28 Thread 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

2020-03-28 Thread 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

2020-03-27 Thread 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

2020-03-26 Thread 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

2020-03-26 Thread 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

2020-03-23 Thread 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




[gentoo-dev] dev.gentoo.org unreachable

2020-03-23 Thread Jaco Kroon
Hi All,

Is there a known issue with dev.gentoo.org?

I initially thought it might just be a routing issue from our network
but have since confirmed at least two other sources with the same
problem.  One of these are IPv4 only, the other two are trying IPv6
too.  All failing.

One v6 and v4:


 1?: [LOCALHOST]    0.011ms pmtu 1500
 1:  2c0f:f720::0:764d:28ff:fe3f:1a4d  0.324ms
 1:  2c0f:f720::0:764d:28ff:fe3f:1a4d  0.285ms
 2:  2c0f:f720::5  3.418ms
 3:  2001:43f8:6d0::42 3.264ms
 4:  2001:470:0:191::1   159.733ms
 5:  2001:470:0:2cf::2   228.372ms
 6:  2001:470:0:4b8::1   245.058ms
 7:  2001:470:0:18e::2   251.433ms
 8:  2001:470:0:22a::1   284.263ms
 9:  2001:470:0:9b::2    283.906ms
10:  2001:470:0:9b::2    288.137ms pmtu 1280
10:  no reply

 1?: [LOCALHOST]  pmtu 1500
 1:  154.73.34.153 0.360ms
 1:  154.73.34.153 0.236ms
 2:  154.73.32.3   2.373ms
 3:  197.96.224.9  3.090ms
 4:  168.209.86.218    3.315ms asymm  6
 5:  168.209.88.125    6.001ms
 6:  196.26.0.62   5.804ms
 7:  168.209.100.19  173.349ms
 8:  149.6.148.133   179.961ms
 9:  154.54.57.105   178.710ms
10:  154.54.82.34    232.281ms asymm 11
11:  154.54.0.221    244.550ms
12:  154.54.26.129   256.873ms
13:  154.54.7.129    280.141ms asymm 14
14:  154.54.42.165   265.994ms asymm 15
15:  154.54.31.89    285.354ms
16:  154.54.42.97    296.996ms
17:  154.54.44.73    306.417ms asymm 18
18:  154.54.31.78    320.279ms
19:  38.142.108.50   322.589ms asymm 20
20:  207.98.64.170   313.345ms asymm 21
21:  207.98.64.25    349.141ms asymm 16
22:  207.98.64.17    307.354ms asymm 16
23:  no reply

Kind Regards,
Jaco




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

2020-03-23 Thread Jaco Kroon
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




Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread Jaco Kroon
Hi,

I'd be in support.  Especially for "data only" kind of packages, like:

net-misc/asterisk-moh-opsound
net-misc/asterisk-extra-sounds
net-misc/asterisk-core-sounds

For all three these I've already dropped the DEPEND on net-misc/asterisk
anyway, and upgraded the PDEPEND on net-misc/asterisk back onto these to
RDEPEND.  Other than that they really only install a bunch of audio
files in various formats.

One could even mark the various acct-{user,group}/* packages this way
(although this is a simple eclass change).

One challenge I foresee is that one could have a perl, python or php
(script language of choice) package depend on a specific version of
interpreter, which may not be stable for given arch.  So may require
some special handling in terms of dependencies.

Kind Regards,
Jaco


On 2020/03/18 16:54, William Hubbs wrote:
> All,
>
> this came up again on the recent thread about dropping non x86/amd64
> support for python packages, and I want to bring it up again on its own
> thread.
>
> How often do architecture specific bugs really exist in languages like
> perl, python etc? From what I've seen they are pretty rare. Not to mention,
> if we found one somewhere, we could adjust keywords as necessary.
>
> Also, if someone did inadvertently keyword a package with noarch that didn't
> work everywhere, it would be a matter of adjusting the keywords for that
> package.
>
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
> Thanks,
>
> William
>



[gentoo-dev] automated build failure bugs

2020-02-24 Thread Jaco Kroon
Hi All,

Example:  https://bugs.gentoo.org/710484

Relates to the dropping of my_bool from mysql-connector-c.

This has been addressed upstream and a ~ ebuild has been pushed.

My question is simple:  Is that good enough to close the bug?  Do I need
to remove 13.29.1 from the tree (via proxy maint PR).

How do I chase stabilization process (https://bugs.gentoo.org/705754),
which has been requested a while ago for 13.29.1 already, as part of a
security issue (https://bugs.gentoo.org/689796)?

Kind Regards,
Jaco




Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

2020-01-21 Thread Jaco Kroon
Hi Michael,

My background:  21 years of Linux, 18 of which was primarily on Gentoo. 
17 years of no other OS other than Linux.  Ex-sysadmin for a largish
setup with 4000+ active users, and ~500-600 available workstations and a
number of storage and other servers.  Not to brag, just to give you an
idea of my background and experience.

I am against this patch.

On 2020/01/20 16:20, Michael Orlitzky wrote:

> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
>>>   install-qa-check.d: allow acct-user home directories under /home.
>> Nope. As you've been told, /home is site specific and can be setup in
>> multiple ways that are incompatible with the package manager installing
>> things there (the only exception being baselayout creating the directory
>> itself).
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking about?

>From my perspective the following should be adequate:

There is technically no real issue, but it's the right thing to do.

Right, motivations for your proposal for allowing this:

* You want it.

Motivations against:

* /home belongs to the sys-admin.  In above environment if you were to
mess with my /home, I'd be very, very angry.
* installing stuff into /home using system-local UIDs has potential
security impacts if /home is distributed (user id conflicts).
* People mentioned encrypted home folders using LUKS ... these typically
mount on /home/${username} so I personally think this is less of an issue.
* FHS standards (back to it's the right thing to do).
* I've worked on numerous distributions (Debian, Ubuntu, RHEL, SuSE,
Fedora, Mint, IMPI, knoppix ... probably others) and not once have I
encountered system packages messing with /home.  Not having encountered
it doesn't say there isn't any, just that I've not encountered them.

>
>
>> Quoting FHS-3.0 again:
>>
>> | On large systems (especially when the /home directories are shared
>> | amongst many hosts using NFS) it is useful to subdivide user home
>> | directories. Subdivision may be accomplished by using subdirectories
>> | such as /home/staff, /home/guests, /home/students, etc.
>>
>> So, how are you going to detect if such a scheme is used on the system,
>> and in which subdirectory the amavis user should be placed?
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is it
> just more FUD?

It's not FUD, there is no fear here, no uncertainty, no doubt.  We don't
*want* you to touch /home.  We want you to use /var/lib.

>
>> I also wonder why you would send this patch, when there wasn't a single
>> voice supporting your proposition in the other thread and several
>> opposing ones.
> I don't want to just complain without offering a solution.
>
> No one has pointed out any problems with it.
>
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.

Use /var/lib/amavis/work and /var/lib/amavis/home.  Simple.

Kind Regards,
Jaco




Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

2019-12-18 Thread Jaco Kroon
Hi,

As someone with a Radeon / Intel hybrid/dual graphics chip.

I can only emphasise what Matt says below.  It's a PITA currently.

Having said that ... I don't see how this can be made simpler, unless we
have a tool of sorts that when run on *any* hardware gives you what this
needs to be set to, or unconditionally install all possible drivers
(something I'd prefer to avoid completely).

Kind Regards,
Jaco

On 2019/12/17 23:21, Matt Turner wrote:
> On Mon, Dec 16, 2019 at 10:26 AM Marek Szuba  wrote:
>> What do you think, guys?
> I don't love it.
>
> I don't like the mess that has become VIDEO_CARDS=... either. radeon
> vs radeonsi vs amdgpu. Different names for different bits of the
> stack, even for the same hardware. I would like to come up with
> something that avoids the confusion users often have.
>
> Does anyone have suggestions?
>
> Should we make a cpuid2cpuflags equivalent for VIDEO_CARDS?
>
> Should VIDEO_CARDS specify only the vendor with MESA_VIDEO_CARDS=...
> etc for individual packages? (Seems gross)
>
> Should VIDEO_CARDS be more fine grained with multiple names for the
> same thing sometimes? (e.g., offer VIDEO_CARDS=amdgpu for
> media-libs/mesa that enables the radeonsi driver; similarly offer
> VIDEO_CARDS=radeonsi for x11-libs/libdrm that enables libdrm_radeon).
>
> I think perhaps that in conjunction with a cpuid2cpuflags-equivalent
> is the most sensible.
>



Re: [gentoo-dev] [PATCH v4] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.

2019-12-09 Thread Jaco Kroon
Hi,

>> What about just checking "${EROOT}/boot" instead?
> For what, existence? There may well be a "boot" directory present under
> EROOT. (And we could check ${EROOT}/etc/fstab, but I don't think we
> should open that can of worms. There's no reliable way to guess the
> user's exact configuration for non-trivial ROOT.)

I was hoping there is a somewhat reliable way ... but if not I guess as
is will be the best we can do.

IMHO:  Ship it.

Even if there is issues still, the new state will be better than current.

Kind Regards,
Jaco




Re: [gentoo-dev] [PATCH v4] mount-boot.eclass: Check if /boot is sane, but don't try to mount it.

2019-12-09 Thread Jaco Kroon
Hi Ulrich,

I'm happy with this "as is", but there may be a few improvements still.

By the way:  This improves the situation for mounted ro /boot by moving
the check from preinst to pretend.

For noauto /boot (I believe the default and recommended) this fixes things.

This is the reason I decided to rather go with mounting /boot but as ro
instead of not mounting at all.

May I also suggest we start recommended read-only /boot instead of not
mounted at all in order to avoid similar issues from recurring?

Kind Regards,
Jaco

On 2019/12/07 11:10, Ulrich Müller wrote:

> The eclass failed to remount a read-only mounted /boot, because package
> collision sanity checks in recent Portage versions prevented it from
> reaching pkg_preinst() at all. Furthermore, with the "mount-sandbox"
> feature enabled, the mount won't be propagated past pkg_preinst() and
> installed files would end up under the (shadowed) mount point.
>
> Therefore don't even attempt to mount /boot ourselves, but error out
> if it isn't mounted read/write and ask the user to mount /boot.
>
> Also clean up and simplify. (For example, awk is a grown-up program
> which doesn't need any help from egrep or sed. :-)
>
> Closes: https://bugs.gentoo.org/532264
> See-also: https://bugs.gentoo.org/274130#c5
> Signed-off-by: Ulrich Müller 
Acked-by: Jaco Kroon 
>
> ---
> v3: Exit awk commands on first match.
>
> v4: Added die statements after awk commands
> Fixed typo in mount-boot_is_disabled function documentation
> Reverted renaming of I_KNOW_WHAT_I_AM_DOING variable
>
>  eclass/mount-boot.eclass | 144 +--
>  1 file changed, 48 insertions(+), 96 deletions(-)
>
> diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
> index 938df6732f43..ca27aca7efbd 100644
> --- a/eclass/mount-boot.eclass
> +++ b/eclass/mount-boot.eclass
> @@ -1,156 +1,108 @@
> -# Copyright 1999-2015 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: mount-boot.eclass
>  # @MAINTAINER:
>  # base-sys...@gentoo.org
>  # @BLURB: functions for packages that install files into /boot
>  # @DESCRIPTION:
>  # This eclass is really only useful for bootloaders.
>  #
>  # If the live system has a separate /boot partition configured, then this
>  # function tries to ensure that it's mounted in rw mode, exiting with an
> -# error if it can't. It does nothing if /boot isn't a separate partition.
> +# error if it can't.  It does nothing if /boot isn't a separate
partition.
> +
> +case ${EAPI:-0} in
> +    4|5|6|7) ;;
> +    *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
>  
>  EXPORT_FUNCTIONS pkg_pretend pkg_preinst pkg_postinst pkg_prerm
pkg_postrm
>  
> -# @FUNCTION: mount-boot_disabled
> +# @FUNCTION: mount-boot_is_disabled
>  # @INTERNAL
>  # @DESCRIPTION:
>  # Detect whether the current environment/build settings are such that
we do not
>  # want to mess with any mounts.
>  mount-boot_is_disabled() {
> -    # Since this eclass only deals with /boot, skip things when ROOT
is active.
> -    if [[ "${ROOT:-/}" != "/" ]] ; then
> +    # Since this eclass only deals with /boot, skip things when EROOT
is active.
> +    if [[ ${EROOT:-/} != / ]] ; then
>          return 0
>      fi

I don't use spaces in path names ... but what happens here if ROOT or
EPREFIX (and by implication EROOT) contains a space?

What about just checking "${EROOT}/boot" instead?

Would that even be possible ... ?

>
>  
>      # If we're only building a package, then there's no need to check
things.
> -    if [[ "${MERGE_TYPE}" == "buildonly" ]] ; then
> +    if [[ ${MERGE_TYPE} == buildonly ]] ; then
>          return 0
>      fi
>  
>      # The user wants us to leave things be.
>      if [[ -n ${DONT_MOUNT_BOOT} ]] ; then
>          return 0
>      fi
>  
>      # OK, we want to handle things ourselves.
>      return 1
>  }
>  
>  # @FUNCTION: mount-boot_check_status
>  # @INTERNAL
>  # @DESCRIPTION:
> -# Figure out what kind of work we need to do in order to have /boot
be sane.
> -# Return values are:
> -# 0 - Do nothing at all!
> -# 1 - It's mounted, but is currently ro, so need to remount rw.
> -# 2 - It's not mounted, so need to mount it rw.
> +# Check if /boot is sane, i.e., mounted read/write if on a separate
> +# partition.  Die if conditions are not fulfilled.
>  mount-boot_check_status() {
>      # Get out fast if possible.
> -    mount-boot_is_disabled && return 0
> +    mount-boot_is_disabled && return
>  
>      # note that /dev/BOOT is in the Gentoo def

Re: [gentoo-dev] Last-rites: media-libs/mediastreamer, media-plugins/mediastreamer-amr, media-plugins/mediastreamer-bcg729, media-plugins/mediastreamer-ilbc, media-plugins/mediastreamer-x264

2019-12-03 Thread Jaco Kroon
Hi,

I've got a local repository for asterisk-g72x that depends on
mediastreamer-bcg729.  It actually conflicts with bcg729 which is more
widely used.  I'll rather check if I can fix asterisk-g72x to work
againts net-libs/bcg729 instead.  Currently we're experiencing decoder
lockups (infinite loops) resulting in broken calls, and having to
completely restart asterisk.

Can we however, please extend the removal time for mediastreamer-bcg729
a bit?

Kind Regards,
Jaco

On 2019/11/30 15:42, Andreas Sturmlechner wrote:
> # Andreas Sturmlechner  (2019-11-30)
> # Version in Gentoo is multiple years old, broken by several dependencies
> # Bugs aren't being fixed: #497412, #509334, #511794, #651010, #654484, 
> #701022
> # Removal in 30 days.
> media-libs/mediastreamer
> media-plugins/mediastreamer-amr
> media-plugins/mediastreamer-bcg729
> media-plugins/mediastreamer-ilbc
> media-plugins/mediastreamer-x264
>
>
>



Re: [gentoo-dev] Migrate away from python-2 or not

2019-11-25 Thread Jaco Kroon
Hi Benda,

On 2019/11/24 14:15, Benda Xu wrote:
> What do you think?

Is it possible to disable python2_7 by default, even if python2 is
installed, and only enable python2_7 for those packages specifically
requiring it (ie, being a dep for one of the packages that only supports
python2_7?

I tried removing python2 on a handful of test systems over the last week
... it's back everywhere.

Kind Regards,
Jaco




Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-16 Thread Jaco Kroon
Hi,

On 2019/11/16 19:08, Michael 'veremitz' Everitt wrote:
> On 16/11/19 16:59, Matt Turner wrote:
>> On Sat, Nov 16, 2019 at 1:06 AM Jaco Kroon  wrote:
>>> Hi,
>>>
>>> On 2019/11/15 21:35, Matt Turner wrote:
>>>> On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
>>>>> The package is somewhat redundant, because sys-kernel/linux-firmware
>>>>> installs the same files. (Same for all other sys-firmware/iwl*-ucode
>>>>> packages.)
>>>> Should last-rite all of them, IMO.
>>>>
>>> I both agree and disagree with this.  It's the simpler solution and
>>> therefore I agree.
>>>
>>> I disagree because in some cases I really only want specific firmware
>>> for specific sets of hardware (especially where space constraints are an
>>> issue, read: embedded type systems).
>>>
>>> The current linux-firmware package is getting quite big in terms of install.
>> USE=savedconfig allows you to choose exactly which files to install :)
>>
> I've never found a good way (yet...) to figure out how to write a fresh new
> 'savedconfig' if you haven't ever previously emerged the package in
> question. Does anyone have a good method for this, that doesn't require
> unpacking the whole nine yards (Megs, Gigs...) first?
>
I Agree.

And for that matter, knowing which files to actually install, and what
to filter out.  With the split packages I know I want firmware for
something specific.  With the big package it really is much harder. 
That said:  generally I just merge the big package by default, unless I
have a specific reason to not do so (which is seldom).

Bandwidth is much less of an issue now than it was a decade ago, but
still, if you only need a few MB of firmware, why download the whole lot
first?

Kind Regards,
Jaco




Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-16 Thread Jaco Kroon
Hi,

On 2019/11/15 21:35, Matt Turner wrote:
> On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
>> The package is somewhat redundant, because sys-kernel/linux-firmware
>> installs the same files. (Same for all other sys-firmware/iwl*-ucode
>> packages.)
> Should last-rite all of them, IMO.
>
I both agree and disagree with this.  It's the simpler solution and
therefore I agree.

I disagree because in some cases I really only want specific firmware
for specific sets of hardware (especially where space constraints are an
issue, read: embedded type systems).

The current linux-firmware package is getting quite big in terms of install.

Kind Regards,
Jaco




Re: [gentoo-dev] RFC acct-{user,group} for asterisk

2019-11-10 Thread Jaco Kroon
Hi,

On 2019/11/10 20:21, Michael Orlitzky wrote:
> On 11/10/19 12:36 PM, Jaco Kroon wrote:
>> What's the motivation for trying to match the UID and GID values from
>> other distributions?
>>
>> I previously tried to motivate a "purely dynamic" allocation with -1,
>> I'm showing this as an example where such an implementation would once
>> more be beneficial.
>>
> When sharing resources between multiple systems, you need some sort of
> centralized identity management. You can put the users in LDAP, for
> example, and then force everything to authenticate against that. But,
> doing that right is complicated, and is overkill if you just want to
> share some files between two machines.
>
> Having fixed UIDs and GIDs on all Gentoo systems gives you an easy way
> to centralize that identity management: in portage, where the IDs are
> hard-coded. Once GLEP81 has been implemented tree-wide, users can trust
> that (on new installs, at least), every system user and group will have
> the same ID. That gives you a simple way to e.g. mount shared apache
> resources without having to learn LDAP.
>
> If our IDs agree with other distributions, then to the extent possible,
> the same thing works cross-distro.
>
> We don't allow dynamic UIDs because it defeats this whole concept. You
> might not care what the ID is, but some of your users will.

Happy.  That makes sense.

May I proceed to use UID+GID 242 then for asterisk?

Seeing that 42 is apparently off limits by the above argument, and 142
could theoretically also end up being problematic.

Kind Regards,
Jaco




Re: [gentoo-dev] RFC acct-{user,group} for asterisk

2019-11-10 Thread Jaco Kroon
Hi Michał,

You're right.

Fedora and RHEL has gdm on 42, we don't have gdm via acct-{user,group}
and it's dynamic in the ebuild.

Arch has privoxy user on 42.  We also don't have acct-{user,group} for
that, enewgroup + user is both dynamic in ebuild.

What's the motivation for trying to match the UID and GID values from
other distributions?

I previously tried to motivate a "purely dynamic" allocation with -1,
I'm showing this as an example where such an implementation would once
more be beneficial.

On a similar note, GLEP 27 allowed for overriding config variables
here.  Never got implemented.  GLEP 81 does not.  Oversight or (as per
my suspicion) exclusion to keep things simpler?

Would 142 be acceptable?

Only conflict seems to be activemq on Fedora (which we don't seem to have).

Otherwise 242 seems to be completely available.

I don't particularly care what the exact value ends up being, 42 would
have been a sweet one due to the ascii value of * being 42.


Kind Regards,
Jaco Kroon

On 2019/11/10 18:31, Michał Górny wrote:

> On Sun, 2019-11-10 at 18:23 +0200, Jaco Kroon wrote:
>> Hi,
>>
>> As part of taking maintainership of the net-misc/asterisk package (and
>> related), one of the cleanup items is to use the new acct-{user,group}
>> method for assigning UID and GID values.
>>
>> As such I'd like to please reserve UID and GID = 42 for asterisk.
>>
>> Why 42?
>>
>> echo -e "\x$(bc <<<"obase=16; 42")"
>>
>> Current net-misc/asterisk uses a dynamically assigned UID and GID value.
>>
>> I do not have permission to edit
>> https://wiki.gentoo.org/wiki/UID_GID_Assignment_Table
>> (https://api.gentoo.org/uid-gid.txt).
>>
>> Neither RHEL nor Fedora seems to have an asterisk user.  Arch uses 77.
>> We already have qemu on 77.
>>
>
> Other distros use 42 for something else, particularly for stuff we have
> as well.
>




[gentoo-dev] RFC acct-{user,group} for asterisk

2019-11-10 Thread Jaco Kroon
Hi,

As part of taking maintainership of the net-misc/asterisk package (and
related), one of the cleanup items is to use the new acct-{user,group}
method for assigning UID and GID values.

As such I'd like to please reserve UID and GID = 42 for asterisk.

Why 42?

echo -e "\x$(bc <<<"obase=16; 42")"

Current net-misc/asterisk uses a dynamically assigned UID and GID value.

I do not have permission to edit
https://wiki.gentoo.org/wiki/UID_GID_Assignment_Table
(https://api.gentoo.org/uid-gid.txt).

Neither RHEL nor Fedora seems to have an asterisk user.  Arch uses 77. 
We already have qemu on 77.

Kind Regards,
Jaco










Re: [gentoo-dev] separate /usr without initramfs

2019-10-25 Thread Jaco Kroon

Hi,

On 2019/10/25 20:14, William Hubbs wrote:

Hey all,

I have been advised to bring this topic back to the list before taking
any action, so here it is.

First, I need to clarify what I'm *NOT* talking about.

This discussion has nothing to do with whether or not you have the
split-usr use flag turned on; all of us officially have that on because
/bin, /lib* and /sbin are directories in the official Gentoo setup. In
other words, I am *not* talking about forcing the /usr merge.

Unfortunately, the concept of separate usr has gotten wrapped up in the
split-usr use flag and doesn't have to be.  For the record, I mean something
very specific when I say "separate usr". I am talking about the situation
where /usr is a mount point separate from /, so in this thread, let's stick
to "separate usr" for that situation. I am *not* even saying that using
separate usr is wrong or unsupported. You can even run separate usr with
split-usr turned off if you would like to do so.

Now for the use case I want to talk about, and that is using separate
/usr without using an initramfs to boot your system and pre-mount /usr.

If you do this, many things are broken, and this is why the binary
distros all use an initramfs if you do this. This configuration is also
unsupported officially in Gentoo [1] [2], and it is not shown as the
example setup in our handbook.

I want to hear from people who have / and /usr on separate partitions
and who are not using an initramfs.

If you are in this group, I have a very specific question. Why aren't
you using an initramfs?


Because until recently it wasn't an issue.  So for me the final kicker 
was still not a separate /usr.  For my use case everything except a big 
warning about md5sum not being available during boot works.  This is NOT 
desktop setup for MOST of my systems.  On the few that are I don't 
generally have things like bluetooth keyboards etc that I need available 
during early(ish) boot or anything crazy.  So the argument that "many 
things break" may be accurate, but I've yet to find a concrete example 
that bugs me enough to care.


There is basically one thing that I found that broke "out of the box" 
with a separate /usr - and that's if I have one of those stupid LTE 
modem things that pretend to be a disk drive/cdrom or something similar 
until you tell it to switch to network mode. The same thing that, for 
me, breaks with suspend resume (after resume I have to kill 
modem_manager, and start it *before* replugging the modem or it simply 
will not work - another discussion).


So frankly, I just don't see the benefit.  The reason I've eventually 
bothered with setting up and creating an initramfs now was because of 
/lib/firmware which I need available during module load (pre 
/etc/init.d/localmount) so that firmware is available as soon as amdgpu 
and i915 loads or else I end up with a borked screen.  Only uefi fb 
compiled into the kernel (required to get hand-over from grub2 ... at 
least, the only way I could get it to work smoothly).


The initramfs we ONLY pull in on systems where it's required (one 
currently, the machine I'm typing this on).


Why do I have /lib/firmware on a separate partition now?  Because 512MB 
for / used to be plenty, and I have MANY history systems out there which 
is non-trivial to make partitioning changes to (I keep / in a raw 
partition).  Now just /lib/firmware is larger than that.


Like William, / and /boot are definite partitions, and I want to keep 
these small.  Everything else is LVM.  Most systems have >50% of VG 
space unallocated because people always overestimate what they really need.


Separate partitions means I can set up separate mount options 
(nosuid,nodev etc ...)


Like William, I feel more cogs means more opportunities for breakage. I 
roll my own vanilla kernel, with one or two of my own patches.  I roll 
my own init script for initramfs.  Why - because system bootability is 
of utmost importance.  So I absolutely have to KNOW that it'll work, and 
when it doesn't that I can walk someone through fixing it over the 
phone. Never used the default gentoo initramfs.  genkernel always pulls 
in stuff I don't want nor need.  Sometimes it's just simpler I guess.  
But that's the thing - Gentoo gives me CHOICE.  Which I don't get from 
other distributions.  These are not the kind of things I like to leave 
to chance, or in the hands of a continuously changing tool (eg, dracut 
as mentioned by William).


Recently we ran into a bug causing filesystem corruption on /usr/portage 
(for some reason it was always under /usr/portage). With /usr on a 
separate partition we could recover that by setting appropriate boot 
options *remotely*.  No need to drive out.  Some of these systems were 
>100km away.


So another motivation for separate / and /usr for me is that / is much 
more read-heavy than /usr, and as such, with the lower write ratio lower 
risk of corruption.  Better ability to recover.


As to why not use the initramfs 

Re: [gentoo-dev] New distfile mirror layout

2019-10-22 Thread Jaco Kroon

Hi,

On 2019/10/22 10:43, Ulrich Mueller wrote:

On Tue, 22 Oct 2019, Jaco Kroon wrote:

I also agree with others that it used to be easy to get distfiles as
and when needed, so an alternative structure could mirror that of the
portage tree itself, in other words "cat/pkg/distfile".

Not a good idea, because some distfiles are shared between packages.
For example, sys-kernel/*-sources use the same distfiles. (It won't
work with categories either, e.g., there are dev-lang/ruby and
app-emacs/ruby-mode.)

Ulrich


You are absolutely correct.  I then fully agree with current implementation.

Kind Regards,
Jaco




Re: [gentoo-dev] New distfile mirror layout

2019-10-22 Thread Jaco Kroon

Hi All,


On 2019/10/21 18:42, Richard Yao wrote:


If we consider the access frequency, it might actually not be that bad. 
Consider a simple example with 500 files and two directory buckets. If we have 
250 in each, then the size of the directory is always 250. However, if 50 files 
are accessed 90% of the time, then putting 450 into one directory and that 50 
into another directory, we end up with the performance of the O(n) directory 
lookup being consistent with there being only 90 files in each directory.

I am not sure if we should be discarding all other considerations to make 
changes to benefit O(n) directory lookup filesystems, but if we are, then the 
hashing approach is not necessarily the best one. It is only the best when all 
files are accessed with equal frequency, which would be an incorrect 
assumption. A more human friendly approach might still be better. I doubt that 
we have the data to determine that though.

Also, another idea is to use a cheap hash function (e.g. fletcher) and just 
have the mirrors do the hashing behind the scenes. Then we would have the best 
of both worlds.



Experience:

ext4 sucks at targeting name lookups without dir_index feature (O(n) 
lookups - scans all entries in the folder).  With dir_index readdir 
performance is crap.  Pick your poison I guess.  Most of our larger 
filesystems (2TB+, but especially the 80TB+ ones) we've reverted to 
disabling dir_index as the benefit is outweighed by the crappy readdir() 
and glob() performance.


There doesn't seem to be a real specific tip-over point, and it seems to 
depend a lot on RAM availability and harddrive speed (obviously).  So if 
dentries gets cached, disk speeds becomes less of an issue.  However, on 
large folders (where I typically use 10k as a value for large based on 
"gut feeling" and "unquantifiable experience" and "nothing scientific at 
all") I find that even with lots of RAM two consecutive ls commands 
remains terribly slow. Switch off dir_index and that becomes an order of 
magnitude faster.


I don't have a great deal of experience with XFS, but on those systems 
where we do it's generally on a VM, and perceivably (again, not 
scientific) our experience has been that it feels slower.  Again, not 
scientific, just perception.


I'm in support for the change.  This will bucket to 256 folders and 
should have a reasonably even split between folders.  If required a 
second layer could be introduced by using the 3rd and 4th digits of the 
hash for a second layer.  Any hash should be fine, it really doesn't 
need to be cryptographically strong, it just needs to provide a good 
spread and be really fast.  Generally a hash table should have a prime 
number of buckets to assist with hash bias, but frankly, that's over 
complicating the situation here.


I also agree with others that it used to be easy to get distfiles as and 
when needed, so an alternative structure could mirror that of the 
portage tree itself, in other words "cat/pkg/distfile". This perhaps 
just shifts the issue:


jkroon@plastiekpoot /usr/portage $ find . -maxdepth 1 -type d -name 
"*-*" | wc -l

167
jkroon@plastiekpoot /usr/portage $ find *-* -maxdepth 1 -type d | wc -l
19412
jkroon@plastiekpoot /usr/portage $ for i in *-*; do echo $(find $i 
-maxdepth 1 -type d | wc -l) $i; done | sort -g | tail -n10

347 net-misc
373 media-sound
395 media-libs
399 dev-util
505 dev-libs
528 dev-java
684 dev-haskell
690 dev-ruby
1601 dev-perl
1889 dev-python

So that's average 116 sub folders under the top layer (only two over 
1000), and then presumably less than 100 distfiles maximum per package?  
Probably overkill but would (should) solve both the too many files per 
folder as well as the easy lookup by hand issue.


I don't have a preference on either solution though but do agree that 
"easy finding of distfiles" are handy.  The INDEX mechanism is fine for me.


Kind Regards,

Jaco


Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

2019-10-16 Thread Jaco Kroon
Hi,

-- large trim --
>> For what it's worth.  All of my systems are installed with a fixed-
>> size
>> 512MB / with everything else (including /usr) on separate LVs.
>>
>> Whilst sbin vs bin is just a matter of what's available, to me it
>> makes
>> sense to keep these split.  To me it's always been logical to keep
>> administrative type (root) tools under sbin, and stuff that's
>> generally
>> useful for users under bin.
>>
>> Keeping / and /usr split (or the ability to keep it split) is rather
>> crucial for me.  It's for historic installations a matter of space
>> constraints on /.  For new installations it's a matter of keeping /
>> as
>> small as possible in order to have a smallish bootable system which
>> can
>> be used for recovering the rest of the system, ideally without an
>> initrd
>> (which also works to an extent).
>>
>> Kind Regards,
>> Jaco
>>
> For the umpteenth time time: nothing will change. You can keep your
> (albeit broken) separate / and /usr partitions. *NOTHING* will change
> for anyone. There are no plans to change the defaults. This is *MERELY*
> about giving people the chance to opt in to the /usr-merge.
Thanks for the confirmation.  As long as it's an OPTION I'm happy.  And
no, other than on my desktop machine a split /usr is working very well,
and even in that case a split off /lib/firmware actually caused me much,
much more problems (for i915 and amdgpu firmware) than a split /usr. 
Unfortunately /lib/firmware grew over the years and so I had no choice
other than to split it off after the fact.
>
> That said, the idea of using / as a "recovery" filesystem in general is
> broken: 
> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
> And no, this is not systemd breaking your system, or Lennart, it's
> distros and userlands not being careful to have things in / never
> depend on things in /usr.

It's saved my butt more than once when the (extremely) limited tools in
the initrds on those same systems failed to do so.  Mostly these cases
weren't Gentoo.  Yes RHEL, I'm looking at you.  Gentoo I generally
recover crazy faults without the use of system rescue CDs (probably
required it 10 times over 15 years).  Can't say the same for those
distro's pushing for "recovery systems in initrd", and I'm running
probably 3x more Gentoo systems than all other distro's combined.

The only stuff so far I really wished worked without /usr was editors
such as vim and/or nano (sed sufficed in those cases).

Would contributing a script that's able to check which binaries in /bin
(and /sbin) depend on libs not also on / be useful here?  Perhaps as a
QA check somehow?

And I get that that's a completely different rabbit hole ...

1.  What about non-lib files, eg, /usr/share/zoneinfo?
2.  Should such binaries be moved to /usr or should the libraries be
moved to /?
X.  a gazillion things I haven't even started to think about.

Kind Regards,
Jaco


>
>



Re: [gentoo-dev] [PATCH] use.desc: add global USE flag 'split-sbin'

2019-10-16 Thread Jaco Kroon
Hi,

On 2019/10/15 19:34, David Seifert wrote:
> On Tue, 2019-10-15 at 12:04 -0400, Mike Gilbert wrote:
>> On Tue, Oct 15, 2019 at 12:02 PM Mike Gilbert 
>> wrote:
>>> On Tue, Oct 15, 2019 at 8:00 AM David Seifert 
>>> wrote:
 On Sun, 2019-10-13 at 12:33 -0400, Mike Gilbert wrote:
> On Sat, Oct 12, 2019 at 1:52 PM David Seifert 
> wrote:
>> On Sat, 2019-10-12 at 19:01 +0200, Dennis Schridde wrote:
>>> On Samstag, 12. Oktober 2019 18:02:28 CEST William Hubbs
>>> wrote:
 On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał Górny
 wrote:
> On Sat, 2019-10-12 at 13:00 +0200, David Seifert wrote:
>> * Some distros have not just merged / and /usr, they
>>
>>   have also merged /usr/bin and /usr/sbin. By giving
>>   users the choice of merging */bin and */sbin,
>>   Gentoo follows suit.
> What about the scenario when /bin has been merged with
> /usr/sbin
> and /sbin with /usr/bin?  ;-P
 I also don't see the need for something like this. The
 idea of
 the
 /usr
 merge is to have all binaries available in one place, and
 there
 really
 is not a good justification for separating bin from sbin.
>>> Do I read this correctly?  USE=-split-usr currently means
>>> that
>>> /bin,
>>> /sbin, /
>>> usr/bin and /usr/sbin point to the same directory?
>>>
>>> If that is not the case, then I agree that users should
>>> have the
>>> possibility
>>> to set it up like this and USE=-split-sbin should be
>>> supported.
>>>
>>> --Dennis
>> I agree, I wasn't aware that USE=-split-usr implies the
>> complete 2-
>> level (/usr and *sbin) merge. In that case, all of this is
>> obsolete.
> That was NOT my intention when I introduced the split-usr USE
> flag.
>
> For bin/sbin, I would prefer to drop any conflicting links
> unconditionally. Do you have examples of scenarios where this
> is not
> possible?
>
 William has confirmed on IRC that USE=-split-usr performs the
 complete
 Fedora-esque /usr merge (which makes sense IMO).
>>> William's opinion is not the only one that matters.
>> Sorry, I guess you are referring to the behavior baselayout? That
>> doesn't necessarily align with the global usage.
>>
> https://gitweb.gentoo.org/proj/baselayout.git/tree/Makefile#n93
>
> Clearly the usr-merge in baselayout intends to merge all these 4
> directories. There is currently no option to merge /usr and / but keep
> /bin and /sbin separate, so the most parsimonious solution here is to
> assume that usr-merge semantics in Gentoo is about merging all 4
> directories.
>
>
For what it's worth.  All of my systems are installed with a fixed-size
512MB / with everything else (including /usr) on separate LVs.

Whilst sbin vs bin is just a matter of what's available, to me it makes
sense to keep these split.  To me it's always been logical to keep
administrative type (root) tools under sbin, and stuff that's generally
useful for users under bin.

Keeping / and /usr split (or the ability to keep it split) is rather
crucial for me.  It's for historic installations a matter of space
constraints on /.  For new installations it's a matter of keeping / as
small as possible in order to have a smallish bootable system which can
be used for recovering the rest of the system, ideally without an initrd
(which also works to an extent).

Kind Regards,
Jaco





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

2019-08-29 Thread Jaco Kroon
Hi Michał,

To the best of my knowledge this used to be a dependency for DAHDI
(zaptel at the time if I recall my time lines).  I've confirmed that
DAHDI and asterisk can compile on current versions without this, can't
find any other users of this in the tree.

So as far as I know this can be retired safely.

Kind Regards,
Jaco

On 2019/08/29 12:43, Michał Górny wrote:

> # Michał Górny  (2019-08-29)
> # Added in 2012 and not touched since.  Fails multilib-strict.  Pending
> # version bump.  No reverse dependencies.
> # Removal in 30 days.  Bug #667064.
> net-misc/libss7
>



Re: [gentoo-dev] [PATCH] acct-*.eclass: Allow dynamic UID/GID assignment via -1

2019-08-19 Thread Jaco Kroon
Thank you.


Kind Regards,
Jaco


On 2019/08/17 22:37, Michał Górny wrote:

> On Wed, 2019-08-07 at 19:10 +0200, Michał Górny wrote:
>> Allow a special value of '-1' to dynamically assign UID/GID for the user
>> or group.  This is intended to be used in overlays where proper
>> assignment does not take place but whose owners wish to switch to acct-*
>> packages.
>>
>> While technically it is possible to choose a free UID/GID, it could be
>> taken afterwards by some Gentoo package and unnecessarily introduce
>> a conflict.  Using '999' was also suggested (as the first dynamic
>> UID/GID) but it would cause issues for people enabling
>> ACCT_*_ENFORCE_ID.  To avoid this, '-1' does not trigger collision
>> checks.
>>
>> Signed-off-by: Michał Górny 
>> ---
>>  eclass/acct-group.eclass | 4 
>>  eclass/acct-user.eclass  | 4 
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
>> index 9eab00db690f..d5ccd209c9e3 100644
>> --- a/eclass/acct-group.eclass
>> +++ b/eclass/acct-group.eclass
>> @@ -59,6 +59,9 @@ readonly ACCT_GROUP_NAME
>>  # @DESCRIPTION:
>>  # Preferred GID for the new group.  This variable is obligatory, and its
>>  # value must be unique across all group packages.
>> +#
>> +# Overlays should set this to -1 to dynamically allocate GID.  Using -1
>> +# in ::gentoo is prohibited by policy.
>>  
>>  # @ECLASS-VARIABLE: ACCT_GROUP_ENFORCE_ID
>>  # @DESCRIPTION:
>> @@ -87,6 +90,7 @@ acct-group_pkg_pretend() {
>>  
>>  # verify ACCT_GROUP_ID
>>  [[ -n ${ACCT_GROUP_ID} ]] || die "Ebuild error: ACCT_GROUP_ID must be 
>> set!"
>> +[[ ${ACCT_GROUP_ID} -eq -1 ]] && return
>>  [[ ${ACCT_GROUP_ID} -ge 0 ]] || die "Ebuild errors: 
>> ACCT_GROUP_ID=${ACCT_GROUP_ID} invalid!"
>>  
>>  # check for ACCT_GROUP_ID collisions early
>> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
>> index 60009643c144..17a58e9126e4 100644
>> --- a/eclass/acct-user.eclass
>> +++ b/eclass/acct-user.eclass
>> @@ -67,6 +67,9 @@ readonly ACCT_USER_NAME
>>  # @DESCRIPTION:
>>  # Preferred UID for the new user.  This variable is obligatory, and its
>>  # value must be unique across all user packages.
>> +#
>> +# Overlays should set this to -1 to dynamically allocate GID.  Using -1
>> +# in ::gentoo is prohibited by policy.
>>  
>>  # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
>>  # @DESCRIPTION:
>> @@ -279,6 +282,7 @@ acct-user_pkg_pretend() {
>>  
>>  # verify ACCT_USER_ID
>>  [[ -n ${ACCT_USER_ID} ]] || die "Ebuild error: ACCT_USER_ID must be 
>> set!"
>> +[[ ${ACCT_USER_ID} -eq -1 ]] && return
>>  [[ ${ACCT_USER_ID} -ge 0 ]] || die "Ebuild errors: 
>> ACCT_USER_ID=${ACCT_USER_ID} invalid!"
>>  
>>  # check for ACCT_USER_ID collisions early
> Pushed now.


Re: [gentoo-dev] [PATCH] acct-user.eclass: ignore missing directory in preinst

2019-08-16 Thread Jaco Kroon
Hi,

On 2019/08/15 16:47, Mike Gilbert wrote:

> On Thu, Aug 15, 2019 at 8:33 AM Michael Orlitzky  wrote:
>> On 8/15/19 3:19 AM, Ulrich Mueller wrote:
>>> I don't think that's a sane situation, so maybe the eclass should just
>>> die here? (Basically, there are two possibilities: Either, things will
>>> break if the dir is missing, then dying might be the best option.
>>> Or, everything works without the dir, then the ebuild should set it to
>>> /dev/null, in the first place.)
>>>
>> That's my feeling as well. In 100% of cases so far, this has been a
>> useful QA tool. Can we wait until that's not the case to change it?
> I think an explicit die with a useful error message for the user would
> be better than the status-quo.

I agree.


Kind Regards,
Jaco




Re: [gentoo-dev] dynamic groups and users

2019-08-08 Thread Jaco Kroon

Hi Ulrich,


> >> I don't see any reason to prohibit having a user/group package for
>> root. > > Is creation of (additional) users with UID 0 a good idea
from a > security point of view? Maybe it is better to explicitly forbid
it? > I believe the current code already prevents re-use of an already
used UID value.  So this concern, whilst valid, is already addressed I
believe.

Kind Regards,
Jaco



Re: [gentoo-dev] dynamic groups and users

2019-08-08 Thread Jaco Kroon
Hi Michał,

On 2019/08/07 17:48, Michał Górny wrote:
> On Tue, 2019-08-06 at 13:41 +0200, Jaco Kroon wrote: >> Hi Guys, >> >> 
> Attaching. It seems for some reason if I inline the
patches they don't >> come through. If I mail to myself only it works
just fine. >> > > Actually, I think it should be changed the other way
around. I don't > see any reason to prohibit having a user/group package
for root.
Hmm, ie, remove root from baselayout?  Honestly, that's a mind stretch. 
And since it makes no sense to have any other package create a uid of
gid =0 I think the change is right.

No objection to do it the other way around, but since the value won't
make any sense it'll effectively become a "please allocate dynamically"
value - which goes against what you stated earlier of everything in
::gentoo should be "static".

Please confirm.

Kind Regards,
Jaco




Re: [gentoo-dev] dynamic groups and users

2019-08-06 Thread Jaco Kroon

Hi Guys,

Attaching.  It seems for some reason if I inline the patches they don't 
come through.  If I mail to myself only it works just fine.



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 <http://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 
<http://www.linkedin.com/com/images/ico-linkedin.jpg>


<http://www.iewc.co.za/> <http://www.uls.co.za/>

This email and all contents are subject to the following disclaimer: 
View Disclaimer <http://www.iewc.co.za/email-disclaimer/>


On 2019/08/04 18:22, Jaco Kroon wrote:

Hi Michał,

On 2019/08/02 19:06, Michał Górny wrote:

On Fri, 2019-08-02 at 12:24 -0400, Michael Orlitzky wrote:

On 8/2/19 11:58 AM, Michał Górny wrote:
Given that overlays won't do proper assignment, the numbers they 
choose
may collide with numbers used in ::gentoo.  Forcing explicit 
assignment

from dynamic range is cleaner in that regard.


I think it would be cleanest to leave the hacks in the overlay, and set
the desired ID to either 999 or a random number like floppym suggested.
The meaning of RANDOM is even more clear than "-1", and doesn't require
us to add both the code that's dead-on-arrival and the CI check to
ensure that it stays that way. But you're the one who's maintaining it
now so I won't argue.


I suppose setting it to 999 would also serve the purpose.  Jaco, do you
agree?


No objections.

999 I think is probably as good a reserved "don't care" number as any, 
since really the first dynamic allocation will already use that.


Kind Regards,
Jaco


>From bf26d929f32d02c5af1967ec4257e0f69fdf7f07 Mon Sep 17 00:00:00 2001
In-Reply-To: 
References: 
From: Jaco Kroon 
Date: Sun, 4 Aug 2019 18:44:09 +0200
Subject: [PATCH 1/2] acct-group eclass - enforce GID > 0 instead of GID >= 0.
To: Jaco Kroon 

Signed-off-by: Jaco Kroon 
---
 eclass/acct-group.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 9eab00db690..9a759f03c57 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -87,7 +87,7 @@ acct-group_pkg_pretend() {
 
 	# verify ACCT_GROUP_ID
 	[[ -n ${ACCT_GROUP_ID} ]] || die "Ebuild error: ACCT_GROUP_ID must be set!"
-	[[ ${ACCT_GROUP_ID} -ge 0 ]] || die "Ebuild errors: ACCT_GROUP_ID=${ACCT_GROUP_ID} invalid!"
+	[[ ${ACCT_GROUP_ID} -gt 0 ]] || die "Ebuild errors: ACCT_GROUP_ID=${ACCT_GROUP_ID} invalid!"
 
 	# check for ACCT_GROUP_ID collisions early
 	if [[ -n ${ACCT_GROUP_ENFORCE_ID} ]]; then
-- 
2.21.0

>From 8ed213968674d38a6809f8638bb649d43cb1a7bf Mon Sep 17 00:00:00 2001
In-Reply-To: 
References: 
From: Jaco Kroon 
Date: Sun, 4 Aug 2019 18:45:17 +0200
Subject: [PATCH 2/2] acct-user eclass: enforce UID > 0 instead of UID >= 0.
To: Jaco Kroon 

Signed-off-by: Jaco Kroon 
---
 eclass/acct-user.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 60009643c14..1276331275c 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -279,7 +279,7 @@ acct-user_pkg_pretend() {
 
 	# verify ACCT_USER_ID
 	[[ -n ${ACCT_USER_ID} ]] || die "Ebuild error: ACCT_USER_ID must be set!"
-	[[ ${ACCT_USER_ID} -ge 0 ]] || die "Ebuild errors: ACCT_USER_ID=${ACCT_USER_ID} invalid!"
+	[[ ${ACCT_USER_ID} -gt 0 ]] || die "Ebuild errors: ACCT_USER_ID=${ACCT_USER_ID} invalid!"
 
 	# check for ACCT_USER_ID collisions early
 	if [[ -n ${ACCT_USER_ENFORCE_ID} ]]; then
-- 
2.21.0



Re: [gentoo-dev] [PATCH] glep-0067: Add 'proxied' and 'watcher' maint types

2019-08-04 Thread Jaco Kroon

Hi

On 2019/08/03 01:19, Jonas Stein wrote:

On 02/08/2019 22.55, Michał Górny wrote:

Add two new maintainer types: 'proxied' for proxied maintainers,
and 'watcher' for people who wish to be CC-ed on bugs but are not
maintainers (e.g. upstream developers).

Can't we solve this simply in the bug tracker? The monitor setting of a
user does not belong into the tree.


The upstream maintainer and all other "watchers" have no write access to
the tree so they will consume manpower in adding and removing their
contacts to packages.

The perfect solution would be that any user can add a watch filter to
my-cat/mypkg in the bugtracker.

Between 2018-01-01 and 2018-12-31 we received and assigned 31280 bugs.
I am no fan of the descriptions in the form "please CC: If the bug is
about x but not y and the moon is in the third house of the lion"

This consumes extra time for every assignment and prevents automagic
assignment in future. We should rather keep it simple instead of
extending the options.


I agree.  I was just thinking "I'd like to watch certain packages, be 
aware of commits et al, but not get involved in ongoing stuff" too.


The rule should be simple:  CC me on any bugs to this list of packages.

I can then unsub myself from individual bugs I don't care about.

Then there are packages that have changed in the past unexpectedly and 
bit me (badly sometimes), so on those I'd like to know about any commit 
going in.  Guess I can set up a git pull + filter myself there, but if 
this is done upstream then it can work for everyone, and not waste 
duplication effort.


Kind Regards,
Jaco




Re: [gentoo-dev] dynamic groups and users

2019-08-04 Thread Jaco Kroon

Hi Michał,

On 2019/08/02 19:06, Michał Górny wrote:

On Fri, 2019-08-02 at 12:24 -0400, Michael Orlitzky wrote:

On 8/2/19 11:58 AM, Michał Górny wrote:

Given that overlays won't do proper assignment, the numbers they choose
may collide with numbers used in ::gentoo.  Forcing explicit assignment
from dynamic range is cleaner in that regard.


I think it would be cleanest to leave the hacks in the overlay, and set
the desired ID to either 999 or a random number like floppym suggested.
The meaning of RANDOM is even more clear than "-1", and doesn't require
us to add both the code that's dead-on-arrival and the CI check to
ensure that it stays that way. But you're the one who's maintaining it
now so I won't argue.


I suppose setting it to 999 would also serve the purpose.  Jaco, do you
agree?


No objections.

999 I think is probably as good a reserved "don't care" number as any, 
since really the first dynamic allocation will already use that.


Kind Regards,
Jaco




Re: [gentoo-dev] dynamic groups and users

2019-08-02 Thread Jaco Kroon

Thank you Michał, much appreciated.

I've in the meantime to make progress on my side picked something which 
was not in use in ::gentoo, so I can move forward, but it's be really 
good to have the below feature anyway going forward.


On 2019/08/01 22:47, Michał Górny wrote:

On Thu, 2019-08-01 at 21:04 +0200, Jaco Kroon wrote:

Hi,

Looking at the new eclasses for acct-user and acct-group.

These enforce that a group and user id should be set.

This is not a requirement for enewuser nor enewgroup.

As a further discrepancy, the user eclass requires >0 for the IDs,
whereas the checks in acct-user and acct-group is for >= 0.

Would it be ok to suggest that we allow -1 (or 0, but that could be
confused with the root user/group) in acct-user and acct-group to
specify "no specific id, please allocate dynamically"?

Use case:  I'm building some experimental packages in an overlay, and I
really don't care what the UID and GID values are, I just need something
unique on the host I can use to avoid running the service as root.
Guessing I could just manually useradd -r but then again ... if I do
later submit these into the main tree (or other packages) then it
becomes a problem, and maintaining acct-{user,group}/* outside of main
tree could conflict with main tree at a later stage ... either way,
having some way to say "I honestly don't care, just give me a random
number" is probably a good thing.


I'll look into adding support for '-1' in a few days.  However, I'm
going to add QA checks to prevent it from getting into ::gentoo first.


Assuming I understand that correctly, you're happy with -1 values going 
into overlays, but not into ::gentoo?


Would you mind to explain the motivation for that?

I'm also happy to take a whack at generating a patch series for you for 
the eclasses themselves (not familiar with the QA check code yet), 
including sorting out the >0 vs >=0 discrepancy, if you're happy with that?


Kind Regards,
Jaco



Re: [gentoo-dev] dynamic groups and users

2019-08-01 Thread Jaco Kroon

Hi Mike,

From user.eclass:

146 if [[ ${euid} -gt 0 ]] ; then
147 if [[ -n $(egetent passwd ${euid}) ]] ; then
148 [[ -n ${force_uid} ]] && die "${FUNCNAME}: UID 
${euid} already taken"

149 euid="next"
150 fi
151 else
152 eerror "Userid given but is not greater than 0 !"
153 die "${euid} is not a valid UID"
154 fi

Similar for egid.

This is the discrepency of >=0 (acct-user and acct-group) vs >0 (user) I 
was referring.  So yes, I can set it, but the underlying enewuser and 
enewgroup calls is going to kick out as per above.


Yes, I could use something like uid=1 (bin) and gid=1 (bin) which I'm 
reasonably sure use comes from baselayout and is thus almost guaranteed 
to conflict always, but the *intention* of that's unclear.  I'd rather 
(and I'm happy to write the patches, just don't want to waste my time 
doing so if it's of no interest to anyone else) have a way to explicitly 
state "I really don't care about this uid or gid value".  Also, should 
it be required to be set to eg -1 to indicate this, or is the variable 
not being set a good enough indication?  I'm included to require -1 else 
a simple typo could result in accidental dynamic allocation.


Regarding your $RANDOM idea ... that is rather crazy, and will work, 
however, I suspect you should make that % 499 ... saw an email earlier 
about the IDs should be <500 since 500 to 999 is reserved for dynamic 
allocation.


I currently have at least four dynamically allocated groups on the 
machine I'm typing this on:


tcpdump:x:999:
mrtg:x:998:
rrd:x:997:
ulsreport:x:996:

I like the idea of it being allocated from 999 downwards, and I really 
think dynamic allocation makes sense for many packages.  I do support 
the idea of predictable IDs, for packages which can trivially use shared 
storage (eg, mail).  For other packages (eg, webrtc2sip which I'm 
working with currently) it seriously doesn't matter as it'll never write 
to disk (other than the log files ...). Heck, even if it could, sharing 
that state wouldn't make much sense either.  Even something like 
asterisk being predictable makes sense, since 
/var/spool/asterisk/monitor (and a few others, as we currently are) 
could be shared between multiple hosts.


Kind Regards,

Jaco Kroon

On 2019/08/01 22:01, Mike Gilbert wrote:


On Thu, Aug 1, 2019 at 3:04 PM Jaco Kroon  wrote:

Hi,

Looking at the new eclasses for acct-user and acct-group.

These enforce that a group and user id should be set.

This is not a requirement for enewuser nor enewgroup.

The new eclasses require you to set a fixed id, but they do not
enforce that the id is available by default. If the id is taken
already, it will allocate a new one.

User/group 0 is pretty much guaranteed to always exist, so you could
set ACCT_{GROUP,USER}_ID=0 to trigger the desired behavior.

If you're feeling crazy, this will get you a random assignment between
1 and 999, with the same fallback logic.

ACCT_GROUP_ID=$(( RANDOM % 998 + 1 ))



[gentoo-dev] dynamic groups and users

2019-08-01 Thread Jaco Kroon

Hi,

Looking at the new eclasses for acct-user and acct-group.

These enforce that a group and user id should be set.

This is not a requirement for enewuser nor enewgroup.

As a further discrepancy, the user eclass requires >0 for the IDs, 
whereas the checks in acct-user and acct-group is for >= 0.


Would it be ok to suggest that we allow -1 (or 0, but that could be 
confused with the root user/group) in acct-user and acct-group to 
specify "no specific id, please allocate dynamically"?


Use case:  I'm building some experimental packages in an overlay, and I 
really don't care what the UID and GID values are, I just need something 
unique on the host I can use to avoid running the service as root.  
Guessing I could just manually useradd -r but then again ... if I do 
later submit these into the main tree (or other packages) then it 
becomes a problem, and maintaining acct-{user,group}/* outside of main 
tree could conflict with main tree at a later stage ... either way, 
having some way to say "I honestly don't care, just give me a random 
number" is probably a good thing.


Kind Regards,
Jaco








Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-23 Thread Jaco Kroon

Hi Michał,

On 2019/07/23 14:39, Michał Górny wrote:

On Wed, 2019-07-24 at 00:17 +1200, Kent Fredric wrote:

On Tue, 23 Jul 2019 13:38:28 +0200
Gerion Entrup  wrote:


What about a compromise?:
Deliver a (prebuild) manpage as package maintainer by default, but keep
a use flag "man-build" (or whatever) that builds the man page for everyone
(also the maintainer herself)  with use of the crazy extra deps. So a user can
do (incomplete) version bumps and gets a manpage and the maintainer
gets the prebuild manpage in a defined way.

You're missing the part where the maintainer is, by the policy,
required to, for every bump:

1. Ensure the generated documentation is extracted from the build
2. Packaged into a tarball somewhere
3. Uploaded to a server that can host that tarball
4. Update the package to use that.

Failure to do this will mean you're shipping out-dated documentation to
the user.

I fail to see how this could happen, unless you'd be using terrible
hacks.

And therein lies the issue.  We would.

This series of back-flips is just not practical at present, and
introduces more steps where mistakes can break the ebuild.

 From this thread, it seems that most devs find it impractical to even
test their ebuilds.


No.  They've been saying that the overhead of maintaining the above 
mentioned terrible hacks is unacceptable.  Imagine this:


In order to build man pages I need to pull in 20 additional packages.  
So when I roll new ebuild, I need those 20 ... not an issue for me, so 
now I need to build the man pages, and I need to create a tarball with 
those.  A tarball which won't exist at the time when I initially build, 
so it's not available to generate a Manifest.  So first I have to avoid 
those from SRC_URI completely.  Then once I've deployed the pre-built 
manpages, I need to re-add it.


So every time there is an upstream version bump, this needs to be 
rechecked and determined whether the manpages also needs to be bumped, 
or I need to bump unconditionally.  More overhead.


This is outright annoying.  Unless it can be automated properly. And I 
believe it might be possible, but it'll involve yet more base complexity 
by adding build-time dependencies to build man pages to a separate 
depend (or at least flag them with a USE=buildman flag), somehow portage 
would need to first sort out the building and deployment of the separate 
SRC_URI for man pages before adding to the Manifest.  You get where I'm 
going I hope.


Everybody agrees with your base premise:  It's ideal to ship (optional) 
documentation along with every single package, especially if it doesn't 
have to pull in a boatload of dependencies.


Kind Regards,
Jaco




Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

2019-07-22 Thread Jaco Kroon

Hi,

I'm with Rich on this one.  I trust that like me most of the developers 
here earn pay checks from elsewhere and that our time here is either 
completely volunteer work, or towards a purpose that suits that of our 
employers.


Unless there is a way to automate the building of the associated man 
pages on a build server in some way.  This might be possible come to 
think of it.


USE flag to enable/disable bundled packages.  Any packages that gets 
committed with this USE flag goes off to a build server that builds the 
package and prepares an install (without bundled) and then the man pages 
can be scraped from the prepared install I reckon and placed on a 
standard URL, say d.g.o/manpages/${CATEGORY}/${PVR}.tar.gz  ... possibly 
an eclass may be required I don't know, haven't thought about it that much.


I am in support of the idea that for any given command there should be a 
"sensible" man page (it could be as simple as pointing to online 
documentation), but don't see this as a show stopper.


I'll support this proposal if, and only if, there is a way to automate 
the building and distribution of "bundled" man pages as proposed.


Kind Regards,
Jaco

On 2019/07/21 00:16, Rich Freeman wrote:


On Sat, Jul 20, 2019 at 4:22 PM Michał Górny  wrote:


Yes, I get it.  User experience is not important if it would mean
developers would actually do anything but the bare minimum to get
from one paycheck to another.  The usual Gentoo attitude.


Not sure where I go to sign up for those paychecks.  However, even
employers have to accept that policies have a resource cost to them.

Requiring people to do more than the bare minimum often just ensures
that they won't even bother to do the bare minimum.  I'm all for
finding ways to standardize things so that everybody benefits at a
very low cost.  This doesn't seem that, and honestly requiring
packages to bundle pre-built manpages seems a bit non-Gentooish to
begin with.





Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-16 Thread Jaco Kroon

Hi,

Ok, so to me that still makes sense.  So you just still motivated to me 
why a separate /usr is still a good idea, not why it should be merged.


There are some arbitrary rules there that doesn't make sense.

The real question then really is, why are we merging into /usr and not 
back into /?


Kind Regards,
Jaco

On 2019/07/15 17:37, William Hubbs wrote:

On Mon, Jul 15, 2019 at 10:51:46AM -0400, Michael Orlitzky wrote:

On 7/15/19 10:45 AM, Jaco Kroon wrote:

I have no idea who wrote this:

"The historical justification for a /bin, /sbin and /lib separate from
/usr no longer applies today." but I strongly disagree.

All of that stuff is written from the perspective of "I feel like doing
it this way in systemd, so I need to post-hoc justify making everyone
else go along with it."

Also add this:

https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/

In particular, note Rob Landley's response linked in that story.

So, this has nothing to do with systemd at all, please stop conflating
it.

William




Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Jaco Kroon

I have no idea who wrote this:

"The historical justification for a /bin, /sbin and /lib separate from 
/usr no longer applies today." but I strongly disagree.


Again, if /usr goes belly up (which with recent ext4/io bug(s) we've had 
probably about 10 systems already that needed repairing, and at least 5 
more that's pending), this fault would require me to head out to site to 
go and repair where currently due to fsck et al living on / and not on 
/usr I could recover without issues.


We've been unable to track an exact issue, but all of the affected 
systems was running 4.14.X kernels, we've not seen the same corruption 
from 5.0.2 onwards.  So we never filed a bug and simply upgraded kernels.


Further, none of the arguments for merging / and /usr makes any sense 
other than "others have already done this and if we don't follow suite 
we'll get cut off".  Not even the statement about network share of /usr 
makes any sense.  We run completely diskless systems with even / over 
nfs ... so seriously.


Even most of the myths and facts arguments are plainly uneducated.

Essentially what happens now is that an initrd needs to be built to 
contain ALL recovery tools that could possibly be required. Where 
previously, with / being mostly read-only this was still a risk worth 
taking.


Anyway, from the looks of this, this is just another comply or die 
situation, so I'm not seeing that there is much choice or say in this 
matter.  We'll just have to bloat our initrd's even further.  
Fortunately they do get freed post post ... just hoping they'll fit into 
the existing /boot partitions we have on our systems.



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 <http://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 
<http://www.linkedin.com/com/images/ico-linkedin.jpg>


<http://www.iewc.co.za/> <http://www.uls.co.za/>

This email and all contents are subject to the following disclaimer: 
View Disclaimer <http://www.iewc.co.za/email-disclaimer/>


On 2019/07/15 16:22, Marek Szuba wrote:

On 2019-07-15 14:59, Jaco Kroon wrote:


I've seen arguments that it's a historic split, and to an extent this is
true, however, having critical system recovery (and basic boot) stuff in
/, on as small as possible a partition, with the bulk of the system on
/usr makes a lot of sense for me.

That's one of the reasons, yes. For a more in-depth discussion, see

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

as well as the Fedora feature the above mentions.

))/io


Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Jaco Kroon

Hi Marek,

Perhaps I need to re-ask the question this way:

What's the motivation for "merging" / and /usr?

I've seen arguments that it's a historic split, and to an extent this is 
true, however, having critical system recovery (and basic boot) stuff in 
/, on as small as possible a partition, with the bulk of the system on 
/usr makes a lot of sense for me.


Kind Regards,
Jaco


On 2019/07/15 14:28, Marek Szuba wrote:

On 2019-07-15 12:38, Jaco Kroon wrote:


I'm personally using a separate /usr (On numerous systems) and other
than one problem I've encountered this isn't actually currently an issue
for me, and the reason this specific case was an issue was due to one
single tool (which unfortunately I can't remember now) having been
installed into /usr where I'd personally expect it to go into /.

The issue is not with *split* /usr, it's with the scenario currently
being adopted by many Linux distros (e.g. Fedora or Debian) in which
/bin, /sbin, /lib and /lib64 are symlinks to respective subdirectories
of /usr. The purpose of the changes at hand is, as described by floppym
in his initial post, to pave the way towards making merged /usr workable
on Gentoo for the average user.



Re: [gentoo-dev] [PATCH 0/6] Make 'split-usr' USE flag global and use it in gen_usr_ldscript

2019-07-15 Thread Jaco Kroon

Hi,

Perhaps it's just me not being in the loop, but what exactly is the 
problem we're trying to solve here?



I'm personally using a separate /usr (On numerous systems) and other 
than one problem I've encountered this isn't actually currently an issue 
for me, and the reason this specific case was an issue was due to one 
single tool (which unfortunately I can't remember now) having been 
installed into /usr where I'd personally expect it to go into /.


Kind Regards,
Jaco

On 2019/07/15 01:50, Mike Gilbert wrote:


This series introduces the global USE flag 'split-usr' to control
whether binaries and libraries are split into separate / and /usr
directories, or if they are always installed in /usr. This is a step
toward making merged /usr workable on Gentoo for the average user.

This USE flag is already being used by some packages, including
sys-apps/baselayout and sys-apps/systemd.

This series also moves the gen_usr_ldscript function to a new eclass,
and makes it a noop on most systems when split-usr is enabled. Moving
it to a new eclass allows us to avoid adding IUSE="split-usr" to every
ebuild that uses toolchain-funcs.eclass.

Mike Gilbert (6):
   profiles: add global USE flag 'split-usr'
   profiles: enable USE="split-usr" in base
   usr-ldscript.eclass: copy gen_usr_ldscript from toolchain-funcs.eclass
   usr-ldscript.eclass: return early if USE=split-usr is disabled
   Convert ebuilds to inherit usr-ldscript
   toolchain-funcs.eclass: deprecate gen_usr_ldscript

  app-accessibility/brltty/brltty-5.2-r1.ebuild |   2 +-
  app-accessibility/brltty/brltty-6.0-r1.ebuild |   2 +-
  app-arch/bzip2/bzip2-1.0.6-r11.ebuild |   2 +-
  app-arch/bzip2/bzip2-1.0.7.ebuild |   2 +-
  app-arch/bzip2/bzip2-1.0.8.ebuild |   2 +-
  app-arch/bzip2/bzip2-.ebuild  |   2 +-
  app-arch/xz-utils/xz-utils-5.2.4-r2.ebuild|   2 +-
  app-arch/xz-utils/xz-utils-5.2.4-r3.ebuild|   2 +-
  app-arch/xz-utils/xz-utils-.ebuild|   2 +-
  dev-libs/expat/expat-2.2.6.ebuild |   2 +-
  dev-libs/expat/expat-2.2.7.ebuild |   2 +-
  dev-libs/libaio/libaio-0.3.110.ebuild |   2 +-
  dev-libs/libaio/libaio-0.3.111.ebuild |   2 +-
  dev-libs/libaio/libaio-0.3.112.ebuild |   2 +-
  dev-libs/libaio/libaio-.ebuild|   2 +-
  dev-libs/libedit/libedit-20130712.3.1.ebuild  |   2 +-
  dev-libs/libedit/libedit-20170329.3.1.ebuild  |   2 +-
  dev-libs/libiconv/libiconv-1.14-r1.ebuild |   2 +-
  dev-libs/libiconv/libiconv-1.15.ebuild|   2 +-
  dev-libs/libintl/libintl-0.19.7.ebuild|   2 +-
  dev-libs/libintl/libintl-0.19.8.1.ebuild  |   2 +-
  dev-libs/libintl/libintl-0.20.1.ebuild|   2 +-
  dev-libs/libpcre/libpcre-8.41-r1.ebuild   |   2 +-
  dev-libs/libpcre/libpcre-8.42.ebuild  |   2 +-
  dev-libs/libpcre/libpcre-8.43.ebuild  |   2 +-
  dev-libs/libpcre2/libpcre2-10.32.ebuild   |   2 +-
  dev-libs/libpcre2/libpcre2-10.33.ebuild   |   2 +-
  .../libpwquality/libpwquality-1.4.0.ebuild|   2 +-
  .../libusb-compat-0.1.5-r2.ebuild |   2 +-
  .../libusb-compat-0.1.5-r3.ebuild |   2 +-
  dev-libs/libusb/libusb-1.0.19-r1.ebuild   |   2 +-
  dev-libs/libusb/libusb-1.0.21.ebuild  |   2 +-
  dev-libs/libusb/libusb-1.0.22.ebuild  |   2 +-
  dev-libs/lzo/lzo-2.10.ebuild  |   2 +-
  eclass/toolchain-funcs.eclass |  15 +-
  eclass/usr-ldscript.eclass| 160 ++
  .../iptables/iptables-1.6.1-r3.ebuild |   2 +-
  .../iptables/iptables-1.6.2-r2.ebuild |   2 +-
  .../iptables/iptables-1.8.2-r2.ebuild |   2 +-
  .../iptables/iptables-1.8.3-r1.ebuild |   2 +-
  net-libs/libmnl/libmnl-1.0.3-r1.ebuild|   2 +-
  net-libs/libmnl/libmnl-1.0.4.ebuild   |   2 +-
  net-libs/libnftnl/libnftnl-1.0.8-r1.ebuild|   2 +-
  net-libs/libnftnl/libnftnl-1.1.1-r1.ebuild|   2 +-
  net-libs/libnftnl/libnftnl-1.1.2-r1.ebuild|   2 +-
  net-libs/libnftnl/libnftnl-1.1.3.ebuild   |   2 +-
  net-libs/libtirpc/libtirpc-1.0.2-r1.ebuild|   2 +-
  net-libs/libtirpc/libtirpc-1.0.3.ebuild   |   2 +-
  net-libs/libtirpc/libtirpc-1.1.4.ebuild   |   2 +-
  profiles/base/make.defaults   |   4 +
  profiles/use.desc |   1 +
  sys-apps/acl/acl-2.2.52-r1.ebuild |   2 +-
  sys-apps/acl/acl-2.2.53.ebuild|   2 +-
  sys-apps/attr/attr-2.4.47-r2.ebuild   |   2 +-
  sys-apps/attr/attr-2.4.48-r2.ebuild   |   2 +-
  sys-apps/attr/attr-2.4.48-r3.ebuild   |   2 +-
  sys-apps/dmapi/dmapi-2.2.12-r1.ebuild |   2 +-
  sys-apps/keyutils/keyutils-1.5.11-r1.ebuild   |   2 +-
  sys-apps/keyutils/keyutils-1.5.9-r4.ebuild|   2 +-
  sys-apps/keyutils/keyutils-1.6.ebuild |   2 +-
  sys-apps/openrc/openrc-0.34.11.ebuild |   2 +-
  

Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Jaco Kroon

Hi,

On 2019/06/21 07:59, Andrew Savchenko wrote:

On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:

On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:

On 6/9/2019 7:39 AM, Michał Górny wrote:

+Tracking of user/group usage is done through dependencies.  As long
+as any installed package depends on a specific user/group package,
+the respective user/group is assumed to be used.  If no package
+requiring the specific user/group is left, the package manager
+automatically prunes the package clearly indicating it is no longer
+used.

You cannot know when a name is "no longer used".  An administrator could
have adopted a username for other purposes.

That's why we don't remove the actual user/group.  However, this is
a valuable information to the administrator that no package is using
the user/group in question.

So how do you propose to clean them up? Or let user systems trash
with unused uids/gids? The GLEP 81 only mensions some possible
tooling for cleanup. Is there an implementation available? I don't
see it within proposed patch sets.

This GLEP should not be accepted unless all necessary tools are
available including a cleanup tool.


find / -{user,group} ???

For files having ownership at least.

There may well be other reasons why the user is still in use (that I 
can't think of right now), but unfortunately this is what makes this so 
difficult.  I'd propose that some tool be used that provides hooks to 
allow additional checks to be added.


Kind Regards,
Jaco




Re: [gentoo-dev] [PATCH v2] profiles: add more language codes to desc/l10n.desc

2019-06-13 Thread Jaco Kroon

Hi,

Any chance of adding en-NZ?

asterisk-core-sounds depends on L10N USE_EXPAND and there is an upstream 
en-NZ pack.  It's the only language pack for which there isn't currently 
an option already in the list here.


Kind Regards,
Jaco

On 2019/06/13 10:26, Marek Szuba wrote:


Many thanks for the feedback, here is the revised patch:

* * *

All of these are supported by recent versions of app-text/tesseract.
Checked against ISO-639 using the code tables from
https://iso639-3.sil.org/ .

Signed-off-by: Marek Szuba 
---
  profiles/desc/l10n.desc | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/profiles/desc/l10n.desc b/profiles/desc/l10n.desc
index 4d30aa57eb3..e5e21346174 100644
--- a/profiles/desc/l10n.desc
+++ b/profiles/desc/l10n.desc
@@ -41,8 +41,10 @@ bs - Bosnian
  ca - Catalan
  ca-valencia - Catalan (Valencian)
  cak - Kaqchikel
+ceb - Cebuano
  chr - Cherokee
  cnr - Montenegrin
+co - Corsican
  cs - Czech
  cy - Welsh
  da - Danish
@@ -53,6 +55,7 @@ de-DE - German (Germany)
  dgo - Dogri (individual language)
  doi - Dogri (macrolanguage)
  dsb - Lower Sorbian
+dv - Dhivehi
  dz - Dzongkha
  el - Modern Greek
  en - English
@@ -88,13 +91,16 @@ he - Hebrew
  hi - Hindi
  hr - Croatian
  hsb - Upper Sorbian
+ht - Haitian
  hu - Hungarian
  hy - Armenian
  ia - Interlingua
  id - Indonesian
  is - Icelandic
  it - Italian
+iu - Inuktitut
  ja - Japanese
+jv - Javanese
  ka - Georgian
  kab - Kabyle
  kk - Kazakh
@@ -120,6 +126,7 @@ mn - Mongolian
  mni - Manipuri
  mr - Marathi
  ms - Malay (macrolanguage)
+mt - Maltese
  my - Burmese
  nan - Min Nan Chinese
  nb - Norwegian Bokmål
@@ -134,9 +141,11 @@ om - Oromo
  or - Oriya (macrolanguage)
  pa - Punjabi
  pl - Polish
+ps - Pushto
  pt - Portuguese
  pt-BR - Portuguese (Brazil)
  pt-PT - Portuguese (Portugal)
+qu - Quechua
  rm - Romansh
  ro - Romanian
  ru - Russian
@@ -156,6 +165,7 @@ sr - Serbian
  sr-Latn - Serbian (Latin script)
  ss - Swati
  st - Southern Sotho
+su - Sundanese
  sv - Swedish
  sw - Swahili (macrolanguage)
  sw-TZ - Swahili (Tanzania)
@@ -165,9 +175,11 @@ ta-LK - Tamil (Sri Lanka)
  te - Telugu
  tg - Tajik
  th - Thai
+ti - Tigrinya
  tk - Turkmen
  tl - Tagalog
  tn - Tswana
+to - Tonga (Tonga Islands)
  tr - Turkish
  ts - Tsonga
  tt - Tatar
@@ -178,6 +190,8 @@ uz - Uzbek
  ve - Venda
  vi - Vietnamese
  xh - Xhosa
+yi - Yiddish
+yo - Yoruba
  zh - Chinese
  zh-CN - Chinese (China)
  zh-TW - Chinese (Taiwan)




Re: [gentoo-dev] [PATCH v4 12/19] user.eclass: Support getting & setting comment field

2019-06-12 Thread Jaco Kroon

Hi,



+   # update the comment
+   case ${CHOST} in
+   *-freebsd*|*-dragonfly*)
+   pw usermod "${euser}" -c "${ecomment}" && return 0
+   [[ $? == 8 ]] && eerror "${euser} is in use, cannot update 
comment"
+   eerror "There was an error when attempting to update the comment for 
${euser}"
+   eerror "Please update it manually on your system:"
+   eerror "\t pw usermod \"${euser}\" -c \"${ecomment}\""
+   ;;
+
+   *)
+   usermod -c "${ecomment}" "${euser}" && return 0
+   [[ $? == 8 ]] && eerror "${euser} is in use, cannot update 
comment"
+   eerror "There was an error when attempting to update the comment for 
${euser}"
+   eerror "Please update it manually on your system (as root):"
+   eerror "\t usermod -c \"${ecomment}\" \"${euser}\""
+   ;;
+   esac
+}
+
  fi



Those error messages are duplicate and can move to after the case.

You should probably also explicitly return with an error if the case 
drops through.


Kind Regards,
Jaco





Re: [gentoo-dev] [PATCH 5/9] user.eclass: Die if no free UID/GID is found

2019-05-31 Thread Jaco Kroon

Hi,

Why not utilize -r or --system as per useradd(8) in order to add system 
users?


The limits for the allocated user ids comes from /etc/login.defs.

Kind Regards,
Jaco

On 2019/05/30 14:50, Michał Górny wrote:

Signed-off-by: Michał Górny 
---
  eclass/user.eclass | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/eclass/user.eclass b/eclass/user.eclass
index 1ffeaae29569..b16c4c6d69b7 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -160,6 +160,7 @@ enewuser() {
for ((euid = 101; euid <= 999; euid++)); do
[[ -z $(egetent passwd ${euid}) ]] && break
done
+   [[ ${euid} -le 999 ]] || die "${FUNCNAME}: no free UID found"
fi
opts+=( -u ${euid} )
einfo " - Userid: ${euid}"
@@ -344,6 +345,7 @@ enewgroup() {
for ((egid = 101; egid <= 999; egid++)) ; do
[[ -z $(egetent group ${egid}) ]] && break
done
+   [[ ${egid} -le 999 ]] || die "${FUNCNAME}: no free GID 
found"
fi
}
  




Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

2019-05-31 Thread Jaco Kroon

Hi,

On 2019/05/29 18:01, Michael Orlitzky wrote:

On 5/29/19 5:50 AM, Jaco Kroon wrote:

This GLEP follows the best practice of leaving obsolete user/groups
accounts intact.  This guarantees that no files with stale ownership are
left (e.g. on unmounted filesystems) and that the same UID/GID is not
reused for another user/group.

The type of checks for both this and certain updates contemplated above
are similar.  And expensive (resources) as you rightly say. I would
provide the tools to perform these checks but in the ebuild I'd rather
the checks be done asap (pkg_pretend?).  If we can fail there and
stating what the admin should do to rectify the issue that would be the
best solution in my personal opinion.  Ie, from the package manager I'd
state how, but not actually action these changes.


My original goal here was to have "emerge -C " actually uninstall
the user. That turns out to be highly unwise, because you need to audit
the system for things owned and used by said user, and to clean them all
up beforehand. That can take forever, and can't be automated.

Plan (b) was to do exactly as you asked: have the uninstall process bail
out, and tell you what to do. That's... also technically infeasible,
because we don't have a way to make an ebuild bail out of an uninstall.
This could change in the future with an EAPI/PMS update, but simply
isn't an option right now.


I think you misunderstood.  My writing was poor on re-read.

My suggestion is to merely lock the user.  And make sure that the admin 
knows this.  Even locking may need to be configurable but by default I 
would lock.


Further, the tools should be provided outside of the ebuild (baselayout 
perhaps) in order to enable the checks to be completed (ie, confirm no 
files has the user as owner), and then report to the sysadmin how to use 
these tools.


On merge:  Perform the checks before any building starts 
(pkg_pretend/pkg_setup, as per libreoffice example I just looked at).  
Need to recheck again obviously just prior to actually making the 
changes.  Bail early in other words during install.


On unmerge:  Lock user.  Advise sysadmin on how to actually remove the 
user (possibly put it in a database somewhere and check somewhere in 
portage that these users are "linkgering", similar to retained libs that 
gets held because of binaries actually still using it, but never 
automatically removed, just checked if the sysadmin has).  Can't (should 
not) fail.


I hope that clarifies.

Kind Regards,
Jaco




Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

2019-05-29 Thread Jaco Kroon

Hi Michal,

This sounds sensible and is an interesting approach.  I kinda like it.

There is only one technical comment I have based on the earlier 
discussion, not addressed.


What if users needs to be created into a centralized UID/GID system to 
be pulled in via nss?


So calling system tools by default is fine, but what if the sysadmin 
would prefer to have users and groups pushed into ldap? Can we at least 
accomodate a hook mechanism to allow system administrators not relying 
on local users to deal with this?


My personal rule of thumb is that system users are (and should be) 
local.  But there are definite use cases where shared "system uids" are 
a definite legitimate requirement.


The one complaint I do have is repo bloat.

Further comments below.

Kind Regards,
Jaco

On 2019/05/29 09:28, Michał Górny wrote:

Motivation
==

User management in Gentoo is currently ad-hoc.  Users and groups are
created through calling system tools directly in packages needing them.
There is no systematic way of tracking which packages need specific
users or groups, and determining which ones are obsolete.  Coordinating
properties of users and groups used by multiple packages must be done
manually by developers.

GLEP 27 originally attempted to address the problem.  Posted in 2004,
it never had reached the reference implementation state, and became
obsolete.  [#GLEP27]_

A good system user and group management proposal should address:

1. Tracking usage of users and groups, and determining which ones
are obsolete.

2. Sharing users and groups reliably between different packages.

3. Maintaining fixed UIDs/GIDs that are consistent between different
systems.

4. Providing local overrides for user/group properties.

5. Ensuring that users and groups are not created unnecessarily
at build time.

At the same time, the proposal should avoid unnecessary complexity
to avoid sharing the fate of GLEP 27.  This proposal aims to address
those points without requiring a new EAPI or any changes in the package
manager.


This looks good.  I'd add "6.  Allow for centralized management of users 
and/or groups" (in order to cover management via for example ldap).



Maintaining users/groups


The primary technical function of user and group packages is to create
the users and groups.  This is done via invoking the respective system
tools at ``pkg_preinst`` phase.  This is done only if the user/group
does not exist on the system already.


I would recommend that this be handled via an eclass that deals with the 
technicalities.  The package then does something like:


inherit userpackage

USER_NAME=mail
USER_UID=8
USER_PRIMARY_GROUP=mail
USER_FORCE_UID=yes

DEPEND=group/mail
RDEPEND=group/mail

And that ends up being the whole package.  Similar for groups. Even the 
R?DEPEND can probably go into the eclass.


The eclass can then potentially support external hooks or something to 
accomodate 6. above.




User/group name/identifier collision detection
--

The user/group packages can install additional files in subdirectories
of ``/var/lib`` indicating their respective names and identifiers.
This ensures that if two packages ever happen to collide, the package
manager's collision detection mechanism will trigger.


Ulrich also commented on this.  How about enforcing a mapping from 
$USER_NAME to package name?  (ie, just replace all characters not 
allowed in package naming with _ or -.


Same as Ulrich I struggle to see any use-case where this would be an 
issue, but artificial or not it's probably a good idea to deal with it 
somehow.



Naming rules


It has been pointed out that the package naming rules are more
restrictive than user/group naming rules.  This is why the proposal
allows for package names to be different from user/group names.
However, this is strongly discouraged and should only be used when
really necessary.


I would personally disallow it and enforce a mapping from username to 
package name.  The question then however is if two names map to the same 
package (which would be confusing to begin with) how to deal with that.



User/group updates
--

If sysadmin needs to change the properties (e.g. home directory) of some
user/group, the obvious course of action is to modify the system
databases directly.  The GLEP aims to respect that and disallow altering
existing user/groups unconditionally.  If any updates need to be done,
the packages need to verify previous values first.


"If any updates need to be done, the package need to verify previous 
values first." conflicts with "disallow altering existing user/groups 
unconditionally".  I'd rephrase as "If any updates need to be done, 
refer those to the system administrator."



User/group removal
--

The original proposal attempted to remove user/groups automatically
when the respective package was unmerged.  This required verifying