[03:08] why does reverse-depends print to stderr [03:08] that seems odd === Eickmeyer is now known as Eickmeyer-Quasse === Eickmeyer-Quasse is now known as Eickmeyer[q] === ben_r_ is now known as ben_r === bpsecret- is now known as bpsecret === pieq_ is now known as pieq [09:10] anyone looking at the sphinx autopkgtest failures in focal proposed? [09:37] rbalint: is that expected that /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal is kept running (started 3h30 half ago) and that I have /var/run/unattended-upgrades.lock and /var/run/unattended-upgrades.progress (latest with Progression : 80.0 % (libegl1-mesa-dev) unchanged) [09:49] didrocks, yes, it is ok [09:49] didrocks, u-u.service is always running waiting for shutdown, then it gracefully stops u-u [09:56] rbalint: is it normal that the progress file is there. with the same % and stuck? [09:58] rbalint: also, I want to have an action hooked up before the first apt call and at the end of the unattended-upgrade transaction (after the last apt call). We are using apt hook currently, with some file to run it only once, but that’s not clean nor fully fix it for unattended-upgrades ofc. Is there a way to hook us to unattended-upgrades that way? [09:58] didrocks, yes, because it is not used nor should be looked at [09:59] rbalint: ok, so it seems we can’t use files to have our pre/post-hook, any hints on how we can do this? ^ [10:00] didrocks, please open a PR/issue at https://github.com/mvo5/unattended-upgrades to discuss that [10:00] doing [10:06] rbalint: https://github.com/mvo5/unattended-upgrades/issues/266 [10:23] hello, could someone approve vala 0.48.3-1 in focal/queue [10:42] infinity, hi :) ^ [10:44] ricotz: I think inf1nity is unlikely to be around. I suspect other r-t members in that channel are a better bet [10:49] There's no need to ping though, it'll get looked at [10:54] :) === arunpyasi_ is now known as arunpyasi [10:57] RikMills, I see, I looked at https://wiki.ubuntu.com/ArchiveAdministration#Archive_days [10:58] Laney, sounds fair, but it doesn't seem that way [10:58] It is that way [10:59] I'm going to go through the queue later on today, for example [11:01] Laney, FIFO would be the concept to wish for here -- thanks [11:02] ricotz: I'll start from the oldest. :P [11:02] but I'm sure Jeremy's syncs will all be obviously great and correct, so very fast to review [11:02] :) === cpaelzer__ is now known as cpaelzer [11:03] that is what fifo means (just saying there are a lot of packages uploaded after vala which are gone already) [11:03] Laney, #1 [11:04] right [11:06] ricotz: Yeah, it'll never be a FIFO, but hey, we get there. [11:08] infinity, ok :) [13:16] jibel (cc zyga): I'm not sure the apparmor change is sufficient to address bug #1871148. See my latest comments [13:16] bug 1871148 in zsys (Ubuntu Focal) "services start before apparmor profiles are loaded" [Undecided,New] https://launchpad.net/bugs/1871148 [13:16] ack [13:16] looking [13:17] jibel (cc zyga): I'm going to ping diddledan in #snapcraft to retest. popey, you may want to as well ^ [13:17] .wu8 [13:17] erf [13:17] heh [13:23] lathiat, hey, any reason avahi-daemon-check-dns.sh isn't being removed in Debian? I saw you suggested some fixes there on https://salsa.debian.org/utopia-team/avahi/-/commit/a856156a but bug #1870824 you suggest removing it? wouldn't that apply to Debian as well? [13:23] bug 1870824 in avahi (Ubuntu) "Errors in script /usr/lib/avahi/avahi-daemon-check-dns.sh" [Low,In progress] https://launchpad.net/bugs/1870824 [13:26] Yeah it should also be removed in Debian. I guess just no one told them. I only thought of it recently as part of that person asking me about that bug seb128 [13:27] seb128: Those other fixes were mainly because we had to backported that fix to bionic without the fixed nss-mdns [13:27] popey: to be clear, I meant you may want to test if the issue is fixed, not ping diddledan ;) [13:27] Well when I say fixed I guess you could say improved [13:27] got it [13:27] * diddledan pings jdstrand [13:28] you know. just for the giggle :-p [13:28] lathiat, http://paste.ubuntu.com/p/7NGn4tfgrR/ looks good to you? [13:31] hey diddledan :) [13:32] jibel: fyi, after a reboot and upgrading apparmor, diddledan sees this: https://paste.ubuntu.com/p/3VjZhgQRyT/ [13:33] jibel: which looks correct. but I'm worried there is a race or something where var.lib.mount will sometimes be there and sometimes won't and people using snaps with root-on-zfs may hit an intermittent bug [13:34] popey: actually, iirc, you had said that restarting apparmor worked to resolve the issue (which of course it would, it was way after /var/lib would be present), but did you always have to do this? just every once in a while? [13:34] popey: (after reboot) [13:35] i almost never reboot [13:35] jibel: (fyi, popey also saw this issue) [13:35] yeah, I hear you [13:35] so this is not an issue I see very often, as a result of that [13:35] * jdstrand nods [13:35] Seb128: Yeah that looks ok. While you’re at it there’s half an Ubuntu patch I’d want to drop as well the local host services only patch I merged half of it upstream in 0.8 which I released some weeks ago but i removed the line where it rewrites the hostname to localhost. That was originally needed by cups for ippusbxd but I got till to fix cups not to need it. And that fix should be in focal. Per here: [13:35] https://github.com/lathiat/avahi/commit/2fd76baeb8298ef1b5b177bf7fd70f6cda3eab00 - if you do prepare a package for either I can test them tomorrow (in about 10 hours) [13:35] diddledan: you only just started seeing this, right? how often do you reboot? how long have you been using zfs-on-root? [13:36] I've been using ZFS-on-root since march 3rd.. I reboot sporadically.. sometimes multiple times a day and other times once in several days [13:37] I need to go to Winders to watch Westworld, so I've started rebooting at least once a week to do that ;-p [13:37] jibel: I don't really know zfs: are there times when zfs is doing something on boot for housekeeping or similar that might cause a smallish delay in boot before its .mount units show up? [13:37] diddledan: have fun! [13:38] every Sunday or Monday ;-) [13:39] jdstrand: zsys/zfs doesn’t really do anything since we enabled the generator. Basically, we have a systemd generator which creates .mount files. Systemd is then ordering the units are mounting them [13:39] jdstrand: so, I think the issue comes from systemd itself [13:40] (I think if you create a similar partitionning on ext4 and let systemd mounting them on boot, you will end up with the same issue) [13:40] zfs-mount.service units are no-op in our configuration [13:43] would it be possible for systemd to have a race in the mount units ordering/picking when RequiresMount= is? unlikely, but maybe a regression… [13:45] didrocks: idk. I only updated the apparmor unit for correctness and am just giving some ideas. I've not tried to create .mount units with ext4 with similar partitioning (cc zyga). but, does zfs perform some housekeeping on boot prior to when the mounts might show up? [13:47] zfs-load-module.service, zfs-import-cache.service and zfs-import.target are all listed in https://paste.ubuntu.com/p/3VjZhgQRyT/ (a successful boot) prior to var.lib.mount [13:47] * zyga checks backlog [13:47] I’m [13:47] perhaps one of those is taking too long, apparmor starts and var.lib.mount isn't generated [13:47] and then at some later point it is [13:47] about that topic [13:47] I don't understand why apparmor starts [13:47] if it has after local-fs.target [13:48] can local-fs.target be reached before zfs probing is done? [13:48] zyga: that is the question. see my comments in the bug [13:48] ok, let me catch up with developments [13:48] zyga: on one boot, local-fs.target had zfs in its critical-chain, on another it did not [13:48] Not sure if strictly related but the Zfs stuff basically doesn’t work for hotplugged stuff including USB devices present at boot. Either in bionic or focal with my current testing (at least for multi device zfs). I thought the new generator stuff would help but it didn’t seem to. The zpool import task seems to run and finish before the USBs appear. I was thinking the generated pool units need to depend on the [13:48] device paths but that’s as far as I got looking into that. [13:49] So I have to run zpool import -a manually atm on my setup [13:50] jdstrand: when we do a manual mount in our tests (like create a pool and then run grub which mounts and immediatly accessing its content on next line), we didn’t see any kind of latency (we ran the tests multiples thousands times on fast and slow machines/disks), so that seems unlikely at first glance, but not impossible ofc [13:50] So if you’re trying to reproduce a problem like that maybe try setup two USB drives [13:50] zyga: the RequiresMountsFor change in apparmor is only going to work if there is a .mount unit at the time the apparmor service is started, aiui [13:50] lathiat: here it was /dev/sda*, sata with zfs [13:50] jdstrand: indeed [13:51] My setup is non root btw. Just a storage mount. [13:51] jdstrand: note that systemd generates .mount units for every mount in the system (however it was created) [13:51] but it is indeed possible to race [13:51] * zyga checks the bug history [13:52] lathiat: the generator is mostly done for root, it will create additional mounts only if you the zfs-list cache corresponding to your disk, otherwise, it will be the traditional import + zfs-mount systemd services [13:52] hi [13:52] zyga: right. I think didrocks is right to point out there could be a bug in systemd. however, if there is something that takes a while for zfs to start up before the mount units can even be generated, that would be a bug somewhere else [13:52] I just discover Zsys it's perfect [13:52] jdstrand: I wonder if we could see when local-fs.target was reached [13:52] jdstrand: and compare that to when zfs was started / completed [13:52] Yeah I setup the list cache but it still fails (with or without). [13:53] jdstrand: and when apparmor was started [13:53] does someone know if it's possible to swithc a non Zsys zfs install to a Zsys one ? [13:54] nomad_fr: if you don’t know the internals, we disabled on purpose zsys on non zsys managed systems [13:54] zyga: well, there is the systemd-analyze plot and dot, but we unfortunately saw that it didn't list apparmor once when it had obviously started :\ [13:54] jdstrand: oh, right [13:54] that's so weird [13:54] bugs bugs bugs :/ [13:55] nomad_fr: so yeah, Zsys isn’t perfect as it won’t manage manually installed setup :) [13:55] didrocks: I'm able to adapt my manually installed setup to match Zsys need [13:56] didrocks: I just need to know what is needed [13:56] jdstrand: perhaps for 20.04 we could avoid it by _not_ making /var/lib a zpool [13:56] nomad_fr: so I suggest do a beta install, look at the datasets layout and mirror that out. You will need to also add the same user properties to your datasets [13:56] whatever the bug is, we can fix it for +1 [13:56] nomad_fr: or wait for a month, I’ll publish some blogs about the internals [13:57] didrocks: I'm so excited about this, I use beadm on FreeBSD it's almost the same [13:57] didrocks: what is your blog url ? [13:58] nomad_fr: https://didrocks.fr (but yeah, will be published in a month or so :p). Glad that you are excited :) [13:59] zyga: /var/lib is not a zpool, it’s a dataset and that’s required for the server type layout [14:00] oh [14:00] sorry, [14:00] well, it's a mount point [14:00] I'm not sure how zfs installer defaults look like precisely, sorry [14:00] no worry :) we have a spec if interested in why this separation :) [14:01] Hower as I wrote, seeing the number of mounts + direct access to its content we have in our tests and how many of them we ran on different hardware, if there was even a slight delay between the mount exiting and the file system content to be available, we should have seen it [14:01] hence my pick on rather ordering on systemd mount units file [14:03] the mount units have Before=local-fs.target zfs-mount.service [14:03] so that ought to be ordred by systemd (/var/lib in particular) before local-fs.target [14:03] ah, but diddledan installation is before beta [14:03] fyi, https://bugs.launchpad.net/apparmor/+bug/1871148/comments/21 [14:03] Launchpad bug 1871148 in zsys (Ubuntu Focal) "services start before apparmor profiles are loaded" [Undecided,New] [14:04] did I break it, didrocks? :-p [14:04] diddledan: maybe your setup isn’t compatible with the generator fix. However, I think jdstrand installed from beta [14:05] I did a fresh install [14:05] diddledan: ensure you both have bpool and rpool in your /etc/zfs/pool.cache [14:05] I used a daily image from early march [14:05] I also have had trouble with kernel update and zfs.mount [14:05] but note my bug comment. based on systemd-analyze plot, it looks ok on the system where systemd-analyze critical-chain looks like it might not be [14:05] cat: /etc/zfs/pool.cache: No such file or directory [14:06] didrocks: on aurai pu parler Francais [14:06] I need to step away for a bit [14:06] diddledan: ensure you both have bpool and rpool in your /etc/zfs/pool.cache [14:06] oopsss [14:06] cat: /etc/zfs/pool.cache: No such file or directory :-p [14:06] jdstrand: yeah, however, the critical chain doesn’t show up all units leading to an unit, no? [14:06] diddledan: :p [14:07] diddledan: /etc/zfs/zpool.cache [14:07] didrocks: I did the critical chain on the unit itself [14:07] sudo systemd-analyze critical-chain apparmor.service [14:07] jdstrand: isn’t that the longest path leading to apparmor.service? [14:08] maybe critical-chain isn't the right diagnostic tool to verify things are ok [14:08] so if those units took longer than var.lib.mount, it’s wait is pending [14:08] isn’t not listed* [14:09] the man page isn't clear on this point [14:09] * jdstrand really has to go [14:10] I wonder how we can have something more precise from systemd :/ [14:11] "precise? this is focal!" [14:13] didrocks: infact I've some 'special' request has I'm installing my computer parc (50 ubuntu) with tftp + preseed + salt. I really love this Zsys feature. I wan't to know how to build my preseed to match it's need. [14:16] nomad_fr: remember that Zsys will be kept as experimental this cycle, so not a really good time to install on a park :) But yeah, just wait on my technical blog posts you should have what you need [14:45] didrocks: cool thanks so Zsys will be 'stable' with 20.10 ? [14:47] cjwatson, hey, sorry do bother you about that again, but looks like I screwed something in by adding those new strings to the gfxboot-theme-ubuntu template .. do you have any idea what in http://launchpadlibrarian.net/473396220/gfxboot-theme-ubuntu_0.23.0_0.23.1.diff.gz could create bug #1871599 [14:47] bug 1871599 in gfxboot-theme-ubuntu (Ubuntu) "Live image boot menu entries of Kubuntu are mistranslated" [Undecided,Confirmed] https://launchpad.net/bugs/1871599 [14:50] nomad_fr: that’s our goal, indeed [14:53] seb128: Uh, no idea, sorry :( [14:53] seb128: Oh maybe the txt_foo comments are parsed? [14:54] cjwatson, could well be in seems... [14:54] seb128: I don't remember by what, but that's probably where I'd start looking [14:54] cjwatson, thanks, I will try to figure that out [15:04] lathiat, I uploaded there, https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions/+sourcepub/11174563/+listing-archive-extra , I would welcome if you could test tomorrow [15:16] didrocks: I just test it on my laptop It seems to work, but I have to manualy zfs mount my home dir [15:22] didrocks: en fait le parametre canmount de mon home est passe a noauto ... je crois [15:24] nomad_fr: you are missing the bootfs-dataset parameter on your user dataset to link to the root dataset [15:25] didrocks:oh ! [15:25] this will be detailed on my blog for people interested in doing a manual transition [15:25] didrocks: ok [15:26] glad it’s almost working though for your first try :) [15:26] cjwatson, another question for you (sorry), I was looking at applying those grub/gettext fixes to the package, looks like autoreconf does overwrite po/Makefile.in.in ... is there any mechanism in grub that could be used for that that I'm overlooking or does applying those patches from override_dh_autoreconf sound like the way to go? [15:26] didrocks: second [15:26] heh [15:26] didrocks: on a 'standard install' it works, and a non standard one not yet [15:27] so for the moment I set canmount to on [15:27] ? [15:28] nomad_fr: you have multiple user properties to set (I think you set the ones on the root pool already, correct?) and one on the user pool. I suggest until I publish the blog post to try to install 20.04 beta on a vm and compare those [15:36] didrocks: ok I really tried it a little to fast [15:36] didrocks: I will have trouble in the future with canmount=on [15:42] didrocks: bon je te laisse, en tout cas encore merci pour tout ca [15:42] nomad_fr: de rien :) [15:43] sil2100, if you are not too busy and can sneak a small review in I submitted https://code.launchpad.net/~seb128/ubuntu-archive-tools/blocked_by_hints/+merge/381934 [15:43] sil2100, no hurry, I just ping because my previous ones didn't get picked by reviewers without a ping even after waiting a week so I'm unsure email notifications is good enough / something to rely on for that project reviews :) [15:44] seb128: hey! Let me look in a bit :) [15:45] seb128: override_dh_autoreconf is probably best. Switching to doing a full bootstrap would I suspect be a fair bit more complicated. [15:45] cjwatson, ok thanks, I just wanted to sanity check with you before submit a mp [15:45] seb128: Though I'm a little surprised that it can't be done without that [15:46] Since autoreconf should just be using what's in the source package ... [15:46] cjwatson, I'm unsure how? from what I can see autoreconf just replace po/Makefile.in.in with the system version [15:46] jibel: ok, based on the conversation in backscroll (thanks didrocks!) I just marked the zsys task back to Invalid with this comment: https://bugs.launchpad.net/ubuntu/focal/+source/zsys/+bug/1871148/comments/22 [15:46] Launchpad bug 1871148 in apparmor (Ubuntu Focal) "services start before apparmor profiles are loaded" [Critical,Fix released] [15:47] jibel: please adjust as you see fit [15:47] seb128: Ah, we maybe need to switch to bootstrap in the packaging somehow, but can't do that immediately [15:48] Fiddly [15:48] seb128: Feel free to hack it in the short term [15:48] cjwatson, will do, thanks [15:50] sil2100, sorry, I screwed the projects name/target :p [15:52] sil2100, resubmitted as https://code.launchpad.net/~seb128/ubuntu-archive-scripts/report_blocked_hints/+merge/381936 [15:52] hah, ok ;) [16:20] doko: you around? [16:22] if not doko, then sil2100 are you around? [16:23] disregard, issue resolved === dax is now known as ezri [22:38] hello friends :) can someone suggest to me if this is a user-error or if this is something broken in dpkg / apt / debconf / ucf / something else? I've seen this a few times recently https://launchpadlibrarian.net/473598994/DpkgTerminalLog.txt [22:38] the bug in question is https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1871615 [22:38] Launchpad bug 1871615 in apparmor (Ubuntu) "package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of file on stdin at conffile prompt" [Undecided,New] [22:42] isn't the eof on stdin message mean it happened when there was no interactive shell? [22:44] powersj: I thought about that, but then I got scared of what that would mean for everybody who uses our GUI update tool === ben_r_ is now known as ben_r [23:48] * mwhudson wrote a thing https://discourse.ubuntu.com/t/please-test-autoinstalls-for-20-04/15250