[09:40] <Fallen> Hey folks, if you need support on getting organized or community things while you adjust please do feel free to reach out to me and my team! Happy to help :)
[12:35] <RikMills> fw 5.103 is out
[12:36] <santa_> good morning everyone
[12:36] <santa_> RikMills: working on that, it's in the PPA for lunar, I'm adjusting some things at the moment
[12:38] <santa_> Fallen: hi there, nice to meet you, who are you and what is your team? I mean if try to google "canonical fallen" or "ubuntu fallen" I don't get good results XD
[12:41] <RikMills> santa_: https://launchpad.net/~kewisch
[12:42] <santa_> nice! thanks for the info
[12:44] <Fallen> Heh sorry I skipped the intro. Yes I work for Canonical and I am leading the community team there.
[14:26] <BluesKaj> Hi all
[14:26] <sgmoore[m]> hiyas
[14:28] <BluesKaj> hey sgmoore[m]
[18:54] <arraybolt3> Eickmeyer[m]: pipewire-pulse is an acceptable dependency in kubuntu-desktop as an alternative to pulseaudio in 22.04.1.
[18:54] <arraybolt3> I wonder if that somehow could cause the problem we're seeing in #kubuntu?
[18:55] <Eickmeyer[m]> arraybolt3: I'm having trouble figuring out how that's possible since seeds (from which kubuntu-desktop is derived) don't allow for alternate dependencies.
[18:56] <arraybolt3> apt-cache show kubuntu-desktop: https://termbin.com/9upg
[18:56] <Eickmeyer[m]> Weiiiird.
[18:57] <Eickmeyer[m]> Imma have to find the seed to see how that was done.
[18:58] <arraybolt3> I don't see anything that would cause the dependency to accidentally be satisfied by pipewire-pulse though, since it's not installed by default on the ISO, and the rdepends are rather sparse - it's unlikely something one would install after the fact would cause that.
[18:58] <arraybolt3> Perhaps something uninstalled kubuntu-desktop (removing default apps perhaps), and then something else went wonky to make it happen?
[18:58] <arraybolt3> Ikd.
[18:58] <arraybolt3> *Idk.
[18:59] <arraybolt3> (I guess Ikd could be "I kan't determine" :P)
[18:59] <Eickmeyer[m]> Or, the most obvious answer (occom's razor): they installed it while experimenting.
[18:59] <arraybolt3> That's more than likely.
[19:02] <RikMills> sounds likely
[19:03] <arraybolt3> Anyway, weird but not an issue atm it sounds like. I'm hungry, and want to get some fresh air, so I'll return and finish SRU verification later.
[19:03] <arraybolt3> (Assuming all goes according to plan.)
[20:25] <RikMills> 5.27.0 should be ready to upload on Tuesday
[20:25] <RikMills> though looks like there may be a tar respin or 2 in the meantime
[20:26] <RikMills> santa_: all in git
[20:27] <santa_> RikMills: thanks for the info, regarding frameworks it's build for lunar (testing right now) and building for kinetic
[20:27] <RikMills> kool
[20:27] <santa_> RikMills: regarding apps I think some need symbols updates and lunar builds in the PPA are broken
[20:28] <RikMills> I guess that is not surprising
[20:30] <santa_> the good news is that they are no FTBFS'es because of symbols not updated
[20:31] <RikMills> would be worrying if there were on a point release
[20:31] <RikMills> though saying that, toolchain changes could have happened
[20:31] <santa_> yeah
[20:31] <santa_> http://tritemio-watertown.duckdns.org:81/build-status/buildstatus_ubuntu-exp3/ubuntu-exp3_status_applications.html
[20:32] <santa_> the FTBFS'es there might be my-server-specific
[20:32] <santa_> the server above is one of the experimental ones
[20:32] <santa_> I still didn't have time to update the main one (groomlake)
[20:36] <RikMills> santa_: I don't see any FTBFS with apps in the archive. I just ran the retry script to see
[20:36] <santa_> as I guessed, let me have a look...
[20:37] <santa_> RikMills: both are tests failing, what do you think about disabling them?
[20:38] <santa_> I mean we know how autotests tend to fail in chroots and that kind of thing
[20:38] <santa_> I'm glad they finally learnt that the hard way in debian XD
[20:39] <RikMills> if you think more hassle than they are worth, then I have no objections
[20:39] <santa_> in general I do think they should be disabled in general
[20:40] <RikMills> we are the odd one out as a distro who runs some of them
[20:40] <santa_> usually when they fail it's not because the code is buggy, but because of the environment
[20:40] <RikMills> plus KDE now have better upstream test coverage
[20:40] <santa_> so you end up fixing the execution of the autotest
[20:40] <RikMills> indeed
[20:40] <santa_> yeah, also that
[20:41] <santa_> another thing that happens is that it makes some builds "unreliable"
[20:41] <santa_> i.e. sometimes they fail because of timeouts but not always
[20:41] <santa_> forcing you to rebuild to get rid of the spurious FTBFS
[20:42] <RikMills> yes, I have had to retry archive builds due to random fails a non trivial number of times
[20:44] <arraybolt3> I wonder how much compute power is wasted on needlessly failed autopkgtests.
[20:45] <RikMills> it keeps the data centre workers warm on a cold night :P
=== guiverc is now known as guiverc_d