== Meeting information ==

 * #ubuntu-meeting: Weekly Ubuntu Foundations team meeting, started by dbungert, 05 Sep at 15:02 — 15:54 UTC.
 * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-09-05-15.02.log.html



== Meeting summary ==

=== Lightning rounds ===

Discussion started by dbungert at 15:02.

 * ''LINK:'' https://discourse.ubuntu.com/t/foundations-team-updates-thursday-2024-09-05/47785/2   (dbungert, 15:02)

=== Release incoming bugs ===

Discussion started by dbungert at 15:11.

 * ''LINK:'' http://reports.qa.ubuntu.com/reports/rls-mgr/rls-oo-incoming-bug-tasks.html#foundations-bugs   (dbungert, 15:11)
 * ''LINK:'' https://bugs.launchpad.net/ubuntu/+bug/2078555   (dbungert, 15:15)
 * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078436   (dbungert, 15:20)
 * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078619   (dbungert, 15:24)
 * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/2078720   (dbungert, 15:32)
 * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078589   (dbungert, 15:36)
 * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078378   (dbungert, 15:38)

=== Team proposed-migration report ===

Discussion started by dbungert at 15:41.

 * ''LINK:'' https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses_by_team.html#foundations-bugs   (dbungert, 15:41)

=== AOB ===

Discussion started by dbungert at 15:52.




== People present (lines said) ==

 * vorlon (40)
 * juliank (36)
 * dbungert (30)
 * schopin (10)
 * enr0n (8)
 * ginggs (6)
 * bdrung (5)
 * adrien (3)
 * meetingology (2)
 * slyon (2)
 * ogayot (2)
 * r41k0u (2)
 * pushkarnk (2)
 * cpete (1)



== Full log ==


 15:02 <dbungert> #startmeeting Weekly Ubuntu Foundations team

 15:02 <meetingology> Meeting started at 15:02:17 UTC.  The chair is dbungert.  Information about MeetBot at https://wiki.ubuntu.com/meetingology

 15:02 <dbungert> #topic Lightning rounds

 15:02 <meetingology> Available commands: action, commands, idea, info, link, nick

 15:02 <dbungert> #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-2024-09-05/47785/2

 15:03 <juliank> oh thanks dbungert I'm in the u-r-u mantic->noble testing

 15:04 <dbungert> sure thing

 15:04 <slyon> o/

 15:06 <bdrung> i like the "Fun with flags" in ginggs report :D

 15:07 <ginggs> it wasn't much fun

 15:11 <dbungert> #topic Release incoming bugs

 15:11 <dbungert> #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-oo-incoming-bug-tasks.html#foundations-bugs

 15:11 <dbungert> LP: #2078449

 15:12 <enr0n> juliank: you opened that one

 15:13 <vorlon> I thought the current behavior is already that it doesn't upgrade

 15:13 <vorlon> it just doesn't explain why

 15:13 <vorlon> (I have a package on my system that I hold, and had to un-hold most recently for mantic->noble)

 15:13 <schopin> juliank: do you happen to have references to the 2 or 3 bugs mentioned?

 15:15 <dbungert> will tag it for investigation

 15:15 <adrien> he mentioned libpipewire-0.3-0t64 I think

 15:15 <dbungert> https://bugs.launchpad.net/ubuntu/+bug/2078555

 15:15 <juliank> Sorry

 15:15 <adrien> or maybe I mix things up, not entirely sure

 15:15 <juliank> schopin: I failed to record them

 15:16 <schopin> that's OK, I guess we can look through them manually.

 15:17 <vorlon> I think LP: #2078555 is wontfix.  systemd-resolved only binds to a specific address to allow for other local resolvers

 15:18 <schopin> Still, it feels like a bug that it re-enabled itself?

 15:18 <juliank> So I looked at it and we have a quirk to install it explciitöy

 15:18 <juliank> data/DistUpgrade.cfg.jammy

 15:18 <juliank> 37:PostUpgradeInstall=systemd-resolved

 15:19 <vorlon> it should be installed

 15:19 <vorlon> I guess if the correct package interfaces were used to disable it, and those didn't translate because of the move to a new package, that's a bug

 15:19 <vorlon> I don't think it's a high-priority bug tho

 15:19 <slyon> Right, we've had a bunch of bugreports where sd-resolved was missing (after it was split out as a separate package), I guess that's why we have the quirk now

 15:20 <dbungert> triaged-medium no foundations todo?

 15:20 <vorlon> ^ +1

 15:20 <dbungert> k

 15:20 <dbungert> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078436

 15:20 <juliank> Oh yeah because systemd is upgraded first and then systemd-resolved is installed, the old data is gone

 15:21 <juliank> So yes, about half of the upgrade bugs are people having newer versions of pipewire installed

 15:21 <juliank> Newer versions in 22.04 than available in noble

 15:21 <juliank> So if we do that it cuts down bug triage accordingly

 15:24 <dbungert> tagging todo

 15:24 <dbungert> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078619

 15:24 <schopin> Doesn't feel like a high-prio item either (although people doing u-r-u triage might disagree)

 15:26 <schopin> To put on the roadmap for 25.04?

 15:26 <enr0n> yeah that's another common issue. Seems like we could do better for sure.

 15:27 <dbungert> we're contending with similar mirror problems in subiquity, and looking at using mirror+ to help, maybe we want that here?

 15:27 <bdrung> Printing an error message to the user instead of crashing would be useful.

 15:27 <vorlon> 'mirror+'?

 15:27 <dbungert> apt-transport-mirror

 15:28 <ogayot> apt-transport-mirror (mirror+file:/)

 15:28 <juliank> mirror+file:/ is magic

 15:28 <cpete> hey ogayot I think we found a mirror to test

 15:28 <vorlon> I mistrust magic

 15:28 <dbungert> hah

 15:28 <juliank> Anyhow the question here is if we fail to set the mirror, should we just try archive.ubuntu.com

 15:28 <juliank> There is some fallback already, but it doesn't handle all cases

 15:29 <schopin> Here the mirror itself is stale, do we have the necessary data to detect that?

 15:29 <ogayot> cpete: I'll play around with it :)

 15:29 <bdrung> Probably better include the user here to allow them to pick a new mirror.

 15:29 <juliank> schopin: In the sense that it does not contain the new release, yes

 15:29 <vorlon> was this an official mirror at the time the user configured it?

 15:29 <schopin> Ah. Yes, of course -_-

 15:29 <juliank> For the other case, once my valid-until change lands we can enable it for -updates too

 15:29 <vorlon> or do they have a broken local mirror config

 15:29 <vorlon> I'm not sure I approve of more magic here in general

 15:30 <vorlon> trying to fall back to archive.u.c could also fail in the case of a corporate network; it's not like there's a guaranteed "fix"

 15:30 <juliank> It's still better than aborting and telling the user to file a bug

 15:30 <enr0n> hm good point, I can't remember off the top off my head if we check if the current mirror has been removed from the official mirror list

 15:31 <enr0n> but I see this with non-local mirrors often

 15:31 <vorlon> juliank: yes, we should not tell them to file a bug :)

 15:31 <juliank> In any case we need to do something

 15:31 <dbungert> tagging todo

 15:32 <juliank> We can just tell them to pick a new mirror if we don't find the base-files

 15:32 <dbungert> https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/2078720

 15:32 <juliank> Julian has fixes ready

 15:32 <juliank> I guess we don't need to tag it todo really

 15:33 <schopin> Is Julian talking about himself at the third person? :P

 15:34 <schopin> s/at/in

 15:34 <adrien> the cat is named Julian

 15:35 <vorlon> dbungert: ?

 15:35 <juliank> We are talking about ourselves in various persons

 15:36 <dbungert> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078589

 15:36 <juliank> This needs a long spike

 15:36 <juliank> This is breaking quite a bunch of kubuntu and ubuntu studio flavor upgrades

 15:38 <vorlon> so take it?

 15:38 <dbungert> tagging

 15:38 <juliank> Yes

 15:38 <dbungert> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2078378

 15:39 <schopin> do we have a repro for this?

 15:39 <juliank> The sources.list looked correct here

 15:39 <juliank> schopin: The tarball should reproduce it

 15:39 <enr0n> I think this is saying the mirror is out of date too

 15:40 <enr0n> hmm maybe not

 15:40 <juliank> No, we did not rewrite the jammy entry for some reason only jammy-updates

 15:40 <juliank> all of them exist on the mirror

 15:41 <juliank> But I did not investigate why it was only rewriting some

 15:41 <dbungert> think we should tag this one as well

 15:41 <juliank> +1

 15:41 <dbungert> I want to cut off there, for proposed-migration

 15:41 <dbungert> #topic Team proposed-migration report

 15:41 <dbungert> #link https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses_by_team.html#foundations-bugs

 15:41 <dbungert> vorlon:

 15:41 <juliank> We have like 3 packages

 15:42 <enr0n> fwiw, for the previous bug, it

 15:42 <vorlon> libselinux/libsemanage just waiting for ruby-defaults

 15:42 <enr0n> is because it's not an official mirror. So I guess there is logic for that

 15:42 <vorlon> setuptools, were these assigned out already?

 15:43 <vorlon> sl-modem uh cough

 15:45 <juliank> I wanted to ping tj aalton on this but got distracted by u-r-u

 15:46 <vorlon> setuptools vs guessit: r41k0u

 15:46 <vorlon> setuptools vs isodate: adrien

 15:46 <vorlon> setuptools vs macsyfinder still with chriscoulson

 15:47 <vorlon> setuptools vs mailman-hyperkitty with bdrung

 15:47 <vorlon> setuptools vs manuel with mwhudson

 15:47 <vorlon> setuptools vs prometheus-xmpp-alerts with tobhe

 15:47 <bdrung> setuptools should retry against the fixed mailman-hyperkitty that I uploaded

 15:47 <vorlon> setuptools vs pylint with andersson123

 15:48 <vorlon> setuptools vs python-mpegdash with rkratky

 15:48 <vorlon> setuptools vs stopit: I'll take

 15:48 <vorlon> setuptools vs python-svg.path: ginggs

 15:49 <ginggs> vorlon: are you reassigning some of these?

 15:49 <vorlon> ginggs: no just restating

 15:49 <vorlon> setuptools vs software-properties: this was created last week but is unassigned?

 15:49 <r41k0u> is setuptools vs guessit not done? - https://tracker.debian.org/news/1561888/accepted-guessit-380-3-source-into-unstable/

 15:49 <vorlon> so xypron

 15:49 <pushkarnk> I've got an MP up for setuptools vs python-svg.path

 15:49 <r41k0u> I think it is resolved by a debian sync

 15:50 <vorlon> r41k0u: unstable is not oracular-proposed, and it's only resolved once tests get rerun in Ubuntu showing that they now pass

 15:50 <vorlon> r41k0u: so this probably just needs tests rerun

 15:50 <bdrung> i'll have a look at the python-svg.path MP

 15:50 <ginggs> vorlon: juliank said there's already a card for software-properties

 15:50 <pushkarnk> thanks bdrung

 15:50 <vorlon> ginggs: yes but it was unassigned

 15:51 <ginggs> vorlon: no, another one.  juliank do you have it?

 15:51 <vorlon> finally, sl-modem vs dkms: mkukri

 15:52 <juliank> I do not have it yet I am focusing on upgrade bugs

 15:52 <vorlon> dbungert: that's all

 15:52 <vorlon> now who uploaded ubiquity, it's time to remove that package from oracular

 15:52 <dbungert> #topic AOB

 15:52 <ginggs> juliank: i mean the number of the jira card

 15:52 <juliank> yes I know

 15:52 <vorlon> waveform: ^^ please turn your ubiquity upload into a removal request :)

 15:53 <juliank> this is bug https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2077940

 15:53 <juliank> that maps to FR-8752

 15:54 <ginggs> juliank: thanks

 15:54 <dbungert> seems like we're done

 15:54 <dbungert> #endmeeting



Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)