[03:09] PR snapd#7900 opened: tests: do reset of tests during restore and add checks to validate the fs [06:20] PR snapd#7901 opened: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests [06:39] morning [07:18] mborzecki: hello [07:18] zyga: hey [07:34] zyga: #7901 trivial PR [07:34] PR #7901: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests [08:03] mborzecki: thank you and done :-) [08:03] zyga: yay :) thx [08:08] good morning [08:08] pstolowski: hey [08:14] hey pstolowski and mborzecki [08:14] mvo: hey [08:18] sdhd-sascha: 7881 looks like it can land. did you sign the CLA already? [08:19] Good morning [08:19] mvo: i think i have signed it on launchpad and on some homepage. Not sure if it was the same [08:21] sdhd-sascha: cool, thank you [08:26] PR snapd#7881 closed: intrefaces: login-session-control - added missing dbus commands [08:26] 7858 looks like an easy win, just needs a second review [08:28] PR snapd#7901 closed: run-checks: check multiline string blocks in restore/prepare/execute sections of spread tests [08:44] hey mvo [08:45] hey zyga [08:45] sorry for starting late, I had some things at home that needed my time [08:45] thanks mborzecki for the 7899 review! [08:45] I need to work a little over weekend [08:45] and catch up [08:46] mvo: np, did't want to commit that whitespace change since travis is already running, we can clean it up when doing some later changes [08:47] mborzecki: yeah, I would prefer to land and fix in one of the followups [08:50] mvo: maybe you have permissions to push to https://github.com/snapcore/snapd/pull/7896 [08:50] PR #7896: interfaces/wayland: Add access to Xwayland's shm files [08:51] mborzecki: I have the same issue, look like only Alan can do this :/ [08:51] PR snapcraft#2797 closed: meson plugin: add support for core20 [08:52] oh, well, we'll just have to wait then [09:02] PR snapd#7899 closed: many: pass consistently boot.Device state to boot methods [09:05] mborzecki: hey, re: the qemu-img AppArmor denial, does this change look sane https://paste.ubuntu.com/p/k8Shd4WyCP/ (where %3…%4 is the full path to qemu-img) ? [09:05] should we have "m" for all the executables we want to run? [09:05] (and why isn't this required on Ubuntu ¿?) [09:22] Saviq: does it work on debian with apparmor? [09:22] mborzecki: we don't use apparmor on debian [09:22] Saviq: or opensuse for that matter [09:24] zyga: it's multipass, and it's classic, from what i can tell, it'll try to use aapparmor when aa_is_enabled returns it's on [09:25] ah [09:25] that's interesting [09:25] more confined than snaps :) [09:25] Saviq: on debian all file rules work the same [09:29] zyga: this is what I got on arch yday: https://github.com/CanonicalLtd/multipass/issues/1223 [09:30] zyga: unclear why it's trying to map qemu-img for reading when there's supposed to be ixr permissions [09:32] looking [09:32] after some kernel version "m" became required as well [09:34] mvo: thanks for landing my PRs, hope they weren't too confusing ... [09:38] PR snapd#7889 closed: overlord,o/snapstate: make sure we never leave config behind [09:38] pedronis: hi, #7658 is ready for you re-review if you have a moment [09:38] PR #7658: cmd/snap-preseed: add snap-preseed executable [09:40] pstolowski: thx, saw that [09:40] pedronis: no, great stuff, I'm in the weeds of uc20 right now [09:41] Saviq: ok, got something that works https://paste.ubuntu.com/p/mV9fR5M3hf/ [09:41] Saviq: and looks like stderr may not be redirected when you're running qemu-img [09:42] Saviq: /snap is a symlink on arch & fedora [09:46] Saviq: ok, added a note too [09:46] I created the Done 2.44 lane [09:47] mborzecki: thanks! [09:51] PR core20#16 opened: bootstrap from locally build snapd snaps too [09:57] PR snapd#7893 closed: daemon,snap: remove screenshot deprecation notice [10:10] Why does the x11 interface has no support to access: @/tmp/.X11-unix/X[0-9]* [10:10] In the plug-case [10:10] pstolowski: https://github.com/snapcore/snapd/pull/7658#pullrequestreview-331769593 [10:10] sdhd-sascha: looking [10:10] PR #7658: cmd/snap-preseed: add snap-preseed executable [10:11] zyga: i see, there is access to Xauthority. But sway's source want to access the socket. [10:11] sdhd-sascha: did you look at abstractions/X? [10:11] zyga: thanks! [10:11] zyga: wait [10:11] sdhd-sascha: there are include rules in that snippet [10:11] sdhd-sascha: those go to /etc/apparmor.d/abstractions/X [10:11] I suspect it is handled there [10:12] pstolowski: description of https://github.com/snapcore/snapd/pull/7658 seems out of date, it sets SNAPD_PRESEED, not SNAPD_PREBAKE_IMAGE [10:12] PR #7658: cmd/snap-preseed: add snap-preseed executable [10:17] pstolowski: I made a countercomment to zyga comment about the help. [10:20] pedronis: the long description will never capture everything that is done by the implementation, nor should it, it should just be comprehensible [10:21] there are better places to capture details, like man pages for example [10:21] pedronis: but that's a minor point, I didn't block or intend to block over that [10:26] I made a middle ground suggestion [10:27] pedronis: this could use your input too https://bugs.launchpad.net/snapd/+bug/1856063 [10:27] Bug #1856063: snap set refresh.hold immediately triggers a refresh when set [10:27] pedronis: perhaps we should also set up automatic 2h refresh.hold for core devices too [10:28] mborzecki: no but open to other options [10:28] mborzecki: it's by design that core images try to refresh as soon as possible [10:30] mborzecki: multipass images are a bit of a odd case, because of how they tend to be used [10:30] pedronis: maybe something we could do from cloud-init level? [10:31] maybe [10:34] mborzecki: anyway I put some guardrails comment in the bug [10:34] pedronis: cool, thanks! [10:43] me just noticed a different papercut [10:54] zyga: ah, and there it is again. [10:54] Before i start to hack 'snapd', a RFC could be nice. I need to split X11 into a X11-provider and a X11-consumer. To make things work. [10:54] sdhd-sascha: why? [10:54] sdhd-sascha: provider is the slot, consumer is the plug [10:55] sdhd-sascha: they have separate properties [10:55] zyga: sway can run under X11, then the abstraction/X is enough [10:55] but currently it creates a X11 socket... [10:55] so i need the slot permissions, too [10:55] sdhd-sascha: if it creates an x11 socket in a common path it needs to have an x11 slot [10:55] sdhd-sascha: but is it a generic x11 server? [10:55] yes, but both didn't work [10:55] it's Xwayland inside X [10:56] sdhd-sascha: should it make sense to connect an app to sway instead of to the system x11 slot? [10:56] inside sway [10:56] i run on a system, without any gui [10:56] i have no system x11 slot there [10:56] sway snap is the only desktop [10:56] sdhd-sascha: I don't know the answers to my questions but I just want to highlight that splitting any interface into a -provide and -consumer is bad idea because it is already part of the existing design [10:56] sdhd-sascha: then you just should have an x11 slot IMO [10:57] you should probably talk to the guys in #mir-server ;) [10:57] (the mir-kiosk snap supports XWayland (in fact all apps use i3wm by default for fullscreen) [10:57] Well, i can look if the slot permission are good enough to work as plug too [10:57] ) [11:04] PR snapd#7902 opened: o/hookstate/ctlcmd: fix command name in snapctl -h [11:04] that's the papercut fix [11:07] Hey, if the slot permission is not enough. Then i could change to allow same names of slot and plug. E.g. allow X11 as slot and X11 as plug in the same snap. Or ? [11:09] ogra: thanks, i joined to #mir-server [11:09] pstolowski: thx for the review, I just noticed this randomly [11:11] https://bugs.launchpad.net/snapd/+bug/1856073 is interesting, systemd records the state of failed service unit and keeps it around even after the unit is gone, imo it's kind of useful, and don't think we should do anything about that [11:11] yw [11:11] Bug #1856073: Failed service state recorded by systemd even after snap removal [11:15] mborzecki: when does it forget though? next boot? never? or are we missing a daemon-reload? [11:16] pedronis: when one runs reset-failed or next boot (maybe reexec too) [11:16] ok [11:17] mborzecki: yea, I agree we shouldn't go to out of our ways to change this, unless it creates problems if you reinstall the snapd or if it was a missing daemon-reload [11:17] s/snapd/snap/ [11:27] mborzecki: it is useful, we can look at why snap install failed because services failed to start :) [11:28] pedronis: there's a command to explicitly forget [11:28] pedronis: otherwise it forgets on reboot, it's only in memory [11:43] zyga: is /var/lib/snapd stable across distros? [11:44] (for the /snap symlink) [11:45] Saviq: yes [11:45] Saviq: (thank god :D [11:46] indeed [11:46] Saviq: not sure how it relates to /snap symlink, do you mean the /var/lib/snapd/snap symlink? [11:46] (the one that points there) [11:46] zyga: we haven't checked hannah montana linux though ;) [11:46] Saviq: then indeed that is stable :) [11:46] zyga: I mean /snap → /var/lib/snapd/snap, yes [11:46] Saviq: that's 100% stable [11:47] mborzecki: :-) [11:47] mborzecki: cannot wait for a distro /apps and /system [11:47] zyga: don't you have one right now? :P [11:47] not exacly linux though [11:48] mborzecki: no, it's /Applications ;-) and it can be localized [11:48] (but without changing the filesystem) [11:54] jdstrand: (just FYI) https://github.com/snapcore/snapd/pull/7875#discussion_r357611665 [11:54] PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old [11:55] degville: I don't know if you ever worked with i18n in software, if you did it's old news, if you didn't you may find that interesting [11:57] zyga: thanks for the link - I did, briefly, when I was writing my own stuff, never from a real docs perspective. [11:58] and that was with Qt, which had a very set way of doing things. [12:12] brb, need to get coffee and warm up [12:12] I'm so cold this week :/ [12:14] zyga: it's been around 0 and raining here for a month, not to mention that the sun barely comes up at all :| I hate this time a year [12:15] zyga, you should move to spain ! [12:24] pokk: indoors? :) ? [12:24] pokk: my office is not insulated very well so it's ... very fresh in the morning [12:25] zyga: nah, we're used to cold weather so indoors it's decently warm. I'd much prefer -20 over this to be honest [12:25] pokk: where are you based if I may ask? [12:26] pokk: here it's around 3-7C during daytime and -1-ish at night [12:28] zyga: Sweden [12:29] pokk: ah, I guess you don't build uninsulated anything, unlike us here [12:30] PR snapd#7903 opened: overlord,boot: follow ups to #7889 and #7899 [12:31] PR snapd#7902 closed: o/hookstate/ctlcmd: fix command name in snapctl -h [12:33] pedronis: hey, i may need to discuss with you some aspects of services once again, it shouldn't take long. do you have a moment today? [12:34] pedronis: that follow-up is just extra test, right? [12:34] pedronis: looks good, just wanted to make sure I understand it [12:36] zyga: yes, just doing the thing people ask to improve the test [12:36] understood [12:36] thanks [12:39] pstolowski: maybe just after standup [12:39] pedronis: great [12:44] mborzecki: 7903 is probably for you when you have a moment (it's not urgent and it's small) [12:48] zyga: no, not really. Especially not the more newly built houses. We can take -30C without much problem here [12:48] degville: how should I submit comments for the glossary ? [12:49] pedronis: would it help if I paste it into a gdoc? or you can make the edits yourself, or leave a comment on the posts. Whichever is easiest for you. [12:50] degville: I just skimmed for now, I'll know more when I have done a good read through, I'll let you know (probably actually not today) [12:50] degville: thanks for it btw [12:51] pedronis: no problem, thanks! [12:51] I'm still adding things. [12:52] degville: a quick thing though, I think you go the description of core and core16 reversed, core is the one that includes snapd [12:52] s/you go/you got/ [12:52] pedronis: oops, thanks!! I'll fix that now. [12:52] core16 doesn't carry it and is not stable/done yet, that part is correct [13:01] brb [13:08] Hi! Is sergiusens off today (or is it the timezone difference he is not online ?) [13:09] I need to talk about https://github.com/snapcore/snapcraft/pull/2843 and know if that change is acceptable in principle [13:09] PR snapcraft#2843: snap: only ship .pyc files, strip shared objects [13:09] re [13:10] jdstrand: https://github.com/snapcore/snapd/pull/7875 is close and needs a small amount of iteration from you to land [13:10] PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old [13:12] om26er: he is off until next year, maybe cjp256 can help [13:19] om26er: it's an interesting one! it was in my queue to look at more closely today, but it's something sergiusens will certainly be opinionated about. :D [13:22] PR snapd#7896 closed: interfaces/wayland: Add access to Xwayland's shm files [13:28] cjp256 cool, we could have something similar for the python plugin as well, that will likely reduce the size of python based snaps [13:30] om26er, while that is really cool, it should be handled via a snapcraft.yaml option though [13:31] ogra I was writing a message to you to get your opinion as you had wrote on the forum about a similar topic [13:31] ;-) [13:32] i love the approach ... but as i said, it shuld be configurable ... [13:34] ogra the above proposed change is only for Snapcraft package itself. I will investigate into the python plugin and figure out how to do that for it, so other snaps could use that feature as well [13:34] (you might want to build an "arch all" python snap that only ships .py files by default ... i.e. the exact opposite) [13:34] ah, thought it was for the plugin actually [13:34] *I thought [13:39] i agree [13:39] ogra: i would have guessed the pyc was platform independent? is that not the case? [13:40] dunno, can you run a pyc file compiled on armhf on an amd64 machine ? i never tried [13:41] specially if it comes to HW related stuff like talking to sensors etc i suspect there are many arch specifics in the backend [13:41] *especially [13:41] pyc are platform independent... [13:42] k === ricab is now known as ricab|lunch [13:44] * om26er is working on a story on how he reduced a snap size by more than 60% [13:44] stripped shared objects, only shipped pyc files and by using Python 3.6 from core18 [13:44] i left my comments in the PR, but generalized stripping should be a flag soon enough (it's on my todo list). and I think it would be interesting to provide a flag for the *.py code, under circumstances we know it'd be OK [13:46] for the last it was only a matter of adding /snap/core18/current/usr/bin to PATH. [13:46] wonder if snaps are mounted at a different mount point on other distros ? [13:47] what was core18 added to path for? [13:47] thanks cjp256, I will take a look [13:48] cjp256 to reuse python3 from there instead of shipping a copy with my snap (saves 7mbs) [13:48] ah, well that's where I think you might run into problems if shipping only pyc [13:49] if core18 updates with a patched python that's somehow incompatible with the separately shipped pyc? [13:49] om26er, other distros might use some dir under /var/lib instead of /snap ... [13:50] /snap is very ubuntu specific [13:54] PR snapd#7904 opened: snapcraft.yaml: add type, build-base and adopt-info, rm builddeb plugin [13:55] will figure out a solution for that, likely by looking at $SNAP and finding core18 directory relative to that [13:56] @cjp256 that's indeed a challenge but I am hoping python in core won't have any API breaking changes, though I need to read a bit more into this to get an idea of how probably a failure is [14:12] mborzecki: would you please try https://github.com/CanonicalLtd/multipass/pull/1228#issuecomment-565418688 out when you have a moment? [14:12] PR CanonicalLtd/multipass#1228: [utils] resolve symlinks to snap directories (Fixes #1223) [14:12] zyga, if you have something like Debian or Fedora on hand, that would be great, too ↑ [14:13] Saviq: nice, you collect the build artifacts! [14:15] mborzecki: yeah, it was just too tiring to have to rebuild locally all the time :) [14:15] you're welcome to some code https://github.com/CanonicalLtd/multipass/blob/master/tools/report_build.py :) [14:16] pretty simple to use, too https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml#L139 [14:37] PR snapd#7903 closed: overlord,boot: follow ups to #7889 and #7899 [14:44] pstolowski: do you want me to just push to your snapcraft.yaml branch then? I think the only thing my branch has that yours doesn't is removal of the x-builddeb plugin [14:45] ijohnson: nope, it's fine, go ahead with yours (minus type:) [14:45] pstolowski: ack thanks, I think I might take a few of your changes to the tests though that I missed when writing it yesterday [14:45] thanks! [14:46] ijohnson: fyi, my branch incorporated some old changes from cmatsuoka, so it's really a team effort ;) [14:47] :-) [14:47] I will credit both of you in my commit message [14:49] sil2100: hey I was wondering about the UC images we have on cdimage, I'm wondering specifically what's the difference between http://cdimage.ubuntu.com/ubuntu-core/18/current/ and http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ ? the former seems regularly updated, but the latter hasn't been updated since august [14:49] (also let me know if you're the wrong person to ask about this) [14:51] * cachio lunch [14:55] Saviq: looking good, i was able to launch an instance [14:56] mborzecki: cool, can you try a mount, too, please? === ricab|lunch is now known as ricab [14:58] Saviq: mount failed: Error enabling mount support in 'lasting-mara' but nothing in dmesg, so probably not AA related [14:58] Saviq: any way to get some info why it failed? [14:58] mborzecki: journal for snap.multipass* [14:58] It try again with -vvv [14:58] *Or [14:59] Saviq: https://paste.ubuntu.com/p/5M9QQsCZyQ/ [14:59] oh, and i need sshfs? [15:01] ijohnson: hey, so the ones in the main directory are dailies built against edge, while all the others are built per given channel [15:01] mborzecki: in the instance, that is installed automagically, and also it should have continue regardless of the profile failing to load, since we skip AA on that… [15:01] so fix is incomplete [15:01] Saviq: what follows is: gru 13 15:58:45 galeon multipassd[897299]: Failed to install 'sshfs', error message: '' [15:01] * Saviq just got a fedora VM so should be able to repro [15:02] ijohnson: so the stable/ ones are built with stable snaps, and we currently only build those before every point-release actually [15:02] mborzecki: ah, so that's the real problem… wonder why, can you try `sudo apt install sshfs` inside the instance? [15:02] ijohnson: we have daily images built against edge (so the ones in /) and against beta (so the ones in /beta) [15:02] Saviq: ah, i've launched ubuntu core, let me try the regular distro [15:03] mborzecki: right, that would be it, oof [15:03] (we're working on a static sshfs snap to work on Core, too) [15:04] https://snapcraft.io/install/multipass/fedora this is so awesome :D [15:04] Saviq: hmm some trouble when stopping the vm https://paste.ubuntu.com/p/ktdPWR7XCX/ [15:05] mborzecki: it stopped, didn't it? ;P [15:05] * Saviq will try to stop Core [15:08] Saviq: you want /{,var/lib/snapd/}snap/core18/*/{,usr/}lib/@{multiarch}/{,**/}*.so* rm, in those profiles instead of {,/var/lib/snapd/}/snap [15:08] Saviq: otherwise the parser complains [15:09] mborzecki: aha, /me fixes [15:09] probably why it failed to load [15:12] error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: [15:12] /tmp/sanity-mountpoint-875787176: unknown filesystem type 'squashfs'. [15:12] hrmf [15:17] Saviq: multipass mount $PWD/spread-mini saving-chamois:~/foo kind of worked (despite apparmor), but I got an unexpected path in the vm, basically $HOME/~/foo :) [15:19] mborzecki: well, it did what you asked it to do ;P [15:20] Saviq: heh, right, presumptions about rsync/ssh like path handling [15:21] mborzecki: please file an issue if you can (I can, too), we should fix [15:27] Saviq: there you go: https://github.com/CanonicalLtd/multipass/issues/1230 [15:27] mborzecki: 👋 [15:28] not trivial since we'll need to resolve this inside the instance [15:32] sil2100: do you think you could look at https://github.com/snapcore/core20/pull/16 ? [15:32] PR core20#16: bootstrap from locally build snapd snaps too [15:32] sil2100: this would unblock uc20 image creation [15:35] PR snapd#7905 opened: snap-bootstrap: actually parse snapd_recovery label [15:48] PR core20#17 opened: Drop encoding digits in units and code paths. [15:53] sil2100: would it be a lot of work to build the current/stable images everytime there's a stable updated to any of the included snaps for core images? i.e. for UC18, rebuild on core18, snapd, (and pc or pc-kernel on the 18/stable tracks) ? [16:09] mvo: looking! [16:09] mvo: btw. uc20 dailies are now up [16:09] http://cdimage.ubuntu.com/ubuntu-core/20/ [16:10] sil2100: thank you! [16:10] sil2100: nice [16:12] ijohnson: hmm, well, we don't have such automation right now, we did plan on adding something like that at one point, but nothing available yet [16:12] ijohnson: it's certainly possible [16:13] Just needs cycle for someone to sit down on it [16:17] PR pc-amd64-gadget#26 opened: Use the correct name for the recovery_system label [16:23] zyga, pedronis updated #7658 [16:23] PR #7658: cmd/snap-preseed: add snap-preseed executable [16:23] pstolowski: thx [16:24] ijohnson, hey, you already commented on this one https://bugs.launchpad.net/snapd/+bug/1855155 [16:24] Bug #1855155: snap install hangs if internet is disconnected exactly right after err upload starts [16:24] ijohnson, any priority to set? [16:27] cachio: sure I'll set the priority, it's low I think [16:27] nice, [16:28] I'll update it in that case [16:36] sil2100: it's not critical by any means, just would be nice to have since that's what multipass uses to boot images from and they are always out of date so you boot a new UC VM and it immediately needs to reboot twice for snap updates [16:40] PR snapcraft#2844 opened: Add punctuation rule for comments === heather is now known as hellsworth [17:00] pstolowski: ack, looking [17:09] cachio: hey [17:10] cachio: wanted to share a sneak peak [17:10] https://www.irccloud.com/pastebin/Km7d1ouy/ [17:10] zyga, looking [17:11] zyga, what is that? [17:11] https://www.irccloud.com/pastebin/KfXWwBsb/ [17:11]