[00:20] <mup> PR snapcraft#2835 closed: colcon plugin: support ROS 2 Eloquent <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2835>
[00:22] <kyrofa> \o/
[02:54] <mup> PR snapd#7893 opened: Remove screenshot deprecation notice <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/7893>
[05:44] <mup> PR snapd#7892 closed: many: pass a Model to the gadget info reading functions <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7892>
[05:45] <mup> PR snapd#7884 closed: snapstate: check gadget model constraints in checkSnap <UC20> <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7884>
[05:48] <mup> PR snapd#7891 closed: devicestate: use correct model constraints in remodel/gadget updates <UC20> <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7891>
[06:29] <mborzecki> morning
[06:48] <mvo> mborzecki: good morning!
[06:50] <mborzecki> mvo: hey
[07:06] <mborzecki> and it's bug triage duty for me today
[07:24] <mborzecki> quick errand
[07:39] <zyga> good morning
[07:39] <mvo> 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] <zyga> hey pedronis
[07:42] <zyga> I'll grab a quick breakfast while checking email
[07:59] <mborzecki> re
[08:03] <pstolowski> morning
[08:06] <mvo> hey pstolowski
[08:24] <mborzecki> pstolowski: hey
[08:27] <zyga> pstolowski: hey hey :)
[08:41] <mup> PR snapd#7594 closed: tests: replace "test-snapd-base-bare" with real "bare" base snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7594>
[08:41] <zyga> degville: good luck on this historic day
[08:44] <degville> zyga: thank you! I'm not too hopeful tbh, but we'll see.
[08:57] <pstolowski> 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] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7830>
[08:57] <pedronis> pstolowski: that's a question of jdstrand
[08:58] <mup> PR snapd#7894 opened: tests/main/parallel-install-remove-after: spread test <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7894>
[08:58] <mborzecki> zyga: ^^
[08:59] <zyga> yup
[09:03] <pedronis> 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] <zyga> pedronis: AFAIK yes, for a weird way the kernel handles sockets
[09:03] <zyga> let me double check
[09:03] <pedronis> sockets ?
[09:04] <zyga> give me a moment please
[09:04] <pedronis> 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] <zyga> pedronis: I misread your question, the real layout would be $SNAP_DATA/etc/foo.conf -> /etc/foo.conf
[09:05] <zyga> pedronis: so yes, we do add the permission for /etc/foo.conf as well
[09:05] <pedronis> ok
[09:05] <pedronis> thx
[09:06] <zyga> pedronis: that's on apparmor/spec.go:357
[09:06] <zyga> pedronis: the thing I mentioned about sockets is unique to content interface
[09:07] <zyga> 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] <zyga> so if two snaps want to share an unix socket
[09:07] <zyga> and snap one makes it in /var/snap/foo/common/socket
[09:07] <zyga> then snap two gets it via content in /var/snap/bar/common/foo.socket
[09:07] <zyga> it gets permission to connect to "/var/snap/foo/common/socket" as well, because otherwise connect doesn't work
[09:08] <zyga> that's in content.go:226
[09:08] <zyga> with a comment describing it above
[09:10] <mup> PR snapd#7895 opened: many: add DeviceCtx.OperatingMode() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7895>
[09:27] <pedronis> zyga: where is the layout blacklist ? is /etc/systemd restricted ? (it doesn't seem to be in my testing)
[09:28] <zyga> pedronis: it is in snap/validate.go AFAIR, I don't believe /etc/systemd is restricted, it won't affect the host
[09:28] <zyga> pedronis: it may only affect systemd running inside your snap
[09:29] <pedronis> zyga: thanks
[09:29] <zyga> brb, power brick
[09:30] <zyga> I think I will need to think about a "winter office" :/ in the kitchen
[09:30] <zyga> as soon as real winter kicks in the office will become a fridge
[09:41] <zyga> re
[10:07] <mvo> sil2100: I uplloaded 2.43~pre1 to focal, so hopefully you have all you need there once its build
[10:23] <zyga> brb
[10:24] <zyga> at least working from the kitchen means tea is made quickly :)
[10:31] <sil2100> mvo: \o/
[10:31]  * sil2100 hugs mvo 
[10:34] <zyga> re
[10:39] <mup> PR snapd#7879 closed: devicestate: use httputil.ShouldRetryError() in prepareSerialRequest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7879>
[10:50] <mborzecki> pstolowski: is https://github.com/snapcore/snapd/pull/7658 next for landing in the preseed series?
[10:50] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[10:59] <pstolowski> mborzecki: yes
[11:00] <mborzecki> pstolowski: ok
[11:08] <sdhd-sascha> Hey, will 18.04 get the next snapd version ?
[11:09] <ogra> snapd is a rolling release ... everyone always gets the latest everywhere ;)
[11:10] <sdhd-sascha> ogra: good to know. Then lesser trouble with lxd and snap-confine
[11:17] <mborzecki> ogra: rolling release where it reexecs ;)
[11:18] <jamesh> sdhd-sascha: if you want to test the new version with your snap, try running "snap refresh --beta core"
[11:18] <jamesh> sdhd-sascha: you can switch back by refreshing to --stable
[11:18] <ogra> mborzecki, well, other distros usually update too, just a bit later
[11:38] <pokk> 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] <mborzecki> do google:ubuntu-{16,18}.04-64:tests/main/interfaces-audio-playback-record fail for anyone else?
[11:42] <zyga> mborzecki: pull master
[11:42] <zyga> mborzecki: it's been fixed yesterday
[11:42] <zyga> brb, let's use that tea and have a short break
[11:42] <mborzecki> zyga: heh, ok, need to merge master to my branch then :/
[11:43] <cachio> pokk, I'll update it, I didn't try
[11:47] <sdhd-sascha> jamesh: thank you. i only run "snap refresh --candidate snapd" and the apparmor DENIED is gone
[11:48] <sdhd-sascha> Have now updated the core too
[12:06] <mup> PR snapd#7896 opened: interfaces/wayland: Add access to Xwayland's shm files <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7896>
[12:08] <sdhd-sascha> alan_g: +1 for 7896
[12:12] <alan_g> sdhd-sascha, I don't think voting here helps. ;^)
[12:21] <mborzecki> 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] <zyga> mborzecki: that's expected
[12:22] <zyga> is this causing any failures?
[12:22] <mborzecki> zyga: for a second there i thought it does, but looks like just a log in the systemd source code
[12:22] <zyga> yep
[12:22] <zyga> I remember reading that
[12:25] <pstolowski> kjackal: hello, question under your old report: https://forum.snapcraft.io/t/restarting-services-from-configure-hook-race-condition/2513/13
[12:26] <mborzecki> btw. jdstrand's fix for deny unix also fixed journal logging?
[12:26] <zyga> 15 minute break
[12:26] <zyga> mborzecki: how so?
[12:26] <kjackal> pstolowski: looking
[12:27] <mborzecki> zyga: i'm seeing [  698.940015] audit: type=1400 audit(1576153071.478:187): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-my_<var-snap-lxd-common-lxd>" 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] <jdstrand> mborzecki: are you referring to my comment later in the bug or something else?
[12:27] <jdstrand> mborzecki: yes, it does
[12:27] <jdstrand> mborzecki: that is a named unix socket
[12:28] <jdstrand> 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] <jdstrand> )
[12:30] <jdstrand> mborzecki: https://bugs.launchpad.net/apparmor/+bug/1855355/comments/3
[12:30] <mup> Bug #1855355: Nested LXD install fails with snapd 2.42.4 (current stable core snap) <AppArmor:New> <snapd:Fix Committed> <https://launchpad.net/bugs/1855355>
[12:30] <jdstrand> mborzecki: 2.42.5 should fix it
[12:31] <mborzecki> jdstrand: looks like i was to eager to mark https://bugs.launchpad.net/snapd/+bug/1856057 as fix released instead of committed
[12:31] <mup> Bug #1856057: Missing daemon service logs in LXD containers <snapd:Fix Released> <https://launchpad.net/bugs/1856057>
[12:33] <mborzecki> pstolowski: zyga: can you check whether paintsupreme-3d snap does not segfault for you?
[12:33] <pstolowski> mborzecki: checking
[12:34] <zyga> checking
[12:34] <pstolowski> mborzecki: yep, segfault
[12:35] <pstolowski> Illegal instruction (core dumped)
[12:35] <zyga> same here
[12:36] <zyga>  /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] <zyga> Błędna instrukcja (zrzut pamięci)
[12:36] <pstolowski> yep, same error from desktop-launch
[12:39] <mborzecki> heh
[12:39] <mborzecki> looking at the backtrace it fails somewhere in libnode
[12:39] <zyga> it's always libnode ;)
[12:39] <zyga> ok, I'll really take that break I was planning to before
[12:40] <mborzecki> https://bugs.launchpad.net/snapd/+bug/1855969/comments/1 if you're interested in the backtrace
[12:40] <mup> Bug #1855969: paintsupreme-3d does not run on Ubuntu 18.04 <18.04> <paintsupreme-3d> <snapd:Invalid> <https://launchpad.net/bugs/1855969>
[12:41] <sdhd-sascha> zyga: i already seen an segmentation fault on sway snap with gdk-pixbuf before...
[12:42] <sdhd-sascha> i think it's gone with gnome-extension in snapcraft.yaml or the right env's
[12:42] <ogra> 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] <pedronis> it should create them
[12:44] <pedronis> ogra: maybe zyga can help
[12:44] <ogra> well, it definitely doesnt, i tested on 16.04, core16 and core18
[12:44] <zyga> ogra: can you describe what you mean
[12:44] <ogra> the current solution works for me though
[12:44] <zyga> ogra: what you did
[12:44] <zyga> ogra: what you expected
[12:44] <zyga> ogra: what you got
[12:45] <ogra> zyga, see https://forum.snapcraft.io/t/manual-review-of-logsync-snap/14059/26
[12:45] <ogra> the last few entries
[12:45] <zyga> ogra: I _think_ this is a known bug, let me find it
[12:46] <zyga> ogra: does this sound familiar https://bugs.launchpad.net/snapd/+bug/1843423
[12:46] <mup> Bug #1843423: snap-update-ns fails to construct a layout in /etc/test-snapd/foo when /etc/test-snapd exists <snapd:Confirmed> <https://launchpad.net/bugs/1843423>
[12:47] <ogra> thats a weird bug description but yeah, seems similar
[12:48] <ogra> i didnt use a tmpfs indeeed
[12:48] <ogra> (but bind mount)
[12:48] <zyga> ogra: tmpfs is just a way to trigger it, the mechanics of the bug is the say
[12:48] <zyga> *same
[12:48] <ogra> yeah, tought so
[12:49] <ogra> ayway, bind-mounting the whole dir seems to be a valid workaround
[12:50] <zyga> afk for 15 minutes
[12:50] <ogra> (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] <ogra> *snap run
[12:54] <mup> PR snapd#7897 opened: overlord/snapstate: tweak assumes error hint <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7897>
[13:00] <mborzecki> hah https://bugs.launchpad.net/snapd/+bug/1855155 is nice
[13:00] <mup> Bug #1855155: snap install hangs if internet is disconnected exactly right after err upload starts <snapd:New> <https://launchpad.net/bugs/1855155>
[13:07] <mborzecki> zyga: google:ubuntu-{16,18}.04-64:tests/main/interfaces-audio-playback-record keeps failing on #7894 with the latest master merged
[13:07] <mup> PR #7894: tests/main/parallel-install-remove-after: parallel installs should not break removal <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7894>
[13:12] <zyga> mborzecki: how does it fail?
[13:12] <mborzecki> zyga: https://api.travis-ci.org/v3/job/624112055/log.txt
[13:12] <mborzecki> weird
[13:14] <zyga> hmmm
[13:14] <zyga> is that reproducible?
[13:14] <zyga> or just on a PR?
[13:14] <zyga> (as in is that reproducible as a single run on master)
[13:16] <mborzecki> zyga: heh, got a debug shell with master branch
[13:17] <pstolowski> 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] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7830>
[13:18] <pstolowski> bbiab
[13:29] <mborzecki> hmm pulseaudio mediates recording access itself?
[13:36] <mborzecki> ok, so
[13:36] <mborzecki> module-snappy-policy is not being loaded by pulseaudio in 18.04 and 16.04 images
[13:36] <mborzecki> anyone know why?
[13:38] <mborzecki> jdstrand: quick question, do you know if module-snappy-policy is still needed in pulseaudio?
[13:38] <zyga> mborzecki: yes
[13:38] <zyga> mborzecki: that's super weird because this test passed yesterday
[13:38] <mborzecki> it passed in the morning too
[13:38] <zyga> mborzecki: literally because it was failing in the opposite way
[13:38] <zyga> mborzecki: so wtf
[13:38] <zyga> s/f/h
[13:39] <mborzecki> zyga: according to travis logs, it was still passing like 3h ago
[13:40] <mborzecki> nothing in the package changelog
[13:51] <ijohnson> morning folks
[13:51] <ijohnson> mborzecki: always happy to find such interesting and fun bugs
[13:52] <mup> PR snapcraft#2839 opened: plugs: add passthrough; check plug_dict is not empty <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2839>
[13:54] <mborzecki> bwt. the standup doc is becoming really slow for me in FF
[13:54] <ijohnson> 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] <mup> PR snapcraft#2839 closed: plugs: add passthrough; check plug_dict is not empty <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapcraft/pull/2839>
[13:58] <degville> 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] <ijohnson> degville: yes, understood, but I think it's looking great so far :-)
[14:24] <Wouter0100> 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] <Wouter0100> for managing the snaps on the device.
[14:33] <ogra> yes, brand stores are commercial things and need to be paid ... sales should reply to you soon
[14:34] <Wouter0100> 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] <jdstrand> 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] <jdstrand> s/to mediating/for mediating/
[14:39] <mborzecki> jdstrand: whole PR or just disabling the tests until things are fixed again?
[14:39] <jdstrand> mvo (cc mborzecki): ie, just the testsuite update from yesterday
[14:39] <jdstrand> or was it tuesday
[14:40] <jdstrand> |R 7885 and PR 7886
[14:40] <jdstrand> erf PR 7885 and PR 7886
[14:40] <mup> PR #7886: tests: 16.04 and 18.04 now have mediating pulseaudio - 2.43 <⚠ Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7886>
[14:40] <mup> PR #7885: tests: 16.04 and 18.04 now have mediating pulseaudio <⚠ Critical> <Created by jdstrand> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7885>
[14:41] <mvo> jdstrand: ok, thanks
[14:41] <jdstrand> mvo (cc mborzecki): they are working to fix that, so the tests will break again when it goes through
[14:41] <mvo> I think I will directly revert on master without  a PR
[14:41] <jdstrand> mborzecki: you said something elsewhere about making them manual?
[14:41] <mvo> mborzecki:  I think I will directly revert on master without  a PR> WDYT?
[14:42] <mborzecki> jdstrand: yeah, we can skip that test on 16.04 and 18.04 specifically (mvo?)
[14:42] <mborzecki> jdstrand: manual would make the whole test non-runnable on travis
[14:42] <jdstrand> we at least know the test works: it caught that the mediation patches were dropped
[14:42] <jdstrand> (and added)
[14:42] <jdstrand> so, 'yay'?
[14:42] <jdstrand> :)
[14:43] <mvo> mborzecki: manual on 16/18 works for me too, no strong opinion
[14:44] <mvo> 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] <mborzecki> mvo: reverting 0552bf0ad62dfad0a92db01350774e77aa82f428 will save 2 spread runs (or more if we need to restart)
[14:44] <jdstrand> 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] <jdstrand> which is a fair stance
[14:44]  * jdstrand has no strong opinion
[14:44] <mvo> mborzecki: ok, I will revert on master
[14:45] <mvo> both reverted
[14:45] <mvo> well, the patch is reverted on both master and release/2.43
[14:45] <mborzecki> mvo: cool, thank you!
[14:46] <mup> PR snapcraft#2840 opened: plugs: plugs can have no element <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2840>
[14:46] <jdstrand> mvo: thanks
[14:46] <mvo> yw
[14:49] <mup> PR snapcraft#2841 opened: plugs: add passthrough <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2841>
[14:50] <jdstrand> mvo: I'm trying to get info in #ubuntu-release on the timing of the update to add it back again
[14:50] <jdstrand> mvo: it would be a shame if the sru landed late next week or during the break
[14:51] <jdstrand> I guess it would be easy enough to revert the revert, but still
[15:01]  * cachio lunch
[15:05] <jdstrand> mvo: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1781428/comments/21
[15:05] <mup> Bug #1781428: please enable snap mediation support <patch> <verification-failed> <verification-failed-bionic> <verification-failed-xenial> <pulseaudio (Ubuntu):Fix
[15:05] <mup> Released by jamesh> <pulseaudio (Ubuntu Xenial):Fix Committed by jamesh> <pulseaudio (Ubuntu Bionic):Fix Committed by jamesh> <https://launchpad.net/bugs/1781428>
[15:05] <mvo> jdstrand: thanks, reading this now
[15:06] <jdstrand> mvo: trying to have your back :)
[15:07] <mvo> jdstrand: yeah, thanks for that!
[15:07] <jdstrand> :)
[15:08] <sdhd-sascha> 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] <zyga> sdhd-sascha: yes, please open a topic abou tit
[15:09] <zyga> *about it
[15:09] <sdhd-sascha> i opened a PR on snapcraft... ok, i wait
[15:09] <zyga> no no
[15:09] <zyga> not a pr on snapcraft
[15:09] <zyga> please open a thread on the forum
[15:10]  * zyga goes for another meeting
[15:13] <sdhd-sascha> zyga: done. But until i got answer. I have to work with my patched version.
[15:26] <sdhd-sascha> the PR was, because snapcraft 3.9.x crash. So something have to be done there
[15:34] <ijohnson> 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] <ijohnson> hope that helps in writing up a doc on how to do this properly
[15:35] <degville> ijohnson: great, thank you! looks good.
[15:35] <sdhd-sascha> degville: ijohnson: thanks. my snapcraft is know 60 line longer :-(
[15:35] <sdhd-sascha> *now
[15:36] <ijohnson> sdhd-sascha: can't you just declare them globally once and not declare any plugs for apps/hooks ?
[15:36] <sdhd-sascha> oh, wait
[15:36] <sdhd-sascha> sorry
[15:36] <ijohnson> sdhd-sascha: the thing you want to avoid is having both the global plugs and the per-app / per-hook plugs
[15:36] <sdhd-sascha> the global case crashes in 3.9.x if the plug is empty
[15:36] <ijohnson> oh well that's unfortunate
[15:37] <sdhd-sascha> it's since interface is in snapcraft/internal/meta/plugs.py
[15:38] <sdhd-sascha> https://github.com/snapcore/snapcraft/pull/2840/commits/0dc7ab09f4b7e0f7744a7606b8b7a80553c89dac
[15:38] <mup> PR snapcraft#2840: plugs: plugs can have no element <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2840>
[15:38] <sdhd-sascha> ijohnson: just overwrite None
[15:38] <sdhd-sascha> above
[15:38] <sdhd-sascha> but, then another validation fails... :-(
[15:39] <sdhd-sascha> afk
[15:40] <sdhd-sascha> the error with my patch: "failed to validate plug=hardware-observe: plug has no defined interface"
[15:40] <sdhd-sascha> now, afk
[15:40] <ijohnson> 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] <mborzecki> meh, multipass lanch failed, apaprently qemu-img grashed or sth, and there's a denial in the logs:
[15:43] <mborzecki> 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] <pokk> 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] <mborzecki> hmm, but multipass is classi, wth
[15:53] <ijohnson> mborzecki: that doesn't look like a snap profile? `profile="multipass.qemu-img"` ?
[15:53] <ijohnson> mborzecki: also what's the status of https://github.com/snapcore/snapd/pull/7570 shall I review that?
[15:53] <mup> PR #7570: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7570>
[15:53] <mborzecki> ijohnson: yeah, looks like something internal to multipass
[15:53] <mborzecki> 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] <ijohnson> mborzecki: ack I added the blocked label to show this
[15:54] <mborzecki> ijohnson: cool thanks
[15:56] <pokk> 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] <cachio> pokk, do you see any denial when you do journalctl -u snapd?
[15:57] <ogra> pokk, how did you get rsync installed in the first place ?
[15:57] <ogra> (i dont think it is in the core snap (definitely not in core18)
[15:57] <ogra> )
[15:58] <pokk> ogra: using https://snapcraft.io/rsync but the test version of it
[15:59] <ogra> pokk, well, i doubt that has access to your credentials on the host
[16:00] <pokk> ogra: No I would buy that, but wouldn't that give me a different error?
[16:00] <ogra> well, it tells you permission to access credentials are denied :) doesnt it ?
[16:01] <pokk> well that highlight didn't really work, cachio https://pastebin.com/K4XTRt7U
[16:01] <pokk> I don't see any errors
[16:01] <ogra> well, in fact it tells you it cant exec ssh
[16:01] <ogra> so thats even before checking credentials
[16:02] <ogra> 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] <pokk> ogra: right, that's the part that I'm very new to how it works.
[16:03] <pokk> and having a hard time googling
[16:03] <pokk> I guessed it was something along those lines tho :/
[16:03] <ogra> well, snap applications run under confinement ... they can not see most of the os by default
[16:04] <pokk> 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] <ogra> typically a snap should ship all binaries it needs inside the snap
[16:05] <jdstrand> mborzecki: notice the profile name is multipass.qemu-img
[16:05] <ogra> 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] <jdstrand> mborzecki: multipass loads a profile to launch vms under
[16:05] <pokk> 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] <jdstrand> mborzecki: it is that profile that would need adjusting
[16:06] <ogra> 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] <ogra> technically you can indeed just snap download any snap and run unsquashfs on it to inspect the content
[16:10] <ogra> 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] <mvo> 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] <mvo> ogra is it not working for you?
[16:12] <ogra> 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] <ogra> probably the unset itself is the issue ... i dont think i had to restart it when i used the set command
[16:13] <ogra> hmm, no, snap set has the same issue ...
[16:15] <ogra> mvo, https://paste.ubuntu.com/p/KrmBQjyMZp/
[16:15] <ogra> smells like a bug then
[16:20] <mborzecki> 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] <mvo> ogra: yeah, that sounds like a bug, that's a bit depressing
[16:21] <ogra> i'll file it before EODing
[16:22] <mvo> ogra thank you
[16:23] <jdstrand> mborzecki: I don't know if it is stored on disk, but:
[16:23] <jdstrand> $ sudo aa-status|grep multipass
[16:23] <jdstrand> ...
[16:23] <cachio> pokk, sorry, I was in a meeting
[16:23] <jdstrand>    multipass.snapcraft-znc-cs.qemu-system-x86_64
[16:23]  * zyga goes for another meeting
[16:23] <cachio> so, what you can't do with rsync?
[16:23]  * zyga should not alt-tab up-enter
[16:23] <zyga> eh
[16:24] <zyga> heh
[16:24] <jdstrand> mborzecki: you can aa-exec -p multipass.snapcraft-znc-cs.qemu-system-x86_64 -- your command
[16:25] <jdstrand> mborzecki: of course, that is for a non-failed stopped vm
[16:26] <mborzecki> jdstrand: aa-status |grep multipass only lists the profiles generated by snapd :/
[16:26] <cachio> mborzecki, hey, when you have time, could you please take a look to this one? https://bugs.launchpad.net/snapd/+bug/1856073
[16:27] <mup> Bug #1856073: Snap services not being removed correctly after snap removal <snapd:New> <https://launchpad.net/bugs/1856073>
[16:27] <mborzecki> guess, i'll just use my qemu wrapper instead
[16:27] <jdstrand> mborzecki: I'm still on beta. maybe it is a difference between 0.9 and 0.10
[16:33] <marcustomlinson> ijohnson: hey, on the topic of snap startup performance: https://forum.snapcraft.io/t/an-investigation-into-snap-startup-speed/14619
[16:34] <ijohnson> hi marcustomlinson thanks, I will try to take a look at that today
[16:35] <marcustomlinson> cool :)
[16:36] <pokk> cachio: no worries :) As ogra suggested I'm guessing it's a permission error due to rsync not having access to ssh?
[16:36] <cachio> rsync does not an interface for ssh
[16:37] <pokk> ogra, cachio I'm not sure if I'm abusing what Core is intended for. To me it seemed like a really good fit. I just want a minimal install with simple updates to keep it safe. For a super small remote backup service. Something that will ssh into my NAS and rsync over a backup.
[16:37] <pokk> it seems like an ideal use of Core. But maybe not
[16:38] <cachio> pokk, this is the definition of the rsync snap https://bazaar.launchpad.net/~snappy-dev/snappy-hub/rsync/view/head:/snapcraft.yaml
[16:38] <ijohnson> mvo: is there maybe an issue with the changelog script? https://github.com/snapcore/snapd/commit/d5d937e2f4c2f90de564beaff78a1742e7e5bd2c#diff-72a2d7a5614a41a35eaf22c94697dbf0R374
[16:38] <pokk> cachio: right, so just the removeable-media that we disussed last time around :)
[16:39] <cachio> pokk, yes
[16:40] <cachio> pokk, could you try the ssh which is not working and then execute "dmesg | grep DENIED"
[16:40] <cachio> and show the output
[16:40] <cachio> so I can see which interfaces are needed
[16:45] <mvo> ijohnson: uh, yes - nice catch
[16:45] <mvo> ijohnson: thanks, let me fix that, sometimes it gets confused, it's not super high-tech
[16:45] <ijohnson> np, just thought I'd make you aware :-)
[16:46] <mvo> ijohnson: thanks! and fixed in 2.43
[16:46] <Saviq> mborzecki: hey, re: https://github.com/CanonicalLtd/multipass/issues/1223 - if you can suggest a fix to the profile, we'd love to know!
[16:47] <cachio> pokk, I'll be afk 20 minutes, please leave the info you get and I'll read it once I am back
[16:48] <mborzecki> Saviq: sure, i need to take a look where the profiles come from first ;)
[16:48] <Saviq> mborzecki: https://github.com/CanonicalLtd/multipass/blob/master/src/platform/backends/shared/linux/qemuimg_process_spec.cpp#L39
[16:49] <mborzecki> Saviq: thanks!
[16:50]  * cachio afk
[16:52] <ogra> pokk, core should be great for that but you probably need to create your own application snap for the backup solution you want
[16:53]  * zyga -> supper 
[16:55] <pokk> ogra: I sort of assumed rsync would already be doing all I needed. But yeah, I can try and figure out how to create my own rsync snap
[16:55] <ogra> i fear that rsync can simply do rsync and nothing more :)
[16:55] <pokk> cachio: not sure what more info you need? If needed I can try and create my own snap for it. If you don't think it's reasonable to add ssh to rsync
[16:56] <pokk> rsync without ssh seems a bit limited imho, but it might be due to how I've always been using it
[16:56] <ogra> me too ... but i havent had any need to use it on core yet ...
[17:13]  * zyga went to explain browser security basics to his 10yo daughter
[17:13] <zyga> prompted by "cat following the browser" icon at school
[17:18]  * ogra files https://bugs.launchpad.net/snapd/+bug/1856212
[17:18] <mup> Bug #1856212: setting/unsetting proxy requires snapd restart on core18 <snapd:New> <https://launchpad.net/bugs/1856212>
[17:22]  * ijohnson has managed to break installing the most basic of test snaps on his machine
[17:24] <mup> PR snapd#7898 opened: overlord: replace DeviceContext.OldModel with GroundContext  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7898>
[17:56] <mup> PR snapd#7899 opened: many: pass consistently boot.Device state to boot methods <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7899>
[17:56] <cachio> pokk, I think in this case initially you could copy the snapcraft.yaml and add the ssh
[17:57] <cachio> and use it, I'll talk tomorrow to the team to see which is the best way to cover all the alternatives for rsync and I'll add a new snap version
[17:58] <pedronis> mvo: proposed #7898 following up on #7895, and then #7899
[17:58] <mup> PR #7898: overlord: replace DeviceContext.OldModel with GroundContext  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7898>
[17:58] <mup> PR #7895: many: add DeviceCtx.OperatingMode() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7895>
[17:58] <mup> PR #7899: many: pass consistently boot.Device state to boot methods <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7899>
[17:59]  * zyga -> coffee
[18:04]  * genii 's ears perk up momentarily at the mention of coffee, then he wanders back to work
[18:20] <mvo> pedronis: cool, I started with 7898
[18:20] <mvo> pedronis: and will see how far I get
[19:41] <mup> PR snapcraft#2842 opened: rust: add support for workspaces <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2842>
[19:42] <pokk> cachio: cool, I'll play around with it. Haven't done any snaps before
[19:51] <cachio> pokk, just copy that file and run snapcraft command
[19:52] <cachio> it  will create the snap
[19:52] <cachio> then you can add the interface you want and try to create the snap again
[19:52] <cachio> pokk, just ping me if you need any help
[20:02] <mup> PR snapcraft#2841 closed: plugs: add passthrough <Created by sd-hd> <Closed by sd-hd> <https://github.com/snapcore/snapcraft/pull/2841>
[20:38] <mup> PR snapd#7895 closed: many: add DeviceCtx.OperatingMode() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7895>
[20:38] <mup> PR snapd#7898 closed: overlord: replace DeviceContext.OldModel with GroundContext  <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7898>
[22:11] <mup> PR snapd#7897 closed: overlord/snapstate: tweak assumes error hint <Simple 😃> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7897>
[22:37] <mup> PR snapd#7894 closed: tests/main/parallel-install-remove-after: parallel installs should not break removal <Simple 😃> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7894>
[22:47] <mup> PR snapcraft#2843 opened: snap: only ship .pyc files, strip shared objects <Created by om26er> <https://github.com/snapcore/snapcraft/pull/2843>