== Meeting information ==

 * #ubuntu-meeting: Weekly Ubuntu Foundations team meeting, started by juliank, 17 Oct at 15:00 — 15:46 UTC.
 * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-10-17-15.00.log.html



== Meeting summary ==

=== Lightning rounds ===

Discussion started by juliank at 15:01.

 * ''LINK:'' https://discourse.ubuntu.com/t/foundations-team-updates-thursday-2024-10-17/   (juliank, 15:01)

=== Release incoming bugs ===

Discussion started by juliank at 15:13.

 * ''LINK:'' http://reports.qa.ubuntu.com/reports/rls-mgr/rls-oo-incoming-bug-tasks.html#foundations-bugs   (juliank, 15:13)
 * ''LINK:'' http://reports.qa.ubuntu.com/reports/rls-mgr/rls-nn-incoming-bug-tasks.html#foundations-bugs   (juliank, 15:23)
 * ''LINK:'' http://reports.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs&ia=web   (juliank, 15:37)

=== Team proposed-migration report ===

Discussion started by juliank at 15:44.


=== AOB ===

Discussion started by juliank at 15:44.




== People present (lines said) ==

 * juliank (101)
 * enr0n (22)
 * slyon (8)
 * bdrung (7)
 * liushuyu (4)
 * Skia (4)
 * upils (3)
 * mkukri (3)
 * adrien (3)
 * meetingology (2)
 * dbungert (2)
 * vorlon (2)
 * ginggs (1)
 * zhsj (1)
 * mateus-morais (1)
 * ravikant_ (1)
 * pushkarnk (1)
 * ogayot (1)
 * andersson123 (1)
 * waveform (1)



== Full log ==


 15:00 <juliank> #startmeeting Weekly Ubuntu Foundations team

 15:00 <meetingology> Meeting started at 15:00:54 UTC.  The chair is juliank.  Information about MeetBot at https://wiki.ubuntu.com/meetingology

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

 15:01 <juliank> #topic Lightning rounds

 15:01 <juliank> #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-2024-10-17/

 15:01 <ginggs> o/

 15:01 <zhsj> o/

 15:01 <mateus-morais> o/

 15:01 <ravikant_> o/

 15:01 <upils> o/

 15:02 <pushkarnk> \o

 15:02 <ogayot> o/

 15:02 <mkukri> o/

 15:03 <bdrung> \o

 15:03 <andersson123> o/

 15:04 <mkukri> what are we using LLVM-18 in focal for? that backport is scary

 15:04 <liushuyu> mkukri: two words: Firefox Thunderbird

 15:04 <adrien> \o

 15:04 <mkukri> ah ic that explains it

 15:07 <juliank> fwiw I'm working on accessing the reports.qa.ubuntu.com but I'm timing out so far

 15:07 <juliank> But it might be trying https only for now

 15:07 <juliank> Obviously my firefox is set https-only, and the site doesn't have https

 15:08 <Skia> juliank: working fine with http

 15:08 <juliank> But _normally_ there should be a fallback button once it fails to upgrade

 15:08 <Skia> I'll probably see to enable https this cycle, but sadly won't hack that right now :-)

 15:08 <dbungert> In my report I have a stack overflow link where I had to tweak hsts to get the sponsoring report to load

 15:09 <juliank> I'll restart my firefox

 15:09 <bdrung> i need to find some time to figure out how to setup letsencrypt with juju

 15:10 <bdrung> for the sponsoring report

 15:11 <juliank> Oh yes

 15:11 <juliank> dbungert: Thanks

 15:12 <juliank> So I guess it turns out ubuntu.com enabled HSTS for all *.ubuntu.com

 15:12 <juliank> So it's not possible to visit the reports after having been to the web page once

 15:13 <juliank> #topic Release incoming bugs

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

 15:13 <Skia> there isn't HSTS on autopkgtest.ubuntu.com, so no

 15:13 <liushuyu> You can try w3m instead

 15:13 <adrien> works for me

 15:13 <juliank> It works now after clearing all ubuntu.com data in firefox

 15:13 <dbungert> Skia: I had to remove the inherited value for ubuntu.com

 15:13 <upils> There is already a bug in http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-pp-incoming-bug-tasks.html#foundations-bugs :)

 15:13 <Skia> oh, okay, I see what you meant now

 15:13 <juliank> bug 2084208

 15:14 <waveform> afraid that report really doesn't work in w3m ... too much js  :)

 15:14 <juliank> upils: Sigh it's too early!

 15:14 <juliank> That sounds striaght forward and awkward

 15:14 <juliank> Let's just take it

 15:14 <slyon> upils: we've been kicking that down the road for a while :)

 15:15 <upils> oh yeah!

 15:15 <juliank> bug 2083942

 15:15 <juliank> I believe we should take that too

 15:15 <enr0n> juliank: should we just block upgrades if esm is enabled in that case?

 15:15 <enr0n> sorry, I don't think we concluded the previous bug

 15:16 <juliank> enr0n: We probably need to remove the sources and justu pgrade

 15:17 <enr0n> juliank: hm, I don't have a great understanding of how the ESM stuff works, but it seems to me that this might be unexpected for users

 15:17 <juliank> enr0n: there is no esm for interim releases so the expectation is for it to be disabled again

 15:18 <juliank> Otherwise youc an't upgrade

 15:18 <enr0n> juliank: right, I am just wondering if this should be made clear to users who might not realize that. Just a y/n prompt

 15:18 <juliank> Or you can prompt I suppose

 15:18 <enr0n> this feels like a product-y question

 15:18 <juliank> Or we could publish empty ESM repositories for non-LTS, shrug

 15:19 <juliank> That's a question for the Pro team

 15:19 <enr0n> anyways, we can move on I think

 15:20 <juliank> Yes

 15:20 <juliank> so snaps, should we  refresh them all during release upgrade?

 15:20 <enr0n> They should get refreshed on reboot, and we prompt for reboot

 15:21 <enr0n> We used to actually do the refresh during upgrades, but that caused bugs in some cases, so we changed the logic to do the channel switch if needed

 15:21 <enr0n> And let the next refresh do the work

 15:21 <juliank> You are saying all  snaps are refreshed at boot?

 15:21 <enr0n> My understanding was that snapd had some logic for this, yes

 15:21 <enr0n> But I am not 100% sure actually

 15:21 <juliank> Well let's add a snapd task

 15:23 <juliank> #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-nn-incoming-bug-tasks.html#foundations-bugs

 15:23 <juliank> bug 2041518 is still with desktop

 15:23 <juliank> bug 2078579

 15:24 <juliank> This is one of those awkward deep deives

 15:25 <juliank> I can't quite think about that; we need to dive deeper but we don't want to spend a week debugging the solver for this either

 15:26 <juliank> Let's move on for now

 15:26 <juliank> bug 2081323

 15:26 <juliank> So we had a discussion about a similar issue vorlon but here we have a local mirror that does not work *but* an ESM archive enabled, so it still believes there was a mirror and doesn't produce useful messages or something

 15:27 <juliank> 2024-09-20 17:57:28,720 ERROR No 'ubuntu-minimal' available/downloadable after sources.list rewrite+update

 15:27 <juliank> 2024-09-20 17:57:28,720 ERROR 'ubuntu-minimal' was not downloadable

 15:27 <juliank> This is not really helpful for the user

 15:27 <juliank> And I *think* without ESM it would use archive.ubuntu.com because it sees no official Ubuntu source?

 15:28 <vorlon> (I don't recall a similar issue I was involved in fwiw)

 15:28 <enr0n> yeah,if the esm archive was not present (i.e. no valid sourcec found) that should be the fallback

 15:28 <juliank> vorlon: well to be fair it was like 2-3 months ago :D

 15:28 <enr0n> FWIW I think --allow-third-party or whatever also allows local mirrors

 15:28 <juliank> yeah

 15:29 <juliank> So we should take this, improve the error message and special case "only ESM is a valid source"

 15:29 <enr0n> ack

 15:30 <juliank> bug 2083068

 15:30 <juliank> glib2.0 is shared so we could take this

 15:30 <vorlon> juliank: I remember stuff around broken local mirrors but not about esm being enabled :)

 15:31 <juliank> I'll go take the glib2.0 I guess, desktop did not seem interested :D

 15:32 <juliank> And I assigned it myself to, I need to re-validate the fix

 15:32 <juliank> bug 2083575

 15:32 <juliank> enr0n: this is funny

 15:32 <enr0n> looking

 15:33 <juliank> I guess we should abort the upgrade or install ubuntu-minimal first

 15:33 <juliank> Or except KeyError: print("blah")

 15:33 <enr0n> what in the

 15:34 <slyon> but original sources should always be restored, I guess

 15:34 <slyon> (on failure)

 15:34 <juliank> yeah

 15:34 <juliank> but if you don't have ubuntu-minimal installed, the check fails if all mirrors are disabled

 15:34 <juliank> if you have ubuntu-minimal installed, an ubuntu-minimal is around even with empty sources.list

 15:34 <juliank> without it, there is none, and the cache lookup we do fails :D

 15:35 <juliank> Like I said, this is very funny

 15:35 <juliank> And the sources are restored in normal control flow but not if an exception happens

 15:35 <juliank> We could also install a global exception handler that does rollback

 15:35 <enr0n> yeah tag away

 15:36 <enr0n> we definitely want a cleaner, more reliable rollback

 15:36 <juliank> tagged

 15:37 <juliank> #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs&ia=web

 15:37 <juliank> bug 2083529

 15:37 <juliank> Who wants to play with networkd?

 15:37 <juliank> I know it's my package :|

 15:37 <enr0n> I guess me? If it's networkd

 15:38 <juliank> I guess networkd-dispatcher reads the wrong field from networkd

 15:38 <enr0n> Not that I know what networkd-dispatcher is

 15:38 <juliank> It's a python script that listens to networkd and dispatches hook scripts

 15:39 <juliank> It's aaaaaargh

 15:39 <juliank> Anyway I did tag this

 15:39 <enr0n> Hm okay, I will ask more questions later

 15:39 <juliank> And that wraps up incoming bugs

 15:39 <slyon> enr0n: you can pull me in on that if needed

 15:39 <juliank> Well I guess we can talk about the dbus-broker MIR again

 15:40 <enr0n> slyon: ack thanks

 15:40 <juliank> slyon: We should just move hook script running into netplan :D

 15:40 <juliank> Any news about dbus-broker?

 15:40 <slyon> :P

 15:40 <juliank> I noticed that there's yet a new dbus broker in town now

 15:40 <juliank> I remember hearing about it at all systems go

 15:41 <slyon> busd

 15:41 <juliank> bug 2015538 fwiw

 15:41 <liushuyu> didn't they want to promote varlink too

 15:41 <bdrung> you guys from the past! varlink is the future! ;)

 15:41 <juliank> Different people doing different things

 15:42 <juliank> *systemd* is all crazy about varlink

 15:42 <juliank> Also the main APT author is all crazy about it

 15:42 <slyon> I think for dbus-broker to be feasible, we still need upstream improvements in gdm (and other greeters?)

 15:42 <juliank> :D

 15:43 <bdrung> or gdm switching to varlink

 15:43 <juliank> heh

 15:43 <slyon> :D

 15:43 <juliank> We write our own dbus broker

 15:43 <juliank> It encapsulates dbus messages in varlink

 15:44 <adrien> I'll watch.

 15:44 <liushuyu> (Haven't we already seen the same story regarding REST vs GraphQL?)

 15:44 <juliank> But alright, nothing new in dbus-broker land

 15:44 <juliank> GraphQL is *amazing*

 15:44 <juliank> Amazingly annoying

 15:44 <bdrung> juliank, dpus is has so many issues in the protocol. the implementation cannot fix that.

 15:44 <juliank> #topic Team proposed-migration report

 15:44 <juliank> We are going to skip this bit

 15:44 <juliank> We don't have an archive to work on

 15:44 <juliank> #topic AOB

 15:45 <juliank> Anything else?

 15:45 <juliank> Otherwise we stop at :46 :D

 15:45 <bdrung> 3cpio to rule the world!?

 15:45 <juliank> yes yes

 15:46 <juliank> To be fair I just want to ship prebuilt initrd cpio archives and combine those :D

 15:46 <juliank> but I digress

 15:46 <juliank> Final call!

 15:46 <juliank> 3

 15:46 <juliank> 2

 15:46 <juliank> 1

 15:46 <juliank> #endmeeting



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