[01:04] <JawnSmith> Is any core dev available to restart the autopkgtest for software-properties version 0.99.3.1 in groovy?
[01:08] <cjwatson> JawnSmith: Done
[01:08] <JawnSmith> cjwatson: thanks!
[01:08] <cjwatson> np
[09:50] <cpaelzer> rbalint: it seems my questons in regard to systemd autopkgtest status didn't reach you yesterday
[09:51] <cpaelzer> rbalint: since today everything looks as bad or worse I've filed bug 1915126 about it
[09:51] <cpaelzer> that way you can pick it up whenever you are around and everyone else blocked by the same can chime in there
[09:51] <cpaelzer> mfo: ^^ FYI
[09:51] <cpaelzer> bryce: ^^ FYI
[13:23] <seb128> ddstreet, hey, I'm mostly curious but what is the moving behind https://code.launchpad.net/~ddstreet/software-properties/+git/software-properties/+merge/396926 ? there is no description or rational nor bug linked to the change
[13:34] <seb128> tjaalton, do you have any idea about the libxcb/s390x build failure?
[13:34] <seb128> https://launchpadlibrarian.net/521797278/buildlog_ubuntu-hirsute-s390x.libxcb_1.14-3_BUILDING.txt.gz
[13:34] <seb128>     inlined from ‘parse_display_negative_fn’ at ../../tests/check_public.c:153:2:
[13:34] <seb128> ../../tests/check_public.c:82:3: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
[13:34] <seb128>    82 |   ck_assert_msg(!success, "unexpected parse success %sfor '%s'", test_string[test_type], name);
[13:34] <seb128> unsure why that would be arch specific...
[13:36] <tjaalton> and only on ubuntu
[13:36] <tjaalton> but no, I don't
[13:38] <seb128> :(
[14:09] <ddstreet> seb128 the author of the MR appears to have wanted to remove the python-requests-unixsocket dep from software-properties, and based on the project having no upstream commits in ~1.5 years it's probably good not to rely on it
[14:10] <seb128> ddstreet, it's confusing, the vcs and mp is from you?
[14:12] <ddstreet> seb128 this was his original mr https://code.launchpad.net/~slingamn/software-properties/+git/software-properties/+merge/389182
[14:12] <ddstreet> then this one, but i preferred to simplify it more https://code.launchpad.net/~slingamn/software-properties/+git/software-properties/+merge/396880
[14:12] <ddstreet> so i opened the final mr
[14:13] <seb128> ddstreet, ah, thanks, the reference was missing, that one has useful details
[14:13] <seb128> makes sense now!
[15:34] <rbalint> cpaelzer, thanks for the bug, i'm working on the next upload
[15:45] <cpaelzer> thanks rbalint
[15:45] <cpaelzer> if you have any further insight to it please dump it to th bug
[15:45] <cpaelzer> I've already got two other that are potentially looking into it and have told them to look&past at the bug to sync on it
[15:47] <rbalint> cpaelzer, do i understand correctly that the tests pass locally for you?
[15:47] <cpaelzer> rbalint: indeed
[15:48] <cpaelzer> systemd-fsckd        PASS
[15:48] <cpaelzer> yep
[15:48] <cpaelzer> I have not redircted the log, but can pass you a copy&poaste of the console if you think it would help (I don't think so)
[15:49] <cpaelzer> This is the command that workss for me "sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries --apt-upgrade --testname=systemd-fsckd --shell systemd_247.1-4ubuntu1.dsc -- qemu --ram-size=1536 --cpus 1 ~/work/autopkgtest-hirsute-amd64.img"
[15:49] <rbalint> cpaelzer, no, your word is enough :-)
[15:49] <cpaelzer> I have not yet iterated on running all/more testcases an or CPU/memory capacity
[15:50] <rbalint> cpaelzer, ack, giving a try to running it on big vms worth trying imo, i'm rebasing my MP @ https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/383953
[16:03] <rbalint> Laney, please give a try to making systemd big on amd64 : https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/397740
[16:03] <rbalint> cpaelzer, ^
[16:04] <rbalint> cpaelzer, as i see ppc64el got better today
[16:07] <cpaelzer> yes rbalint, at least I got through two tests
[16:08] <cpaelzer> on ppc64el that is
[16:38] <Laney> rbalint: I'll try it manually first, we'll see
[16:39] <rbalint> Laney, thanks!
[16:39] <Laney> cpaelzer's sizes there are the sizes of the instances we use currently though and it passed
[16:39] <Laney> do you know why having a too small instances ends up with you in emergency mode?
[17:13] <tdaitx> doko: I updated bug 1915009 with the requirements for MIR, should I ping someone from the ~ubuntu-mir and security team for reviews or is this bug update enough?
[17:15] <tdaitx> I am asking about the pings because I was told by mclemenceau that this is somewhat urgent
[17:21] <mclemenceau> thanks tdaitx for updating the ticket
[17:47] <teward> this will sound a tad like a "why are you asking" question, but at what point did /run and /boot get mounted with 'nodev' options, and is there a way to make that happen on older systems?  Asking on the older systems part because a vuln management system is whining about /run and /boot not being mounted with nodev.
[17:47] <teward> mounted with nodev option by default*
[19:20] <xnox> teward:  initramfs-tools, systemd built'in, fstab will try to mount those end points.
[19:20] <xnox> teward:  if you want them with nodev, you should be able to set that in fstab; and do update-initramfs -u.
[19:20] <xnox> teward:  then on boot it will be mounted without nodev option; but should then be remounted with it.
[19:20] <xnox> teward:  if it doesn't it's a bug in ubuntu.
[19:21] <xnox> teward:  more comonly people tweak the tmpfs size of /run. or like umask of /boot => so it's not that uncommon to customize those.
[20:03] <rbalint> Laney, how did the manual test go?
[20:04] <rbasak> vorlon, sil2100: TB meeting?
[20:16] <Laney> rbalint: I didn't do it yet, I've been busy with .0 stuff
[21:09] <ItzSwirlz> rbasak: oops im late.. LP #1901344 reminder
[23:13] <santa_> hi everyone
[23:16] <santa_> doko: note for whenever you can read: since a short time ago, I have been getting some kde packages built with files with the wrong owner
[23:16] <santa_> for example:
[23:17] <santa_> https://launchpadlibrarian.net/522205798/buildlog_ubuntu-hirsute-amd64.kwayland-integration_4%3A5.20.90-0ubuntu1~ubuntu21.04~ppa2_BUILDING.txt.gz
[23:17] <santa_> -rw-r--r-- buildd/buildd 18984 2021-01-21 23:44 ./usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kguiaddons/kmodifierkey/kmodifierkey_wayland.so
[23:18] <santa_> this file ↑ should be owned by root
[23:19] <santa_> I have the impression that the new libc6 & friends triggered this, but I have no solid evidence
[23:19] <santa_> this doesn't happen without -proposed
[23:21] <santa_> I have *temporarily* available here the results of a test rebuild of our kubuntu kde WIP packages: http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp3/
[23:21] <santa_> they are several packages affected from kde applications
[23:22] <santa_> so if you can give me a hand with this I would appreciate it very much
[23:22] <santa_> in case it's not libc6 & friends fault, sorry for the noise :)