[02:56] <mwhudson> 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] <vorlon> mwhudson: hmm, won't be tonight
[02:57] <mwhudson> vorlon: sure :)
[02:58] <mwhudson> although https://github.com/r-lib/vctrs/issues/1353#issuecomment-814097160
[10:53] <apw> are we aware of sound issues (no sources listed in gnome-settings) with jammy today?
[11:29] <seb128> apw, no, could you share your recent apt log to see what changed?
[11:30] <apw> 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] <apw> likely we should make the transition request a reboot for sanity.
[11:31] <seb128> apw, not really, pipewire isn't supposed to take over sound. Likely you got pipewire-pulse installed by some recent upgrade?
[11:31] <seb128> which would be a bug
[11:32] <apw> i cirtainly have pipewire-pulse installed; it does at least work :)
[11:32] <seb128> apw, could you check the apt log to see if it was just pulled in for you?
[11:32] <seb128> or is that something you opted in to install before?
[11:34] <apw> seb128, it seems it was requested by the ubuntu-desktop^ task.
[11:35] <apw> i routinly install that after a large dist-upgrade to avoid losing thing necessary for reboot
[11:35] <apw> https://paste.ubuntu.com/p/xbrv4knXhk/
[11:35] <apw> seb128, ^
[11:37] <seb128> apw, thanks, it's basically http://bugs.debian.org/999363
[11:37] <seb128> 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] <apw> ahh so you don't see it in install testing, but only upgraders.  /me enjoys some dogfood.
[11:38] <seb128> indeed
[11:39] <seb128> 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] <apw> 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] <seb128> apw, anyway, the issue is tracked as part of bug #1949776 for us
[11:39] <apw> ack thank.
[11:40] <seb128> np, thank you for mentioning it, it's always useful to have issues reported
[13:39] <ijohnson[m]> 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] <slyon> ijohnson[m]: Yes, I will have a look later!
[13:54] <ijohnson[m]> thank you
[15:11] <seb128> 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] <bdmurray> seb128: Edit then change Status to Disabled should do the trick
[15:18] <seb128> bdmurray, ah, thanks, a bit confusing :)
[16:09] <schopin> 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] <vorlon> schopin: 'apt rdepends $soname'
[16:17] <vorlon> 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] <schopin> 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] <vorlon> schopin: ah - the approximation I use is checking whether it's currently in -proposed
[16:19] <vorlon> (the transition tracker is also written in ocaml, I avoid it whenever I can ;)
[16:19] <seb128> I was going to say, check if it's proposed and what is listing it on update_excuses
[16:28] <vorlon> schopin: here's my terrible script, if it would be useful to you: https://paste.ubuntu.com/p/vr5p2R62Xw/
[16:30] <schopin> thanks!
[16:32] <vorlon> (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] <teward> 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] <vorlon> schopin: now with those improvements: https://paste.ubuntu.com/p/WzRSFrpSCs/
[20:29] <vorlon> has anyone written an apt-bisect?  Would be useful...
[20:33] <bdmurray> I'm not certian I know exactly what you might but bryyce might have done something like what I think you mean
[20:33] <bdmurray> s/might/mean/
[20:33] <sarnold> 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] <vorlon> 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] <vorlon> bryyce: ?
[20:35] <vorlon> sarnold: in this case I would be happy just bisecting the set of packages selected for upgrade between the releases
[20:36] <vorlon> ... beacuse it doesn't make sense why *any* of the packages would have broken the build
[20:36] <sarnold> vorlon: oh! that's a different angle than I expected :) yeah that'd be useful.
[20:37] <vorlon> ok just confirmed it wasn't linux-libc-dev that broke it, phew
[20:38] <vorlon> 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] <bryyce> 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] <vorlon> good news, I reproduced the failure!  bad news, the set of packages I upgraded that triggered it are crazypants
[20:49] <bryyce> 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] <vorlon> and the winner is.... <drumroll>
[20:55] <vorlon> dpkg-dev
[20:56] <vorlon> a dpkg-dev upgrade results in a misbuild of python3-pypillowfight
[21:37] <vorlon> ... because LTO \o/
[21:38] <sarnold> oh boy oh boy :)
[21:49] <vorlon> 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] <lucas> vorlon: bisecting by timestamps using snapshot.debian.org works reasonably well (for Debian)
[21:50]  * vorlon nods
[21:54] <sarnold> there's a lto-disabled-list package that may need some updates: https://wiki.ubuntu.com/ToolChain/LTO
[21:56] <vorlon> 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] <sarnold> vorlon: aha
[22:01] <Eickmeyer[m]> Indeed. I have a couple of packages that require overrides on LTO (the upstream hates the very idea of LTO).
[23:00] <bryyce> dovecot has optimize=-lto, but the new version from debian fails its tests due to lto issues, even with that.
[23:03] <bryyce> 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] <vorlon> mwhudson: https://launchpad.net/ubuntu/+source/r-cran-vctrs/0.3.8-1ubuntu1 you made me write in R >_<
[23:33] <sarnold> that's the most R i've ever seen in one place before
[23:35] <vorlon> a worse language to google about than go
[23:36] <sarnold> oh my
[23:36] <vorlon> hmph, just found a bug in the patch, ohwell
[23:36] <vorlon> (the bug does not stop the tests from passing)