Re: Non-responsive maintainer check for olem

[Maxwell G]

On Fri Sep 2, 2022, Maxwell G via devel wrote:
>  Sep 2, 2022 5:36:41 AM Fabio Valentini <decathorpe(a)gmail.com&gt;:
>
>  > Does anybody know whether olem still wants to maintain their Fedora
>  > packages?
>  I'm fairly sure that they no longer wish to maintain Fedora packages. I
>  reached out to them about moby-engine and containerd at the end of May,
>  and they said they no longer have time to maintain them. I have been
>  maintaining those packages myself for a while.
>
>  Side note: I have asked for co-maintainers for those packages a couple
>  times, but so far, I have not found any. Perhaps one of the CoreOS people
>  would be interested? It seems those packages are used a lot there based
>  on the bug reports we've gotten. 
It looks like the nonresponsive maintainer process is going to proceed.
I've done some analysis of the Go packages that will be orphaned so the
Go SIG can figured out how to handle this. This was done by hand, so
please excuse any errors.

The following packages are dependencies of golang-github-docker{,-cli} and/or
containerd:

1. golang-github-hanwen-fuse
2. golang-github-fvbommel-sortorder
3. golang-github-containerd-nri
4. golang-github-moby-locker
5. golang-github-moby-term
6. golang-github-tonistiigi-rosetta
7. golang-github-google-containerregistry
8. golang-github-containerd-stargz-snapshotter (FTBFS)

9. golang-github-kyokomi-emoji is a dependency of hugo

olem also maintained open-policy-agent and some of its
dependencies:

- open-policy-agent
- golang-github-yashtewari-glob-intersection (open-policy-agent is the only dependent)
- golang-uber-automaxprocs (dependency of both open-policy-agent and
  clash)

This maintainer also maintained golang-github-jsonnet-bundler and
golang-github-containerd-cni. These packages are leaves. I sent a
separate message to the golang list about retiring these. I suppose we
could just wait for it to happen automatically.

Many of these libraries are out of date, but only one of them FTBFS
(according to Koschei), which I'd consider pretty good. Updating these
packages will likely require packaging a bunch of new dependencies. I
think eclipseo has been doing some work on the docker side of things,
though. Thanks for that!

I have been keeping containerd and moby-engine up to date. moby-engine
could use a cleanup. Currently, docker-proxy
(github.com/moby/libnetwork), docker-init (bundled tini-static), dockerd
(github.com/moby/moby), and the docker cli (github.com/docker/cli) are
all part of the moby-engine package. This makes the specfile rather
cumbersome. Ideally, it should be split up. I just haven't had the time
to do so. docker cli should be straightforward.
github.com/moby/libnetwork will soon be merged into
github.com/moby/moby, so docker-proxy doesn't make sense to split out
right now. For docker-init, we should investigate whether we could
configure docker to look for the existing tini-static binary or at least
create a symlink. It expects the binary to be installed to
%{_libexecdir}/docker/docker-init. I am really not a fan of the bundled
tini-static.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

Non-responsive maintainer check for olem

[Robert-André Mauchin]

On 9/22/22 01:10, Maxwell G wrote:
>  On Fri Sep 2, 2022, Maxwell G via devel wrote:
> >
> > Sep 2, 2022 5:36:41 AM Fabio Valentini <decathorpe(a)gmail.com&gt;:
> >
> >> Does anybody know whether olem still wants to maintain their Fedora
> >> packages?
> > I'm fairly sure that they no longer wish to maintain Fedora packages. I
> > reached out to them about moby-engine and containerd at the end of May,
> > and they said they no longer have time to maintain them. I have been
> > maintaining those packages myself for a while.
> >
> > Side note: I have asked for co-maintainers for those packages a couple
> > times, but so far, I have not found any. Perhaps one of the CoreOS people
> > would be interested? It seems those packages are used a lot there based
> > on the bug reports we've gotten.
>  
>  It looks like the nonresponsive maintainer process is going to proceed.
>  I've done some analysis of the Go packages that will be orphaned so the
>  Go SIG can figured out how to handle this. This was done by hand, so
>  please excuse any errors.
>  
>  The following packages are dependencies of golang-github-docker{,-cli} and/or
>  containerd:
>  
>  1. golang-github-hanwen-fuse
>  2. golang-github-fvbommel-sortorder
>  3. golang-github-containerd-nri
>  4. golang-github-moby-locker
>  5. golang-github-moby-term
>  6. golang-github-tonistiigi-rosetta
>  7. golang-github-google-containerregistry
>  8. golang-github-containerd-stargz-snapshotter (FTBFS)
>  
>  9. golang-github-kyokomi-emoji is a dependency of hugo
>  
>  olem also maintained open-policy-agent and some of its
>  dependencies:
>  
>  - open-policy-agent
>  - golang-github-yashtewari-glob-intersection (open-policy-agent is the only dependent)
>  - golang-uber-automaxprocs (dependency of both open-policy-agent and
>     clash)
>  
>  This maintainer also maintained golang-github-jsonnet-bundler and
>  golang-github-containerd-cni. These packages are leaves. I sent a
>  separate message to the golang list about retiring these. I suppose we
>  could just wait for it to happen automatically.
>  
>  Many of these libraries are out of date, but only one of them FTBFS
>  (according to Koschei), which I'd consider pretty good. Updating these
>  packages will likely require packaging a bunch of new dependencies. I
>  think eclipseo has been doing some work on the docker side of things,
>  though. Thanks for that!
>  
>  I have been keeping containerd and moby-engine up to date. moby-engine
>  could use a cleanup. Currently, docker-proxy
>  (github.com/moby/libnetwork), docker-init (bundled tini-static), dockerd
>  (github.com/moby/moby), and the docker cli (github.com/docker/cli) are
>  all part of the moby-engine package. This makes the specfile rather
>  cumbersome. Ideally, it should be split up. I just haven't had the time
>  to do so. docker cli should be straightforward.
>  github.com/moby/libnetwork will soon be merged into
>  github.com/moby/moby, so docker-proxy doesn't make sense to split out
>  right now. For docker-init, we should investigate whether we could
>  configure docker to look for the existing tini-static binary or at least
>  create a symlink. It expects the binary to be installed to
>  %{_libexecdir}/docker/docker-init. I am really not a fan of the bundled
>  tini-static.
>  
>  --
>  Best,
>  
>  Maxwell G (@gotmax23)
>  Pronouns: He/Him/His 
Hi,

I can take care of all the Docker deps since I am in the process of updating them.

Best regards,

Robert-André