[05:04] PR snapd#7598 closed: test/lib/names.sh: make backslash escaping explicit [05:12] morning [05:19] mborzecki: good morning [05:20] yay 7536 landed :P [05:20] PR snapd#7536 closed: gadget: accept system-seed role and ubuntu-data label [05:20] mvo: thanks! [05:20] mborzecki: yes, finally :) [05:24] i've updated #7593 [05:24] PR #7593: recovery-tool: add sfdisk wrapper [05:24] and there are some comments from zyga too [05:24] hmm, new kernel, i better reboot [05:24] brb [05:28] and back on 5.3.6 kernel [06:50] PR snapd#7599 opened: gadget: refactor ensureVolumeConsistency === pstolowski|afk is now known as pstolowski [07:04] morning [07:08] pstolowski: hey, good morning! [07:18] pstolowski: hey [07:21] hello? [07:21] is this thing on? [07:21] I think I connected now [07:23] sorry for starting late, lucy was sleeping hugging me all the time and got grumpy the second I tried to put her to bed [07:24] zyga: hey [07:24] mborzecki: hey, question on how to proceed for you [07:24] mborzecki: I removed the guts of snap-update-ns so that I can create other tools with the same logic [07:25] mborzecki: I moved it to system/mount for lack of a better name [07:25] mborzecki: some bits can go to sandbox/cgroup [07:25] mborzecki: but most has no good place to go [07:25] mborzecki: ideas? [07:26] mborzecki: I'm mainly after plan-writable-mimic and execute-writable-mimic [07:26] mborzecki: this pulls in change, assumptions, restrictions and tresspassing [07:27] mborzecki: along with loads of tests [07:27] mvo: i'm looking at 7593, perhaps our consistency checks are too strict, in particular the len(volumes) != 0 only counts when constraints are used, but once there's a system-seed structure defines and SsytemSeed is not true, then we bail out, why not allow this case? [07:28] zyga: that's part of mount related logic though? [07:28] zyga: or hmm we call it namespace (or whatnot) often [07:28] mborzecki: mainly yes [07:28] zyga: system/mount/namespace? [07:29] mborzecki: I'd go for system/mount really, it would help abbreviate the API names and would look nice [07:29] mount.Change [07:29] mount.Assumptions [07:29] mount.Restrictions [07:29] etc [07:29] system/mounts stgm too [07:29] though [07:29] my main question is: can we use main :) [07:29] er [07:29] system/ [07:29] or is that too vague [07:29] I want to have this because otherwise debugging some issues is very hard [07:30] and having an interactive tool where you can do stuff is very useful to understand things misbehaving [07:30] and sadly it's forbidden to import from "main" packages [07:30] zyga: hm we have osutil which kind of is system like already, and there's some mount related stuff in there too [07:31] mborzecki: yeah but any existing package may trigger import loops [07:31] zyga: osutil/mount ? [07:31] I can tryt [07:31] *try [07:31] let's see if that works [07:31] mborzecki: do you know if go has some rules on what is in a binary [07:31] if there's a package foo/bar [07:31] and I use only bar.Symbol [07:32] does it include all of foo? [07:32] zyga: no, bar is bar, foor is foo [07:33] mborzecki: so foo does _not_ bloat a binary using bar? [07:33] mborzecki: and the reverse case? [07:33] mborzecki: is presence of foo/bar affecting a binary that only uses symbols from foo? [07:33] zyga: same, no effect unless you import it, or it's imported internally [07:33] zyga: or you created an import loop :P [07:34] ok, let's give it a try [07:37] mvo: simply put, if i have a gadget yaml with system-seed and system-data, and use an empty ModelConstraints (just want to have consistency checked), this will error out [07:44] mborzecki: I need to look, could you please add a note in the PR? maybe we are too strict .) it seems like the refactor helped to reason about this easier [07:44] mborzecki: I'm in the middle of 7593 right now [07:44] mvo: ah ok, started to play with thhis code too, i'll leave a comment in the PR then [07:48] mborzecki: or feel free to propose a pr on top if you feel this should be ok, either way is fine with me :) [08:02] ackk: hey, in snapd 2.42 we improved the fuse performance in lxd, I heard maas is using this a lot, did you see improvements? [08:06] 👋 [08:08] hello Chipaca [08:09] mborzecki: the easy branch https://github.com/snapcore/snapd/pull/7600 [08:09] PR #7600: sandbox/cgroup: move freeze/thaw code [08:09] PR snapd#7600 opened: sandbox/cgroup: move freeze/thaw code [08:26] pedronis: 👋 [08:27] pedronis: did you see my question about the quotes in the repair script? [08:27] yes, but I didn't understand it [08:27] maybe mvo does [08:28] pedronis: you didn't understand the question, or the origin of the quotes? :) [08:29] Chipaca: good morning! I did not see the quotes at all [08:29] Chipaca: oh, fun! [08:29] mvo: snap known --remote repair brand-id=canonical repair-id=1 [08:29] mvo: the script has typographic quotes [08:29] Chipaca: I think it's copying from a gdoc [08:29] Chipaca: haha - I see it now [08:29] mvo: that might be intentional, but I doubt it [08:29] that did that [08:30] Chipaca: yeah, it was not [08:30] yeah, that would do it [08:30] Chipaca: we need to improve the way we sign assertions [08:30] Chipaca: or let assertion sign :) [08:30] Chipaca: THANKS for spotting this [08:30] it's silly that I worry about this, but I worry because although "echo" doesn't care, there's not a lot more that is as amicable [08:30] Chipaca: oh, totally [08:31] Chipaca: we need to improve our process here [08:31] that's all i needed to hear to stop worrying about it :-) [08:31] Chipaca: I'm editing a gdoc now so that we don't use gdocs for this :) [08:34] mvo: added a bunch of comments in #7593, i think some relate to how the seed/recovery is supposed to work, can you take a look and maybe we could discuss that with whoever is interested before/after the standup? [08:34] PR #7593: recovery-tool: add sfdisk wrapper [08:36] mborzecki: I'm stuck [08:36] mborzecki: the challenge is as follows: [08:36] mborzecki: there's lots of tailored mocking going on [08:36] mborzecki: in osutil/ snap-update-ns and now in osutil/mount [08:37] mborzecki: then there's the general mocking all syscalls that are used in snap-update-ns [08:37] mborzecki: if you try to reconcile all of that it's a big mess [08:37] mborzecki: thinking about it, I see the following way forward and perhaps out of the problem as well [08:37] mborzecki: we can make a new package syscalls/ that has just the system calls and a means to mock them [08:38] mborzecki: as things move out of snap-update-ns, they get updated to use this package over the private mocking code used locally [08:38] mborzecki: then some parts of snap-update-ns, for example all the mk{dir,file,symlink} and openpath code move to osutil/ [08:39] (or osutil/mk... if that helps to scope it) [08:39] mborzecki: while the real essence of mount, like secure bind mount, mimic logic, can move to osutil/mount [08:39] or even osutil/mimic [08:39] mborzecki: moving everything in bulk might help in the short term [08:40] mborzecki: but won't change how those things are messy internally when considered along with the rest of osutil [08:41] heh, if you move some of the calls to osutil there's probably going to be some funky import dependencies [08:42] mborzecki: there already are, much of the code uses osutil already [08:43] mborzecki: how would you feel about the syscalls package? [08:43] mborzecki: the public API would be various system calls [08:43] mborzecki: and a means to mock them all (e.g. with the recorder already present in another package) [08:44] zyga: there's stdlib syscalls already, could those wrappers just live in osutil instead? [08:44] mborzecki: yes but I'd like them not to [08:44] osutils is already kind of large [08:44] but most importantly it already has a number of them and some mocking [08:45] mborzecki: (mock-this, mock-that, not in general) [08:45] mborzecki: the idea is that eventually, over time, code could move to use the new pakcage [08:45] and drop its own mocking [08:45] mborzecki: this is why I think a new package would help [08:45] mborzecki: if we move them over to osutil right now you will see a number of separate mocking systems that need to be reconciled [08:46] zyga: osutils/syscalls? with a godoc that 'here lie the syscalls we can mock' ? :) [08:46] :D [08:46] mborzecki: that works for me [08:46] mborzecki: importantly, mock in bulk [08:46] not one by one [08:47] mborzecki: osutil/sys [08:47] ? [08:47] right, avoids a name clash with stdlib's syscalls [08:48] would gadgets on top of debian work or is there any special-casing-code that only allows them on ubuntu classic ? [08:49] Chipaca: would you prefer if this was in osutil/sys? [08:59] brb [09:12] zyga: i'm not sure quite what you're asking, but, probably? the difference between osutil/syscall[s] and the existing osutil/sys escapes me [09:19] zyga: what are the changes to snap-update-ns about ? [09:28] pedronis: being able to expose the internals for interactive debugging [09:28] zyga: what's the context? are you chasing a bug? [09:29] Yes, correct. [09:29] which one? [09:29] I did that yesterday and thought that some of those could land [09:29] Not all changes are easy though [09:31] zyga: I fear I still don't have enough context, maybe you need to propose the mess as is, and I can look what to do with it [09:31] when I have a bit of time [09:33] I think some bits are easier than others but the main value already exists. In a branch I can build mimic-tool to experiment and see where the kernel behavior is coming from [09:34] zyga: still no context [09:39] Finishing breakfast, I’ll be back soon [09:41] mborzecki: I addressed a bunch of your comments in 7593, I am looking into using "-apend" now [09:42] mvo: thanks! btw. that's an interesting find about blockdev [09:43] mborzecki: thank you for pointing this out! [09:43] mborzecki: blockdev seems to be part of busybox fwiw [09:43] mvo: ah, that makes sens [09:44] mborzecki: also thanks for the comment about -apend, I was wondering about this myself but wasn't aware of -append :) [09:44] PR snapd#7601 opened: overlord/ifacestate: use SetupMany in setupSecurityByBackend [09:45] mborzecki: what's the status of #7079, is it being absorbed by the snap-recovery work? [09:45] PR #7079: [RFC] cmd/snap-image: tool for building UC images [09:47] pedronis: not really, parts of it probably affected snap recovery work, but iirc claudio did not pull in any patches directly [09:47] mvo: are we going to do a 2.42.1 ? mvo, pstolowski: when should we try to land #7092, it's unblocked now? [09:47] PR #7092: packaging: use snapd type and snapcraft 3.x [09:47] pedronis: though, the sfdisk parts should be consolidated into the gadget package since we alredy have some code there [09:48] mborzecki: it sounds like we would redo it on top of the recovery work at this point, no? [09:48] should it be closed? [09:48] pedronis: other than that, the tools are run in different environment and differnt part of the cycle [09:50] pedronis: i can close it for now and we can discuss what to do witht he tool separately [09:50] ok, sounds good [09:51] mborzecki: to be clear, the medium term plan is still for ubuntu-image to be a thin wrapper around snapd code, but I don't we want to land two codebases doing partions into snapd, we probably want to get to one codebase surface maybe in two slightly diffferent ways [09:52] PR snapd#7079 closed: [RFC] cmd/snap-image: tool for building UC images [09:53] pedronis: yes i think we should land 7092. going to deconflict it [09:54] * Chipaca brb [09:55] mborzecki: I think 7593 is good for now, I want to do a followup with some real sfdisk tests but that will probably become quite a bit bigger [09:56] mvo: do you think it'd make sense to move the code that creates a LaidOutVolume out of sfdisk dump into gadget/partition.go ? [09:57] PR snapd#7222 closed: tests: show just the last log as part of the debug output when check journal logs [10:00] mvo: mborzecki: volmgr is a strange name, it makes one think LVM [10:01] makes me think of androids vold ... :) [10:03] Voldmgrd [10:03] ;-) [10:03] pedronis, do you knwo off the top of your head if it is seamlessly possible to use gadget snaps on debian systems (i.e. to attach to a brand store or add certain interfaces) or does snapd currently restrict this to ubuntu systems ? [10:06] pedronis: we could move it to osutil/fdisk ? [10:06] PR snapd#7600 closed: sandbox/cgroup: move freeze/thaw code [10:07] mvo: probably not osutil given it uses types from gadget [10:07] it could be under gadget [10:07] pedronis: good point [10:08] pedronis: or just cmd/snap-recovery/fdisk ? [10:08] that's fine too [10:08] mostly against the volume manager terminology [10:09] pedronis: cool, I will rename to fdisk for now, I think it will later grow luks and stuff but even that seems to be ok to put under fdisk [10:10] mvo: gadget/partition ? [10:11] (I'm fine with fdisk as well) [10:13] pedronis: yeah, partition works for me, shall I keep it under cmd/snap-repair for now or do you prefer gagdet? [10:13] mvo: as your prefer, discuss with mborzecki [10:14] pedronis: thanks, will do [10:26] got ubuntu-core-18-64:tests/core18/snapd-failover failure in one of my PRs: 2019-10-15T10:05:40Z INFO Waiting for restart... [10:26] error: cannot perform the following tasks: [10:26] - Mount snap "snapd" (unset) (remove /etc/systemd/system/snap-snapd-x2.mount: no such file or directory) [10:26] - Automatically connect eligible plugs and slots of snap "snapd" (there was a snapd rollback across the restart) [10:46] Bug #1835024 changed: Links triggered within most snap apps open in a separate browser session

[10:50] Bug #1801201 changed: Installed snap icons missing if using pixmap [10:50] Bug #1809729 changed: Removing a snap triggers 'Starting scheduled backup' notification

[10:56] Bug #1773416 changed: Interface from Thunderbird/Firefox to LibreOffice/VLC [10:56] Bug #1797745 changed: "ln: failed to create symbolic link" in deepin 15.7 [10:59] it is frustrating when lxd and snapd use different bug trackers [10:59] and that launchpad does not automatically ping-back the other bug when an URL is mentioned. [11:00] stgraber: hello, could you kindly look at https://bugs.launchpad.net/snappy/+bug/1773044 and if appropriate, convert it to an LXD bug on github please. [11:00] Bug #1773044: Can't get snap gui apps (notepadqq and firefox) to run in LXD/LXC container [11:02] Bug #1773044 changed: Can't get snap gui apps (notepadqq and firefox) to run in LXD/LXC container [11:05] zyga: doesn't look like a bug, just misconfiguration by the user. I suspect they've bind-mounted the X11 socket which works fine for everything but snaps as snaps need the abstract Unix socket instead [11:05] Bug #1763071 changed: Error message installing a paid snap as unauthenticated user [11:05] Bug #1765979 changed: snap applications icons missing in launcher wayland [11:05] Bug #1766079 changed: ripgrep installed via snap fail to work in /lib/systemd/system folder [11:06] zyga: I kind of wish that snapd didn't use launchpad as the bug tracker [11:06] diddledan: Dear Tea., … ? [11:06] it's surprisingly difficult to locate bugs in launchpad [11:06] Eighth_Doctor: that makes 1002 of us [11:07] Eighth_Doctor: at least we're looking now :) [11:07] Eighth_Doctor: progress! [11:07] yeah [11:07] the only really useful feature of launchpad is multi-tracker aggregation [11:07] that's actually a powerful feature if it worked more... [11:08] Bug #1758465 changed: snapd doesn't upgrade on bionic when a local installed snap mount is failing [11:08] hmm? [11:08] diddledan: https://forum.snapcraft.io/t/need-to-add-our-product/13694?u=chipaca [11:08] aha [11:09] yeah, I think they missed an M [11:09] zyga: but does this mean I need to clone rhbz bugs to LP to get them fixed? ☹️ [11:10] Eighth_Doctor: why would you do that? [11:10] ah [11:10] I see [11:10] are you saying that we should look at RHBZ bugs as well? [11:10] yes [11:11] Bug #1750856 changed: snapd on s390x tried to run locationd tests, which does not exist on s390x [11:11] Bug #1752916 changed: Desktop interface should allow accessing to recent files and xdg dirs [11:11] I've been doing some of the triage for a while now, but if there's an actual code problem, it's a bit difficult to escalate because I don't know how to get people's attention on it [11:11] zyga: we do look at ubuntu/+source/snapd bugs, so why not rhbz bugs? [11:11] mvo: could you kindly check if the bionic task of this bug is still valid https://bugs.launchpad.net/snappy/+bug/1750856 [11:11] Bug #1750856: snapd on s390x tried to run locationd tests, which does not exist on s390x [11:11] Chipaca: I agree, it's just a matter of manpower and gardening the mess first [11:12] Eighth_Doctor: we have a recurring triage work, at some point we'll run out of overflowing NEW bugs and can look at existing bugs [11:12] Eighth_Doctor: can you point me to the list of snapd bugs in RH bugzilla please [11:12] Eighth_Doctor: I'll add that to our laundry list [11:13] http://bugz.fedoraproject.org/snapd [11:13] I need to write a script to mass-close all these SELinux bugs [11:13] WONTFIX :-p [11:13] I'm pretty sure a large chunk of those are from before the policy rewrite that mborzecki did in May [11:14] how do we feel about snaps that tell users to do things that could easily trick them to run things unconfined? [11:14] Bug #1748510 changed: shell's test gives false positive on readability of files [11:14] Chipaca: RUN THIS SNAP WITHOUT PESKY ERRORS WITH THIS ONE TRICK [11:14] Chipaca: that sounds dirty [11:14] zyga: you'll never believe what happens next [11:14] diddledan: I know, I know [11:14] zyga: protip, all Fedora packages actually have a BugURL property set on them ;) [11:14] sudo wget | sh [11:15] 'loopchain' (brought to my attention by requesting a track) is like this [11:15] it's always like tat [11:15] *that [11:15] love those instructions appearing everywhere because macOS [11:15] `rpm --query --queryformat "%{BUGURL}" snapd` [11:15] it doesn't seem to be immediately bad, but it makes me feel a little uncomfortable [11:16] "to install, first snap install this, then apt install rabbitmq, then run thesnap.init, then run the scripts it wrote in $SNAP_COMMON [11:16] " [11:16] zyga: thankfully all these Fedora 29 bugs go away when F29 EOLs next month [11:16] * Chipaca would NOPE out of that really fast, but some users are perseverant... [11:16] or "run `$(thesnap.init)` [11:17] Bug #1747200 changed: console conf crashes on dragonboard [11:17] diddledan: sudo $(thesnap.ok) [11:17] Chipaca: you didn't think snaps would actually stop people from doing dumb things, did you? 😶 [11:17] Eighth_Doctor: that's a bit annoying on the user side but that's very convenient for the developer side :) [11:17] diddledan: they will all need to change to curl | zsh [11:17] well, it's the only way I maintained my sanity with snapd bugs [11:18] and sudo won't help since macos is locked down more than ever now [11:18] macOS has become an annoying platform to be a developer on [11:18] Eighth_Doctor: https://www.youtube.com/watch?v=TL0dfzK3Aqs [11:19] love that song [11:19] it's a good song [11:19] and very appropriate here [11:19] BUT THE SUDO COMES AT NIGHT [11:19] Eighth_Doctor: i'm quite sure there's still a bunch of things popping up when installing snaps :/ [11:20] is lxd security.nesting enabling nested apparmor? [11:20] Bug #1744584 changed: Exclude Snap .cache from Dejadup backups

[11:20] yeah [11:20] it's a lot less nowadays, thankfully [11:20] and some of the warnings I don't want to fix [11:20] Eighth_Doctor: i should try installing some snaps on my wife's lapotp to catch them all :P [11:21] there are cases where it's actually bad behavior it's blocking, and I'm okay with the denial status [11:21] zyga: sure, done [11:23] mborzecki: the issue right now is that Silverblue users are upset that snaps using the "home" perm fail to start because of `/var/home` [11:24] there's a symlink for `/home` to `/var/home`, but that isn't enough for snapd, I guess [11:24] mvo: thank you [11:24] Eighth_Doctor: there's been some patches to make /var/home work already [11:24] Eighth_Doctor: though we obviously lack the full test [11:25] zyga: oh cool, can I cherry-pick that into 2.42 release for Fedora? [11:25] Eighth_Doctor: it's not the full fix yet, just initial patches [11:25] I haven't pushed it yet because this bug just came up as I started working on it [11:25] Eighth_Doctor: base snaps will have /var/home so we can start binding onto it [11:25] ah, I see [11:26] we'll need to keep that in mind for fedora base as well [11:26] Bug #1732494 changed: Impossible to manage package after Trusty --> Xenial upgrade

[11:26] mvo: do you have access to launchpad.net/snapd project description? [11:26] mvo: it would be good to change the first line [11:26] mvo: now it reads "code hosted at URL" [11:26]