[07:13] <juliank> Eickmeyer: I don't think that's the right level to fix this, tbh
[07:13] <juliank> Eickmeyer: Reading the bug, there seems to be an issue in gio wrt detecting online presence
[08:25] <schopin> juliank: since you volunteered yesterday, care to sponsor LP: #1943109 ? :-)
[08:28] <juliank> schopin: on it
[08:28] <schopin> Thanks!
[08:32] <juliank> schopin: uploaded
[08:33] <schopin> thank you very much.
[08:35] <schopin> ... and I forgot to add the LP number in the changelog. Oh well.
[12:06] <icey> I'm a bit stuck diagnosing a C build failure - I'm getting an `undefined refeernce to` a function that does, in fact, exist, and it exists in the source tree I'm in. afaict, the build is correct and using the upstream build parameters but I'm running out of steam digging
[12:11] <cjwatson> Is the relevant object being passed to the linker?
[12:35] <mapreri> paride: yes, we haven't fixed policies and rules and process currently, unexpectedly just dealing with the administrative bits took a whole hour.  better wait for now.
[12:36] <mapreri> % listadmin backports
[12:36] <mapreri> fetching data for ubuntu-backports@lists.ubuntu.com ...
[12:36] <mapreri> [1/2121] [12:36] <mapreri> ...
[12:36] <mapreri> ddstreet: I think I'm very much not going to go through 2k+ pending mails.  I'll look at those received in 2021 (they are only 30) and discard everything else.
[12:37] <mapreri> (there are mails from 2013 stuck in that mod queue)
[12:38] <ddstreet> mapreri definitely, anything older surely isn't still relevant
[12:40] <mapreri> so apparently only 1 good mail in the queue from July 2021, due to not being subscribed, but I see that the sender realized it: https://lists.ubuntu.com/archives/ubuntu-backports/2021-July/021758.html  - so I suppose I'll just throw everything to /dev/null.
[12:43] <icey> cjwatson: I think so? I see `-lsqlite3` in the `cc` invocation; what's more concerning to me about this is that I don't think the build steps have changed (upstream's Makefile) but I'm seeing this failure
[12:44] <cjwatson> icey: On the linker command line, does the -lsqlite3 come before or after the objects that have references to it?
[12:45] <icey> cjwatson: I don't see any linked specific command line; in the `cc` invocation (thing before ld starts complaining), I the -lsqlite3 is right at the end, so after
[12:47] <icey> s/linked/linker
[12:50] <cjwatson> (cc is acting as the linker in this case)
[12:50] <cjwatson> I think I'd need to see the full build
[12:50] <icey> cjwatson: https://launchpad.net/ubuntu/+source/fossil/1:2.16-3/+build/21757434
[12:51] <icey> cjwatson: picked that one up from excuses yesterday and still haven't figured out what's up; not enough C experience methings
[12:51] <icey> methinks
[13:16] <cjwatson> icey: According to sqlite.h, those symbols are only available if sqlite3 is configured using the SQLITE_ENABLE_DESERIALIZE option, and it would appear that the packaged version of sqlite3 isn't.
[13:17] <cjwatson> icey: fossil has an internal vendored copy of sqlite, and debian/rules is set up to use it depending on what version of the system library is available, so that could be related
[13:17] <icey> cjwatson: the source tree for this project includes sqlite.h and sqlite.c directly though?
[13:17] <icey> ah
[13:17] <cjwatson> icey: It might be worth checking previous builds to see whether it used the internal copy or whether it used -lsqlite3 (i.e. the system copy) instead
[13:18] <cjwatson> icey: Either that or the uses of sqlite3_{serialize,deserialize} were only added recently
[13:18] <cjwatson> (I haven't checked)
[13:22] <icey> cjwatson: well, it looks like the last passing build also had `-lsqlite3`
[13:24] <cjwatson> icey: If you look at http://launchpadlibrarian.net/546994450/fossil_1%3A2.15.2-1_1%3A2.16-2.diff.gz, it seems to introduce calls to sqlite3_{serialize,deserialize}
[13:24] <cjwatson> icey: So I guess that 2.16 needs this facility where 2.15.2 didn't
[13:25] <icey> cjwatson: yeah :-/
[13:27] <cjwatson> icey: Also, fossil 2.16 requires sqlite >= 3.35.0 (according to ./configure --print-minimum-sqlite-version), and compare https://tracker.debian.org/pkg/fossil and https://tracker.debian.org/pkg/sqlite3
[13:27] <cjwatson> icey: When the Debian maintainer uploaded fossil most recently, sqlite3 in unstable was still 3.34.1
[13:27] <cjwatson> icey: So I suspect if you run a test build in unstable, you'll find that it similarly fails to build there, and then you can file a Debian bug
[13:32] <icey> cjwatson: I'll try to figure out that next then, thanks!
[13:33] <cjwatson> np, interesting digging exercise
[13:47] <icey> cjwatson: annoyingly, even if I add `-DSQLITE_ENABLE_DESERIALIZE`, the build fails (although in a different place) :-/
[13:49] <icey> rather, enable that and use the local sqlite
[16:35] <schopin> Looking for a sponsor for bionic and focal SRUs for scilab. LP: #1870813
[16:46] <bdmurray> schopin: I can do that
[16:50] <bdmurray> schopin: don't forget update-maintainer
[16:55] <xypron> golang-1.16 - 1.16.7-1ubuntu2 is available in ppa:xypron/golang. I am looking for a sponsor.
[18:56] <Eickmeyer> juliank: Even the packagekit maintainers see it as a trivial/sane fix.
[18:57] <Eickmeyer> juliank: They asked me for a pull request, so it will be upstream in a matter of hours.
[18:57] <Eickmeyer> juliank: Moreso, I can confirm that it fixes the issue 100%.
[18:57] <Eickmeyer> Go home, ubottu, you're drunk.
[18:58] <cjwatson> I mean it's 1900Z on a Friday, it has an excuse
[18:58] <Eickmeyer> Fair, cjwatson. HAHAHA
[19:01] <Eickmeyer> juliank: See https://github.com/PackageKit/PackageKit/issues/336#issuecomment-916666713
[19:02] <juliank> Eickmeyer: I'm on my weekend but this looks reasoable
[19:02] <Eickmeyer> juliank: Cool. Enjoy your weekend. :)
[19:02]  * juliank goes disable IRC notification on his wrist
[19:03] <Eickmeyer> Good call. :)
[19:03] <Eickmeyer> I'm US West Coast, so our times don't always line-up.
[21:01] <Eickmeyer> Is syncpackage crashing for anyone else?
[21:07] <RikMills> Eickmeyer: just worked for me
[21:07] <GunnarHj> Eickmeyer: Haven't tried recently. But I just discovered that I can't access update_excuses with latest FF. Wonder if those issues may be related.
[21:08] <Eickmeyer> RikMills: I had to sign-in to a focal VM to make it work.
[21:08] <Eickmeyer> GunnarHj: Could be, I just reported a hard crash I had from it.
[21:08] <Eickmeyer> bug 1943286
[21:10] <sarnold> GunnarHj: I understand an apache process wasn't restarted when a certificate on people was replaced; try again, it should work
[21:12] <GunnarHj> sarnold: You're right, works now. Thx.
[21:12] <RikMills> Eickmeyer: yeah, I was using a focal machine
[21:14] <Eickmeyer> Actually, it's working again, so it must've had to do with apache like sarnold said.  Either way, it should fail more gracefully than a hard crash.
[21:15] <sarnold> Eickmeyer: ah cool I wondered if those were related. it felt pretty plausible..
[21:16] <Eickmeyer> It turned out to be correct. That said, the script shouldn't fail the way it failed, so I'm not closing the bug.