Mentioned in SAL (#wikimedia-operations) [2024-11-08T08:05:53Z] <XioNoX> add gnmic 0.39 from official git repo to bookworm reprepro - T347461

Completion was announced in Tech News: 2024-24.
Thank you very much for processing

Upgraded the package all clean now on db1179.

Mentioned in SAL (#wikimedia-operations) [2024-07-22T10:33:08Z] <volans> upgraded manually prometheus-ipmi-exporter to v 1.8.0-1~wmf12+1 on db1179 (leftover because was down) T368088

I'm getting failures for this change on db1179:

level=info msg="Starting ipmi_exporter" version="(version=1.6.1, branch=debian/sid, revision=1.6.1-2+b5)"
level=error msg="Error parsing config file" error="invalid collector: sel-events"

Change #1054649 had a related patch set uploaded (by Herron; author: Herron):

[operations/alerts@master] ipmi-sel: create task on critical ipmi sel events

https://gerrit.wikimedia.org/r/1054649

Change #1051207 merged by Herron:

[operations/puppet@production] prom-ipmi-exporter: add sel-events collector

https://gerrit.wikimedia.org/r/1051207

Mentioned in SAL (#wikimedia-operations) [2024-07-15T18:04:15Z] <herron> upgraded prometheus-ipmi-exporter to 1.8.0 T368088

Thanks @aborrero indeed ! I added the packages to bookworm-wikimedia on the APT repo and linked to that task from the Ganeti doc in case we need to redo it.

https://wikitech.wikimedia.org/w/index.php?title=Ganeti&diff=2204519&oldid=2203166

If we go for the direct upload to reprepro please let's create a Wikitech page explaining the procedure, so we can have a way to redo it in the future (if needed).

hey @ayounsi, I have reviewed the .deb packages that you built. They LGTM. I even installed them on my laptop :-P So from my point of view, you have a +1 to put them on reprepro.

A one-off would be good enough for us, as we especially need the few latest commits. I agree we shouldn't "own" it as it's not a critical part of our infra.

We have a number of WMF SREs who have uploading rights to Debian (who could, assuming the existing maintainer isn't opposed, upload a new version), be that as a one-off or as a desire to have WMF take over the packaging for a while. It's really a question of how much effort we feel we want to spend on looking after this package (which may in turn relate to how important it is / how much work we'll need to do if Debian's version continues to not get updated).

I am in favor of spending time to update the Debian's version, but reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985047 doesn't give a lot of hope (the package seems somehow abandoned?). We could upload a new version using a sponsor, but not sure if any of us has the commitment to maintain it longer term.

Is this important enough for us that we should think about spending WMF time on updating the version in Debian?

I'm not familiar with Debian packaging, but I guess it depends on how much time it takes (now and in the future). Is it better to spend time updating the Debian version or maintaining our own?
There is also a small component about "giving back" to the community.

Is this important enough for us that we should think about spending WMF time on updating the version in Debian?
[honest question]

Keeping archives happy - on IRC we discussed the use case and dgit could be a good fit in my opinion (until Debian upstream publishes the new version.

Change #1051207 had a related patch set uploaded (by Herron; author: Herron):

[operations/puppet@production] prom-ipmi-exporter: add sel-events collector

https://gerrit.wikimedia.org/r/1051207

Buster is looking fine with this deb as well. So I've gone ahead and uploaded 1.8.0 to bookworm-wikimedia, bullseye-wikimedia, and buster-wikimedia. Up next is a small canary upgrade before fully rolling out.

Indeed, CGO_ENABLED=0 rings a bell.

Nice, thanks for the pointer! It looks like export CGO_ENABLED=0 does the right thing. At least, with this set the package builds and installs successfully on my bullseye test host.

The dependency is added because some feature in the compiled Go code uses syscalls which were only wired up in 2.34 (maybe openat() at al). We ran into this problem before and there was a Go build flag to force it to use a fallback. I can't find a reference currently, but maybe Filippo remembers when he's back.

In T368088#9917836, @MoritzMuehlenhoff wrote:

Given that this is a Go static ELF we can also simply build on bookworm and copy over the deb to bullseye-wikimedia, we're doing this for other exporters as well. buster might be tricky due to it's old libc6, but we can also ignore it, there's less than 150 hosts left and they can simply live the old IPMI monitoring.

Given that this is a Go static ELF we can also simply build on bookworm and copy over the deb to bullseye-wikimedia, we're doing this for other exporters as well. buster might be tricky due to it's old libc6, but we can also ignore it, there's less than 150 hosts left and they can simply live the old IPMI monitoring.

Suggested wording for tech news:

Resolving for now, following up in related issues.

We are using Thumbor on bullseye everywhere which means that SVGs will be rendered by 2.50.3. Keeping this task open for tracking issues for the moment.

We have established that with the system of separate component we introduced a few years ago. Marking as resolved.

@Reedy is it still valid?