=== amurray_ is now known as amurray === JanC is now known as Guest3733 === JanC_ is now known as JanC === pushkarnk1 is now known as pushkarnk === cpete_ is now known as cpete === pushkarnk1 is now known as pushkarnk === pushkarnk1 is now known as pushkarnk [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] \o [15:01] o/ [15:01] o/ [15:02] o/ [15:02] o/ [15:03] #startmeeting Weekly Ubuntu Foundations team [15:03] Meeting started at 15:03:05 UTC. The chair is juliank. Information about MeetBot at https://wiki.ubuntu.com/meetingology [15:03] Available commands: action, commands, idea, info, link, nick [15:03] #topic Lightning rounds [15:03] \o [15:03] #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-2024-03-21/43313 [15:04] o/ [15:08] waveform, `eval "$(grep "^VERSION_CODENAME=" /etc/os-release)"` can be just changed to `. /etc/os-release` [15:09] it could... but it just feels a bit "dirty" to me :) [15:10] Less dirty than that ^^ [15:10] quite tricky that os-release [15:10] you could do that in a subshell and echo the appropriate value too [15:10] You definitely need a subshell [15:10] waveform, the os-release spec says that it is shell sourceable [15:11] i.e. we needed to do +GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-@DPKG_VENDOR@} ) 2>/dev/null || echo @DPKG_VENDOR@` [15:11] sure, but do I want to trawl the spec and make certain it can't clobber any existing vars I've got in the env or do I just want to cherry pick the one I'm interested in? [15:12] The shell just aborts entirely if sourcing os-release fails, hence the need for the subshell [15:12] i.e. we don't trust it's always readable [15:13] users mess up stuff but breaking boot for it would be ugh [15:13] "But I want my system to identify itself as Foobar OS 25.564.53"! [15:13] Anyway, it's getting late, we should move on :) [15:13] "users mess up stuff" <- truer words were never said [15:13] but in this case it is an autopkgtest and it would be fine to fail if os-release contains garbage [15:13] ack [15:13] #topic Release incoming bugs [15:14] #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-nn-incoming-bug-tasks.html#foundations-bugs [15:14] bug http://launchpad.net/bugs/2054343 [15:14] -ubottu:#ubuntu-meeting- Launchpad bug 2054343 in gcc-10 (Ubuntu) "arm64 build of gcc-10 10.5.0-3ubuntu1 still broken (CVE-2023-4039 still open)" [Wishlist, Confirmed] [15:14] This is the only bug today! [15:15] This needs to be fixed in focal as it is in main [15:15] In all other releases it is in universe, so it's up to the ESM team to deliver a fix to esm-app-security [15:15] there is one in unknown that may be foundations too: bug 2058227 [15:15] -ubottu:#ubuntu-meeting- Bug 2058227 in apt-xapian-index (Ubuntu) "Crash during upgrade from Mantic to Noble due to Python 3.12" [Undecided, New] https://launchpad.net/bugs/2058227 [15:17] Wait am I right in counting, is focal still in standard support? === pushkarnk1 is now known as pushkarnk [15:17] yup [15:17] focal's still supported [15:17] * waveform eyes his home server still running focal... [15:18] yeah, have been running JDK compliance tests for focal :D [15:18] a-x-i is only in main for trusty [15:18] I imagine the fix is simple though but is that package even useful? it was last updated in Focal [15:20] OK so what I did for gcc-10 is add focal task, change jj, mm to wontfix and said that's a Pro thing [15:20] Oh but probably it should be split into a FTBFS bug and a security one [15:21] Left the bug :) [15:26] So what's the conclusion on the apt-xapian-index one? [15:26] where does the crash even happen? [15:26] I think we should add a quirk to stop the service from running during the upgrade. [15:26] It happens during a dist-upgrade of Kubuntu. [15:27] We probably should have a quirk to inhibit all systemd timers and cron jobs [15:27] Probably should add a feature to systemd to actually inhibit timers [15:27] But that'S 25.04 talk [15:28] cant something like this also happen if an already running service pulls in new stuff dynamically? [15:28] sure [15:29] Possibly atomic A/B upgrades are also a topic for 25.04 [15:29] But need cooperating file system with snapshots [15:30] And figuring out how to upgrade snaps inside the new target [15:30] 25.04 we said, juliank, not right now ;) [15:30] time is short [15:30] heh [15:30] #topic Team proposed-migration report [15:30] #link https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses_by_team.html#foundations-bugs [15:31] I don't really want to assign anything particularly much, there's so much flux and it's hard to figure out what is not time_t and we should work on time_t first anyhow? [15:32] Well we can assign any non-armhf failures [15:32] Because they block progress and are clearly not time_t armhf bugs ;) [15:33] * juliank finds last week's assignments [15:34] Apparently Skia is still on libbsd migration but only one armhf task left hooray [15:34] yes, and it should probably be done shortly after the gvmd upload from this afternoon [15:35] libapt-pkg-perl [15:36] liushuyu: bdrung - supposed to have freetype but that seems cleared? [15:36] sigh [15:36] libapt-pkg-perl: bdrung? you're supposed to have freetype but that seems cleared? [15:36] i had libapt-pkg-perl the previous week [15:37] juliank, i'll be on vacation next week. so please skip me. [15:37] ok [15:37] i sync'd the fix from debian, just waiting for tests [15:37] ginggs: There is no libapt-pkg assignment in the epic from last week [15:37] but good [15:37] previous week [15:38] ack [15:38] python-apt is mine [15:39] waiting for tests I suppose [15:39] I don't see my test requests on the package page but I did them [15:39] will check /running later [15:40] apt vs xz-utils is with upils [15:40] well, this is a time_t related issue AFAIU [15:41] so I cannot really do anything about it except waiting for the -all-proposed run, no? [15:41] if you queued one then yeah [15:41] I did: they're not helpful [15:41] libtirpc was with liushuyu, there are no failures, but it doesn't migrate; someone to dig at update_output.txt? [15:41] I did but It may have been lost at some point, I will check again [15:41] possibly needs hinting [15:42] Britney lags but updated an hour ago luckily [15:43] juliank: libtirpc is still waiting on the excuses to update (the last test just passed several hours ago) [15:43] no [15:44] hmm [15:44] maybe yes but excuses by teams doesn't show [15:44] "Migration status for libtirpc (1.3.4+ds-1build1 to 1.3.4+ds-1.1): Waiting for test results, another package or too young (no action required now - check later)" [15:44] ok [15:44] * adrien_web only looks at not by team [15:44] libuv1 is with mwhudson [15:44] adrien_web: heh but we need to look at by team one here [15:45] xz-utils is still with zhsj waiting for tests to run I suppose [15:45] I did retries for it, i think they're maybe all good now [15:45] For libuv [15:45] optipng is with bdmurray still [15:46] slang2 is with tim andersson whatever his handle is, I don't know right know :) [15:46] juliank: yeah; I wanted to give more context to what I say [15:46] nfs-utils is with danilogondolfo still [15:46] andersson123, usually, but he's not online right now it seems [15:47] fwupd vs libmbim is with pushkarnk [15:47] fwupd - waiting for results on amd64/armhf, tests pass locally. Failures on s390x need some investigation [15:47] This really should unlock all the fwupd vs * [15:49] (actually, I can't repro the fwupd test failures on s390x locally, the tests seem to pass) [15:49] glib2.0 blocking *: waveform [15:49] ack [15:50] Let's skip a couple which only fail on armhf and get more interesting one [15:50] In the past there were network issues with fwupd [15:50] babeltrace is blocked by ceph, but due to dependency issues, but on amd64! [15:50] bdmurray: ack, will check from that angle [15:51] babeltrace: dviererbe (previous week assignment seems solved) [15:52] being more specific issues with fwupd trying to access external resources [15:52] nice, but I did nothing [15:52] debhelper: Skia you wanna take those? [15:52] sure [15:52] It's 6 packages failing but hmm [15:53] dwz ginggs [15:53] ack [15:53] libnsl slyon [15:54] ok [15:54] gdbm itself: mkukri [15:54] ack [15:55] file, primarily non-armhf ones: mateus-morais [15:55] juliank: ack [15:57] zlib has a bunch of dependency issues across non-armhf architectures: pushkarnk (please ping if you need assistance) [15:58] ack [15:58] zlib non-armhf ones: schopin [15:58] isn't it what you just assigned? [15:58] oops [15:59] Let me wait until I find a bigger one for you [15:59] erm... OK? [15:59] gsasl blocking iproute2: liushuyu [15:59] juliank: okay [16:00] initramfs-tools: So bdrung wants none, so maybe schopin wants that one [16:00] It's s390x! [16:00] i'll take care of initramfs-tools [16:01] all those failures should be fixed with the latest uploads === JanC is now known as Guest1790 === JanC_ is now known as JanC [16:02] libpng1.6: schopin [16:02] but like maybe focus on the one arm64 [16:02] and the i386 [16:02] * schopin looks around for someone else to jump in. [16:02] ACK. [16:02] python-click ogayot [16:03] (again the non-armhf ones) [16:03] libcgi-pm-perl i386: spyros [16:04] libclass-xsaccessor-perl non-armhf: vpa1977 [16:05] libdbi-perl non-armhf: adrien_web [16:05] libemail-address-xs-perl non-armhf chriscoulson [16:05] doko and vorlon get to do time_t only [16:06] uh I think let's leave it here [16:07] #topic AOB [16:08] I'll be out on Monday. [16:08] The next week is going to be a short one for me (two public holidays - Monday and Friday) [16:12] #endmeeting [16:12] Meeting ended at 16:12:30 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-21-15.03.moin.txt