Hi! On Mon, 2025-01-27 at 17:07:52 +0100, Daniel Swarbrick wrote: > On Thu, 16 Jan 2025 11:52:03 +0100 Jérôme Warnier <jwarn...@beeznest.net> > wrote: > > Any news about this? > > I would be interested in packaging this too, including contributing to > > your effort.
Sorry, was working on all required dependencies, then got stuck at the end because the latest upstream version was not even working with any of the latest upstream dependencies, which were staged for a transition by Reinhard Tartler (on CC), but do not have the details fresh in my mind and would need to recheck IRC logs, but I'd say we should just go ahead and then deal with the fallout. I think this specific problem might now be fixed in the newer upstream releases for its dependencies (AFAIR from when I looked into it at the time, which they fixed way after they had done the breaking changes in the dependencies), but have not had time to look into this again. Was planning to work on this last week and this week, but part of my time went into dealing with the workflow stuff. > This looks like yet another nightmarish CNCF monorepo package with extremely > enthusiastic git tagging habits. Yes. > I just tried packaging 0.108.1-1 as indicated by this ITP, and found that it > failed to build due to what is probably a breaking change in one of the > other otel dependencies (which seems to be the case with literally every > release). > > src/go.opentelemetry.io/collector/service/telemetry/tracer.go:59:15: cannot > use attributes(set, cfg) (value of type map[string]interface{}) as > []config.AttributeNameValue value in struct literal > # go.opentelemetry.io/collector/service/internal/proctelemetry > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:189:39: > undefined: config.MetricExporter > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:196:64: > undefined: config.MetricExporter > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:238:9: > invalid argument: otlpConfig.Endpoint (variable of type *string) for > built-in len > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:239:51: > cannot use otlpConfig.Endpoint (variable of type *string) as string value in > argument to normalizeEndpoint > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:263:50: > cannot use otlpConfig.Headers (variable of type > []config.NameStringValuePair) as map[string]string value in argument to > otlpmetricgrpc.WithHeaders > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:284:9: > invalid argument: otlpConfig.Endpoint (variable of type *string) for > built-in len > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:285:51: > cannot use otlpConfig.Endpoint (variable of type *string) as string value in > argument to normalizeEndpoint > src/go.opentelemetry.io/collector/service/internal/proctelemetry/config.go:312:50: > cannot use otlpConfig.Headers (variable of type > []config.NameStringValuePair) as map[string]string value in argument to > otlpmetrichttp.WithHeaders > > When the upstream developers break the API so often, I can kinda see why > they favour monorepos. I don't think I've ever seen another project with > such frequent breaking changes listed in their release notes. However, it > still seems that the three or four main otel repos are extremely tightly > coupled in terms of required version, which is going to be quite a headache. > So much for semantic versioning... > > I suspect that the otel/collector package might need to target a slightly > newer release, in order to be compatible with the other main dependencies, > i.e. opentelemetry-contrib and opentelemetry-otel. I'll try to refresh my memory on what was the state of this from some months ago, as this is a required dependency for both Prometheus and VictoriaMetrics. Thanks, Guillem