Discussion:
Coordingating/planning various golang transitions
(too old to reply)
Reinhard Tartler
2024-07-13 17:00:01 UTC
Permalink
Hi,

We currently ship docker version 20.10 in Debian oldstable, stable and
currently testing. This is an EOL version that I really don't think Debian
trixie should be shipping with.

I've been working over the last couple of weeks (months?) on updating
podman and docker to recent versions, including:

docker.io -> 26.1
containerd -> 1.7
podman -> 5

All of these packages are built successfully in experimental and I have
received test reports that they appear to work fine. So let's get them into
unstable/testing!

While doing so, I've encountered that those new versions really require
updated versions of golang-grpc and protobuf. I've been looking at that set
of packages last month, see the thread starting at [1]. The situation is
not pretty.

My takeaway is that we need to update a large number of packages at the
same time, starting with src:golang-google-genproto
and src:golang-google-grpc. This will unblock a number of packages that are
currently in experimental, and will allow them to enter unstable. However,
this comes with the risk of breaking other packages.

I've been chasing down the stack of dependency fairly far, but I feel I'm
reaching my capacity of how far I'm able to push this transition. I'm
therefore requesting help from the Debian release and golang teams. It is
simply not feasible for me to backtest that large amount of packages. I've
been going through that stack all the way to podman 5.0.3, and can tell
that it is feasible for us as a project. I'm asking for your expertise on
what's the best way to get this project through.

I'd like to have these transitions coordinated so that we can minimize the
disruption for testing. Dear Release Team, please have a look at let me
know what you think. When would be a good time for me (or anyone else) to
start the transition? What kind of information would be useful for that
decision making?

For your convenience, I believe the following listing is a good starting
set of packages to look at:

***@x1:/ $ build-rdeps --distribution testing
golang-google-genproto-dev
Reverse Build-depends in testing/main:
--------------------------------------

caddy
cloudsql-proxy
containerd
crowdsec
crowdsec-custom-bouncer
crowdsec-firewall-bouncer
distrobuilder
docker-libkv
docker.io
etcd
fastnetmon
fever
gh
go-containerregistry
gobgp
golang-collectd
golang-entgo-ent
golang-github-anacrolix-dms
golang-github-anacrolix-ffprobe
golang-github-anacrolix-missinggo
golang-github-anacrolix-tagflag
golang-github-backblaze-blazer
golang-github-canonical-candid
golang-github-census-instrumentation-opencensus-proto
golang-github-checkpoint-restore-checkpointctl
golang-github-containerd-errdefs
golang-github-containerd-nri
golang-github-containerd-stargz-snapshotter
golang-github-containers-buildah
golang-github-containers-common
golang-github-containers-image
golang-github-containers-ocicrypt
golang-github-containers-psgo
golang-github-containers-storage
golang-github-crc-org-crc
golang-github-crowdsecurity-go-cs-bouncer
golang-github-docker-leadership
golang-github-expediadotcom-haystack-client-go
golang-github-francoispqt-gojay
golang-github-fsouza-go-dockerclient
golang-github-go-kit-kit
golang-github-gogo-status
golang-github-googleapis-gax-go
golang-github-googlecloudplatform-guest-logging-go
golang-github-grafana-grafana-plugin-model
golang-github-gravitational-trace
golang-github-grpc-ecosystem-go-grpc-middleware
golang-github-grpc-ecosystem-go-grpc-prometheus
golang-github-grpc-ecosystem-grpc-gateway
golang-github-grpc-ecosystem-grpc-opentracing
golang-github-hashicorp-go-discover
golang-github-hashicorp-go-getter
golang-github-hashicorp-go-plugin
golang-github-jacobsa-gcloud
golang-github-juju-persistent-cookiejar
golang-github-katalix-go-l2tp
golang-github-kubernetes-cri-api
golang-github-lightstep-lightstep-tracer-common
golang-github-lucas-clemente-quic-go
golang-github-mendersoftware-mender-artifact
golang-github-micromdm-scep
golang-github-mudler-docker-companion
golang-github-newrelic-go-agent
golang-github-openshift-imagebuilder
golang-github-opentracing-contrib-go-grpc
golang-github-openzipkin-zipkin-go
golang-github-optiopay-kafka
golang-github-samalba-dockerclient
golang-github-seandolphin-bqschema
golang-github-sercand-kuberesolver
golang-github-sigstore-fulcio
golang-github-sigstore-protobuf-specs
golang-github-sigstore-sigstore
golang-github-smallstep-certificates
golang-github-spiffe-go-spiffe
golang-github-sylabs-sif
golang-github-tonistiigi-fsutil
golang-github-uber-jaeger-lib
golang-github-viant-assertly
golang-github-viant-toolbox
golang-github-vulcand-oxy
golang-github-vulcand-predicate
golang-github-xenolf-lego
golang-github-xordataexchange-crypt
golang-gitlab-gitlab-org-labkit
golang-go.opencensus
golang-go.uber-zap
golang-go4
golang-gocloud
golang-gogottrpc
golang-google-api
golang-google-cloud
golang-google-genproto
golang-google-grpc
golang-opentelemetry-contrib
golang-step-linkedca
golang-v2ray-core
google-guest-agent
hugo
ignition
in-toto-golang
incus
influxdb
libpod
lxd
mirrorbits
mtail
nextcloud-spreed-signaling
nncp
notary
oci-seccomp-bpf-hook
open-vm-tools
opensnitch
prometheus
prometheus-blackbox-exporter
prometheus-hacluster-exporter
prometheus-mqtt-exporter
prometheus-postfix-exporter
prometheus-sql-exporter
protobuild
rclone
receptor
rekor
restic
shoelaces
skeema
skopeo
stenographer
syncthing
trillian
victoriametrics
vip-manager
vip-manager2
yggdrasil

Found a total of 134 reverse build-depend(s) for golang-google-genproto-dev.

Unfortunately, I won't be able to make it to Busan this year. It would be
amazing if these transitions could be discussed in person and a plan could
be devised that would end with trixie shipping a modern version of docker
and related packages.

Thank you so much for your help and interest.

[1]
https://lists.debian.org/debian-go/2024/06/msg00008.html
--
regards,
Reinhard
Simon Josefsson
2024-07-13 19:00:01 UTC
Permalink
Post by Reinhard Tartler
My takeaway is that we need to update a large number of packages at the
same time, starting with src:golang-google-genproto
and src:golang-google-grpc. This will unblock a number of packages that are
currently in experimental, and will allow them to enter unstable. However,
this comes with the risk of breaking other packages.
I've been chasing down the stack of dependency fairly far, but I feel I'm
reaching my capacity of how far I'm able to push this transition.
I am suffering from lack of grpc update too (for rekor and cosign), and
I'm available to help do the required work here. Alas, I'm a bit at a
loss how to approach this problem, as whenever I've started to look into
this I reach some kind of circular dependency loop that I don't know how
to resolve. If someone were to do the heavy thinking and maybe make a
list of packages and versions to upload to experimental I am willing to
help :)

Shouldn't the process really be to take one important package, like
podman, and then go through each reverse dependency that's not already
in unstable and just upload them to experimental? Entering into
dependency loops as it may be, but eventually reaching back to podman.
If some other package stops building with the new reverse dependency,
threat that as a serious bug in that separate package instead of with
the new upload. Maybe we have to live with some failed builds after the
upload to unstable due to circular dependencies, but shouldn't that be
possible to resolve by scheduling a binnmu or simply doing another
upload of the relevant package? I wish some documentation on how to
approach this were available.

/Simon
Reinhard Tartler
2024-07-14 00:50:01 UTC
Permalink
Post by Reinhard Tartler
Post by Reinhard Tartler
My takeaway is that we need to update a large number of packages at the
same time, starting with src:golang-google-genproto
and src:golang-google-grpc. This will unblock a number of packages that
are
Post by Reinhard Tartler
currently in experimental, and will allow them to enter unstable.
However,
Post by Reinhard Tartler
this comes with the risk of breaking other packages.
I've been chasing down the stack of dependency fairly far, but I feel I'm
reaching my capacity of how far I'm able to push this transition.
I am suffering from lack of grpc update too (for rekor and cosign), and
I'm available to help do the required work here. Alas, I'm a bit at a
loss how to approach this problem, as whenever I've started to look into
this I reach some kind of circular dependency loop that I don't know how
to resolve. If someone were to do the heavy thinking and maybe make a
list of packages and versions to upload to experimental I am willing to
help :)
I'm really glad to hear that an experienced and active DD like you
is volunteering to help with this migration. That's really much
appreciated.

As far as I can tell, I've managed to execute this transition in
"experimental"
for all packages that are currently in testing and are affected by
the containerd migration.

It is possible that I missed packages, so I'd appreciate some
double-checking
of my work.


Shouldn't the process really be to take one important package, like
Post by Reinhard Tartler
podman, and then go through each reverse dependency that's not already
in unstable and just upload them to experimental? Entering into
dependency loops as it may be, but eventually reaching back to podman.
If some other package stops building with the new reverse dependency,
threat that as a serious bug in that separate package instead of with
the new upload. Maybe we have to live with some failed builds after the
upload to unstable due to circular dependencies, but shouldn't that be
possible to resolve by scheduling a binnmu or simply doing another
upload of the relevant package? I wish some documentation on how to
approach this were available.
That sounds very goal oriented if we agreed on the goal being
"get podman 5 into testing asap". This is clearly one of my goals.

The approach that you describe above comes with risk:
- Does uploading packages that start this transition cause unpleasant
surprises?
- Does this break packages that we miss to testbuild?
- Does this slow down other, unrelated ongoing transitions?
- Does this require major upstream version updates to other packages (and
if so, are the maintainers of affected packages available to quickly react
and help with restoring those packages)?
- Do we need to temporarily remove other packages to ease this migration?

I personally believe the benefits of achieving the goal outweighs the risk.
I
do hope the Debian release team agrees and is comfortable with me starting
the
migration by uploading packages that are currently in experimental to
unstable,
and are able to advise and help with hints to britney to minimize the
disruption.

My pitch would be to start with sourceful uploads of (and in that order):

- golang-google-genproto
- golang-google-grpc
- golang-github-grpc-ecosystem-grpc-gateway.v2
- golang-github-google-cel-go
- golang-opentelemetry-otel
- golang-github-googleapis-gnostic
- etcd
- golang-gogottrpc
- golang-github-containerd-btrfs
- golang-github-containerd-go-cni
- golang-github-containerd-go-runc
- golang-github-coreos-bbolt
- golang-github-google-certificate-transparency
- golang-github-lightstep-lightstep-tracer-common
- golang-github-kurin-blazer
- golang-google-cloud
- golang-github-containerd-cgroups
- golang-github-containerd-typeurl
- containerd
- golang-github-cloudflare-cfssl
- rootlesskit
- docker.io
- golang-github-fsouza-go-dockerclient
- golang-github-openshift-imagebuilder
- golang-github-containers-storage
- golang-github-containers-image
- golang-github-containers-common
- golang-github-containers-buildah
- libpod


Yes, that is a long list. I think we can do it, but I'm also
interested in minimizing surprises, smooth transitions, and would like to
mititgate
the risks mentioned above with coordination and thinking this through.

Thanks so much for your assistance!

--
regards,
Reinhard
weepingclown
2024-07-14 03:00:01 UTC
Permalink
Hi Reinhard,

First of all thank you for your hard work. I would like to help you out, but am limited currently in time and my golang knowldege as a whole. But my understanding is that the go team plans to have a bof at the debconf this time, so probably this topic can be brought up and hopefully you get good reinforcements. I myself will try to be invovled depending on my availability.

Best,
Ananthu
Mathias Gibbens
2024-07-23 03:30:01 UTC
Permalink
Are there any objections to starting the process of uploading
packages to unstable, following the outline that Reinhard provided
(quoted at the end of the message)? I'm here at DebCamp and would be
happy to start working through the uploads and any other hand-holding
to get the migration underway.

I know we've got an item on the BoF to discuss this, but maybe by
next week we could have a status update of how things are going?

I've spend some time today checking things in experimental and
building a few other packages against those versions, and at least from
what I have testing things appear to be working OK with the newer
versions.

Mathias
Post by Reinhard Tartler
- golang-google-genproto
- golang-google-grpc
- golang-github-grpc-ecosystem-grpc-gateway.v2
- golang-github-google-cel-go
- golang-opentelemetry-otel
- golang-github-googleapis-gnostic
- etcd
- golang-gogottrpc
- golang-github-containerd-btrfs
- golang-github-containerd-go-cni
- golang-github-containerd-go-runc
- golang-github-coreos-bbolt
- golang-github-google-certificate-transparency
- golang-github-lightstep-lightstep-tracer-common
- golang-github-kurin-blazer
- golang-google-cloud
- golang-github-containerd-cgroups
- golang-github-containerd-typeurl
- containerd
- golang-github-cloudflare-cfssl
- rootlesskit
- docker.io
- golang-github-fsouza-go-dockerclient
- golang-github-openshift-imagebuilder
- golang-github-containers-storage
- golang-github-containers-image
- golang-github-containers-common
- golang-github-containers-buildah
- libpod
t***@goirand.fr
2024-07-23 04:30:01 UTC
Permalink
Post by Mathias Gibbens
Are there any objections to starting the process of uploading
packages to unstable, following the outline that Reinhard provided
(quoted at the end of the message)? I'm here at DebCamp and would be
happy to start working through the uploads and any other hand-holding
to get the migration underway.
I know we've got an item on the BoF to discuss this, but maybe by
next week we could have a status update of how things are going?
I've spend some time today checking things in experimental and
building a few other packages against those versions, and at least from
what I have testing things appear to be working OK with the newer
versions.
Mathias
I'm with Mathias on this thinking we must move forward during debcamp. I'd be helping with it if the team gives us a go... :)


Thomas
Post by Mathias Gibbens
Post by Reinhard Tartler
- golang-google-genproto
- golang-google-grpc
- golang-github-grpc-ecosystem-grpc-gateway.v2
- golang-github-google-cel-go
- golang-opentelemetry-otel
- golang-github-googleapis-gnostic
- etcd
- golang-gogottrpc
- golang-github-containerd-btrfs
- golang-github-containerd-go-cni
- golang-github-containerd-go-runc
- golang-github-coreos-bbolt
- golang-github-google-certificate-transparency
- golang-github-lightstep-lightstep-tracer-common
- golang-github-kurin-blazer
- golang-google-cloud
- golang-github-containerd-cgroups
- golang-github-containerd-typeurl
- containerd
- golang-github-cloudflare-cfssl
- rootlesskit
- docker.io
- golang-github-fsouza-go-dockerclient
- golang-github-openshift-imagebuilder
- golang-github-containers-storage
- golang-github-containers-image
- golang-github-containers-common
- golang-github-containers-buildah
- libpod
On Jul 23, 2024 12:28 PM, Mathias Gibbens <***@debian.org> wrote:

Are there any objections to starting the process of uploading
packages to unstable, following the outline that Reinhard provided
(quoted at the end of the message)? I'm here at DebCamp and would be
happy to start working through the uploads and any other hand-holding
to get the migration underway.

I know we've got an item on the BoF to discuss this, but maybe by
next week we could have a status update of how things are going?

I've spend some time today checking things in experimental and
building a few other packages against those versions, and at least from
what I have testing things appear to be working OK with the newer
versions.

Mathias
Post by Mathias Gibbens
- golang-google-genproto
- golang-google-grpc
- golang-github-grpc-ecosystem-grpc-gateway.v2
- golang-github-google-cel-go
- golang-opentelemetry-otel
- golang-github-googleapis-gnostic
- etcd
- golang-gogottrpc
- golang-github-containerd-btrfs
- golang-github-containerd-go-cni
- golang-github-containerd-go-runc
- golang-github-coreos-bbolt
- golang-github-google-certificate-transparency
- golang-github-lightstep-lightstep-tracer-common
- golang-github-kurin-blazer
- golang-google-cloud
- golang-github-containerd-cgroups
- golang-github-containerd-typeurl
- containerd
- golang-github-cloudflare-cfssl
- rootlesskit
- docker.io
- golang-github-fsouza-go-dockerclient
- golang-github-openshift-imagebuilder
- golang-github-containers-storage
- golang-github-containers-image
- golang-github-containers-common
- golang-github-containers-buildah
- libpod
Mathias Gibbens
2024-07-14 20:50:01 UTC
Permalink
Post by Reinhard Tartler
Hi,
We currently ship docker version 20.10 in Debian oldstable, stable and
currently testing. This is an EOL version that I really don't think Debian
trixie should be shipping with.
I've been working over the last couple of weeks (months?) on updating
docker.io -> 26.1
containerd -> 1.7
podman -> 5
All of these packages are built successfully in experimental and I have
received test reports that they appear to work fine. So let's get them into
unstable/testing!
While doing so, I've encountered that those new versions really require
updated versions of golang-grpc and protobuf. I've been looking at that set
of packages last month, see the thread starting at [1]. The situation is
not pretty.
[snip]
Post by Reinhard Tartler
Unfortunately, I won't be able to make it to Busan this year. It would be
amazing if these transitions could be discussed in person and a plan could
be devised that would end with trixie shipping a modern version of docker
and related packages.
I will be attending DebCamp and DebConf, and during those couple of
weeks can spend some focused time helping get these newer versions into
unstable. Especially with Reinhard staging a lot of this in
experimental, hopefully there won't be anything too unexpected or
problematic.

We're about six months out from the trixie freezes starting. I think
that's more than enough time to complete these transitions and be
confident adjacent dependencies haven't been accidentally broken in
some manner.
Post by Reinhard Tartler
First of all thank you for your hard work. I would like to help you
out, but am limited currently in time and my golang knowldege as a
whole. But my understanding is that the go team plans to have a bof
at the debconf this time, so probably this topic can be brought up
and hopefully you get good reinforcements. I myself will try to be
invovled depending on my availability.
I don't think I've seen a Go Team BoF, but I did add a Go Team
listing to the sprints wiki page: https://wiki.debian.org/DebConf/24/Sprints.

Mathias
weepingclown
2024-07-14 21:30:01 UTC
Permalink
Hi,

Discussions in #d-golang indicate a BoF was submitted. My understanding is that it was submitted late after the initial reviews were done by the content team and so it is probably in the list of late submissions the content team has yet to review.

Best,
Ananthu
Post by Mathias Gibbens
I don't think I've seen a Go Team BoF, but I did add a Go Team
listing to the sprints wiki page: https://wiki.debian.org/DebConf/24/Sprints.
Reinhard Tartler
2024-07-23 07:40:01 UTC
Permalink
Control: reassign -1 release.debian.org
Control: user ***@packages.debian.org
Control: usertag transition
Control: severity -1 normal

Dear Release Team,

I am aware that right now we have a number of transitions going on right now
https://release.debian.org/transitions/, however, none of them are
obviously interfering
with the transition I'm proposing below. Therefore it seems to me that
now'ish might be
a good time to start to give us enough time to deal with surprises.

I have also not seen a response to my inquiry below in 10 days. I
understand that
at least some of you might be on vacation or traveling to Debcamp/Debconf.
I am actively
seeking your input, guidance, and ideally a simple "yes, the plan sounds
agreeable and the
risk is acceptable". In order to make this easier to track for you, I'm
usertagging this bug
and re-assigning this to "release.debian.org".

I'm CC'ing the list of DDs who have agreed to help with triaging, fixing
and uploading packages
that are affected by this transition. I'm banking on the help of the whole
golang team to
assist with making this transition as smooth as humanly possible.

I'd appreciate any kind of reply, ideally in the form of: "please hold of,
here is a list
of things we need to consider and/or look at first.".

thank you so much for your assistance!

-rt
Post by Reinhard Tartler
Hi,
We currently ship docker version 20.10 in Debian oldstable, stable and
currently testing. This is an EOL version that I really don't think Debian
trixie should be shipping with.
I've been working over the last couple of weeks (months?) on updating
docker.io -> 26.1
containerd -> 1.7
podman -> 5
All of these packages are built successfully in experimental and I have
received test reports that they appear to work fine. So let's get them into
unstable/testing!
While doing so, I've encountered that those new versions really require
updated versions of golang-grpc and protobuf. I've been looking at that set
of packages last month, see the thread starting at [1]. The situation is
not pretty.
My takeaway is that we need to update a large number of packages at the
same time, starting with src:golang-google-genproto
and src:golang-google-grpc. This will unblock a number of packages that are
currently in experimental, and will allow them to enter unstable. However,
this comes with the risk of breaking other packages.
I've been chasing down the stack of dependency fairly far, but I feel I'm
reaching my capacity of how far I'm able to push this transition. I'm
therefore requesting help from the Debian release and golang teams. It is
simply not feasible for me to backtest that large amount of packages. I've
been going through that stack all the way to podman 5.0.3, and can tell
that it is feasible for us as a project. I'm asking for your expertise on
what's the best way to get this project through.
I'd like to have these transitions coordinated so that we can minimize the
disruption for testing. Dear Release Team, please have a look at let me
know what you think. When would be a good time for me (or anyone else) to
start the transition? What kind of information would be useful for that
decision making?
For your convenience, I believe the following listing is a good starting
golang-google-genproto-dev
--------------------------------------
caddy
cloudsql-proxy
containerd
crowdsec
crowdsec-custom-bouncer
crowdsec-firewall-bouncer
distrobuilder
docker-libkv
docker.io
etcd
fastnetmon
fever
gh
go-containerregistry
gobgp
golang-collectd
golang-entgo-ent
golang-github-anacrolix-dms
golang-github-anacrolix-ffprobe
golang-github-anacrolix-missinggo
golang-github-anacrolix-tagflag
golang-github-backblaze-blazer
golang-github-canonical-candid
golang-github-census-instrumentation-opencensus-proto
golang-github-checkpoint-restore-checkpointctl
golang-github-containerd-errdefs
golang-github-containerd-nri
golang-github-containerd-stargz-snapshotter
golang-github-containers-buildah
golang-github-containers-common
golang-github-containers-image
golang-github-containers-ocicrypt
golang-github-containers-psgo
golang-github-containers-storage
golang-github-crc-org-crc
golang-github-crowdsecurity-go-cs-bouncer
golang-github-docker-leadership
golang-github-expediadotcom-haystack-client-go
golang-github-francoispqt-gojay
golang-github-fsouza-go-dockerclient
golang-github-go-kit-kit
golang-github-gogo-status
golang-github-googleapis-gax-go
golang-github-googlecloudplatform-guest-logging-go
golang-github-grafana-grafana-plugin-model
golang-github-gravitational-trace
golang-github-grpc-ecosystem-go-grpc-middleware
golang-github-grpc-ecosystem-go-grpc-prometheus
golang-github-grpc-ecosystem-grpc-gateway
golang-github-grpc-ecosystem-grpc-opentracing
golang-github-hashicorp-go-discover
golang-github-hashicorp-go-getter
golang-github-hashicorp-go-plugin
golang-github-jacobsa-gcloud
golang-github-juju-persistent-cookiejar
golang-github-katalix-go-l2tp
golang-github-kubernetes-cri-api
golang-github-lightstep-lightstep-tracer-common
golang-github-lucas-clemente-quic-go
golang-github-mendersoftware-mender-artifact
golang-github-micromdm-scep
golang-github-mudler-docker-companion
golang-github-newrelic-go-agent
golang-github-openshift-imagebuilder
golang-github-opentracing-contrib-go-grpc
golang-github-openzipkin-zipkin-go
golang-github-optiopay-kafka
golang-github-samalba-dockerclient
golang-github-seandolphin-bqschema
golang-github-sercand-kuberesolver
golang-github-sigstore-fulcio
golang-github-sigstore-protobuf-specs
golang-github-sigstore-sigstore
golang-github-smallstep-certificates
golang-github-spiffe-go-spiffe
golang-github-sylabs-sif
golang-github-tonistiigi-fsutil
golang-github-uber-jaeger-lib
golang-github-viant-assertly
golang-github-viant-toolbox
golang-github-vulcand-oxy
golang-github-vulcand-predicate
golang-github-xenolf-lego
golang-github-xordataexchange-crypt
golang-gitlab-gitlab-org-labkit
golang-go.opencensus
golang-go.uber-zap
golang-go4
golang-gocloud
golang-gogottrpc
golang-google-api
golang-google-cloud
golang-google-genproto
golang-google-grpc
golang-opentelemetry-contrib
golang-step-linkedca
golang-v2ray-core
google-guest-agent
hugo
ignition
in-toto-golang
incus
influxdb
libpod
lxd
mirrorbits
mtail
nextcloud-spreed-signaling
nncp
notary
oci-seccomp-bpf-hook
open-vm-tools
opensnitch
prometheus
prometheus-blackbox-exporter
prometheus-hacluster-exporter
prometheus-mqtt-exporter
prometheus-postfix-exporter
prometheus-sql-exporter
protobuild
rclone
receptor
rekor
restic
shoelaces
skeema
skopeo
stenographer
syncthing
trillian
victoriametrics
vip-manager
vip-manager2
yggdrasil
Found a total of 134 reverse build-depend(s) for
golang-google-genproto-dev.
Unfortunately, I won't be able to make it to Busan this year. It would be
amazing if these transitions could be discussed in person and a plan could
be devised that would end with trixie shipping a modern version of docker
and related packages.
Thank you so much for your help and interest.
[1]
https://lists.debian.org/debian-go/2024/06/msg00008.html
--
regards,
Reinhard
--
regards,
Reinhard
Graham Inggs
2024-07-25 04:40:02 UTC
Permalink
Control: tags -1 confirmed

Hi Reinhard
Post by Reinhard Tartler
I am aware that right now we have a number of transitions going on right now
https://release.debian.org/transitions/, however, none of them are obviously interfering
with the transition I'm proposing below. Therefore it seems to me that now'ish might be
a good time to start to give us enough time to deal with surprises.
I have also not seen a response to my inquiry below in 10 days. I understand that
at least some of you might be on vacation or traveling to Debcamp/Debconf. I am actively
seeking your input, guidance, and ideally a simple "yes, the plan sounds agreeable and the
risk is acceptable". In order to make this easier to track for you, I'm usertagging this bug
and re-assigning this to "release.debian.org".
I'm CC'ing the list of DDs who have agreed to help with triaging, fixing and uploading packages
that are affected by this transition. I'm banking on the help of the whole golang team to
assist with making this transition as smooth as humanly possible.
I'd appreciate any kind of reply, ideally in the form of: "please hold of, here is a list
of things we need to consider and/or look at first.".
I'm not aware of anything that should block this, please go ahead.

Feel free to update this bug if anything gets stuck migrating to testing.

Regards
Graham
Mathias Gibbens
2024-07-25 04:50:01 UTC
Permalink
Post by Graham Inggs
Post by Reinhard Tartler
I am aware that right now we have a number of transitions going on right now
https://release.debian.org/transitions/, however, none of them are obviously interfering
with the transition I'm proposing below. Therefore it seems to me that now'ish might be
a good time to start to give us enough time to deal with surprises.
I have also not seen a response to my inquiry below in 10 days. I understand that
at least some of you might be on vacation or traveling to Debcamp/Debconf. I am actively
seeking your input, guidance, and ideally a simple "yes, the plan sounds agreeable and the
risk is acceptable". In order to make this easier to track for you, I'm usertagging this bug
and re-assigning this to "release.debian.org".
I'm CC'ing the list of DDs who have agreed to help with triaging, fixing and uploading packages
that are affected by this transition. I'm banking on the help of the whole golang team to
assist with making this transition as smooth as humanly possible.
I'd appreciate any kind of reply, ideally in the form of: "please hold of, here is a list
of things we need to consider and/or look at first.".
I'm not aware of anything that should block this, please go ahead.
Feel free to update this bug if anything gets stuck migrating to testing.
I will begin with uploading golang-google-genproto and golang-google-
grpc to unstable shortly.

Mathias
Shengjing Zhu
2024-08-01 04:50:02 UTC
Permalink
* For some reason golang-google-genproto hasn't yet migrated into
testing. I pinged the release team this morning to see if they can help
figure out why.
You can check https://release.debian.org/britney/update_output.txt.
I think some Breaks in that package make it needs to be migrated with
other packages stuck in proposed migration.
--
Shengjing Zhu
Mathias Gibbens
2024-08-01 04:50:01 UTC
Permalink
Here's an update, one week into the transition:

~35 packages have been successfully uploaded to unstable, including
containerd, docker.io, etcd, and libpod.

* siretart and zhsj have been working on containerd, packaging a few
new dependencies and getting its autopkgtest passing again.

* etcd needs some attention to its autopkgtests, I think zhsj might
be looking into this

* For some reason golang-google-genproto hasn't yet migrated into
testing. I pinged the release team this morning to see if they can help
figure out why.

* golang-google-grpc needs some cleanup of DH_GOLANG_EXCLUDES in
d/rules to properly exclude source files that can't compile due to
other missing dependencies. (Probably can be done after this migration
completes.)

Getting etcd happy once again and a new upload of golang-google-grpc
with an additional Breaks line should, I think, finally get a large
chunk of the recently uploaded packages fully happy and able to migrate
to testing.

Mathias
Post by Reinhard Tartler
Hi,
We currently ship docker version 20.10 in Debian oldstable, stable and
currently testing. This is an EOL version that I really don't think Debian
trixie should be shipping with.
I've been working over the last couple of weeks (months?) on updating
docker.io -> 26.1
containerd -> 1.7
podman -> 5
All of these packages are built successfully in experimental and I have
received test reports that they appear to work fine. So let's get them into
unstable/testing!
While doing so, I've encountered that those new versions really require
updated versions of golang-grpc and protobuf. I've been looking at that set
of packages last month, see the thread starting at [1]. The situation is
not pretty.
My takeaway is that we need to update a large number of packages at the
same time, starting with src:golang-google-genproto
and src:golang-google-grpc. This will unblock a number of packages that are
currently in experimental, and will allow them to enter unstable. However,
this comes with the risk of breaking other packages.
I've been chasing down the stack of dependency fairly far, but I feel I'm
reaching my capacity of how far I'm able to push this transition. I'm
therefore requesting help from the Debian release and golang teams. It is
simply not feasible for me to backtest that large amount of packages. I've
been going through that stack all the way to podman 5.0.3, and can tell
that it is feasible for us as a project. I'm asking for your expertise on
what's the best way to get this project through.
I'd like to have these transitions coordinated so that we can minimize the
disruption for testing. Dear Release Team, please have a look at let me
know what you think. When would be a good time for me (or anyone else) to
start the transition? What kind of information would be useful for that
decision making?
For your convenience, I believe the following listing is a good starting
golang-google-genproto-dev
--------------------------------------
caddy
cloudsql-proxy
containerd
crowdsec
crowdsec-custom-bouncer
crowdsec-firewall-bouncer
distrobuilder
docker-libkv
docker.io
etcd
fastnetmon
fever
gh
go-containerregistry
gobgp
golang-collectd
golang-entgo-ent
golang-github-anacrolix-dms
golang-github-anacrolix-ffprobe
golang-github-anacrolix-missinggo
golang-github-anacrolix-tagflag
golang-github-backblaze-blazer
golang-github-canonical-candid
golang-github-census-instrumentation-opencensus-proto
golang-github-checkpoint-restore-checkpointctl
golang-github-containerd-errdefs
golang-github-containerd-nri
golang-github-containerd-stargz-snapshotter
golang-github-containers-buildah
golang-github-containers-common
golang-github-containers-image
golang-github-containers-ocicrypt
golang-github-containers-psgo
golang-github-containers-storage
golang-github-crc-org-crc
golang-github-crowdsecurity-go-cs-bouncer
golang-github-docker-leadership
golang-github-expediadotcom-haystack-client-go
golang-github-francoispqt-gojay
golang-github-fsouza-go-dockerclient
golang-github-go-kit-kit
golang-github-gogo-status
golang-github-googleapis-gax-go
golang-github-googlecloudplatform-guest-logging-go
golang-github-grafana-grafana-plugin-model
golang-github-gravitational-trace
golang-github-grpc-ecosystem-go-grpc-middleware
golang-github-grpc-ecosystem-go-grpc-prometheus
golang-github-grpc-ecosystem-grpc-gateway
golang-github-grpc-ecosystem-grpc-opentracing
golang-github-hashicorp-go-discover
golang-github-hashicorp-go-getter
golang-github-hashicorp-go-plugin
golang-github-jacobsa-gcloud
golang-github-juju-persistent-cookiejar
golang-github-katalix-go-l2tp
golang-github-kubernetes-cri-api
golang-github-lightstep-lightstep-tracer-common
golang-github-lucas-clemente-quic-go
golang-github-mendersoftware-mender-artifact
golang-github-micromdm-scep
golang-github-mudler-docker-companion
golang-github-newrelic-go-agent
golang-github-openshift-imagebuilder
golang-github-opentracing-contrib-go-grpc
golang-github-openzipkin-zipkin-go
golang-github-optiopay-kafka
golang-github-samalba-dockerclient
golang-github-seandolphin-bqschema
golang-github-sercand-kuberesolver
golang-github-sigstore-fulcio
golang-github-sigstore-protobuf-specs
golang-github-sigstore-sigstore
golang-github-smallstep-certificates
golang-github-spiffe-go-spiffe
golang-github-sylabs-sif
golang-github-tonistiigi-fsutil
golang-github-uber-jaeger-lib
golang-github-viant-assertly
golang-github-viant-toolbox
golang-github-vulcand-oxy
golang-github-vulcand-predicate
golang-github-xenolf-lego
golang-github-xordataexchange-crypt
golang-gitlab-gitlab-org-labkit
golang-go.opencensus
golang-go.uber-zap
golang-go4
golang-gocloud
golang-gogottrpc
golang-google-api
golang-google-cloud
golang-google-genproto
golang-google-grpc
golang-opentelemetry-contrib
golang-step-linkedca
golang-v2ray-core
google-guest-agent
hugo
ignition
in-toto-golang
incus
influxdb
libpod
lxd
mirrorbits
mtail
nextcloud-spreed-signaling
nncp
notary
oci-seccomp-bpf-hook
open-vm-tools
opensnitch
prometheus
prometheus-blackbox-exporter
prometheus-hacluster-exporter
prometheus-mqtt-exporter
prometheus-postfix-exporter
prometheus-sql-exporter
protobuild
rclone
receptor
rekor
restic
shoelaces
skeema
skopeo
stenographer
syncthing
trillian
victoriametrics
vip-manager
vip-manager2
yggdrasil
Found a total of 134 reverse build-depend(s) for golang-google-genproto-dev.
Unfortunately, I won't be able to make it to Busan this year. It would be
amazing if these transitions could be discussed in person and a plan could
be devised that would end with trixie shipping a modern version of docker
and related packages.
Thank you so much for your help and interest.
[1]
https://lists.debian.org/debian-go/2024/06/msg00008.html
Loading...