[06:07] PR snapd#8068 closed: tests: tweak and enable tests on ubuntu 20.04 [06:10] hey mborzecki [06:10] mvo: hey [07:46] Hey mvo [07:46] mvo: pushed the change with link structure to #7972 [07:46] zyga: hey [07:46] PR #7972: overlord/snapstate, wrappers: undo of snapd on core [07:46] I was woeking till 2am [07:46] Somewhat sleepy still [07:46] Kids woke me up [07:46] Sick and staying at home [07:46] zyga: i know you were playing c&c red alert :P [07:46] I wish :-) [07:47] I went for a walk at 2am [07:47] With my sleeping dog in my hand :] [07:48] He dislikes water so much I had to carry him for a while to convince him to walk [07:48] I wrote first spread tests for apparmor prompting [07:51] I’ll start later today [07:51] Need to wake up first [07:57] mborzecki: mvo: hi, is one of you going to work on #8064 this morning? [07:57] PR #8064: boot: add Device iface to coreKernel [08:02] pedronis: i was thinking about #8001 but i can look into 8064 first [08:02] PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <⛔ Blocked> [08:03] mborzecki: I made comment there and I didn't make on 8001 [08:03] mvo extracted it [08:16] PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58 [08:17] PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58 [08:23] mborzecki: thank you, I check 7972 [08:33] PR snapd#8070 opened: dirs: fixlet for XdgRuntimeDirGlob [09:04] * Chipaca returns from the doctor's and has breakfast [09:05] PR snapd#8071 opened: o/auth,daemon: do not remove unknown user [09:05] Chipaca: ^ [09:06] pedronis: you ok with the toctou race there? [09:06] Chipaca: for now yes [09:07] the current behavior is kind of worse [09:07] pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the system user, remove the home and spool [09:07] your question last night left me thinking and that's what i thought we'd do [09:07] er [09:08] insert 'release the lock' after 'remove system user' [09:08] Chipaca: well, if you think is doable simply enough you can do it on top of my PR [09:08] otherwise leave possible todo [09:08] gah i made a mess [09:08] pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the auth user, release the lock, remove the home and spool [09:08] ^ there better [09:09] the split of the current remove-user-and-home being so as not to hold the lock for ages [09:09] yes, I understand that [09:11] Chipaca: I also think that snap remove-user email should do something, given create-user email [09:11] but that we can deal with it [09:11] pedronis: given we're looking it up anyway, sure :-) [09:11] (it's a bit of a mess of its own) [09:12] because there might many users with the email and some might not have a username [09:24] o/ [09:24] how are you guys [09:28] zyga: we're latest/edgy [09:29] could be better [09:29] tired? [09:29] I'm energized, despite not sleeping much [09:39] mvo: pedronis: i've updated #8064 [09:39] PR #8064: boot: add Device iface to coreKernel [09:41] mborzecki: thank you! [09:44] did the change to warn about invalid seeds get done? [09:51] kenvandine: where should bugs for desktop-launcher go, on launchpad? [09:52] mborzecki: thanks, small remark [09:53] mvo: maybe you know ^^ [09:54] Chipaca: do you know the package name? I guess not :) or a binary name in /usr or something? [09:54] pedronis: ack [09:54] mvo: i mean the snapcraft desktop laucnher helper thing [09:55] desktop-helper? worker-dancer? warrior-priest? [09:55] Chipaca: haha - sorry, now I get what you mean [09:56] Chipaca: my guess is snapcraft itself but I'm not super confident, kenvandine will know but it's very early for him I guess [09:57] you mean kenvandine isn't a robot? [09:57] mvo: I think I'm leaving #1861177 as New so either you or Ian take a look at it when it's your triage day [09:57] Bug #1861177: seccomp_rule_add is very slow

[09:59] Chipaca: nice! let me check that [09:59] Chipaca: that looks pretty neat [09:59] mvo: i'm assuming the bit :-) [09:59] not the actual 'iz slow' bit [10:03] Chipaca: yeah, the patch bit [10:10] mborzecki: feedback in 7972, looks very nice now [10:11] pedronis: I hope https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1860769/comments/3 isn't too much of a lie :-) [10:11] Bug #1860769: should record changes after snap transactions [10:14] Chipaca, https://github.com/ubuntu/snapcraft-desktop-helpers/issues [10:14] ogra: what part of 'on launchpad' is that [10:16] also why is that still pointing people to rocketchat [10:16] is rocketchat/snapcraft still a thing? [10:18] o idea, but that tree is the source people typically include in their snapcraft.yaml to get the launchers [10:18] s/o/no/ [10:29] mvo: can you take a look at #8064 ? [10:29] PR #8064: boot: add bootloader options to coreKernel [10:29] mvo: #8064 needs some kind of 2nd review [10:29] if it's ok, i'll land it an update 8001 accordingly [10:31] pedronis, mborzecki sure, on it [10:33] #8071 also needs a 2nd review [10:33] PR #8071: o/auth,daemon: do not remove unknown user [10:34] pedronis: was looking at this one as we speak :) [10:36] mborzecki: 8064 should be ok to land once gree and then we can pick up 8001 [10:36] green [10:36] PR snapd#8071 closed: o/auth,daemon: do not remove unknown user [10:36] pedronis: (post merge) https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285 [10:36] PR #8071: o/auth,daemon: do not remove unknown user [10:36] pedronis: ok [10:37] Chipaca: #8071 is in, you might want to update your PRs also consider zyga suggestion but I thought of it myself and not sure whether it makes the message too clunky [10:37] PR #8071: o/auth,daemon: do not remove unknown user [10:38] pedronis: which suggestion would that be? [10:38] Chipaca: https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285 [10:38] grah, it now conflicts [10:38] not fair [10:39] Chipaca: not suprising though, no [11:00] * Chipaca takes a break [11:14] PR snapd#8064 closed: boot: add bootloader options to coreKernel [11:21] Hey folks, I ended up with 6 loop devices with deleted snap squashfs: https://paste.ubuntu.com/p/ry5ZKGqxCS/ [11:21] hey [11:21] This machine has an uptime of 9 days [11:21] It's running focal [11:21] this is a known issue, it feels like a systemd / libmount bug [11:21] we never manage loop devices ourselves [11:22] it is reported on launchpad [11:22] hmm [11:23] The problem is that, as mentioned on #ubuntu-devel, these now show up in nautilus, confusing users (in this case, me) [11:23] Not sure how to solve that [11:24] Probably udisks should look if backing file is in /var/lib/snapd/snaps, and then set HintIgnore to true [11:31] there's logic like that [11:31] it's a different problem [11:31] it shows up as deleted, unmounted loop device you can mount (??) by clicking on it [11:31] but it isn't possible because it is deleted [11:32] I really don't know what to do about it, apart from chasing kernel/libmount/systemd internals [11:32] I think we used to have a reproducer script [11:32] but perhaps I'm confusing this with another issue [11:40] zyga: Oh you can absolutely mount them, the loop device still has an open file descriptor, so the inode is never actually freed [11:41] the loop devices, yes [11:41] the backing file they used is not linked to the filesystem anymore (but still takes space) [11:41] yes [11:43] Couldn't snapd like look once each hour / after it updates a snap for loop devices that point to deleted snap files and delete them? [11:44] Hah no [11:44] If I losetup -d the loop device it remains active [11:45] well, effectively systemd should do this [11:45] ogra: But I can't even do it manually, so something is off there [11:45] Ah [11:46] So closing my telegram window removed the loop device [11:46] Which I guess means the loop device is used in a different mount namespace? [11:47] hmm, doesnt for me .... but then ... unity7 here ... [11:47] OK, I also ran losetup -d multiple times before, it might have marked it for dettachment [11:47] yeah, that might be [11:51] Confirmed [11:52] The lxd snap still has deleted loop devices mounted [11:52] /proc/1425517/mounts:/dev/loop53 /bin/kmod squashfs ro,nodev,relatime 0 0 [11:53] and various other processes [11:55] I don't understand why the mount point is listed as /bin/kmod, though [11:57] Running unmount /bin/kmod inside the namespace a few times made all except one lxd snap loop device go away [11:57] lxd modprobing something inside the container ? [11:58] probably squashfuse related ? [11:59] juliank: if you come up with a reliable way to reproduce [11:59] we can start chasing this more aggresively [12:00] aggressively [12:08] hmm I'm not sure I have time to come up with a reproducer [12:09] Given the number of lxd in there, I'd sort of expect that just switching around lxd versions should trigger this, but not tried it [12:17] PR snapd#8070 closed: dirs: fixlet for XdgRuntimeDirGlob [12:57] mvo: is #7999 ready for re-review? [12:57] PR #7999: devicestate: allow encryption regardless of grade <⛔ Blocked> [13:11] pedronis: yes, I think so [13:13] mvo: it's failing though? it's a new initramfs to land? [13:13] *it needs === ricab is now known as ricab|lunch [13:25] pedronis: yeah, I pinged dimitri earlier [13:26] pedronis: but yeah, this will only work once the initrd can open it [13:32] mborzecki: can you look at https://github.com/snapcore/snapd/pull/8067#discussion_r372947893 please [13:32] is that sensible? [13:32] if so I'll make that happen and we can merge this [13:32] maybe for .3? [13:32] PR #8067: cmd/snap-confine,tests: support x.y.z nvidia version [13:32] mvo: we will have .3 - correct? [13:33] zyga: well, maybe [13:33] zyga: there is a (small) chance that we can get away witout [13:33] without [13:44] brb [13:44] see you at the standup [13:55] morning folks [13:58] ijohnson: hey [13:58] hey mborzecki [13:58] ijohnson: 8064 landed, i've pushed some updates to #8001 and doing a little cleanup now, i'll push it after the standup hopefully [13:58] PR #8001: boot: enable UC20 kernel extraction and bootState20 handling [13:59] mborzecki: ack thanks for doing that [13:59] ijohnson: or maybe i should push it to my fork, in case it's too dramatic :) [13:59] mborzecki: how dramatic of a change is it ? [14:00] ijohnson: splitting the boot state update 20 commit() into separate successful/candidate kernel code paths [14:01] mborzecki: you meant a separate commit for setNext and markSuccessful ? [14:01] err commit() method I mean [14:01] ijohnson: yeah, actually doing that via 2 separate types, each implementing bootStateUpdate [14:01] mborzecki: smells a lot like my rewrite I have locally for the next step with base snaps [14:02] hahah ;) [14:02] mborzecki: but sure feel free to push it, I can always re-work mine on top of yours [14:26] Hi, should i ask here, or on #maas, about: [14:26] # snap install maas [14:26] 2020-01-30T14:25:28Z INFO Waiting for restart... [14:26] error: cannot perform the following tasks: [14:26] - Run configure hook of "maas" snap if present (run hook "configure": chown: changing ownership of '/var/snap/maas/common/log/proxy': Operation not permitted) === ricab|lunch is now known as ricab [14:38] mborzecki: let me know when you've pushed that up [14:38] ijohnson: sure [14:38] sdhd-sascha: chown is usually not allowed, the exception is chown to a special snapd daemon user [14:39] sdhd-sascha: I'm not sure if that's what maas is doing [14:41] zyga: i just installed the `apt` version. I tried the snap inside of lxd ... [14:42] maybe, i look later deeper into the script. [14:42] sdhd-sascha: I don't know how that's related [14:43] mvo: Chipaca: I'm having a break, ping me later when you want to chat about download [14:43] I'll grab lunch/dinner now [14:43] and finish my cold soup :) [14:52] pedronis: are you ok with picking 8067 for 2.43? if we have to do a release it seems like a nice and simple fix [15:02] pedronis: mvo: mborzecki: sorry I forgot to inquire during SU, but shall I go with mvo's suggestion and extract the initramfs-mounts bits from #8001 into a separate pre-req PR, or are we looking okay to merge with that in there? [15:02] PR #8001: boot: enable UC20 kernel extraction and bootState20 handling [15:04] mmm [15:04] yummy food today :) [15:04] polish salad and veggie soup :) [15:04] mvo: you should try the polish salad one day [15:05] mborzecki: ^ do you know how it's called in English? [15:11] random falures [15:11] just love'm [15:11] mmm failure :D [15:12] just slower, travis stopped [15:12] eh === heather is now known as hellsworth [15:30] ijohnson: meh, i don't think i'll push it anytime today, got more complicated that i hoped [15:31] ijohnson: well, I reviewed that code and what it needs is really to be some kind of helper, I don't think splitting helps at this point [15:31] but maybe other reviewers have other preferences [15:36] zyga: polish salad? [15:36] mborzecki: yeah... geez how to explain that [15:36] zyga: photo? [15:36] https://www.google.com/search?q=sa%C5%82atka+jarzynowa [15:36] something like this? [15:40] zyga: ah, well, no clue whether there's an generally accepted english name for it, veggie salad? boiled veggie sald? [15:40] but it's nothing like I've seen in other countries [15:40] anywy [15:40] we need a sprint in poland [15:40] lodz would be great [15:41] :) [15:47] mvo: pedronis: shared a doc with you about download. GOing to step out for ~40 minutes, let's talk when i get back? [15:48] Chipaca: ok [15:48] PR snapcraft#2894 closed: Fix issue with multipass mount on win32 [15:48] PR snapcraft#2895 closed: lifecycle: raise detailed error if mksquashfs fails [15:54] PR snapcraft#2897 closed: meta: include environment in hook wrappers [16:00] PR snapcraft#2898 closed: meta: remove dead code from snap packaging [16:07] pedronis: ok I asked mvo about splitting it and I think it's best to leave it in for now, and I can refactor the bootloader kernel bits in initramfs-mounts into a helper later [16:09] mborzecki: sure, I will go through the rest of the comments in 8001 and address them then, perhaps you can cleanup anything else you need tomorrow AM === heather is now known as hellsworth [16:40] how can i debug or step this process: [16:40] ``` [16:40] $ sudo snap refresh lxd [16:40] error: snap "lxd" has "auto-refresh" change in progress [16:40] ``` [16:40] stop [16:45] Chipaca: back? [16:49] pedronis: back [16:49] sdhd-sascha: snap watch --last auto-refresh [16:51] Chipaca: thank you. It's seems to hang [16:51] sdhd-sascha: snap tasks --last auto-refresh would be the next thing to look at [16:55] Chipaca: should we have the chat? [16:55] Is it normal, that three times `snap-confine` runs, like this: [16:55] ``` [16:55] $ ps -Af | grep lxd [16:55] root 3504 1 0 Jan29 ? 00:00:49 lxcfs /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid [16:55] root 264698 2355 0 05:10 ? 00:00:02 systemctl start snap.lxd.activate.service [16:55] root 264699 1 0 05:10 ? 00:00:00 /bin/sh /snap/lxd/13073/commands/daemon.activate [16:55] root 264758 264699 0 05:10 ? 00:00:00 lxd activateifneeded [16:55] root 2561183 1 0 17:53 ? 00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon [16:55] root 2561205 2561183 0 17:53 ? 00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon [16:55] root 2561206 2561183 98 17:53 ? 00:00:21 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon [16:55] root 2561767 2554559 0 17:53 pts/7 00:00:00 sudo systemctl restart snap.lxd.daemon.service [16:55] root 2561768 2561767 0 17:53 pts/7 00:00:00 systemctl restart snap.lxd.daemon.service [16:56] pedronis: I'll ping mvo and get a cuppa and yes [16:56] Chipaca: I'm in the standup [16:56] Chipaca: here [16:57] * sdhd-sascha I killed all the process. Now it seems to work [17:40] * Chipaca resumes all the downloads [17:45] PR snapd#8067 closed: cmd/snap-confine,tests: support x.y.z nvidia version [18:27] PR snapcraft#2900 opened: Travis pr snapstore [18:51] Chipaca: I added to your doc [18:52] pedronis: thanks [18:52] pedronis: I don't think I can wrangle that in tomorrow tho [18:52] pedronis: that == the hmac option [18:52] Chipaca: that's fine, it's not hard to add once we have the basics [18:52] of the rest [18:52] HEAD support and resume params [18:52] that one i probably can get up tomorrow :) [18:57] ijohnson: as far as I can tell this are the not yet applied/answered things in #8001: https://github.com/snapcore/snapd/pull/8001#discussion_r368975082 , https://github.com/snapcore/snapd/pull/8001#discussion_r372449659 , https://github.com/snapcore/snapd/pull/8001#discussion_r372451326 [18:57] PR #8001: boot: enable UC20 kernel extraction and bootState20 handling [18:58] pedronis: this is what I have that I'm doing now https://pastebin.ubuntu.com/p/YsN6rDWqq4/ [18:59] sounds right [18:59] so I think your 3 things are contained in that [19:01] good that we found the same things just about [21:01] PR snapcraft#2899 closed: ci: publish the CI built snap to the Snap Store