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.