[10:01:31] if I build on bullseye-backports or sid the resulting deb will depend on a too new glibc for buster :/ [10:53:12] taavi: you can try dropping ${shlibs:Depends}, from the list of depends https://salsa.debian.org/b4ldr/golang-github-cloudflare-cfssl/-/commit/fb1c738ecfb01cbfa99f3f1a486c07ed797a8276. as long as there is no cgo making use of more modern syscalls i think it should be fine. [11:01:20] taavi: what dependency do you get? also what are you trying to achieve exactly ? [11:07:38] I want a karma deb that works on buster and includes https://github.com/prymitive/karma/commit/7e5571e13597438f43f7d22da714f0d8de7e71b3 [11:10:04] importing upstream 0.94 and building on sid gives me a "Depends: libc6 (>= 2.32)", and I'd imagine I'd get a similar result (too new libc6 dependency) if I build a patched version of the current 0.90 on bullseye-backports [11:11:08] ack, yeah I haven't tried building > 0.90 yet [11:11:27] haven't got such a strict dependency heh, I'm wondering why [11:14:06] godog, taavi: i think this is just comming from dh_shlibs blindly adding a dependency to the libc version it is using to build instead of the actull libc version required. im gussing the above is built on side and if build on bullseye you would get a dependency on libc6 2.31 [11:15:02] and as said unless the the package (or dependency) is using some cgo functions released in libc6 2.32 https://sourceware.org/pipermail/libc-announce/2020/000029.html it will probably just work [11:15:49] jbond: heh what's confusing to me is that the dependency should be the minimum required for the symbols used, or at least that's been my experience in the past [11:16:02] that said i would be happy for a cleaner fix as well, as we also hit this with golang-cfssl [11:17:27] taavi: do you have a .dsc for 0.94 handy I can try build ? [11:21:38] https://phabricator.wikimedia.org/P18400 is the resulting .dsc file when try to build locally, not sure if it helps or if I should push my changes to the git repo somewhere [11:22:53] taavi: err, sorry I should have been more specific: the .dsc and the resulting files karma_0.94.orig.tar.gz karma_0.94-1.debian.tar.xz [11:23:03] godog: ack i you are right, and have just tested and the cfssl packages depend on 2.28 even when built with bullseye [11:24:19] https://people.wikimedia.org/~taavi/karma_0.94-1/ [11:24:44] jbond: ack, yeah I'll take a look now [11:24:50] to karma that is, thanks taavi [11:25:29] godog: please let me know the results as i will need to make a cleaner fix to the cfssl packages [11:25:47] jbond: for sure -- will do [11:25:52] thx [11:26:06] trying to use the resulting .deb on buster fails with "/usr/bin/karma: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/karma)" [11:44:52] godog: fyi i did some digging on cfssl and see thet the symbol causing issues was fcntl64 which lead me to https://stackoverflow.com/questions/58472958/how-to-force-linkage-to-older-libc-fcntl-instead-of-fcntl64 [11:48:10] jbond: interesting, thank you I didn't know [11:48:13] that'd explain [11:57:32] jbond taavi I think building on bullseye-backports with golang-1.17 ought to work [11:57:52] i.e. get a libc6 dependency that's compatible with buster [12:03:57] godog: did you mean buster-backports and golang 1.15? [12:14:47] jbond: in karma's case IIRC it won't work with golang 1.15, no I meant 1.17 [12:18:34] godog: i think im a bit lost :), do you mean we should backport golang 1.17 from bullseye-backports to buster then build on buster. i.e. if we just build on bullseye with bullseye-backports we will still not have the correct libc? [12:22:09] now my next question is to figure out how to build packages with backports enabled :/ [12:22:51] taavi: if buildnig on deneb you can use BACKPORT=yes [12:23:18] I don't have access to deneb [12:27:46] ahh ok :( [12:29:17] jbond: I mean building on bullseye-backports with golang-1.17 (no backports needed), that'll get a dependency on libc6 2.3.2 [12:29:42] gotta go to lunch now [13:35:46] building on bullseye-backports finally worked! https://gerrit.wikimedia.org/r/c/operations/debs/karma/+/751743/ is what I ended up going with [13:45:59] taavi: neat! glad you got it working, I built your 0.94 package too on bullseye-backports by depending on golang-1.17, feel free to send a patch for that too -- we'll need to upgrade karma anyways at some point [13:51:01] I don't think Gerrit will like me if I send the hunders of upstream commits for review [13:53:19] so I pushed them to https://gitlab.wikimedia.org/taavi/karma [13:54:30] taavi: nice, thank you, I'm filing a task to upgrade karma as the next best thing since I don't have time atm [13:54:50] yeah no worries, thank you for your help [13:57:10] not sure if you have a need for karma acls in production, but at least I need them for my cloud vps prometheus project [14:12:08] not atm but it is good to keep up with karma upstream anyways [15:50:29] https://phabricator.wikimedia.org/T298619 [15:50:32] this is a 'fun' one :) [16:12:34] hah! 'fun' indeed, the once a year fun [17:35:47] has anyone here tried https://github.com/albertodonato/query-exporter or something simlar (converting generic sql queries into grafana metricts)