[02:33] <RAOF> Ok, I need some help for https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995
[02:33] <RAOF> Who's good for ppc64 toolchain-esque bugs?
[02:33] <ubottu> Launchpad bug 1934995 in umockdev (Ubuntu) "Broken on ppc64el (toolchain bug?)" [Undecided, New]
[02:48] <mwhudson> RAOF: probably me or doko these days
[02:51] <mwhudson> RAOF: "A umockdev build with the versions that hirsute's 0.15.4-1 built with." seems incomplete, i assume that should end "still crashes"?
[02:52]  * RAOF checks.
[02:52] <RAOF> Hm, yes.
[02:53] <RAOF> I built a umockdev package using the versions of binutils, gcc, and vala found in https://launchpadlibrarian.net/515322542/buildlog_ubuntu-hirsute-ppc64el.umockdev_0.15.4-1_BUILDING.txt.gz
[02:54] <RAOF> The umockdev from that package also crashes.
[02:54] <mwhudson> RAOF: i don't suppose you have a command line to invoke that crashes?
[02:54] <mwhudson> as in, some way of starting in with gdb?
[02:54] <mwhudson> i'm running a build in canonistack
[02:54] <RAOF> I can
[02:54] <mwhudson> but that will take a while
[02:54] <RAOF> I wonder if I can share my canonistack instance with you?
[02:55] <mwhudson> yeah just ssh-import-id i think
[02:55] <mwhudson> i don't think we have any fancy per-user security groups
[02:56] <RAOF> umockdev-run bin/mir_umock_unit_tests will hit it.
[02:57] <RAOF> Your launchpad SSH key should have access to ubuntu@10.48.129.58 now.
[02:57] <mwhudson> i am in
[02:58] <RAOF> There's a byobu session with a built Mir tree and umockdev build.
[02:58] <RAOF> (In a hirsute schroot)
[02:58] <mwhudson> er how do i join a byobu session? i only know screen
[02:59] <RAOF> Just run byobu
[02:59] <mwhudson> ah got it
[03:02] <mwhudson> RAOF: ah heh so need to get an old gdb deb from somewhere?
[03:03] <RAOF> Maybe!
[03:03] <RAOF> Could also just upgrade everything and fix the brokenness.
[03:03] <RAOF> Oh, huh. This is an impish chroot.
[03:04] <RAOF> Forgot what I was doing last :)
[03:04] <mwhudson> RAOF: yeah maybe just upgrading everything makes sense
[03:05] <mwhudson> RAOF: if that's not going to lose state that would be annoying to recover?
[03:05] <RAOF> Nah.
[03:06] <RAOF> The built-with-the-working-build's-umockdev .debs are still in there for testing, as are all the relevant gcc, binutils, and vala debs :)
[03:09] <mwhudson> RAOF: meep
[03:10] <RAOF> Yes!
[03:16] <mwhudson> RAOF: have you tried using liblttng-ust0 from the last passing test?
[03:16] <RAOF> Presumably something has been corrupted before we hit this point, but valgrind doesn't complain about any out-of-bounds writes until the stack smashing.
[03:17] <RAOF> I think this is the liblttng-ust0 from the last passing test?
[03:17]  * RAOF double-checks.
[03:18] <RAOF> Oh, yeah, it definitely is. LTTNG hasn't been rebuilt in impish, and mir 2.4.0-0ubuntu2 built and ran its tests fine in impish.
[03:21] <mwhudson> RAOF: so what has changed since things worked? glibc?
[03:22] <mwhudson> but only in minor ways
[03:22] <RAOF> umockdev got rebuilt.
[03:22] <RAOF> (Or, rather, umockdev 0.16.something was built in impish)
[03:22] <mwhudson> there's always the LTO bogeyman
[03:22] <RAOF> If you install umockdev 0.15.4-1 from the hirsute archives, it works.
[03:22] <mwhudson> hmmmm
[03:23] <mwhudson> have you tried a build of umockdev without lto yet?
[03:23] <RAOF> I have not, no.
[03:23] <mwhudson> ... i wonder when that became the default
[03:23] <RAOF> That seems a sensible next step!
[03:23] <RAOF> If it was about half-way through the hirsute cycle that would be an excellent candidate.
[03:24] <mwhudson> seems it was just before release
[03:25] <mwhudson> which seems a bit crazy so maybe it was earlier
[03:25] <RAOF> Odd time to turn it on, but sure.
[03:25] <RAOF> That tracks; as I say, rebuilding umockdev in hirsute release results in a umockdev that crashes in this way.
[03:26] <mwhudson> yeah definitely worth a try
[03:26] <mwhudson> i wouldn't mind keeping the schroot i'm currently poking around in though
[03:46] <RAOF> If you can walk me through adding storage to a canonistack instance I can make that happen :)
[03:46] <RAOF> But I'm not sure the disc is big enough to handle a second schroot.
[03:46] <RAOF> Hm. Yes. The working version of umockdev was built prior to LTO by-default.
[03:46] <RAOF> (Or, at least, the 0.15.4-1 buildlog does not contain any references to lto, and the 0.16.1-1 buildlog does)
[03:48] <mwhudson> grr why can i only run the failing command once in each gdb session?
[03:51] <RAOF> Because it's a wrapper that tests some environment variables and then exec()s the real thing.
[03:51] <RAOF> mwhudson: As that's getting annoying for you, you can export the relevant environment variables (I *think* LD_LIBRARY_PATH is the only one relevant for this test?) and then run bin/mir_umock_unit_tests.bin
[03:52] <RAOF> mwhudson: You're after `export LD_LIBRARY_PATH=/root/mir-2.4.1/build-ppc64el/bin/../lib`, I believe.
[03:53] <mwhudson> RAOF: ah yes
[03:58] <RAOF> It's a bit of a panda's thumb.
[04:03] <mwhudson> so i don't remember the ppc64el abi inside and out but it sure looks like the open in libumockdev-preload is doing very bad things
[04:03] <mwhudson> like saving non-volatile registers way outside its stack frame
[04:04] <RAOF> Huh.
[04:04] <RAOF> I wonder why valgrind didn't pick that up?
[04:05]  * mwhudson drowns in preprocessor
[04:08] <mwhudson> https://paste.ubuntu.com/p/BSNKBGrSHZ/
[04:09] <mwhudson> no wait what is this doing
[04:09] <mwhudson> it's writing r5 to r10 to crazy locations but they're not non-volatile registers
[04:10] <mwhudson> ah no that's the parameter save area
[04:10] <mwhudson> aaaaaaaaaah
[04:11] <mwhudson> RAOF: i think it's because mir's declaration for real_open does not match that of umockdev
[04:11] <mwhudson>     int (*real_open)(char const *path, int flags, mode_t mode);
[04:12] <mwhudson> vs (const char *path, int flags, ...) for umockdev
[04:12] <RAOF> Oh, no! va_args!
[04:13] <mwhudson> i'm not completely sure that's the problem
[04:14] <mwhudson> yeah i bet it is
[04:15] <RAOF> Well, this should be quick to test!
[04:17] <RAOF> mwhudson: Can I quit your gdb session to test that change?
[04:18] <mwhudson> RAOF: i think i just quit the schroot in fact but yes
[04:18] <mwhudson> ah i'll stop typing :)
[04:18] <mwhudson> how do i disconnect?
[04:19] <RAOF> F12 d
[04:19] <RAOF> By default.
[04:19] <mwhudson> ok
[04:19] <mwhudson> i'm out
[04:19] <mwhudson> RAOF: btw i have no idea how this ever worked :-)
[04:19] <RAOF> The best sort of bugs!
[04:20] <mwhudson> a schrödinbug
[04:21] <RAOF> It's been perfectly happy with this code for the last 3 years :)
[04:22] <mwhudson> how does open(2) manage to have an optional argument anyway??
[04:22] <RAOF> 🤷‍♀️
[04:26] <mwhudson> oh the protoype has va_args
[04:27] <mwhudson> so yeah mir's needs to too
[04:29] <mwhudson> RAOF: you'll need to fix the open64 wrapper too, not sure about the others
[04:29] <mwhudson> anyway i must vanish in a puff of childcare obligations
[04:29] <RAOF> Sweet.
[04:29] <RAOF> Enjoy!
[04:29] <RAOF> Thanks very much.
[07:39] <egorenar> Hi all, i'm working on a new stand-alone dump concept for IBM z Architecture on Ubuntu (and other distros) and my idea is to use the dracut package to build an initramfs image for the dumper. This is similar to how kdump tooling works. That would make the package s390-tools (in particular the zipl tool) depend on the dracut package. I was told to ask on this channel whether you see any problem with that. Furthermore, i would like to
[07:39] <egorenar> know whether the dracut package will continue to be supported on Ubuntu in the future ? Thank you very much.
[07:48] <ricotz> juliank, hi :), fwupd-signed did not bump its build-dep as mentioned in the changelog and therefore is not installable -- https://launchpad.net/ubuntu/+source/fwupd-signed/1.27.1ubuntu4
[07:48] <juliank> ricotz: yes, I know
[07:49] <ricotz> alrighty :)
[07:56] <schopin> bdmurray: re openssl, I was pinging the uploader to hirsute-proposed to understand what was going on with the previous upload and how to... coordinate, I guess? In any case, we're good, but I'm still in need of a sponsor :)
[08:44] <rbasak> egorenar: in Ubuntu we wouldn't be able to carry a dracut dependency on s390-tools without further work, since s390-tools is in main but dracut is in universe. I'm fairly sure we don't use dracut for initramfs images on Ubuntu.
[09:34] <mwhudson> we do not use dracut by default for sure
[09:51] <egorenar> rbasak: dracut would be just a soft dependency for s390-tools, we would have a helper script in s390-tools that calls dracut, and if it's not installed then you can't use the new stand-alone dump, that's all. but there would be no hard dependency on dracut. I know that Ubuntu uses initramfs-tools for building initramfs images.
[09:52] <egorenar> The reason we are trying to go with dracut because it is supported on all distros that Linux Z targets.
[09:58] <egorenar> Other alternatives we considered would mean a lot more effort to maintain custom initramfs scripts and tools to build the required images for the dumper.
[09:59] <egorenar> With dracut, we just need to provide a small custom module, uniform for all distros.
[10:04] <rbasak> egorenar: I don't see an issue there then, but wouldn't it be difficult for Ubuntu users to switch to dracut to make use of this feature?
[10:07] <egorenar> maybe we misunderstand each other :) Ubuntu users don't have use dracut to build *regular* initramfs, to use the new dump feature, Ubuntu users just need to install dracut, that's all. we don't want to change any initramfs tooling Ubuntu already using.
[10:08] <rbasak> Sounds fine to me :)
[10:08] <egorenar> great :) and dracut will be supported for a long time ? no plans to remove it ?
[10:11] <rbasak> What do you mean by "supported"?
[10:11] <rbasak> dracut is in universe so relies entirely on community support. It is autosynced from Debian.
[10:11] <rbasak> In general packages aren't removed from Ubuntu as long as they exist in Debian, unless they cause problems.
[10:15] <egorenar> ok, thanks for clarifying
[11:21] <GunnarHj> Hi vorlon! Can you please take a look at bug #1937922. Should gtk4 be added to the list of packages which are built on i386?
[11:21] <ubottu> Bug 1937922 in ibus (Ubuntu) "gtk4 not built for i386" [Undecided, New] https://launchpad.net/bugs/1937922
[11:37] <laney> autopkgtest [12:36:34]: ERROR: "dpkg --unpack /tmp/autopkgtest.N3wyHj/2-autopkgtest-satdep.deb" failed with stderr "dpkg-deb: error: archive '/tmp/autopkgtest.N3wyHj/2-autopkgtest-satdep.deb' uses unknown compression for member 'control.tar.zst', giving up
[11:37] <laney> blerp
[11:37] <laney> did we break running debian autopkgtests from ubuntu
=== genii-core is now known as genii
[15:24] <vorlon> GunnarHj: what will reference gtk4 that is currently in the i386 set?
[15:24] <vorlon> (or, will anything)
[16:03] <GunnarHj> vorlon: Don't know. It's rather about build-deps in ibus. Or do you indicate that we should skip the build of ibus-gtk4 when building for i386? Can that be done without creating a permanent Ubuntu/Debian delta?
[16:08] <schopin> Anyone willing to sponsor an openssl upload to impish? THis is bug #1931994 which will be SRUed if all goes well, but first Impish :).
[23:03] <bdmurray> dbungert, jawn-smith: here is an example of hint MP https://code.launchpad.net/~ginggs/britney/+git/britney/+merge/405912
[23:04] <jawn-smith> thanks bdmurray
[23:08] <bdmurray> there are also branches for stable releases
=== genii is now known as genii-core