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