[02:56] vorlon: could you look at the r-cran-vctrs autopkgtest failures on s390x? i think that's all that's holding up a bunch of r stuff [02:56] * mwhudson gives it a retry to make sure it's still broken [02:57] mwhudson: hmm, won't be tonight [02:57] vorlon: sure :) [02:58] although https://github.com/r-lib/vctrs/issues/1353#issuecomment-814097160 [02:58] Issue 1353 in r-lib/vctrs "test-partial-factor fails on big-endian machines" [Open] [10:53] are we aware of sound issues (no sources listed in gnome-settings) with jammy today? [11:29] apw, no, could you share your recent apt log to see what changed? [11:30] seb128, seems that restarting the various daemons made the sources and sinks come back; so i assume this is an upgrade order issue [11:31] likely we should make the transition request a reboot for sanity. [11:31] apw, not really, pipewire isn't supposed to take over sound. Likely you got pipewire-pulse installed by some recent upgrade? [11:31] which would be a bug [11:32] i cirtainly have pipewire-pulse installed; it does at least work :) [11:32] apw, could you check the apt log to see if it was just pulled in for you? [11:32] or is that something you opted in to install before? [11:34] seb128, it seems it was requested by the ubuntu-desktop^ task. [11:35] i routinly install that after a large dist-upgrade to avoid losing thing necessary for reboot [11:35] https://paste.ubuntu.com/p/xbrv4knXhk/ [11:35] seb128, ^ [11:37] apw, thanks, it's basically http://bugs.debian.org/999363 [11:37] Debian bug 999363 in wireplumber "Shouldn't replace pulseaudio by pipewire by default" [Normal, Open] [11:37] apw, I though we wouldn't be impacted yet since wireplumber is still in universe but that's enabled for most users upgrading [11:38] ahh so you don't see it in install testing, but only upgraders. /me enjoys some dogfood. [11:38] indeed [11:39] also new install would probably work from an user perspective because you don't have the issue of having the sound server changing under you from pulseaudio to pipewire in a session [11:39] well i guess i get to test pipewire-pulse as a thing for a bit; other than the upgrade being "poor", the experience audio wise is ok [11:39] apw, anyway, the issue is tracked as part of bug #1949776 for us [11:39] Bug 1949776 in wireplumber (Ubuntu) "[MIR] wireplumber" [Undecided, Incomplete] https://launchpad.net/bugs/1949776 [11:39] ack thank. [11:40] np, thank you for mentioning it, it's always useful to have issues reported [13:39] slyon: hey when you have a chance could you take a look at this netplan + ubuntu core related problem on the forum: https://forum.snapcraft.io/t/ubuntu-core-20-boot-delayed-by-missing-wi-fi-usb-dongle-despite-optional-true-netplan-config/27403/1 [13:50] ijohnson[m]: Yes, I will have a look later! [13:54] thank you [15:11] bdmurray, hey, iso tracker question, how does one delete a testcase from a testsuite? example, http://iso.qa.ubuntu.com/admin/config/services/qatracker/testsuites/410/edit , I want to remove the live session test from that set [15:17] seb128: Edit then change Status to Disabled should do the trick [15:18] bdmurray, ah, thanks, a bit confusing :) [16:09] Is there an easy way to know if a package is involved in a transition? I'm looking into merging libxmlb, which bumped soname, meaning a small transition (3 rdeps), but I'd like to make sure that this wouldn't conflict with other stuff. [16:16] schopin: 'apt rdepends $soname' [16:17] I also have a 'misc-transition-script' here that I should clean up and publish, its --dry-run mode would be useful for this [16:18] That much I have, yes. I was more thinking of something akin to the mention on tracker.debian.org which displays if a package is part of a planned transition. [16:18] schopin: ah - the approximation I use is checking whether it's currently in -proposed [16:19] (the transition tracker is also written in ocaml, I avoid it whenever I can ;) [16:19] I was going to say, check if it's proposed and what is listing it on update_excuses [16:28] schopin: here's my terrible script, if it would be useful to you: https://paste.ubuntu.com/p/vr5p2R62Xw/ [16:30] thanks! [16:32] (needs improvement: auto-detect the devel release; take a list of package exclusions as commandline arguments; take a changelog override as commandline argument; then I would push it somewhere public and maintained) [16:45] ddstreet: fyi i'm still wanting to backport vmfs6-tools because its needed in 18.04. but i'm maintianer for that in Debian too so [17:01] schopin: now with those improvements: https://paste.ubuntu.com/p/WzRSFrpSCs/ === genii-core is now known as genii [20:29] has anyone written an apt-bisect? Would be useful... [20:33] I'm not certian I know exactly what you might but bryyce might have done something like what I think you mean [20:33] s/might/mean/ [20:33] you could probably get there with an aptly mirror or snapshots.debian.org without too much trouble. given how quickly ubuntu reaps replaced packages off the mirrors I think it'd be pretty hard to do over here [20:34] bdmurray: libpillowfight/amd64 has some kind of misbuild; the last good binary was built in the middle of the hirsute release; building it on released hirsute fails, building it on released groovy succeeds - bisect the apt dist-upgrade [20:34] bryyce: ? [20:35] sarnold: in this case I would be happy just bisecting the set of packages selected for upgrade between the releases [20:36] ... beacuse it doesn't make sense why *any* of the packages would have broken the build [20:36] vorlon: oh! that's a different angle than I expected :) yeah that'd be useful. [20:37] ok just confirmed it wasn't linux-libc-dev that broke it, phew [20:38] at this point I'm assuming what's going to happen is I'm going to upgrade ALL of the packages on top of groovy and it's still going to rebuild successfully [20:48] vorlon, I do have a menagerie of scripts for the ppa transition but alas no equivalent of an apt-bisect which does sound handy [20:49] good news, I reproduced the failure! bad news, the set of packages I upgraded that triggered it are crazypants [20:49] I'd also love a cli to generate a listing of packages involved in a transition ala the transition tracker, although I find the tracker's list is more of a starting point; there's more packages involved than that [20:55] and the winner is.... [20:55] dpkg-dev [20:56] a dpkg-dev upgrade results in a misbuild of python3-pypillowfight [21:37] ... because LTO \o/ [21:38] oh boy oh boy :) [21:49] doko: so libpillowfight regresses on amd64 due to LTO, only detected at runtime by the autopkgtests. Aside from turning off LTO in the package build, what do you want done with this? [21:50] vorlon: bisecting by timestamps using snapshot.debian.org works reasonably well (for Debian) [21:50] * vorlon nods [21:54] there's a lto-disabled-list package that may need some updates: https://wiki.ubuntu.com/ToolChain/LTO [21:56] sarnold: my understanding from doko's email to the list is this was a temporary measure to be superseded by per-package overrides anyway [21:57] vorlon: aha [22:01] Indeed. I have a couple of packages that require overrides on LTO (the upstream hates the very idea of LTO). [23:00] dovecot has optimize=-lto, but the new version from debian fails its tests due to lto issues, even with that. [23:03] in this case, looks like the dovecot maintainers enabled it (adding -flto), as it worked with gcc 10. Doesn't work with gcc 11 though. [23:31] mwhudson: https://launchpad.net/ubuntu/+source/r-cran-vctrs/0.3.8-1ubuntu1 you made me write in R >_< [23:33] that's the most R i've ever seen in one place before [23:35] a worse language to google about than go [23:36] oh my [23:36] hmph, just found a bug in the patch, ohwell [23:36] (the bug does not stop the tests from passing) === genii is now known as genii-core