| 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 :) | 09:40 |
|---|---|---|
| RikMills | fw 5.103 is out | 12:35 |
| 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:36 |
| 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:38 |
| RikMills | santa_: https://launchpad.net/~kewisch | 12:41 |
| santa_ | nice! thanks for the info | 12:42 |
| Fallen | Heh sorry I skipped the intro. Yes I work for Canonical and I am leading the community team there. | 12:44 |
| BluesKaj | Hi all | 14:26 |
| sgmoore[m] | hiyas | 14:26 |
| BluesKaj | hey sgmoore[m] | 14:28 |
| 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:54 |
| 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:55 |
| arraybolt3 | apt-cache show kubuntu-desktop: https://termbin.com/9upg | 18:56 |
| Eickmeyer[m] | Weiiiird. | 18:56 |
| Eickmeyer[m] | Imma have to find the seed to see how that was done. | 18:57 |
| 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:58 |
| 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. | 18:59 |
| RikMills | sounds likely | 19:02 |
| 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.) | 19:03 |
| 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:25 |
| RikMills | santa_: all in git | 20:26 |
| 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:27 |
| RikMills | I guess that is not surprising | 20:28 |
| santa_ | the good news is that they are no FTBFS'es because of symbols not updated | 20:30 |
| 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:31 |
| 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:32 |
| 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:36 |
| santa_ | RikMills: both are tests failing, what do you think about disabling them? | 20:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| RikMills | yes, I have had to retry archive builds due to random fails a non trivial number of times | 20:42 |
| arraybolt3 | I wonder how much compute power is wasted on needlessly failed autopkgtests. | 20:44 |
| RikMills | it keeps the data centre workers warm on a cold night :P | 20:45 |
| === guiverc is now known as guiverc_d | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!