[01:53] sarnold: yeah that's not giving me warm fuzzies === popey0 is now known as popey [08:43] Hi all. Has any foundation's team members got a short cycle avail to review our (ubuntu budgie) ubiquity slideshow update please for kinetic? https://code.launchpad.net/~fossfreedom/ubiquity-slideshow-ubuntu/kinetic/+merge/430170 === nomad1 is now known as nomad_fr [14:06] I am looking for a core dev to sponsor bug 1990578, which resolves a socat FTBFS from the kinetic test rebuild [14:06] Bug 1990578 in socat (Ubuntu) "FTBFS due to syntax error in test.sh" [Medium, New] https://launchpad.net/bugs/1990578 [15:32] enr0n: did you find out what caused it to fail now, whereas it worked before? [15:41] Ah, looks like newer bash rejects it at definition time, whereas before it was a runtime syntax error only. [15:46] rbasak: Yes I figured it was the change to bash 5.2. I can add that additional context to the LP [15:47] No worries - I noted it in the bug. [15:47] Sponsored - thanks! [15:55] rbasak: Great, thank you! [16:08] nteodosio: do you know if the firefox snap is good to go yet? [16:09] bdmurray: It has already been merged: https://github.com/canonical/firefox-snap/pull/5 [16:09] Pull 5 in canonical/firefox-snap "Stage hunspell instead of depending on content snap" [Merged] [16:11] nteodosio: Okay, do you know if there is a new version of the snap with that change? I'd like to try and build the ISOs again [16:13] bdmurray: We have https://launchpad.net/~nteodosio/+snap/firefox-stable/+build/1888438, though it includes the copyright files, which amount to an extra 8 MB according to osomon. [16:14] I'll start a new build presently in any case. [16:54] bdmurray: Ah, he already started a build, and it will be automatically published to candidate once successfully completed. https://launchpad.net/~mozilla-snaps/firefox/+snap/firefox-snap-stable/+build/1889553 [16:58] bdmurray: That is the Arm64 one actually, Amd64 and Armhf are already in candidate. [19:07] W: Ignoring non-equal Provides for package ubuntustudio-wallpapers-jammy in ubuntustudio-wallpapers-kinetic:all=22.10.2 [19:07] In kinetic [19:08] juliank: Fixed in new upload. My bad. [19:08] Ack [19:08] I have hourly edos-distcheck run which caught it [19:09] Yeah, vorlon caught it to and told me I'm apt-spamming everybody and their dog, cat, and chicken. (not quite, but I got the hint). [19:09] is this working as intended? https://www.irccloud.com/pastebin/yaJrAXF7/ https://www.irccloud.com/pastebin/jOniaqEC/ or something kinda off here? [19:10] sarnold: vorlon pulled the update an hour or so ago [19:10] aha, thanks [19:10] sarnold: I've just rolled back the grub2-{un,}signed SRU, we caught a bug report about it; this is again about apt misbehavior with phased-updates [19:10] sarnold: bug in the apt solver triggered by phasing [19:10] It's actually reverse of the other buh [19:10] And my fix for that doesn't work here [19:11] oh fun! reversi! card played [19:11] though this isn't an apt crash, so I'm not sure we can actually "fix" this short of having phased-update groups [19:11] There's a spec for that [19:11] But I don't think we need groups anymore [19:11] Just fix the solvet [19:11] I think anything less than groups is a wrong solution that undermines the intent of phasing [19:12] the intent of having both grub2-signed binaries and grub2-unsigned binaries phased to 10% is that 10% of users get the update [19:12] Well it's a side effect that it will always phase to the lowest phasing if multiple updates are phasing and have dependens [19:13] "biletto but for installs"? [19:13] Ah without groups it's 10%*10% or 1% of users seeing it [19:13] and any apt side solution that doesn't group these two sources together and use the same key for calculating whether they should be installed, will result in something other than 10% of users getting the packages installed [19:13] yes, exactly [19:13] Well sort of, not exactly [19:13] Either how need to fix the solver bug too [19:14] It did not consider grub-efi-arm64 broken, so it did not keep it back [19:14] * vorlon nods [19:15] in any case, I think based on the above we should maybe re-publish grub after all [19:15] But that would have been needed to unbreak the kept back -signed one [19:15] We can presumably publish everything except signed but can't be sure [19:16] or, could just publish grub2-unsigned with phasing to 100% [19:16] since nobody should have -unsigned && ! -signed installed [19:17] There's some worry it would remove the signed package [19:17] hmm [19:17] if a user ran apt dist-upgrade and didn't pay attention to the output yes [19:17] ok I'll park it as-is until Monday [19:18] Though did we make shim-signed Protected: yes? Then the chain to -signed is pseudo-protected [19:18] yes we did [19:19] regardless, I'm sticking with leaving this as-is until Monday so we're not causing fires after Europe EOW [19:45] < timeless> sarnold: so, do i need to uninstall this update? [19:46] I haven't got a clue what to tell my friend [19:49] sarnold: what update was installed? [19:49] sarnold: the error message is about the update failing to install and getting an apt message [19:50] vorlon: he needed some of the other updates so he forced the thing https://www.irccloud.com/pastebin/UBSqbT6U/ [19:50] sarnold: ok that's fine [19:50] there are no known regressions in the update itself, this is just an issue with the apt resolver [19:51] cool, thanks [19:52] there are various ways one might force it that would be bad for your bootability [19:52] but that one's ok [19:53] heh yeah I've seen far too many dist-upgrades remove *vital* stuff... but two interacting grub packages is foreign to me and I hadn't heard if the update itself had problems [21:53] dbungert: I updated the description of bug 1990552 [21:53] Bug 1990552 in apport (Ubuntu) "update apport's package installation failure hook to gather a new file" [Undecided, New] https://launchpad.net/bugs/1990552 [21:53] thanks!