[00:20] PR snapcraft#2835 closed: colcon plugin: support ROS 2 Eloquent [00:22] \o/ [02:54] PR snapd#7893 opened: Remove screenshot deprecation notice [05:44] PR snapd#7892 closed: many: pass a Model to the gadget info reading functions [05:45] PR snapd#7884 closed: snapstate: check gadget model constraints in checkSnap <⛔ Blocked> [05:48] PR snapd#7891 closed: devicestate: use correct model constraints in remodel/gadget updates <⛔ Blocked> [06:29] morning [06:48] mborzecki: good morning! [06:50] mvo: hey [07:06] and it's bug triage duty for me today [07:24] quick errand [07:39] good morning [07:39] hey zyga [07:39] * zyga needs to spend time debugging a few spread tests that show signs of more complexity than just the reboot [07:41] hey pedronis [07:42] I'll grab a quick breakfast while checking email [07:59] re [08:03] morning [08:06] hey pstolowski [08:24] pstolowski: hey [08:27] pstolowski: hey hey :) [08:41] PR snapd#7594 closed: tests: replace "test-snapd-base-bare" with real "bare" base snap [08:41] degville: good luck on this historic day [08:44] zyga: thank you! I'm not too hopeful tbh, but we'll see. [08:57] pedronis: hey, what do you mean by the comment to #7830: "Maybe you are thinking a snap with plugs and slots of interfaces that needs this?" ? [08:57] PR #7830: interfaces: include hooks in plug/slot apparmor label [08:57] pstolowski: that's a question of jdstrand [08:58] PR snapd#7894 opened: tests/main/parallel-install-remove-after: spread test [08:58] zyga: ^^ [08:59] yup [09:03] zyga: I'm probably confused about something, does a layout bind-file /etc/foo.conf -> $SNAP_DATA/etc/foo.conf also grant read access to /etc/foo.conf ? [09:03] pedronis: AFAIK yes, for a weird way the kernel handles sockets [09:03] let me double check [09:03] sockets ? [09:04] give me a moment please [09:04] zyga: np, I don't think it's bad, but I'm trying to use something like this and want to understand if the layout is enough [09:05] pedronis: I misread your question, the real layout would be $SNAP_DATA/etc/foo.conf -> /etc/foo.conf [09:05] pedronis: so yes, we do add the permission for /etc/foo.conf as well [09:05] ok [09:05] thx [09:06] pedronis: that's on apparmor/spec.go:357 [09:06] pedronis: the thing I mentioned about sockets is unique to content interface [09:07] pedronis: where because of apparmor/lsm weirdness we grant additional permission to connect to a socket at the location it was bound to [09:07] so if two snaps want to share an unix socket [09:07] and snap one makes it in /var/snap/foo/common/socket [09:07] then snap two gets it via content in /var/snap/bar/common/foo.socket [09:07] it gets permission to connect to "/var/snap/foo/common/socket" as well, because otherwise connect doesn't work [09:08] that's in content.go:226 [09:08] with a comment describing it above [09:10] PR snapd#7895 opened: many: add DeviceCtx.OperatingMode() [09:27] zyga: where is the layout blacklist ? is /etc/systemd restricted ? (it doesn't seem to be in my testing) [09:28] pedronis: it is in snap/validate.go AFAIR, I don't believe /etc/systemd is restricted, it won't affect the host [09:28] pedronis: it may only affect systemd running inside your snap [09:29] zyga: thanks [09:29] brb, power brick [09:30] I think I will need to think about a "winter office" :/ in the kitchen [09:30] as soon as real winter kicks in the office will become a fridge [09:41] re [10:07] sil2100: I uplloaded 2.43~pre1 to focal, so hopefully you have all you need there once its build [10:23] brb [10:24] at least working from the kitchen means tea is made quickly :) [10:31] mvo: \o/ [10:31] * sil2100 hugs mvo [10:34] re [10:39] PR snapd#7879 closed: devicestate: use httputil.ShouldRetryError() in prepareSerialRequest [10:50] pstolowski: is https://github.com/snapcore/snapd/pull/7658 next for landing in the preseed series? [10:50] PR #7658: cmd/snap-preseed: add snap-preseed executable [10:59] mborzecki: yes [11:00] pstolowski: ok [11:08] Hey, will 18.04 get the next snapd version ? [11:09] snapd is a rolling release ... everyone always gets the latest everywhere ;) [11:10] ogra: good to know. Then lesser trouble with lxd and snap-confine [11:17] ogra: rolling release where it reexecs ;) [11:18] sdhd-sascha: if you want to test the new version with your snap, try running "snap refresh --beta core" [11:18] sdhd-sascha: you can switch back by refreshing to --stable [11:18] mborzecki, well, other distros usually update too, just a bit later [11:38] cachio: Hi, did you get your fix for rsync updated? Looking at https://snapcraft.io/rsync it seems like it's not been updated? [11:38] do google:ubuntu-{16,18}.04-64:tests/main/interfaces-audio-playback-record fail for anyone else? [11:42] mborzecki: pull master [11:42] mborzecki: it's been fixed yesterday [11:42] brb, let's use that tea and have a short break [11:42] zyga: heh, ok, need to merge master to my branch then :/ [11:43] pokk, I'll update it, I didn't try [11:47] jamesh: thank you. i only run "snap refresh --candidate snapd" and the apparmor DENIED is gone [11:48] Have now updated the core too [12:06] PR snapd#7896 opened: interfaces/wayland: Add access to Xwayland's shm files [12:08] alan_g: +1 for 7896 [12:12] sdhd-sascha, I don't think voting here helps. ;^) [12:21] zyga: heh, inside lxd container with 18.04 on 18.04 host: Dec 12 12:11:31 my systemd[1]: system.slice: Failed to reset devices.list: Operation not permitted [12:21] mborzecki: that's expected [12:22] is this causing any failures? [12:22] zyga: for a second there i thought it does, but looks like just a log in the systemd source code [12:22] yep [12:22] I remember reading that [12:25] kjackal: hello, question under your old report: https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition/2513/13 [12:26] btw. jdstrand's fix for deny unix also fixed journal logging? [12:26] 15 minute break [12:26] mborzecki: how so? [12:26] pstolowski: looking [12:27] zyga: i'm seeing [ 698.940015] audit: type=1400 audit(1576153071.478:187): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-my_" profile="/snap/core/8213/usr/lib/snapd/snap-confine" name="/run/systemd/journal/stdout" pid=7017 comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=1000000 ouid=1000 without the fix [12:27] mborzecki: are you referring to my comment later in the bug or something else? [12:27] mborzecki: yes, it does [12:27] mborzecki: that is a named unix socket [12:28] mborzecki: (even though it is mediated by 'file', that provides an additional clue on the bug since it is unix in the kernel [12:28] ) [12:30] mborzecki: https://bugs.launchpad.net/apparmor/+bug/1855355/comments/3 [12:30] Bug #1855355: Nested LXD install fails with snapd 2.42.4 (current stable core snap) [12:30] mborzecki: 2.42.5 should fix it [12:31] jdstrand: looks like i was to eager to mark https://bugs.launchpad.net/snapd/+bug/1856057 as fix released instead of committed [12:31] Bug #1856057: Missing daemon service logs in LXD containers [12:33] pstolowski: zyga: can you check whether paintsupreme-3d snap does not segfault for you? [12:33] mborzecki: checking [12:34] checking [12:34] mborzecki: yep, segfault [12:35] Illegal instruction (core dumped) [12:35] same here [12:36] /snap/paintsupreme-3d/2/bin/desktop-launch: line 204: 348665 Segmentation fault (core dumped) $RUNTIME/usr/lib/$ARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders > $GDK_PIXBUF_MODULE_FILE [12:36] Błędna instrukcja (zrzut pamięci) [12:36] yep, same error from desktop-launch [12:39] heh [12:39] looking at the backtrace it fails somewhere in libnode [12:39] it's always libnode ;) [12:39] ok, I'll really take that break I was planning to before [12:40] https://bugs.launchpad.net/snapd/+bug/1855969/comments/1 if you're interested in the backtrace [12:40] Bug #1855969: paintsupreme-3d does not run on Ubuntu 18.04 <18.04> [12:41] zyga: i already seen an segmentation fault on sway snap with gdk-pixbuf before... [12:42] i think it's gone with gnome-extension in snapcraft.yaml or the right env's [12:42] pedronis, see my last comment of the logsync thread ... i got it working, but not the way you suggested ... is it a bug that layouts fail for non-existing files ? [12:44] it should create them [12:44] ogra: maybe zyga can help [12:44] well, it definitely doesnt, i tested on 16.04, core16 and core18 [12:44] ogra: can you describe what you mean [12:44] the current solution works for me though [12:44] ogra: what you did [12:44] ogra: what you expected [12:44] ogra: what you got [12:45] zyga, see https://forum.snapcraft.io/t/manual-review-of-logsync-snap/14059/26 [12:45] the last few entries [12:45] ogra: I _think_ this is a known bug, let me find it [12:46] ogra: does this sound familiar https://bugs.launchpad.net/snapd/+bug/1843423 [12:46] Bug #1843423: snap-update-ns fails to construct a layout in /etc/test-snapd/foo when /etc/test-snapd exists [12:47] thats a weird bug description but yeah, seems similar [12:48] i didnt use a tmpfs indeeed [12:48] (but bind mount) [12:48] ogra: tmpfs is just a way to trigger it, the mechanics of the bug is the say [12:48] *same [12:48] yeah, tought so [12:49] ayway, bind-mounting the whole dir seems to be a valid workaround [12:50] afk for 15 minutes [12:50] (funnily the dir is get in the 2snp run --shell" setup is completely empty ... but i can create the file i need and the app sees it in the right place) [12:50] *snap run [12:54] PR snapd#7897 opened: overlord/snapstate: tweak assumes error hint [13:00] hah https://bugs.launchpad.net/snapd/+bug/1855155 is nice [13:00] Bug #1855155: snap install hangs if internet is disconnected exactly right after err upload starts [13:07] zyga: google:ubuntu-{16,18}.04-64:tests/main/interfaces-audio-playback-record keeps failing on #7894 with the latest master merged [13:07] PR #7894: tests/main/parallel-install-remove-after: parallel installs should not break removal [13:12] mborzecki: how does it fail? [13:12] zyga: https://api.travis-ci.org/v3/job/624112055/log.txt [13:12] weird [13:14] hmmm [13:14] is that reproducible? [13:14] or just on a PR? [13:14] (as in is that reproducible as a single run on master) [13:16] zyga: heh, got a debug shell with master branch [13:17] jdstrand: hey! thanks for taking a look at https://github.com/snapcore/snapd/pull/7830 (and sorry it landed without your review, was an oversight, i marked you as reviewer but probably should marked it Blocked as well). does it make sense what i wrote in the reply to your comment? [13:17] PR #7830: interfaces: include hooks in plug/slot apparmor label [13:18] bbiab [13:29] hmm pulseaudio mediates recording access itself? [13:36] ok, so [13:36] module-snappy-policy is not being loaded by pulseaudio in 18.04 and 16.04 images [13:36] anyone know why? [13:38] jdstrand: quick question, do you know if module-snappy-policy is still needed in pulseaudio? [13:38] mborzecki: yes [13:38] mborzecki: that's super weird because this test passed yesterday [13:38] it passed in the morning too [13:38] mborzecki: literally because it was failing in the opposite way [13:38] mborzecki: so wtf [13:38] s/f/h [13:39] zyga: according to travis logs, it was still passing like 3h ago [13:40] nothing in the package changelog [13:51] morning folks [13:51] mborzecki: always happy to find such interesting and fun bugs [13:52] PR snapcraft#2839 opened: plugs: add passthrough; check plug_dict is not empty [13:54] bwt. the standup doc is becoming really slow for me in FF [13:54] degville: I looked over your glossary doc and it looks really good! I think it would also be a good idea to add "snappy" there and explain that can mean multiple things, i.e. snapd, ubuntu core, etc. and that AFAIK the term should be kinda deprecated now [13:55] PR snapcraft#2839 closed: plugs: add passthrough; check plug_dict is not empty === ricab is now known as ricab|lunch [13:58] ijohnson: thanks, and great idea about snappy. It's most definitely in a preliminary state, but I just wanted to get something up so we/I can iterate over it a little. [13:58] degville: yes, understood, but I think it's looking great so far :-) [14:24] Hmmm, I've send a request for a Brand Store a week ago, but haven't received anything back. Is that normal? And, for my information, is a Brand Store paid? I haven't read much about this on the forums, but I could imagine it's paid due the way its requested (through sales :-P). This because I need to ship a package with access to `snapd-control` [14:24] for managing the snaps on the device. [14:33] yes, brand stores are commercial things and need to be paid ... sales should reply to you soon [14:34] Ah, okay. Thanks, than let's have a look if we're able to make some deal work with you guys for my customer :). [14:38] mvo (cc mborzecki): sigh, seb128 emergency reverted the pulseaudio SRU since there was a snapd-glib issue that was affected users so now we need to revert the PRs to mediating pulseaudio [14:39] s/to mediating/for mediating/ [14:39] jdstrand: whole PR or just disabling the tests until things are fixed again? [14:39] mvo (cc mborzecki): ie, just the testsuite update from yesterday [14:39] or was it tuesday [14:40] |R 7885 and PR 7886 [14:40] erf PR 7885 and PR 7886 [14:40] PR #7886: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 <⚠ Critical> [14:40] PR #7885: tests: 16.04 and 18.04 now have mediating pulseaudio <⚠ Critical> [14:41] jdstrand: ok, thanks [14:41] mvo (cc mborzecki): they are working to fix that, so the tests will break again when it goes through [14:41] I think I will directly revert on master without a PR [14:41] mborzecki: you said something elsewhere about making them manual? [14:41] mborzecki: I think I will directly revert on master without a PR> WDYT? [14:42] jdstrand: yeah, we can skip that test on 16.04 and 18.04 specifically (mvo?) [14:42] jdstrand: manual would make the whole test non-runnable on travis [14:42] we at least know the test works: it caught that the mediation patches were dropped [14:42] (and added) [14:42] so, 'yay'? [14:42] :) [14:43] mborzecki: manual on 16/18 works for me too, no strong opinion [14:44] mborzecki: if we switch it to manual we just need a card that reminds us to re-enable it agian once the dust settled [14:44] mvo: reverting 0552bf0ad62dfad0a92db01350774e77aa82f428 will save 2 spread runs (or more if we need to restart) [14:44] mborzecki: well, I would prefer a revert and reapply after the new SRU since they are working as designed and it is just a one line change. unless you foresee a back and forth and don't want them to break up over and over until the dust settles [14:44] which is a fair stance [14:44] * jdstrand has no strong opinion [14:44] mborzecki: ok, I will revert on master [14:45] both reverted [14:45] well, the patch is reverted on both master and release/2.43 [14:45] mvo: cool, thank you! [14:46] PR snapcraft#2840 opened: plugs: plugs can have no element [14:46] mvo: thanks [14:46] yw [14:49] PR snapcraft#2841 opened: plugs: add passthrough [14:50] mvo: I'm trying to get info in #ubuntu-release on the timing of the update to add it back again [14:50] mvo: it would be a shame if the sru landed late next week or during the break [14:51] I guess it would be easy enough to revert the revert, but still [15:01] * cachio lunch [15:05] mvo: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/comments/21 [15:05] Bug #1781428: please enable snap mediation support

Released by jamesh> [15:05] jdstrand: thanks, reading this now [15:06] mvo: trying to have your back :) [15:07] jdstrand: yeah, thanks for that! [15:07] :) [15:08] zyga: just have a discussion on snapcraft. Is it possible to add "wayland" to the global plugs and then it's for all apps ? I thought you wrote this to me on the first days [15:09] sdhd-sascha: yes, please open a topic abou tit [15:09] *about it [15:09] i opened a PR on snapcraft... ok, i wait [15:09] no no [15:09] not a pr on snapcraft [15:09] please open a thread on the forum [15:10] * zyga goes for another meeting === ricab|lunch is now known as ricab [15:13] zyga: done. But until i got answer. I have to work with my patched version. [15:26] the PR was, because snapcraft 3.9.x crash. So something have to be done there [15:34] degville: it occured to me I forgot to type up a little blurb for you about how global plugs and explicitly delcared plugs interact, but I responded to sdhd-sascha on the forum about how this works here: https://forum.snapcraft.io/t/plugs-in-global-position-in-snapcraft-yaml/14618/2 [15:34] hope that helps in writing up a doc on how to do this properly [15:35] ijohnson: great, thank you! looks good. [15:35] degville: ijohnson: thanks. my snapcraft is know 60 line longer :-( [15:35] *now [15:36] sdhd-sascha: can't you just declare them globally once and not declare any plugs for apps/hooks ? [15:36] oh, wait [15:36] sorry [15:36] sdhd-sascha: the thing you want to avoid is having both the global plugs and the per-app / per-hook plugs [15:36] the global case crashes in 3.9.x if the plug is empty [15:36] oh well that's unfortunate [15:37] it's since interface is in snapcraft/internal/meta/plugs.py [15:38] https://github.com/snapcore/snapcraft/pull/2840/commits/0dc7ab09f4b7e0f7744a7606b8b7a80553c89dac [15:38] PR snapcraft#2840: plugs: plugs can have no element [15:38] ijohnson: just overwrite None [15:38] above [15:38] but, then another validation fails... :-( [15:39] afk [15:40] the error with my patch: "failed to validate plug=hardware-observe: plug has no defined interface" [15:40] now, afk [15:40] sdhd-sascha: not sure about why snapcraft fails that way, I'd recommended asking about why snapcraft dies like that over in #snapcraft [15:43] meh, multipass lanch failed, apaprently qemu-img grashed or sth, and there's a denial in the logs: [15:43] apparmor="DENIED" operation="file_mmap" profile="multipass.qemu-img" name="/var/lib/snapd/snap/multipass/1425/usr/bin/qemu-img" pid=649663 comm="qemu-img" requested_mask="rm" denied_mask="rm" [15:43] ok, next stupid question. Should rsync over ssh not work on ubuntu core? Doing `rsync me@1.2.3.4:/path` I get "rsync: Failed to exec ssh: Permission denied (13)" followed by "rsync error: error in IPC code (code 14) at pipe.c(85) [sender=3.1.1]" [15:44] hmm, but multipass is classi, wth [15:53] mborzecki: that doesn't look like a snap profile? `profile="multipass.qemu-img"` ? [15:53] mborzecki: also what's the status of https://github.com/snapcore/snapd/pull/7570 shall I review that? [15:53] PR #7570: [RFC] snap-mount-dir: add mount unit for snap-mount-dir [15:53] ijohnson: yeah, looks like something internal to multipass [15:53] ijohnson: it's on hold now, we found a problem that we don't know how to address in a clean way yet [15:54] mborzecki: ack I added the blocked label to show this [15:54] ijohnson: cool thanks [15:56] cachio: would you happen to know why ssh isn't allowed to be used with rsync as well? I'm guessing it's some kind of permission problem as well, but I know way to little about it to debug it [15:57] pokk, do you see any denial when you do journalctl -u snapd? [15:57] pokk, how did you get rsync installed in the first place ? [15:57] (i dont think it is in the core snap (definitely not in core18) [15:57] ) [15:58] ogra: using https://snapcraft.io/rsync but the test version of it [15:59] pokk, well, i doubt that has access to your credentials on the host [16:00] ogra: No I would buy that, but wouldn't that give me a different error? [16:00] well, it tells you permission to access credentials are denied :) doesnt it ? [16:01] well that highlight didn't really work, cachio https://pastebin.com/K4XTRt7U [16:01] I don't see any errors [16:01] well, in fact it tells you it cant exec ssh [16:01] so thats even before checking credentials [16:02] the rsync snap would have to ship its own openssh copy i guess (so the binary is there) and then would need allowance to access your credentials [16:03] ogra: right, that's the part that I'm very new to how it works. [16:03] and having a hard time googling [16:03] I guessed it was something along those lines tho :/ [16:03] well, snap applications run under confinement ... they can not see most of the os by default [16:04] right, but for me it would make sense to have rsync be able to access at least ssh. Given it's wide use together [16:04] typically a snap should ship all binaries it needs inside the snap [16:05] mborzecki: notice the profile name is multipass.qemu-img [16:05] for the credentials there are two interfaces ssh-keys and ssh-public-keys ... but for the binary itself there is nothing i think [16:05] mborzecki: multipass loads a profile to launch vms under [16:05] ogra: right, but how would one know what is shiped? Looking at https://snapcraft.io/rsync or https://snapcraft.io/rsync-leftyfb there's very little information abut that [16:06] mborzecki: it is that profile that would need adjusting [16:06] pokk, you'd have to either look at the snapcraft.yaml inside the snap (if it ships one, not all of them do) or ask the packager [16:07] technically you can indeed just snap download any snap and run unsquashfs on it to inspect the content [16:10] mvo, setting/unsetting a proxy does not restart snapd ? (so the change isnt picked up on core until i reboot) ... is that wanted ? [16:11] ogra (in a meeting, so a bit slow). snapd should pick this up dynamically, i.e. not look at the environment but instead at the config [16:11] ogra is it not working for you? [16:12] mvo, i had a non-existent proxy set for a demo ... did a snap unset on it and snapd still tried to use the proxy url until i ran sudo systemctl restart snapd [16:12] probably the unset itself is the issue ... i dont think i had to restart it when i used the set command [16:13] hmm, no, snap set has the same issue ... [16:15] mvo, https://paste.ubuntu.com/p/KrmBQjyMZp/ [16:15] smells like a bug then [16:20] jdstrand: filed a bug, looks like it's being generated on the fly? aa-status doesn't list it, can't really switch it to complain mode [16:20] ogra: yeah, that sounds like a bug, that's a bit depressing [16:21] i'll file it before EODing [16:22] ogra thank you [16:23]