[gentoo-dev] Re: Packages up for grabs due to developer inactivity

[Holger Hoffstätte]

On 2024-02-14 10:49, Michał Górny wrote:


net-dns/dnsdist


I can proxymaint this since I occasionally report bugs/contribute to upstream.
Will open a maintainer PR and version bump soon-ish.

cheers
Holger

[gentoo-dev] Re: Proposal to undeprecate EGO_SUM

[Holger Hoffstätte]

(I hope this makes it to the -dev list)

Hello everyone -

I'm not an official dev but frequently report bugs, fixes and also
maintain a few go-based ebuilds in my private overlay. I also hate
golang with the force of a thousand suns, but hat's not important
right now.

Since I recently converted all my ebuilds from EGO_SUM to the
tarball way of doing things I'd like to chime in.
Also I'm not going to rehash everything that has been said, except
maybe that the space usage of the tarballs is nothing short of *insane*.

OTOH having to paste a weird list of dependencies into the
ebuild is also insane, even though get-ego-vendor makes this
palatable. With an eye towards fixing *that* with a bit more
automation, let's look at the pieces of the puzzle.

The candidate on the table: the ebuild for restic, a popular
and pretty clever backup program.

The restic ebuild by itself is ~40k:
$cd /var/db/repos/gentoo/app-backup/restic
$ls -al restic-0.13.1.ebuild
-rw-r--r-- 1 root root 40699 Apr 23 13:11 restic-0.13.1.ebuild

If we separate the ebuild from the EGO_SUM blurb, we get:
$ls -al restic-0.13.1*
-rw-r--r-- 1 holger users 39668 Jun 14 17:50 restic-0.13.1-EGO_SUM
-rw-r--r-- 1 holger users  1030 Jun 14 17:51 restic-0.13.1.ebuild

Nothing new here. But how large is the EGO_SUM really?
$ls -al restic-0.13.1-EGO_SUM.bz2
-rw-r--r-- 1 holger users 7902 Jun 14 17:50 restic-0.13.1-EGO_SUM.bz2

Much smaller obviously, but probably still too large for including in
$FILESDIR. So my idea here is: instead of chucking EGO_SUM (automatically
generated declarative dependency management) out the window, can we not
separate the two and instead of uploading the tarball upload the
dependency set instead? This does not fix the mentioned trust problem
since a dev space can still be hijacked, but that is already the case.
Anyway.

The only new requirement here would be to load/parse the EGO_SUM.bz2 into
the ebuild, but I'm sure that can be solved. Note that only the SHA of
the EGO_SUM.bz2 would be verified as dependency, not all the
contents - same as with the tarball.

This would eliminate the space bloat/bandwith amplification problem,
distfile caching across ebuilds could again work as expected (even though
go successfully makes that almost futile), and with slightly better
tooling in ego-get-vendor could reduce toil when bumping an ebuild.

I'm looking forward to hear why this idea is terrible. :)

Thank you all for Gentoo.

cheers
Holger

[gentoo-dev] Re: Last rites: unmaintained Go packages with license issues

[Holger Hoffstätte]

On 12/3/19 7:42 PM, William Hubbs wrote:

I'm not sure what happened to my last message, so I'm trying again.

On Sun, Dec 01, 2019 at 10:23:12PM +0100, Michał Górny wrote:

app-admin/docker-bench
app-emulation/cadvisor
app-emulation/reg
app-metrics/alertmanager
app-metrics/bind_exporter
app-metrics/blackbox_exporter
app-metrics/burrow_exporter
app-metrics/elasticsearch_exporter
app-metrics/mongodb_exporter
app-metrics/nginx-vts-exporter
app-metrics/node_exporter
app-metrics/openvpn_exporter
app-metrics/postfix_exporter
app-metrics/postgres_exporter
app-metrics/prometheus
app-metrics/snmp_exporter
app-metrics/vault_exporter
dev-util/drone
dev-util/drone-cli
sys-auth/docker_auth


My employer has an interest in all of these, so please unmask and assign
to me.



That's great, thanks. They are already unmasked again and most packages are
already fixed, see https://bugs.gentoo.org/695212.

-h

[gentoo-dev] Re: vanilla-sources broken

[Holger Hoffstätte]

On 01/05/18 15:08, Nicolas Bock wrote:
> currently vanilla-sources are broken, but there is an upstream patch
> that fixes it (appended at the end). I know that vanilla-sources are
> supposed to be vanilla, but it would help if we added this patch
> until upstream backports it. Any thoughts?

This is now fixed in 4.15-rc8 (with the patch you cited) and will be
in stable 4.14.15 (the one after the upcoming release).

cheers,
Holger

[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

[Holger Hoffstätte]

On Wed, 02 Aug 2017 17:51:43 +, Martin Vaeth wrote:

> Michał Górny  wrote:
>>
>> What are your thoughts?
> 
> If this already was discussed then sorry for the noise:
> 
> What is the rationale for merging lib32 with lib?
> Wouldn't it be somewhat cleaner to have a completely
> split structure
> 
> lib64
> lib32
> libx32 (possibly)
> lib

I wondered the same. If anything it would make more sense to merge
lib64 into lib, since it's the platform's default (assuming 64bit).
Merging lib32 into lib is going to cause nothing but problems.

-h

[gentoo-dev] Re: Infiniband/OmniPath/iWARP and other RDMA related staff

[Holger Hoffstätte]

On Wed, 29 Jun 2016 10:07:07 +0300, Alexey Shvetsov wrote:

> Hi all!
> 
> I'm going to revive RDMA fabric related things in gentoo. And since its not 

Yay!

> only about infiniband staff but about more generic fabric types there is and 
> idea to rename category sys-infiniband to more generic name. Suggestions are
> 
> sys-rdma
> sys-fabric
> 
> What will be inside? It will be RDMA related stuff like OFED, fabric 
> userspace 
> drivers (verbs, psm, psm2, libfabric and others), plugins for specific 
> devices, 
> tools to flash RDMA cards and other related staff.

This makes me happy. I've been playing with a standalone libfabric in my
overlay via the sockets/UDP providers, and had nothing but problems when I
tried to add USE flags for the various OFED bits (psm2 etc.)

An up-to-date libfabric that pulls in ofed only when needed would finally enable
people without the otherwise necessary fabric HW to write against the much more
usable & sane (when compared to raw IB verbs) libfabric APIs.

As far as the name is concerned IMHO fabric sounds less RDMA-specific;
I think the OFI WG now also prefers implementation-neutral terms.

cheers,
Holger

[gentoo-dev] Re: Excessive rsync time after git migration

[Holger Hoffstätte]

On Sat, 15 Aug 2015 15:29:21 -0400, Joshua Kinard wrote:

 This might already be covered in one of the other e-mail threads, but I've 
 been
 super-busy as of late and just recently ran 'emerge --sync' on my main dev box
 for the first time after the git migration.  I just synced my main dev box
 again, ~10 hours after the last sync, but it looks like the 'Manifest' files
 for *every* package in the tree are getting downloaded with each sync.

https://bugs.gentoo.org/show_bug.cgi?id=557192

-h