Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins

[A Schenck]

On 1/27/23 11:21, Michał Górny wrote:

On Fri, 2023-01-27 at 10:51 -0800, A Schenck wrote:

On 1/27/23 09:36, Michał Górny wrote:

# Michał Górny  (2023-01-27)
# GKrellM and a variety of plugins.  It's unmaintained for some
time.
# Upstream homepage is gone, and the whole suite is collecting dust
# and patches.
# Removal on 2023-02-26.  Bug #892251.

[also eclass/gkrellm-plugin.eclass]

app-admin/gkrellm
x11-plugins/gkrelltop


The old homepage listed in the ebuild is gone but has moved[0].

The live ebuild has the correct upstream repository so it seems like

just an oversight to not update the homepage whenever that was

changed.


Thanks.  Unfortunately, it only confirms what I've suspected: it's not
maintained and nobody's working on a GTK+3 port [1].

[1] https://git.srcbox.net/gkrellm/gkrellm/issues/1

Gkrellm is built similarly to the GIMP where it draws it's chrome 
directly with GDK to be thin and lightweight without window manager 
decorations makes it more useful to leave always on the side of the 
screen. GTK+3 has gotten rid of GDK entirely and the porting docs say 
"use cairo for drawing" and "the transition is usually straightforward" 
which is not super helpful :-( Adding `DGTK_DISABLE_SINGLE_INCLUDES` and 
`DGTK_DISABLE_DEPRECATED` were reasonably straightforward but 
`DGDK_DISABLE_DEPRECATED` is proving challenging.
At the moment all these changes are local because it doesn't seem 
possible to subscribe to the mailing list or create an account from the 
gitea interface for upstream. Will probly post the patches to gentoo 
bugzilla just to get them on some external storage pending getting them 
upstream.


Thanks,
-A

--
Attached is my PGP public key.
Primary key fingerprint: C334 A85F 5B84 0061 2DF9 7310 6E37 4F22 EB0C 3D3A

If you have a PGP key (and a minute to spare)
please send it in reply to this email.

If you have no idea what PGP is, feel free
to ignore all this gobbledegook.


OpenPGP_0x6E374F22EB0C3D3A.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-admin/gkrellm & plugins

[A Schenck]

On 1/27/23 09:36, Michał Górny wrote:

# Michał Górny  (2023-01-27)
# GKrellM and a variety of plugins.  It's unmaintained for some time.
# Upstream homepage is gone, and the whole suite is collecting dust
# and patches.
# Removal on 2023-02-26.  Bug #892251.

[also eclass/gkrellm-plugin.eclass]

app-admin/gkrellm
x11-plugins/gkrelltop


The old homepage listed in the ebuild is gone but has moved[0].

The live ebuild has the correct upstream repository so it seems like

just an oversight to not update the homepage whenever that was

changed. Bugzilla is crashing when navigating around the bug list

but except for the recent CLANG-STRICTER-SYSTEM[1] report the

issues[2] are mostly ancient and / or specific to plugins. It was sad

losing gkrellm-cpufreq ages ago but cleaning up broken rarely used

plugins would be much preferable to "throwing the baby out with

the bathwater" if that idiom translates. . . The patches[3] currently

in tree are just a default config and some opinions about font and

max width.

Every non-handheld device we use has gkrellm, two on the personal

laptop because one is connected to gkrellmd running on the home

server. On the work Mac laptop (though the X implementation there

is somewhat broken). On the previous Windows work laptop. The

various alternatives all seem much heavier like Plasma System

Monitor which wants to take up most of the screen and show things

in big pie graphs, or too light like the Mac things that put tiny-to-the-

point-of-being-useless icons in the menu bar at the top of the screen.

Will try to take a look at the CLANG-STRICTER bug if bugzilla starts

working again but it might take a while to figure out the build system

since gcc is still the default cc here.


Thanks,

-A


[0] http://gkrellm.srcbox.net/

[1] https://bugs.gentoo.org/show_bug.cgi?id=881957

[2] https://bugs.gentoo.org/buglist.cgi?quicksearch=gkrellm_id=6713191

[3] https://gitweb.gentoo.org/repo/gentoo.git/tree/app-admin/gkrellm/files

--
Attached is my PGP public key.
Primary key fingerprint: C334 A85F 5B84 0061 2DF9 7310 6E37 4F22 EB0C 3D3A

If you have a PGP key (and a minute to spare)
please send it in reply to this email.

If you have no idea what PGP is, feel free
to ignore all this gobbledegook.



OpenPGP_0x6E374F22EB0C3D3A.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo LLVM project needs help!

[A Schenck]

On 2/10/22 15:36, Michał Górny wrote:
> Hi,
>
> As you may have noticed, I'm practically maintaining LLVM all by myself.
> This is a really tedious, time consuming and ungrateful task, and I'm
> pretty close to burnout.  I'd really appreciate some help.
>
> The problem with LLVM that it's a really huge, rapidly moving forward
> (and breaking things) project.  It needs frequent testing as regressions
> happen frequently, and we have a good chance of having somebody else fix
> it if we report them early.  At the same time, testing takes a lot of
> time.  While ccache is pretty much a must, it doesn't help much long
> term as the code is changing frequently and invalidating the cache.
>
> On top of this, there's almost-overlapping release process and Gentoo
> slotting that's working so-so at best.  After I've pushed LLVM 13.0.1
> final, I've had to immediately start testing 14.x and barely managed to
> get some fixes in before rc1.  Now 14.0.0 is expected soon,
> simultaneously major changes are happening on the main branch
> (i.e. 15.x) that also need testing and adjusting the ebuilds to.
>
> I barely manage to keep up with amd64 multilib.  Other arches are likely
> to be broken.  Some specific projects that need help are:
>
> 1. Compiler-RT (particularly sanitizers, fuzzer etc.) -- they break
> quite often on glibc upgrades.  Miraculously, right now 13.0.1
> and 14.0.0 are clean right now but I'm pretty sure we'll see a new glibc
> release soon and they're going to require fixing again.
>
> 2. OpenMP -- there are many test regressions on every release, and 14.x
> is particularly bad.  I have no clue about this package, the test output
> is usually cryptic and I don't really have the time to look into it. 
> Honestly, at this point I would gladly have last rited it if it hadn't
> had revdeps.
>
> 3. LLDB -- while it mostly works and I've managed to fix the worst of
> it, I still haven't managed to get the test suite fully working.  What's
> even worse, the test runner just hangs at the very end and I have
> no clue why or how to debug that.
You've probly already thought of this but this is when strace comes to
mind. Is it truly hanging in own code, or waiting on something to change
in the system that isn't happening?
>
> Plus the generic stuff:
>
> 4. Testing LLVM 15.x periodically, bisecting, reporting bugs early.
> I can help triaging and reporting the bugs but at least I'd need
> somebody else to run the builds more often than I can.
>
> 5. Testing LLVM 14.x, 15.x on non-amd64 architectures (including x86
> builds -- not all LLVM components are multilib) and reporting bugs. 
> Unfortunately, this part may require actually providing patches.
>
> 6. Work on setting up and configuring a buildbot for Gentoo LLVM builds.
> This is some effort and I don't have the time to learn how to do that. 
> You'll probably need to set up a local instance and figure out how to
> set our builds before submitting anything upstream; in my experience
> they aren't very responsive to buildbot changes, so ideally we need to
> flesh out any problems early.
>
> Yes, that's a lot of work.  I can't do it all myself, I'm already doing
> too much and this is having negative impact on my health.  I really need
> help with this.
>
> Disclaimer: I've been doing some LLDB-related paid work in the past. 
> However, this work wasn't Gentoo-related and if anything, it required me
> to spend my CPU time on work and not testing LLVM for Gentoo.
>
-- 
Attached is my PGP public key.
Primary key fingerprint: C334 A85F 5B84 0061 2DF9 7310 6E37 4F22 EB0C 3D3A

If you have a PGP key (and a minute to spare)
please send it in reply to this email.

If you have no idea what PGP is, feel free
to ignore all this gobbledegook.



OpenPGP_signature
Description: OpenPGP digital signature

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

[A Schenck]

On 11/30/21 17:32, William Hubbs wrote:
> On Tue, Nov 30, 2021 at 12:59:18PM +0100, Ulrich Mueller wrote:
>>> On Tue, 30 Nov 2021, James Cloos wrote:
>>> "UM" == Ulrich Mueller  writes:
>> UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
>> UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.
>>
>>> why do you thing gentoo is everyone's first or only dist on their
>>> network?
>>> or even on any given box?
>> I was specifically asking about Gentoo infra there.
>>
>>> forcing existing boxen to change just because a new dist is added
>>> is also unacceptable.
>>> for me though, it would be enough if there is something i can add to
>>> make.conf to ensure that the acct-user and acct-group builds avoid the
>>> ranges i already use.
>>> that may also work for others.
>> UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
>> used for dynamic allocation of system accounts. GLEP 81 hasn't really
>> changed anything there, except that the ebuild will now suggest an ID to
>> try first.
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.
At risk of sounding pithy, it could maybe be summed up as: 'because
"Gentoo is about choice" (but a sensible default doesn't hurt).' As you
say "users _can_ pick the IDs they want," but if they don't happen to
want to, we've tried to pick defaults (which are even shared by other
distributions where possible) so that there's a greater than zero chance
that things will "just work" when the time comes for them to
interoperate. As a user, despite having initially installed way before
this was a thing, it seems nice. The new SBC (rockpro64) we installed
last year or so has a much more consistent user setup now than the
laptop which is just random.
>
> William
-A


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

On 10/2/21 10:51 AM, Mike Gilbert wrote:
> On Sat, Oct 2, 2021 at 1:25 PM A Schenck  wrote:
>> Further discussion belongs on a different list, but the link provided by
>> mgorny and repeated by you does not allow collaborating in compliance
>> with the Gentoo Social Contract.
> The patches were also posted for review on the gentoo-portage-dev mailing 
> list.
Thanks. The patch is a bit messier than hoped but it's a starting point.



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

On 10/1/21 11:32 AM, Alec Warner wrote:
> On Fri, Oct 1, 2021 at 11:30 AM A Schenck  wrote:
>> On 9/29/21 11:44 PM, Michał Górny wrote:
>>> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to have some switch (e.g. --style=legacy) that
>>>> controls this new vs. the old behaviour?  Would perhaps allow
>>>> applications that parse the output to work via setting this in the
>>>> global opts.
>>> Patches welcome.  It shouldn't be hard, my commit shows which files need
>>> to be edited to alter the prefixes and how to pass them into ebd.
>> Would it be possible to get this patch in an format that it can be
>> interacted with with open tools? Per the other branch of this thread,
>> we'd be happy to make this an opt-in so as to not break existing people.
> I'm not sure what you mean; you can download the PR...
>
> https://github.com/gentoo/portage/pull/759
>
> -A

This isn't really the place to rehash the whole discussion of free
speech vs. free beer: http://www.gnu.org/philosophy/free-sw-en.html .
Suffice to say the Gentoo Social Contract
(https://www.gentoo.org/get-started/philosophy/social-contract.html#gentoo-is-and-will-remain-free-software)
states: "Gentoo will never depend upon a piece of software or metadata
unless it conforms to the GNU General Public License, the GNU Lesser
General Public License, the Creative Commons - Attribution/Share Alike
or some other license approved by the Open Source Initiative"; which
GitHub does not conform to:
https://www.gnu.org/software/repo-criteria-evaluation.html#GitHub .
Further reading (linked from gnu.org) at
https://sanctum.geek.nz/why-not-github.html , and of course we all know
that Microsoft acquired GitHub, and of course Microsoft has a history of
suing Free / Libre / Open Source Software creators and users.

Further discussion belongs on a different list, but the link provided by
mgorny and repeated by you does not allow collaborating in compliance
with the Gentoo Social Contract.

-A

>> -A
>>
>>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

On 9/29/21 3:58 PM, Francesco Riosa wrote:
> Il giorno mer 29 set 2021 alle ore 23:52 A Schenck
> mailto:lane_and...@hotmail.com>> ha scritto:
>
> On 9/28/21 8:36 AM, Michał Górny wrote:
> > Hi, everyone.
> >
> > I know I'm going to regret asking this... but I've prepared a
> change to
> > the Portage output format and I think it asks for a wider discussion
> > than internally in Portage team.
> >
> > The primary problem with the current output format is that different
> > kinds of messages differ only in color.  This makes them
> > indistinguishable without colors and hard to grep.  ago's been
> asking
> > for a better way to grep for QA warnings and this is pretty much
> what
> > motivated me to do this.
> >
> > The proposed new format distinguished message types both using
> colors
> > and strings.  This is roughly inspired by Xorg logs.  For example,
> > instead of:
> >
> >  * some message
> >  * other message
> >  * hell if i know what this is
> >
> > You get:
> >
> > [WW] some message
> > [EE] other message
> > [QA] hell if i know what this is
> >
> > I've also added more colors to explicitly distinguish einfo from
> elog,
> > and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> > used by Portage with four-character versions to keep messages
> aligned.
> > The 'zings' used for merging files remain three-character, so
> now it's
> > easily possible to distinguish messages from installed file list.
>
> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there
> must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has
> existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the
> point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it
> to the
> point it could replace parsing the output.
>
> It wouldn't be worth blocking progress for one application that
> not many
> people use, but assuming there are others that will also break
> with this
> change. Are we sure there's no way to support ago's (very
> valuable) work
> without breaking other things?
>
> -A
>
>
> Kuroo is already a quite complex application that parse portage
> output. A quick grep seems to show that changes needed are quite
> manageable.
> Also the parsing should be more accurate with proposed changes.
> Rather it should be easy for the application to know in advance which
> format the output will be.
> There is also the opportunity to have a flag that enable (or disable)
> the augmented output, but IMHO this should be done only if the added
> complexity is NIL
>
> $ grep -c  -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1  | grep
> -v :0$
> kuroo-1.2.1/TODO:1
> kuroo-1.2.1/src/history/history.cpp:3
> kuroo-1.2.1/src/config/configdialog.h:2
> kuroo-1.2.1/src/queue/queuelistview.cpp:1
> kuroo-1.2.1/src/core/scanupdatesjob.cpp:1
> kuroo-1.2.1/src/core/global.h:2
> kuroo-1.2.1/src/core/packageinspector.cpp:4
> kuroo-1.2.1/src/core/packageversion.h:2
> kuroo-1.2.1/src/core/etcupdate.h:1
> kuroo-1.2.1/src/core/portagedb.cpp:2
> kuroo-1.2.1/src/core/scanhistoryjob.cpp:3
> kuroo-1.2.1/src/core/global.cpp:1
> kuroo-1.2.1/src/core/dependatom.h:2
> kuroo-1.2.1/src/core/emerge.cpp:8
>
Alas and alack, just searching for regular expressions isn't enough,
there are places that use QString::startsWith and contains and mid, 
with literal QStrings. Tthere might be "spooky action at a distance" in
some fifteen year old code that used some esoteric method to parse
output because it was hip like -funroll-loops, and that could takes
years to track down and fix despite best efforts to fix all the obvious
QReg(|ular)Ex(|pression)s.

If the idea is to clean up old code that admins haven't looked at in
years because it "just worked"™, that's valid too; treecleaner project
is laudable for that. But if breaking things isn't the goal, then we
should consider if there are options to keep things working. Regarding
"added complexity": it would probably mean parsing one additional
o

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

On 9/29/21 11:44 PM, Michał Górny wrote:
> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
>> Hi,
>>
>> Would it be possible to have some switch (e.g. --style=legacy) that
>> controls this new vs. the old behaviour?  Would perhaps allow
>> applications that parse the output to work via setting this in the
>> global opts.
> Patches welcome.  It shouldn't be hard, my commit shows which files need
> to be edited to alter the prefixes and how to pass them into ebd.

Would it be possible to get this patch in an format that it can be
interacted with with open tools? Per the other branch of this thread,
we'd be happy to make this an opt-in so as to not break existing people.

-A




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

On 9/28/21 8:36 AM, Michał Górny wrote:
> Hi, everyone.
>
> I know I'm going to regret asking this... but I've prepared a change to
> the Portage output format and I think it asks for a wider discussion
> than internally in Portage team.
>
> The primary problem with the current output format is that different
> kinds of messages differ only in color.  This makes them
> indistinguishable without colors and hard to grep.  ago's been asking
> for a better way to grep for QA warnings and this is pretty much what
> motivated me to do this.
>
> The proposed new format distinguished message types both using colors
> and strings.  This is roughly inspired by Xorg logs.  For example,
> instead of:
>
>  * some message
>  * other message
>  * hell if i know what this is
>
> You get:
>
> [WW] some message
> [EE] other message
> [QA] hell if i know what this is
>
> I've also added more colors to explicitly distinguish einfo from elog,
> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> used by Portage with four-character versions to keep messages aligned. 
> The 'zings' used for merging files remain three-character, so now it's
> easily possible to distinguish messages from installed file list.

Didn't expect to be the only dissenting opinion on something like this
but. . . Some applications parse portage output looking for these
'zings'. At very least app-portage/kuroo does it this way; there must be
others, right? This is obviously not the ideal way to get information
out of portage, but it's been stable for the 15 years Kuroo has existed.
10-ish years ago dol-sen started some work on building and API for
portage, but then got sucked into core portage development to the point
of abandoning their GTK+ portage GUI porthole, which was the original
impetus for an API, and as far as we know, the API never made it to the
point it could replace parsing the output.

It wouldn't be worth blocking progress for one application that not many
people use, but assuming there are others that will also break with this
change. Are we sure there's no way to support ago's (very valuable) work
without breaking other things?

-A

>
> The PR doing this is: https://github.com/gentoo/portage/pull/759
>
> Example screenshot:
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

[A Schenck]

On 8/6/21 11:58 AM, A Schenck wrote:
> On 8/5/21 5:57 PM, Alec Warner wrote:
>> On Thu, Aug 5, 2021 at 2:44 PM Georgy Yakovlev  wrote:
>>> Hi,
>>>
>>> We've been collecting more and more container related packages in
>>>  app-emulation/*
>>>
>>> What do you think about finally moving those packages to separate category?
>> As always my opinion is that:
>>
>> (a) Categories were a design mistake.
>> (b) The mistake is hard to fix.
>> (c) It's basically low-value to try to 'correctly' categorize packages
>> because of A.
>> (d) Recategorizing means a bunch of stuff has to be updated.
>>
>> Do people actually care what category things are in? I just use
>> --search or eix or whatever and the category is just this...bad
>> concept we attach to packages for silly historical reasons..
> We particularly like categories, and especially the (mostly) two-level
> concept in gentoo.  `emerge --search` works for some things, but often
> returns extra junk to filter through, when we know a project name, it's
> easier to just `ls /usr/portage/dev-ruby/` and see if there's a `grpc`
> package in it (upstream gem seems to force `-j12` for native
> compilation, wondered if gentoo packagers had fixed that problem). 
> Also, the graphical portage interface we use (and barely maintain) has a
> two-level category picker which even lets you select just the top-level
> category and see what's under several of it's subcategories:
>
> kuroo two-level category picker
Unsurprisingly the list dropped the image even though it was small. 
Here's an ancient screenshot of the two-level category-package view:
https://a.fsdn.com/con/app/proj/kuroo/screenshots/Kuroo4-packages.png
>
> -A
>
>
>> -A
>>
>>> probably app-containers/
>>>
>>> Here's the tentative list, most tools have description attached for easier
>>> review, 36 candidates so far, there may be more around, I only looked at
>>> app-emulation.
>>>
>>> app-emulation/buildah - A tool that facilitates building OCI images
>>> app-emulation/cadvisor - container analyzer
>>> app-emulation/conmon - An OCI container runtime monitor
>>> app-emulation/containerd - A daemon to control runC
>>> app-emulation/containers-storage - containers/storage library
>>> app-emulation/cri-o - OCI-based implementation of Kubernetes CRI
>>> app-emulation/cri-tools - CLI and validation tools for CRI
>>> app-emulation/crun - OCI Container Runtime fully written in C
>>> app-emulation/distrobuilder - System container image builder for LXC and LXD
>>> app-emulation/docker - Main offender
>>> app-emulation/docker-bench-security - Test for best docker practices
>>> app-emulation/docker-cli - Main offender cli
>>> app-emulation/docker-compose - Multi-container orchestration for Docker
>>> app-emulation/docker-credential-helpers -
>>> app-emulation/docker-gc - Docker garbage collection of containers and images
>>> app-emulation/docker-proxy - Docker container networking
>>> app-emulation/docker-registry -
>>> app-emulation/docker-swarm -
>>> app-emulation/flannel - An etcd backed network fabric for containers
>>> app-emulation/go-secbench - run and evaluate the docker security benchmark
>>> app-emulation/img - Standalone Dockerfile and OCI container image builder
>>> app-emulation/k3d - creates k3s clusters in docker
>>> app-emulation/kompose - Tool to move from docker-compose to Kubernetes
>>> app-emulation/lxc - A userspace interface for the Linux kernel containment
>>> app-emulation/lxc-templates -
>>> app-emulation/lxd - Fast, dense and secure container management
>>> app-emulation/nerdctl - Docker-compatible CLI for containerd
>>> app-emulation/podman - Main offender killer
>>> app-emulation/reg - Docker registry v2 command line client
>>> app-emulation/runc - another docker thing
>>> app-emulation/s6-overlay - an s6-based init system for containers
>>> app-emulation/sen - Terminal User Interface for docker engine
>>> app-emulation/skopeo - Utility for operations on container 
>>> images/repositories
>>> app-emulation/slirp4netns - User-mode networking for unpriv network 
>>> namespaces
>>> app-emulation/snapd - Service and tools for management of snap packages
>>> app-emulation/umoci - Manipulation tool for OCI images
>>>
>>> Those 4 are technically emulation related, so I'm not sure about category:
>>> app-emulation/docker-machine
>>> app-emulation/docker-machine-kvm
>>> app-emulation/hyperd
>>> app-emulation/runv

Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

[A Schenck]

On 8/5/21 5:57 PM, Alec Warner wrote:
> On Thu, Aug 5, 2021 at 2:44 PM Georgy Yakovlev  wrote:
>> Hi,
>>
>> We've been collecting more and more container related packages in
>>  app-emulation/*
>>
>> What do you think about finally moving those packages to separate category?
> As always my opinion is that:
>
> (a) Categories were a design mistake.
> (b) The mistake is hard to fix.
> (c) It's basically low-value to try to 'correctly' categorize packages
> because of A.
> (d) Recategorizing means a bunch of stuff has to be updated.
>
> Do people actually care what category things are in? I just use
> --search or eix or whatever and the category is just this...bad
> concept we attach to packages for silly historical reasons..

We particularly like categories, and especially the (mostly) two-level
concept in gentoo.  `emerge --search` works for some things, but often
returns extra junk to filter through, when we know a project name, it's
easier to just `ls /usr/portage/dev-ruby/` and see if there's a `grpc`
package in it (upstream gem seems to force `-j12` for native
compilation, wondered if gentoo packagers had fixed that problem). 
Also, the graphical portage interface we use (and barely maintain) has a
two-level category picker which even lets you select just the top-level
category and see what's under several of it's subcategories:

kuroo two-level category picker

-A


>
> -A
>
>> probably app-containers/
>>
>> Here's the tentative list, most tools have description attached for easier
>> review, 36 candidates so far, there may be more around, I only looked at
>> app-emulation.
>>
>> app-emulation/buildah - A tool that facilitates building OCI images
>> app-emulation/cadvisor - container analyzer
>> app-emulation/conmon - An OCI container runtime monitor
>> app-emulation/containerd - A daemon to control runC
>> app-emulation/containers-storage - containers/storage library
>> app-emulation/cri-o - OCI-based implementation of Kubernetes CRI
>> app-emulation/cri-tools - CLI and validation tools for CRI
>> app-emulation/crun - OCI Container Runtime fully written in C
>> app-emulation/distrobuilder - System container image builder for LXC and LXD
>> app-emulation/docker - Main offender
>> app-emulation/docker-bench-security - Test for best docker practices
>> app-emulation/docker-cli - Main offender cli
>> app-emulation/docker-compose - Multi-container orchestration for Docker
>> app-emulation/docker-credential-helpers -
>> app-emulation/docker-gc - Docker garbage collection of containers and images
>> app-emulation/docker-proxy - Docker container networking
>> app-emulation/docker-registry -
>> app-emulation/docker-swarm -
>> app-emulation/flannel - An etcd backed network fabric for containers
>> app-emulation/go-secbench - run and evaluate the docker security benchmark
>> app-emulation/img - Standalone Dockerfile and OCI container image builder
>> app-emulation/k3d - creates k3s clusters in docker
>> app-emulation/kompose - Tool to move from docker-compose to Kubernetes
>> app-emulation/lxc - A userspace interface for the Linux kernel containment
>> app-emulation/lxc-templates -
>> app-emulation/lxd - Fast, dense and secure container management
>> app-emulation/nerdctl - Docker-compatible CLI for containerd
>> app-emulation/podman - Main offender killer
>> app-emulation/reg - Docker registry v2 command line client
>> app-emulation/runc - another docker thing
>> app-emulation/s6-overlay - an s6-based init system for containers
>> app-emulation/sen - Terminal User Interface for docker engine
>> app-emulation/skopeo - Utility for operations on container 
>> images/repositories
>> app-emulation/slirp4netns - User-mode networking for unpriv network 
>> namespaces
>> app-emulation/snapd - Service and tools for management of snap packages
>> app-emulation/umoci - Manipulation tool for OCI images
>>
>> Those 4 are technically emulation related, so I'm not sure about category:
>> app-emulation/docker-machine
>> app-emulation/docker-machine-kvm
>> app-emulation/hyperd
>> app-emulation/runv

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

[A Schenck]

On 7/8/21 11:15 AM, Matt Turner wrote:
> On Thu, Jul 8, 2021 at 4:54 AM Michael Orlitzky  wrote:
>> On Wed, 2021-07-07 at 22:01 -0700, Matt Turner wrote:
>>> Enable these flags by default, since they effectively add no additional
>>> dependencies:
>> Why? This list should be getting smaller, not larger.
>>
>> Polluting the base profiles makes running a minimal system that much
>> harder, and only "adds no dependencies" because people omit the
>> corresponding dependencies -- a situation that has to change
>> eventually.
>>
>> If they're actually important to a particular package, you should
>> change the defaults for that package.
> Not the file I'm changing, but I think the sentiment of the comment is
> correct: profiles/prefix/make.defaults says:
>
>   # Some USE-flags that only die-hards don't want:
>
> So, the thing about running a minimal system is... you already have
> these dependencies installed. This doesn't change that...
>
> I could of course change the default of every bzip2/lzma/zstd in IUSE
> (and might as well handle zlib too so we can remove it from
> make.defaults!) but what practical advantage does that bring?
>
> I doubt there's a sensible reason to build without any of these USE
> flags enabled. I think the claim that most people will want them
> enabled is not really a question. So we should enable them by default.
> I think that logic is pretty straightforward. If someone wants to
> disable the flags for some reason, they of course still have that
> option.

I recently found exactly a sensible reason to build without these
flags.  I was cleaning up my abi_x86_32 use flags on an otherwise mostly
x86_64 ~amd64 desktop system.  Lots of things depend on these with
${MULTILIB_USEDEP}.  I of course have the actual programs themselves,
but I don't need 32-bit versions of them for linking.  So I now have

```

a@gen5 ~/code $ grep "\-lzma" /etc/portage/package.use/*
/etc/portage/package.use/package.use:dev-libs/elfutils valgrind -lzma
-bzip2    #avoid multilib usedep on xz-utils and bzip2
/etc/portage/package.use/package.use:dev-libs/libxml2 -lzma -dbus  
#avoid multilib dep on xz-utils and dbus
a@gen5 ~/code $ grep "\-bzip" /etc/portage/package.use/*
/etc/portage/package.use/package.use:dev-libs/elfutils valgrind -lzma
-bzip2    #avoid multilib usedep on xz-utils and bzip2
/etc/portage/package.use/package.use:media-libs/freetype -bzip2 #avoid
multilib usedeps on bzip2 cairo requires [png]

```

in package.use.

>
> If you can find a case where you wouldn't want to enable one of these
> USE flags, please let me know and I'll reconsider my position.
>

Re: [gentoo-dev] Re: New Developer: Florian Schmaus (flow)

[A Schenck]

On 6/22/21 12:45 PM, Wolfgang E. Sanyer wrote:
> Welcome flo!
>
> I think toralf made thin on-topic now: I quite enjoy Andechser
> Doppelbock Dunkel, which I believe is brewed in Germany :)
>
We're lucky enough to occasionally get that even out here in San
Francisco, I seek it out whenever it's here.

-A

> On Tue, Jun 22, 2021 at 3:34 PM Toralf Förster  > wrote:
>
> On 6/22/21 9:27 PM, Gokturk Yuksek wrote:
> > he enjoys running and the cold beverages of his home region,
> > Franconia.
> >
> > Please give him a warm welcome!
>
> Welcome flo !
>
> OT but worth to mention I prefer a "Störtebecker" (brewewd in
> Stralsund).
>
> -- 
> Toralf
> PGP 23217DA7 9B888F45
>

Re: [gentoo-dev] Keywordreqs and slacking arch teams

[A Schenck]

On 12/28/19 3:14 AM, Michael 'veremitz' Everitt wrote:
> On 28/12/19 11:05, Kent Fredric wrote:
>> On Sat, 28 Dec 2019 10:35:09 +0100
>> Fabian Groffen  wrote:
>>
>>> Hmmm, interested to hear what kind of things you're thinking about here.
>> A lot of the "Work" of filing a keyword request is modelling all the
>> consequential keywordings that have to take place.
>>
>> If there was say, a web based UI, that:
>>
>> - Automatically determined which packages are ready for stabilization
>>   due to all their dependencies already being stable (and maybe with
>>   automatic cooldown-from-testing detection )
>>
>> - Automatically determined which packages can be keyworded without
>>   additional work due to all their dependencies being keyworded
> 
>
> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like ..
app-portage/kuroo manages an SQLite database of packages without any
bash sourcing craziness, but defers to `emerge` to do the actual install
/ uninstall work and parses stdout and stderr from it.  DB schema is
described at
https://sourceforge.net/p/kuroo/code/HEAD/tree/kuroo4/trunk/src/core/portagedb.cpp#l219
and there are queries for packages by category / subcategory, installed
/ updateable status, and search string there.  Code to walk the main
tree from md5-cache and fill in those tables starts about
https://sourceforge.net/p/kuroo/code/HEAD/tree/kuroo4/trunk/src/core/scanportagejob.cpp#l135
.  Back before burnout there was some hope of porting it to a 'unified
portage API' that dol-sen wanted to build for other portage tools to
use, but that never came to fruition.  Most of this code is 15 years old
though, and I've only done the bare minimum to keep it working-ish as
portage and the tree have changed.
>
> Ok, let the flamewars begin ...
>

-A

Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags

[A Schenck]

On 9/10/19 10:24 PM, Michał Górny wrote:
> On Tue, 2019-09-10 at 22:44 +0200, Michał Górny wrote:
>> Hi, everyone.
>>
>> I've recently (finally!) started adding tests to cpuid2cpuflags.  Tests
>> are based on mocked syscalls that return arch-specific data read from
>> text files.  So far I've got x86 and ppc covered, and now I'd like to
>> add tests for various arm hardware.  Since ARM covers a pretty broad
>> range of hardware, I'd use as much data as possible, especially from
>> different ARM generations.
>>
>> If you have an ARM board and would like to help, please:
>>
>> wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2
>> tar -xf cpuid2cpuflags-7-dev.tar.bz2
>> cd cpuid2cpuflags-7-dev
>> ./configure
>> make hwcap-dump
>> ./hwcap-dump
>>
>> and send me the output along with 'uname -m'.  TIA!
>>
> I'm sorry but sending it this late, I forgot two more important things:
>
> 1. Name of the CPU or the board (i.e. something I can use to name
> the test).
>
> 2. Output of cpuid2cpuflags, preferably verified against cpuinfo.
>
Don't laugh, it actually still works as a NAS and nextcloud server:

amphisbœna ~/cpuid2cpuflags-7-dev # ./hwcap-dump
uhwcap:0097
hwcap2:

namphisbœna ~/cpuid2cpuflags-7-dev # uname -m
armv5tel

amphisbœna ~/cpuid2cpuflags-7-dev # ./cpuid2cpuflags
CPU_FLAGS_ARM: edsp thumb v4 v5

amphisbœna ~/cpuid2cpuflags-7-dev # dog /proc/cpuinfo
processor   : 0
model name  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS    : 400.00
Features    : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part    : 0x131
CPU revision    : 1

Hardware    : Marvell Kirkwood (Flattened Device Tree)
Revision    : 
Serial  : 

amphisbœna ~/cpuid2cpuflags-7-dev # dog /proc/device-tree/model
Globalscale Technologies Dreamplug