[06:39] <Skuggen> rbasak: Do you have time to take a look at https://salsa.debian.org/mariadb-team/mysql/merge_requests/6 ?
[06:39] <Skuggen> tsimonq2: ^
[06:57] <rbasak> tsimonq2: it sounds fairly harmless to add a static lib. I don't know if any existing builds would change behaviour, but if not, it should be OK. What's missing from that bug though is a real explanation of _user_ impact.
[06:57] <rbasak> Skuggen: it's on my list. Sorry I haven't got to it yet
[06:58] <Skuggen> rbasak: Np. It's not a great rush, so if you have it on your list that's fine :)
[07:20] <cyphermox> bluesabre: oem-setup does that for oem sessions, you might want to look at the config written (it's in ubiquity source)
[07:55] <RAOF> cyphermox: Heeeeeeeey! You mentioned on https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/771805 that you were going to track it down soonish (in 2016 ☺). I don't suppose that you did track it down and just forgot to close the bug? :)
[08:03] <cyphermox> RAOF: ah, nope?
[08:03] <cyphermox> RAOF: are you saying it's still hanging in cosmic?
[08:06] <RAOF> cyphermox: I don't know; I've got a xenial system on this board and it hangs.
[08:06] <RAOF> (I'd be perfectly happy to install the cosmic package if that's likely to work, although it doesn't seem to have changed significantly since xenial)
[08:16] <cyphermox> ah, yes
[08:17] <cyphermox> RAOF: try it, there's some added arm64 support, that might help
[08:17] <RAOF> Well, this is an armhf board ☺
[08:17] <cyphermox> basically, when I looked at it, we needed ppc64el patching, and then I tried to fix armhf at the same time but it needed a gazillion extra patches
[08:17] <RAOF> But I'll try it, thanks.
[08:17] <cyphermox> yeah, but some was arm64 ;)
[08:17] <cyphermox> basiclaly, it was getting unwieldy for a SRU
[08:18] <cyphermox> I saw some patches that looked like they'd help, but also not really in a position to test it
[08:18] <cyphermox> alternatively, let's try to build from a recent git snapshot?
[08:19] <mwhudson> er i think armhf and arm64 are going to be pretty different if you're thinking at the level of ltrace
[08:19] <mwhudson> (and also i'd much rather work on the arm64 implementation myself :-p)
[08:20] <RAOF> cyphermox: No dice; cosmic package fails identically.
[08:20] <cyphermox> heh
[08:20] <cyphermox> looks like there's isn't a git up anymore
[08:21] <cyphermox> and maybe I'm wrong about git altogethr, because this seems like an original debian project :(
[08:21] <cyphermox> RAOF: anything I can help with re: debugging whatever you're debugging?
[08:22] <RAOF> cyphermox: I just want to get the set of calls this particular build of weston is making into libMali
[08:22] <cyphermox> ah
[08:22] <RAOF> cyphermox: And gdb is being unhelpful, and aaaaaargh.
[08:22] <cyphermox> RAOF: heh. I was under the impression ltrace was relying heavily on gdb things
[08:23] <RAOF> It's apparently all the `ptrace`, all the time.
[08:24] <cyphermox> ah
[08:24] <cyphermox> any luck with 'latrace' ?
[08:24] <mwhudson> well gdb is _also_ all ptrace all the time i guess
[08:25] <cyphermox> or maybe systemtap
[08:25] <RAOF> cyphermox: Nah, latrace segfaults as soon as it tries to do anything.
[08:25] <cyphermox> yay
[08:25] <Faux> (riir!)
[08:25] <RAOF> Embedded development is the best!
[08:26] <mwhudson> is systemtap any less awful than the last time i tried to use it?
[08:26] <cyphermox> heh, I thought I had something for systemtap already, but it would be more akin to strace anyway
[08:27] <cyphermox> mwhudson: depends, I've had some success in the very odd, infrequent cases I had gone through all other options with no luck and resorted to it
[08:27] <RAOF> printf debugging it is!
[08:27] <RAOF> (If I can actually build something that runs…)
[08:27] <cyphermox> RAOF: can you file a bug for your latrace segfault too?
[08:27] <sarnold> RAOF: woah woah woah.. that's a dastic step
[08:27] <sarnold> RAOF: if you don't mind out-of-archive, perhaps sysdig would suit you
[08:28] <sarnold> RAOF: maybe perf trace?
[08:28] <cyphermox> if we can fix one of the tools, at the very least the next people might have more luck :)
[08:28] <RAOF> cyphermox: Sure, although it may be a quirk of this board.
[08:28] <cyphermox> ack
[08:28] <cyphermox> well, I'm definitely no arm wizard
[08:38] <RAOF> cyphermox: Enjoy https://bugs.launchpad.net/ubuntu/+source/latrace/+bug/1793272
[09:06] <cyphermox> ta
[11:32] <rbasak> Skuggen: the merge looks good in itself, but there are some entries missing from debian/changelog - probably the ones that didn't get imported into our VCS tree?
[11:33] <rbasak> It might be easiest to fix it just by adding a commit to the end rather than redoing everything.
[11:33] <rbasak> Separately, should we perhaps note in the changelog that we're reverting a sync?
[11:37] <Skuggen> For the first, sure I can add those (5.7.22-0ubuntu18.04.1 and 5.7.23-0ubuntu0.18.0.4.1?)
[11:37] <rbasak> No the ones that landed in the development release only
[11:41] <Skuggen> Not entirely sure I know what you mean.
[11:41] <rbasak> In a meeting but I can do a HO with you in a bit?
[11:41] <Skuggen> Sure
[11:41] <rbasak> I'll ping when available. Hopefully within the next hour or so
[11:41] <Skuggen> I'm free from about 30 minutes from now
[12:01] <jamesh> robert_ancell: here's the details on the snapd-glib changes needed: https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1793298
[12:01] <robert_ancell> jamesh, ok
[12:38] <rbasak> Skuggen: I can be ready in five minutes if you are
[12:38] <Skuggen> Yup
[12:39] <rbasak> OK I'll find a corner
[12:41] <rbasak> Skuggen: corner found. I'm at the usual link