=== TheMaster is now known as Unit193 === cpaelzer_ is now known as cpaelzer [06:39] rbasak: Do you have time to take a look at https://salsa.debian.org/mariadb-team/mysql/merge_requests/6 ? [06:39] tsimonq2: ^ [06:57] 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] Skuggen: it's on my list. Sorry I haven't got to it yet [06:58] rbasak: Np. It's not a great rush, so if you have it on your list that's fine :) [07:20] bluesabre: oem-setup does that for oem sessions, you might want to look at the config written (it's in ubiquity source) [07:55] 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? :) [07:55] Launchpad bug 771805 in ltrace (Ubuntu) "[armel/armhf] ltrace hangs" [Medium,Triaged] [08:03] RAOF: ah, nope? [08:03] RAOF: are you saying it's still hanging in cosmic? [08:06] cyphermox: I don't know; I've got a xenial system on this board and it hangs. [08:06] (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] ah, yes [08:17] RAOF: try it, there's some added arm64 support, that might help [08:17] Well, this is an armhf board ☺ [08:17] 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] But I'll try it, thanks. [08:17] yeah, but some was arm64 ;) [08:17] basiclaly, it was getting unwieldy for a SRU [08:18] I saw some patches that looked like they'd help, but also not really in a position to test it [08:18] alternatively, let's try to build from a recent git snapshot? [08:19] er i think armhf and arm64 are going to be pretty different if you're thinking at the level of ltrace [08:19] (and also i'd much rather work on the arm64 implementation myself :-p) [08:20] cyphermox: No dice; cosmic package fails identically. [08:20] heh [08:20] looks like there's isn't a git up anymore [08:21] and maybe I'm wrong about git altogethr, because this seems like an original debian project :( [08:21] RAOF: anything I can help with re: debugging whatever you're debugging? [08:22] cyphermox: I just want to get the set of calls this particular build of weston is making into libMali [08:22] ah [08:22] cyphermox: And gdb is being unhelpful, and aaaaaargh. [08:22] RAOF: heh. I was under the impression ltrace was relying heavily on gdb things [08:23] It's apparently all the `ptrace`, all the time. [08:24] ah [08:24] any luck with 'latrace' ? [08:24] well gdb is _also_ all ptrace all the time i guess [08:25] or maybe systemtap [08:25] cyphermox: Nah, latrace segfaults as soon as it tries to do anything. [08:25] yay [08:25] (riir!) [08:25] Embedded development is the best! [08:26] is systemtap any less awful than the last time i tried to use it? [08:26] heh, I thought I had something for systemtap already, but it would be more akin to strace anyway [08:27] 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] printf debugging it is! [08:27] (If I can actually build something that runs…) [08:27] RAOF: can you file a bug for your latrace segfault too? [08:27] RAOF: woah woah woah.. that's a dastic step [08:27] RAOF: if you don't mind out-of-archive, perhaps sysdig would suit you [08:28] RAOF: maybe perf trace? [08:28] if we can fix one of the tools, at the very least the next people might have more luck :) [08:28] cyphermox: Sure, although it may be a quirk of this board. [08:28] ack [08:28] well, I'm definitely no arm wizard [08:38] cyphermox: Enjoy https://bugs.launchpad.net/ubuntu/+source/latrace/+bug/1793272 [08:38] Launchpad bug 1793272 in latrace (Ubuntu) "latrace segfaults on armhf" [Undecided,New] [09:06] ta === pitti is now known as deputy-github-bo === deputy-github-bo is now known as pitti [11:32] 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] It might be easiest to fix it just by adding a commit to the end rather than redoing everything. [11:33] Separately, should we perhaps note in the changelog that we're reverting a sync? [11:37] 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] No the ones that landed in the development release only [11:41] Not entirely sure I know what you mean. [11:41] In a meeting but I can do a HO with you in a bit? [11:41] Sure [11:41] I'll ping when available. Hopefully within the next hour or so [11:41] I'm free from about 30 minutes from now [12:01] robert_ancell: here's the details on the snapd-glib changes needed: https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1793298 [12:01] Launchpad bug 1793298 in snapd-glib (Ubuntu) "snapd-glib changes needed for pulseaudio snap policy module xenial backport" [Undecided,New] [12:01] jamesh, ok [12:38] Skuggen: I can be ready in five minutes if you are [12:38] Yup [12:39] OK I'll find a corner [12:41] Skuggen: corner found. I'm at the usual link === Foxhoundz is now known as BenderRodriguez === gpunk is now known as gpunk-away === gpunk-away is now known as gpunk === cpaelzer_ is now known as cpaelzer