* Package name : golang-opentelemetry-auto-sdk Version : 1.2.1 Upstream Contact: https://github.com/open-telemetry/opentelemetry-go-instrumentation Upstream Author : OpenTelemetry Authors * URL : https://github.com/open-telemetry/opentelemetry-go-instrumentation * License : Apache-2.0 Programming Lang: Go Description : OpenTelemetry Go auto-instrumentation SDK OpenTelemetry tracing instrumentation for Go libraries using eBPF. Support package for OpenTelemetry Go auto-instrumentation. This is a submodule of the opentelemetry-go-instrumentation monorepo. Its only runtime dependencies are go.opentelemetry.io/otel and go.opentelemetry.io/otel/trace, both already in Debian. This package is needed as a direct dependency of golang-opentelemetry-otel (>= 1.43.0).
Hi Juan, I have been working on updating golang-opentelemetry-otel 1.43. And I found sdk is a submodule, we should package golang-opentelemetry-auto instead. Package: wnpp Severity: wishlist * Package name : golang-opentelemetry-auto Version : 0.24.0-1 Upstream Author : OpenTelemetry - CNCF * URL : https://github.com/open-telemetry/opentelemetry-go-instrumentation * License : Apache-2.0 Programming Lang: Go Description : OpenTelemetry Auto Instrumentation using eBPF This library provides a way to instrument Go applications automatically without requiring manual code changes by the developer. It utilizes eBPF technology to intercept execution at the kernel level and collect telemetry data such as traces and metrics directly from the running process. This approach significantly reduces the friction of adding observability to existing services and ensures a consistent data collection strategy across different applications. Best regards,
Hi Juan, I have been working on updating golang-opentelemetry-otel 1.43. And I found sdk is a submodule, we should package golang-opentelemetry-auto instead. Package: wnpp Severity: wishlist * Package name : golang-opentelemetry-auto Version : 0.24.0-1 Upstream Author : OpenTelemetry - CNCF * URL : https://github.com/open-telemetry/opentelemetry-go-instrumentation * License : Apache-2.0 Programming Lang: Go Description : OpenTelemetry Auto Instrumentation using eBPF This library provides a way to instrument Go applications automatically without requiring manual code changes by the developer. It utilizes eBPF technology to intercept execution at the kernel level and collect telemetry data such as traces and metrics directly from the running process. This approach significantly reduces the friction of adding observability to existing services and ensures a consistent data collection strategy across different applications. Best regards,
Hi Andrew,
Thanks for quick heads up!
I wanted to unblock siso, so I started to look into otel and his deps. I will stop packaging otel 1.43.0, but let me know if you needed help. I have a working branch with the upstream import done, patches refreshed and I could push it.
On the other hand, I've retitled this ITP accordingly.
Also filed ITPs for the other two missing dependencies needed by otel 1.43.0:
- golang-github-cenkalti-backoff-v5
(bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1136683)
backoff/v4 -> v5 migration in all OTLP exporters
- golang-github-prometheus-otlptranslator
(bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1136685)
new dep for exporters/prometheus
Best,
Juan
Hi Juan, Nothing needs to be encryped here. And sorry for my bad that I should communicate first via team mailing list. Feel free to put all of your WIP packages into go-team space on salsa under team maintain if there is anything that I haven't pushed yet. And please send an email to let us know what you pushed. So that we can coordinate them better. Best regards,
Hi! Initial packaging [1] Two items that I would like to bring. First. I still don't have access to the team workspace. Could a team member with the appropriate permissions move it to salsa.debian.org/go-team/packages/golang-opentelemetry-auto? I can add it as owner when someone wants to move it. Second. The repo has two modules: - the root (go.opentelemetry.io/auto) - the sdk submodule (go.opentelemetry.io/auto/sdk). The sdk/ submodule is the module that golang-opentelemetry-otel >= 1.43.0 requires. The root module has three missing deps, blocked by a circular dependency: pdata and contrib/detectors/autodetect both require otel >= 1.43.0 (this package unblocks it), autodetect is already in experimental (contrib 1.39.0-2), and sqlparser. The packaging order could be: ship sdk/ now with this package, then otel 1.43.0, then package pdata and sqlparser while contrib migrates from experimental. At that point, the root module build gets enabled in this package. Please, let me know if this is the right approach to initially unblock otel and this one. Best, Juan [1] https://salsa.debian.org/mendezr/golang-opentelemetry-auto [2] https://salsa.debian.org/go-team/packages/golang-opentelemetry-otel
Hi Andrew, Go team: I've been actively working on this package and its dependencies. The sdk/ submodule is ready on salsa. The root/ submodule also has more details below https://salsa.debian.org/mendezr/golang-opentelemetry-auto The reason I did not push it to team workspace, is that I don't have team access. For this I would like to ask the team what's the best procedure while my NM is in process. I noticed you took ownership of this ITP, shall I take it back, waiting for your answer for better coordination For the root module, the remaining blockers are version bumps needed by the auto go.mod, plus a contrib upgrade to align with otel 1.43.0. I have MRs open for all of them (since May 18): [1] golang-go.uber-multierr 1.6.0 -> 1.11.0 [2] golang-github-cilium-ebpf 0.17.3 -> 0.21.0 [3] golang-golang-x-arch 0.13.0 -> 0.27.0 [4] golang-opentelemetry-contrib -> 1.43.0 [1] https://salsa.debian.org/go-team/packages/golang-go.uber-multierr/-/merge_requests/2 [2] https://salsa.debian.org/go-team/packages/golang-github-cilium-ebpf/-/merge_requests/4 [3] https://salsa.debian.org/go-team/packages/golang-golang-x-arch/-/merge_requests/1 [4] https://salsa.debian.org/go-team/packages/golang-opentelemetry-contrib/-/merge_requests/3 Regards, Juan
Hi Juan, I'm glad to see you active on these. https://salsa.debian.org/go-team/packages/golang-opentelemetry-auto# It was duplicated with my ITP. However I have multiple tasks to do in Debian at the moment. I changed the owner to you now. :) Yes, I noticed all that. But I haven't had time to check reverse-dependency rebuilds yet. Since I put you as the owner now. To avoid duplicate work, Can you please also do the the reverse-dependency rebuilds check then? Best regards,
El sábado, 23 de mayo de 2026 a las 16:53, Andrew Lee <ajqlee@debian.org> escribió:
Hi Andrew,
I ran ratt over all my previously opened MRs
(ratt -direct-rdeps -chdist sid -sbuild_dist sid -skip_ftbfs)
Results:
multierr 1.11.0: 13/13 PASS
cilium-ebpf 0.21: 6/9 PASS (3 fixed, see below)
x-arch 0.27.0: 2/2 PASS (delve test fail is unrelated, see below)
contrib 1.43.0: 13/13 PASS
cilium-ebpf 0.21 breaks 3 rdeps due to removed APIs in ebpf 0.19+.
So I prepared new patches and filed a bug.
- MR 1: opencontainers-cgroups: drop removed RunCount/Runtime debug calls.
ratt with the patch: 3/3 PASS (containers-common, docker.io, runc)
https://salsa.debian.org/go-team/packages/golang-github-opencontainers-cgroups/-/merge_requests/1
- MR 2: pwru: replace removed btf.Iterate with TypeByID loop
ratt with the patch: 0 rdeps
https://salsa.debian.org/go-team/packages/pwru/-/merge_requests/3
- Bug: delve: FTBFS with Go 1.26.3 (TestDisassPosCmd), not x-arch related built fine on buildd with Go 1.26.2, fails with 1.26.3
https://bugs.debian.org/1137556
Full MR list:
https://salsa.debian.org/go-team/packages/golang-go.uber-multierr/-/merge_requests/2
https://salsa.debian.org/go-team/packages/golang-github-cilium-ebpf/-/merge_requests/4
https://salsa.debian.org/go-team/packages/golang-golang-x-arch/-/merge_requests/1
https://salsa.debian.org/go-team/packages/golang-opentelemetry-contrib/-/merge_requests/3
https://salsa.debian.org/go-team/packages/golang-github-opencontainers-cgroups/-/merge_requests/1
https://salsa.debian.org/go-team/packages/pwru/-/merge_requests/3
Regards,
Juan
The root module now builds with all deps in sid. Package ready at: https://salsa.debian.org/mendezr/golang-opentelemetry-auto The go-team repo is empty, so I can't fork it, could you either pull from mine or give me push access so I can create an MR? sbuild and tests pass. Build-Depends updated for both root module and sdk. Best, Juan
I granted you rights to the go-team repo, please move things there as a first step towards go-team review. /Simon Juan M. Méndez Rey <juan.mendezr@proton.me> writes:
Thanks Simon, much appreciated. The changes are now in: https://salsa.debian.org/go-team/packages/golang-opentelemetry-auto Ready for review/sponsoring. Juan El martes, 16 de junio de 2026 a las 12:09, Simon Josefsson <simon@josefsson.org> escribió:
- Missing copyright notice for ./internal/pkg/instrumentation/bpf/net/http/http_event.go - Push upstream/* tags to Salsa - The 'git diff v0.24.0..upstream' (I assume upstream branch is intended to be 0.24.0) is large, could you look at the upstream source import? - I don't think you need to files-excludes LICENSES/, and minimizing the amount of changes compared to upstream is often useful. /Simon Juan M. Méndez Rey <juan.mendezr@proton.me> writes:
El martes, 16 de junio de 2026 a las 12:33, Simon Josefsson <simon@josefsson.org> escribió: As always, thanks Simon for the very good pointers. I have double-checked the licenses and pushed the tags. I am avoiding now an unnecessary repack so there are less diff to check, while removing the Files-Excluded Now, the root module now builds fully (not just sdk/). All 17 test suites pass. The pre-requisite packages not yet in sid: - ITP #1140162 https://salsa.debian.org/mendezr/golang-github-brunoscheufler-aws-ecs-metadata-go - ITP #1140163 https://salsa.debian.org/mendezr/golang-github-googlecloudplatform-opentelemetry-operations-go Full repo packaged. Currently only detectors/gcp is built and tested; the exporter submodules have additional dependencies (golang-google-cloud-dev and golang-google-api-dev) that may need version bumps. Enabling them is just removing excludes and adding Build-Depends. Package now at: https://salsa.debian.org/go-team/packages/golang-opentelemetry-auto I would appreciate any sponsoring on those two so auto could be uploaded too. Best, Juan
Hi Juan (and go-team), I am packaging helm.sh/helm/v4 and related leafs toward kzero (ITP #1142432). The estimate pulls in go.opentelemetry.io/auto/sdk via github.com/distribution/distribution/v3. Your ITP #1136684 (golang-opentelemetry-auto) covers that import path (and the wider auto / eBPF tree). It is not in the archive yet; I am not filing a competing ITP. Local rebuild of go-team/packages/golang-opentelemetry-auto on 2026-09-20 failed on Build-Depends: several packages have no candidate in sid (e.g. aws-ecs-metadata-go, opentelemetry-operations-go, sqlparser, opentelemetry-collector) and others are too old vs debian/control (ebpf, multierr, x-arch, otel, contrib, …). Two questions: 1) What is the current status / next step for landing this in unstable? 2) Would you be open to packaging go.opentelemetry.io/auto/sdk as a smaller leaf first (closer to the original auto-sdk ITP text — runtime deps mostly already in Debian), with the full eBPF auto package following later? If you prefer to keep one source package, I can instead help with missing leaf Build-Depends one at a time under go-team, if that is useful. Separately: I run a small HTTPS staging apt on https://packaging.hermesrodriguez.com/apt (personal MVP — not Debian). If it helps your local rebuilds or Salsa CI EXTRA_REPOSITORY while leaf -dev packages wait for unstable, I can publish built .debs there and share a one-line sources.list / EXTRA_REPOSITORY snippet. Say the word and which packages you want mirrored. One more small note on both Salsa trees (go-team/packages and your mendezr fork, debian/sid): there is debian/gitlab-ci.yml only — no debian/salsa-ci.yml. It still includes the old pkg-go-tools pipeline/test-archive.yml, and the project ci_config_path is unset (null). Current go-team / Flight Deck preference is debian/salsa-ci.yml (Salsa CI team recipe). Happy to send a tiny MR that adds salsa-ci.yml and turns gitlab-ci.yml into a thin local include wrapper, if you want — same pattern as recent leafs. Happy to coordinate on Salsa or on this bug. Thanks for the work so far. Best regards, Hermes Rodríguez
El domingo, 20 de septiembre de 2026 a las 07:09, Hermes Jesus Rodriguez Azuaje <hrodrig@usb.ve> escribió: Hi Hermes, Thanks for your interest, I contributed on the majority of those packages, and almost all Build-Depends for auto are in sid already. You might need to update your chroot. The only one missing is aws-ecs-metadata-go, changes are in salsa waiting for upload. https://salsa.debian.org/go-team/packages/golang-github-brunoscheufler-aws-ecs-metadata-go [1] We made a request in July: https://lists.debian.org/debian-go/2026/07/msg00052.html Regarding, splitting auto/sdk, I remember speaking with Andrew about this and I am not wrong the outcome was to keep it together. Regarding salsa-ci.yml: Good catch, please, send a MR to go-team/packages/ . These are the pending items waiting for a DD: Upload aws-ecs-metadata-go (link above), this is the last blocker for auto. PS: The go-team is involved in the Module-Aware Build Transition Plan, resolving autopkgtest errors, and getting dh-golang 1.66 in unstable. When things estabilizes, could be a good time to ask for sponsorships again, unless some DD reads it and is willing to sponsor [1] Cheers, Juan
Hi Juan, Thanks for the clarification on the chroot — that matches what I see after refreshing sid-amd64-sbuild on my packaging host. Agreed that aws-ecs-metadata-go is the remaining Build-Depends gap in sid. salsa-ci.yml MR as requested: https://salsa.debian.org/go-team/packages/golang-opentelemetry-auto/-/merge_requests/1 Minimal change only: debian/salsa-ci.yml with the Salsa CI team recipe, and debian/gitlab-ci.yml as a thin local include wrapper (no extra SALSA_CI_DISABLE_* from my leaf policy). Happy to adjust if you want something different. On the DD upload of aws-ecs-metadata-go I will stay out of the way unless a short ping on the July debian-go thread would help. Cheers, Hermes El dom, 20 sept 2026 a las 10:38, Juan M. Méndez Rey (<juan.mendezr@proton.me>) escribió: