=== JanC is now known as Guest4647 [14:59] o/ [15:00] o/ [15:00] o/ [15:00] o/ [15:00] o/ [15:00] o/ [15:00] \o [15:00] o/ [15:01] \o [15:01] o7 [15:01] #startmeeting Weekly Ubuntu Foundations team [15:01] Meeting started at 15:01:30 UTC. The chair is juliank. Information about MeetBot at https://wiki.ubuntu.com/meetingology [15:01] Available commands: action, commands, idea, info, link, nick [15:01] #topic Lightning rounds [15:01] o/ [15:01] #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-2024-06-27/ [15:02] o/ [15:03] o/ [15:03] o/ [15:04] o/ [15:04] \o (my ability to attend completely might be hampered today) [15:09] o/ [15:09] skia: "maybe fixed" :D [15:11] #topic Release incoming bugs [15:11] #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-oo-incoming-bug-tasks.html#foundations-bugs [15:12] bug 2065040 [15:12] -ubottu:#ubuntu-meeting- Bug 2065040 in snapd (Ubuntu) "Drop UBUNTU_CODENAME from /etc/os-release. Use VERSION_CODENAME instead" [Undecided, New] https://launchpad.net/bugs/2065040 [15:12] dviererbe: yeah, time will tell :D [15:13] bdrung: I don't agree with this, the _CODENAME is super useful to have to guide downstreams, such that you can still look at UBUNTU_CODENAME there for tools [15:13] e.g. PPAs continue to work on Mint and such [15:14] I know there are several things using it for just that, but I don't remember which ones :) [15:14] that is an argument I cannot rebut [15:15] I'm setting it to Opinion [15:15] #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-nn-incoming-bug-tasks.html#foundations-bugs [15:16] bug 2067672 [15:16] -ubottu:#ubuntu-meeting- Bug 2067672 in OEM Priority Project "[SRU] Openssl copyright/changelog.Debian.gz file points at non-existent location" [High, Triaged] https://launchpad.net/bugs/2067672 [15:16] basically the question is: can this be accepted as an SRU for openssl? [15:16] some people are bothered/annoyed or maybe see that as very problematic [15:16] I don't think it should be released as a standalone SRU [15:16] but still, that's openssl [15:17] But it should be folded with the next openssl SRU or security update [15:17] therefore it can be years [15:17] I would suggest combining it with the next security update [15:17] So it can be uploaded now and staged in proposed [15:17] It's marked as High prio by OEM. [15:17] 3.0.x has been expectedly with fewer and fewer issues [15:17] ANd I'm not sure how security would feel about shipping this in one of their upload. Someone should check with them? [15:18] can do that [15:18] (not volunteering) [15:18] One consideration when making a decision like this is how many people have the package installed and the size of the package. [15:18] note that we won't be shipping the same change in OO, even now [15:18] it doesn't apply anymore IIRC (I should check nonetheless :) ) [15:19] bdmurray: I'd normally not consider this, but we're talking about the copyright file so maybe urgency is different in that case? [15:19] schopin: That could be. [15:20] The copyright file is still there it's just hard to find but we never end up actually breaking any license rules [15:20] one alternative: do the SRU now but keep it in -proposed until the next update comes around? [15:20] Yes we should upload it and verify it [15:20] IIRC people in the security team don't like updates lingering in proposed [15:21] And add block-proposed-noble [15:21] That's exactly what block-proposed-$ is for [15:21] that goes back to checking with them [15:21] adrien: This is the standard procedure to stage those updates. [15:21] yes that [15:21] In any case yes first of all we need to have a fixed oracular [15:21] yes but it doesn't meant it's enjoyed by every party :D [15:22] Otherwise someone will shout at the uploader [15:22] oracular is fixed but differently [15:22] In what sense? [15:23] hmmm, maybe not actually [15:24] let's take that outside of this meeting. I'll discuss/sponsor the oracular fix afterwards (as last patch pilot action) [15:24] the changelog says it links libssl-dev to openssl etc, but that's obviously not correct legally [15:24] Anyway no other incoming bugs for us! [15:24] #topic Team proposed-migration report [15:25] #link https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses_by_team.html#foundations-bugs [15:25] juliank: there's another issue: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1297025 [15:25] I am still on dracut vs systemd [15:25] -ubottu:#ubuntu-meeting- Launchpad bug 1297025 in openssl (Ubuntu) "Either the changelog.gz is missing or there is an erroneous link in the libssl1.0.0 package" [Medium, Triaged] [15:25] bdrung: ok, thanks [15:26] 17 packages needing attention, 12 packages not yet considered late [15:26] pyopenssl is with adrien still [15:26] i've been looking into execnet for sphinx. the tests randomly fail on ppc64 [15:26] apport is with schopin sitll [15:27] yes [15:27] sphinx vs bugwarrior remains with liushuyu [15:27] sphinx vs execnet with tobhe [15:27] tobhe: you can also trigger with migration-reference/0 and if that also fails it will migrate :D [15:27] openssh is just waiting ignoring [15:28] mkukri: might be worth it. I did some research and saw that at least one of the tests was disabled in debian at some point until someone refactored things and turned it back on [15:28] bugwarrior is waiting on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029032#15 (a new package needs to be added, and adrien is still waiting for a sponor in Debian) [15:28] debhelper vs autopkgtest: bdmurray [15:28] -ubottu:#ubuntu-meeting- Debian bug 1029032 in wnpp "ITP: python-google-api-core -- Google API client core library" [Wishlist, Open] [15:29] tobhe: it's really simple, just put &trigger=migration-reference/0 at the end of the url [15:29] dpkg bugs: bdrung did you have a quick check since you uploaded it if that's caused by dpkg in a trivial way to spot or something to distribute? [15:30] juliank, the failures caused by me are normally easy to spot: missing environment variables DEB_* [15:30] bdrung: Yes, they all seem to be DEB_HOST_ARCH being undefined, so I'll uh leave that with you to fix up [15:31] yes, DEB_HOST_ARCH is caused by me. give them to me. [15:31] vim has migrated [15:31] bad bdrung, causing archive-wide breakage. [15:31] ;) [15:32] ...says Mr. Archive Breaker :D [15:32] libcgi-pm-perl cpete [15:32] we are a good team [15:32] btrfs-progs: dbungert [15:32] We should have an archive breaker trophy or something [15:32] ack [15:32] And that's all [15:32] juliank: I still have gcc-13, would you assign this to someone else? [15:32] #topic AOB [15:33] next Thursday is a holiday in the US [15:33] Monday is a holiday in Canada [15:33] dbungert: Oh it did not migrate so you are investigating the candidate status and update_output.txt? [15:33] correct [15:33] I don't think that we reached the level of last cycle (where we had armhf time_t and xzutils) [15:33] ack [15:33] So btrfs-progs: danilogondolfo [15:34] juliank, ok, but it should migrate soon, the last test passed hehe [15:34] So last time we started from the back, this time from the front, I guess next time we start from the middle? [15:34] And then we like go wide, alternating up and down the list of people [15:34] :D [15:35] I vote hilbert curve... [15:35] Gotta keep proposed-migration fair [15:35] Or we use the ordering bot that we used to use for the status reports? [15:35] Could also pick at random [15:35] we could keep statistics of historical assignments and automate the new ones based on that [15:35] Indeed [15:36] with a weighting for new hires [15:36] mkukri: I take it you volunteer to write the statistics? [15:36] and people without upload rights [15:36] :D [15:36] You mean give more assignments the longer your tenure? I'm all for it :P [15:36] I actually wonder if this is possible as a JIRA report, mclemenceau_, tag them all proposed migration and see who worked on how many in the past 4 weeks? [15:37] I had to drop at the wrong time but it's possible to upload python-google-api-core in ubuntu directly with minor tweaks to the package I sent for inclusion in debian if anyone wants to do that [15:37] im not sure where to source the data, irc log sounds like a pain [15:37] but assuming jira is accurate it might be easy [15:37] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029032#25 [15:37] -ubottu:#ubuntu-meeting- Debian bug 1029032 in wnpp "ITP: python-google-api-core -- Google API client core library" [Wishlist, Open] [15:38] cool [15:38] I lost a bit track of that [15:40] Ack juliank, I can definitely look into that. that seems possible [15:42] cool [15:46] #endmeeting [15:46] Meeting ended at 15:46:35 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-06-27-15.01.moin.txt === dbungert1 is now known as dbungert