[09:48:52] GitLab needs a short maintenance restart at 11:00 UTC [10:57:22] Out for lunch [11:07:45] GitLab maintenance done [12:04:17] gerrit needs a short maintenance reboot now as well [12:35:21] question for the debian developers around, what would be the best way of asking debian packagers of golang-github-confluentinc-confluent-kafka-go-dev to update it to match librdkafka version? [12:36:25] as an example, in bullseye we got librdkafka 1.6.0 but golang-github-confluentinc-confluent-kafka-go-dev 0.11.6, in bookworm we got librdkafka 2.0.2 but still golang-github-confluentinc-confluent-kafka-go-dev 0.11.6 and so on.. [12:41:56] vgutierrez: open a bug report asking for the version to be updated, and/or email the debian-go list [12:42:08] thx [14:42:41] <_joe_> vgutierrez: my take is to vendor all your dependencies and stop using the golang source packages [14:43:32] <_joe_> that's at least what I always do, including librdkafka.so if it talks to kafka, nowadays :) [14:44:06] <_joe_> the debian golang ecosystem is just debian refusing to acknowledge that statically linked binaries are a thing and they'd need different tooling to manage them [14:47:15] +1 to all of the above...do we make our own prometheus packages? It would probably be good to roll one for node-exporter [14:49:24] newer versions have a lot more stats...would be nice for dashboards [14:52:16] second this [14:54:29] <_joe_> that's not what I was talking about though :) [14:56:11] to avoid the mess, that's mostly the way to go. To fix a security vulnerability quickly and easily, no. [14:56:34] <_joe_> akosiaris: except it's not useful even for that [14:57:01] <_joe_> say you need to fix a dependency, you still need to go rebuild every software that build-depends on your library [14:57:23] <_joe_> you could instead keep a record without forcing everything in the debian package model [14:57:24] for static linking? yup. For dynamic linking, all you need are restarts [14:57:48] <_joe_> ah yes, but golang is statically linked (well, at least for golang libraries) [14:58:02] btw, I love to compare static linking and vendor with the npm model [14:58:14] oh wait, why do I have 10 copies of lib X ? [14:58:19] <_joe_> "model" [14:58:29] <_joe_> I think npm's stuff mostly happened [14:58:46] static linking and vendor were a thing btw. Even in Debian [14:58:50] decades ago ofc [14:58:53] <_joe_> 'model' kind of implies an intelligent design :) [14:59:17] <_joe_> uh when was that? I probably didn't care about it at the time [14:59:24] good point :-) [14:59:56] I think that the zlib debacle was the undoing of all of that, but we are talking 2001? 2002? Maybe 2004. I 'll have to dig [15:00:27] I distinctly remember FreeBSD 4.x being statically linked and FreeBSD 5.x being dynamically linked [15:00:34] boy that upgrade was fun [15:00:36] NOT [15:09:20] vgutierrez: heads up, I 'll revert the /api/ change on ATS, per https://phabricator.wikimedia.org/T364400#10123233 there is unfortunately no consensus yet (it did appear easy enough on paper). Change is https://gerrit.wikimedia.org/r/c/operations/puppet/+/1071229 [15:10:33] akosiaris: ok [15:13:49] godog: so we got all the reboots done for hosts that needed it because nftables switch. except the durum hosts. I would normally talk at least briefly to sukhe about them, but he is out. How urgent would you rate this? good enough if we check after weekend, given it's only durum now? [15:14:38] mutante: Thanks for the reboots! As for the durum hosts, I think it's okay to wait as we'll do the failover next week. [15:14:58] denisse: thanks, i will make sure to follow-up and have it on my list [15:21:19] mutante: Awesome, thank you! :)