Bug#1144068: ITP: python-opentelemetry-contrib -- The Python auto-instrumentation libraries for OpenTelemetry
Carsten Schoenert <[email protected]> Mon, 10 Aug 2026 21:44:17 +0200
| Newsgroups | gmane.linux.debian.devel.wnpp |
|---|---|
| Message-ID | <b102a655-923e-4e4c-806b-f418aff3d934__48434.340143443$1786391144$gmane$org@t-online.de> |
Hello Pieter, Am 10.08.26 um 20:05 schrieb Pieter Lenaerts: > Hi Carsten, > > You are right, the ITP should be more specific. You are pointing at the right repo. > > Judging from pyproject.toml from pydantic-logfire #1143122, which is needed for > python-mcp, we *might* be needing a number of binary packages coming from the > opentelemetry-python-contrib github repo. > > I need to check which ones are really needed. take your time I'd suggest to understand what is maintained where. The upstream OpenTelemetry packages are quite fractured to my impression and the git trees are very often more a collection of libraries that should from Debian perspective live in different VCS trees. It took me I think more than three months to sort out things while I did work on python-opentelemetry to get all needed information for the packages I wanted to have and write into a proper control file. >> If so I suggest to also use this URL in the source package later. > > Yes, will definetely include this. > >> From what I can see here I'd guess you could mean this library you want >> to packge? >> >> https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/opentelemetry-instrumentation/pyproject.toml > > Yes, but not sure yet. Since this is a collection of pypi packages, I wanted to > open the ITP early. The Git tree contains a lot of the source for various libraries and packages. It takes time to understand how these different project are related to each other, if they are. :-) But I think this is somehow important to know to not fall into some trap later due version number constraints e.g as unfortunately also in this git tree various versions are used in these projects. Once you think you understand enough then you can dive into the Debian packaging as some maybe in the future introduced binary packages from the same source need get included into the build. I want to say that d/rules needs to get constructed flexible enough to get this later handled easily. Then start with the easiest to package project.