* Package name    : python-opentelemetry-contrib
  Version         : 0.65b0
  Upstream Contact: cncf-opentelemetry-contributors@lists.cncf.io
* URL             : https://opentelemetry.io/
* License         : Apache 2.0
  Programming Lang: Python
  Description     : The Python auto-instrumentation libraries for OpenTelemetry

A software layer that adds OpenTelemetry instrumentation to a service without
modifying the source code for that service.

Some of the instrumentation python packages are a dependency for python-mcp
2.0.0, which is a dependency for home assistant.

I will try to build at least some binaries in this source package in function
of home assistant, but propose to bring this under the Debian Python team since
this should be usefull for other purposes than home assistant.

Hello Peter,

Am 10.08.26 um 17:23 schrieb Pieter Lenaerts:

the description is very generic. And I struggle to find the upstream
source based on your information and the also very generic Upstream URL
that reflects the Opentelemetry Project in general.

Do you mean one or more packages from

https://github.com/open-telemetry/opentelemetry-python-contrib ?

If so I suggest to also use this URL in the source package later.
 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

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.

Yes, will definetely include this.

Yes, but not sure yet. Since this is a collection of pypi packages, I wanted to
open the ITP early.

Thanks for reaching out and reviewing/checking this early.

Br,

Pieter

Hello Pieter,

Am 10.08.26 um 20:05 schrieb Pieter Lenaerts:

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.

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.

Thanks for the advice. This kind of stuff is exactly why I wanted to open the
ITP before I really got into d/control and d/rules.

I will take this slow and I'll see where this takes me.

I will come back for advice once I know more.

Thanks again!

Pieter