[04:32] <jamesh> amurray: out of interest, was there some project in particular you wanted debug symbols for?
[04:33] <amurray> jamesh: I have a couple reports of crashes of my emacs snap and I am stumped how to easily enable users to get good backtraces
[04:37] <jamesh> we definitely want debug symbols for the snaps seeded on the desktop
[04:39] <jamesh> but there's not much to be done when they want a full design for snapcraft+store+snapd before considering any changes
[04:52] <amurray> jamesh: understood this is a "hard problem" ... but if folks want snaps to be first-class on the desktop there needs to be more focus on this IMO from all parties - it's not enough to have just you pushing on it (but I am glad you were)
[04:55] <jamesh> amurray: sure.  We've discussed it multiple times at previous dev summits, but when I've got more work to do than time available it is hard to prioritise something that gets ignored.
[04:56] <amurray> jamesh: i hear you
[04:56] <jamesh> I have gone back to update the first PR (https://github.com/snapcore/snapcraft/pull/2229) a few times to save it from bitrot, but that's about it
[04:56] <mup> PR snapcraft#2229: elf: extract build ID and presence of debug info <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/2229>
[05:13] <mborzecki> morning
[05:13] <mborzecki> wow, +11C outside :/
[05:39] <zyga> Good morning
[05:40] <zyga> Wow, I have a few more so not that drastic yet
[05:40] <zyga> Brrrrrr
[05:43] <mborzecki> zyga: hey
[05:48] <zyga> Doing school walk, be in the office soon
[06:03] <Mirv> do apps like signal-desktop, spotify, discord work for you on Ubuntu under Wayland? none of them start for me on SUSE under Wayland, and I'm wondering whether there's some low hanging fruit to grap.
[06:04] <Mirv> FYI https://pastebin.ubuntu.com/p/bSjqrJDhtf/
[06:05] <Mirv> I tried to search for LP bug reports at one point but it didn't sound they'd be broken for everyone
[06:05] <Mirv> Ubuntu defaults to X.org still so that makes it a bit different of course
[06:06] <jamesh> Mirv: is Xwayland listening on the abstract namespace socket?
[06:07] <Mirv> let me parse that for some time (or tell me how to check). it's running as /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -auth /run/user/1000/mutter/Xauthority -listen 4 -listen 5 -displayfd 6
[06:07] <jamesh> i.e. @/tmp/.X11-unix/X0 in addition to /tmp/.X11-unix/X0
[06:07] <jamesh> I think you can check with ss.  Let me work out the invocation
[06:08] <jamesh> "ss -xl | grep X11" might be the best way to check
[06:09] <jamesh> I see two listening sockets locally
[06:09] <mborzecki> zyga: ^^ opensuse & wayland
[06:10] <Mirv> there's @ too: https://pastebin.ubuntu.com/p/QVKJpjP26R/
[06:11] <jamesh> I'm not sure then. The non-abstract socket is definitely blocked by snap confinement though
[06:11] <Mirv> ok, let's wait for zyga then. I'm in no hurry, just starting my work day, happy to help debugging.
[06:23] <zyga> back in the office now
[06:24] <zyga> aha, I see the chatter about wayland and suse
[06:24] <zyga> I _guess_ I'm running tumbleweed under X11, let me recheck
[06:26] <zyga> logged back under wayland
[06:27] <zyga> it fails on
[06:28] <zyga> (and now no copy-paste, fun)
[06:28] <zyga> on /run/user/1000/mutter/Xauthority
[06:28] <zyga> I recall seeing this in a PR recently
[06:28] <zyga> hold on
[06:31] <zyga> Mirv: confirmed, adding an extra rule for that makes it work
[06:31] <zyga> Mirv: is there a bug report? I'll handle the rest
[06:43]  * zyga needs to work on reviews today
[06:44] <zyga> good morning mvo
[06:44] <mvo> hey zyga
[06:44] <mvo> zyga: good morning! I also need to do reviews
[06:45] <mborzecki> mvo: hey
[06:46] <mvo> hey mborzecki
[06:48] <abeato> morning! question about the content interface, is it possible to share only a file, or it must be a full folder?
[06:48] <zyga> abeato: currently it must be a file but I have a patch to share single files stashed
[06:49] <zyga> er
[06:49] <zyga> must be a directory
[06:49] <abeato> :D
[06:49] <abeato> zyga, great, nice that we will have one file sharing soon, that will be useful if you want to share just a socker
[06:49] <abeato> shocket
[06:50] <zyga> sockets are more tricky
[06:50] <zyga> not sure it'd work for sockets
[06:50] <zyga> I have not tried
[06:51] <abeato> hm, right, well, but in the end it is a file, right? mount bind should work too?
[06:51] <zyga> ish,
[06:52] <zyga> sockets have a tricky apparmor side
[06:52] <zyga> anyway, it's a matter of checking
[06:52] <abeato> right
[06:59] <mup> PR snapd#7403 opened: cmd: use libtool for the internal library <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
[07:02] <pstolowski> morning
[07:02] <Mirv> zyga: there was not, I now filed bug #1842615
[07:02] <mup> Bug #1842615 opened: Wayland apps not starting under openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1842615>
[07:03] <mup> Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1842615>
[07:03] <mborzecki> pstolowski:  hey
[07:04] <Mirv> zyga: awesome :) meanwhile I checked the problem does not affect openSUSE Leap 15.0, so just Tumbleweed
[07:04] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/7387 ?
[07:04] <mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
[07:17] <zyga> Mirv: thank you
[07:17] <zyga> mborzecki: yeah but I'll start with older PRs first
[07:17] <zyga> or I'll starve them again :)
[07:19] <ackk> zyga, hi, so I just ran into that issue again, and it doesn't have to do with snapcraft rewriting the prime dir: https://paste.ubuntu.com/p/BVDHmmCn48/
[07:20] <zyga> ackk: that's interesting, can you mkdir /root/snap/maas/x1 yourself?
[07:20] <zyga> ackk: or will you get a EROFS error?
[07:20] <zyga> Mirv: I've updated the bug report and I'll be sending a PR to fix it later today
[07:20] <ackk> zyga, the dir already exists
[07:20] <zyga> ackk: is it a mount point?
[07:20] <zyga> ackk: can you write through it?
[07:21] <ackk> $ sudo ls -ld /root/snap/maas/x1
[07:21] <ackk> drwxr-xr-x 1 root root 12 Sep  4 06:59 /root/snap/maas/x1
[07:21] <mup> Bug #1842615 changed: Wayland apps not starting under openSUSE Tumbleweed <snapd:In Progress by zyga> <https://launchpad.net/bugs/1842615>
[07:21] <ackk> zyga, yeah I can write it as root
[07:21] <ackk> I mean, write a file in it
[07:21] <ackk> it's not a mountpoint
[07:21] <zyga> let me look again
[07:21] <zyga> that's odd
[07:22] <zyga> ackk: can you please try this:
[07:23] <zyga> sudo strace -o /tmp/strace.log SNAP_INSTANCE_NAME=maas
[07:23] <zyga> /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
[07:24] <zyga> not sure if free of typos
[07:24] <zyga> but give it a try
[07:24] <zyga> I'd like to see strace run of snap-confine
[07:24] <zyga> to see what was the error it failed on
[07:25] <ackk> zyga, that's all a single command right?
[07:25] <zyga> correct
[07:25] <ackk> strace: Can't stat 'SNAP_INSTANCE_NAME=maas': No such file or directory
[07:25] <ackk> that can't go there, it seems
[07:26] <ackk> I guess before the strace?
[07:26] <zyga> sorry, my bad
[07:26] <zyga> yes
[07:26] <zyga> :)
[07:26] <ackk> $ sudo SNAP_INSTANCE_NAME=maas strace -o /tmp/strace.log /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
[07:26] <ackk> strace: exec: Permission denied
[07:26] <Mirv> thank you zy_ga!
[07:27] <ackk> zyga, ^
[07:27] <zyga> ackk: _hmm_
[07:27] <zyga> did I get strace wrong somehow
[07:28] <zyga> ackk: and it didn't leave any log, did it?
[07:29] <ackk> zyga, just http://paste.ubuntu.com/p/5VW47nhgv9/
[07:29] <zyga> why would it do that?
[07:29] <zyga> is that under lxd?
[07:29] <zyga> perhaps thats why :/
[07:30] <zyga> can you check on your host, if you got a denial in dmesg?
[07:30] <Jonno_FTW> hello
[07:30] <zyga> ackk: one more idea
[07:31] <Jonno_FTW> I get this error: error: cannot add authorization: open /users/jonm/.snap/auth.json: permission denied
[07:31] <Jonno_FTW> when my $HOME is on NFS
[07:31] <zyga> ackk: can you install an older snapd and check if this happens?
[07:31] <zyga> Jonno_FTW: hey, can you tell us the command you ran?
[07:31] <zyga> Jonno_FTW: and snap version, please
[07:31] <ackk> zyga, like, stable?
[07:32] <zyga> yes
[07:32] <Jonno_FTW> sudo snap install redis-desktop-manager, snap version 2.39.2-1.fc30
[07:32] <mvo> ondra: hey, do you want to push your "lk-next" changes to "lk"? it seems you adrdress issues found in the review from chipaca?
[07:32] <zyga> aha, fedora
[07:32] <Jonno_FTW> yep
[07:32] <zyga> mborzecki: ^ can you render ideas on how to check denials for selinux + nfs?
[07:33] <ondra> mvo I will, once I test them :)
[07:33] <ondra> I'm just flashing test image
[07:33] <mborzecki> zyga: ackk: snap run --strace='--raw -o foo.log' maas if you can hit ^C in time
[07:33] <zyga> mborzecki: that likely wont help if lxd is in control on top and denies it already
[07:33] <zyga> mborzecki: I meant the case above from Jonno_FTW
[07:34] <mborzecki> Jonno_FTW: can you try ausearch -m AVC and look for anything with recent time stamp
[07:34] <ondra> mvo it is booting, so image prepare is working, I just want to run few core refresh tests
[07:34] <ondra> mvo I already tested snapd snap update and that worked as well
[07:35] <Jonno_FTW> mborzecki: there's nothing recent
[07:35] <Jonno_FTW> certainly nothing from around the time I started using snap (like 30m ago)
[07:37] <ackk> zyga, I can't switch to stable snapd as maas uses the system-usernames
[07:38] <zyga> ackk: well, just for a test, it doesn't really have to work all the way
[07:38] <zyga> just to see if this is something in 2.41
[07:38] <mborzecki> Jonno_FTW: for the record, the error when you do snap login right?
[07:38] <mborzecki> s/error when/error pops up when/
[07:38] <ackk> zyga, mborzecki https://paste.ubuntu.com/p/D7Ddt4rZ6X/
[07:39] <ackk> zyga, well it doesn't work at all as I get https://paste.ubuntu.com/p/rJ4pWKvQkC/ from snapd
[07:39] <zyga> what's /snap/snap/bin/maas/current?!
[07:39] <zyga> ackk: try without /snap/bin/maas, just maas
[07:39] <zyga> I think that's snap run getting confused
[07:39] <ackk> zyga, that's the first try there
[07:40] <zyga> right, I just mean that /snap/snap is clearly wrong
[07:41] <ackk> $ snap run --strace='--raw -o foo.log' maas upgrade
[07:41] <ackk> /usr/bin/strace: exec: Permission denied
[07:41] <ackk> error: exit status 1
[07:41] <zyga> ackk: on lxd host, can you run dmesg | grep DENIED
[07:41] <zyga> I'm sure it's lxd
[07:45] <ackk> zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/
[07:45] <zyga> ackk: that's excellent
[07:45] <zyga> so that is confirmed
[07:45] <zyga> ackk: to move forward we should figure out how to switch lxd's own profile on your host into permissive mode
[07:46] <zyga> then we can debug forther
[07:46] <zyga> *further
[07:46] <zyga> ackk: do you think we can postpone until lxd developers are online?
[07:46] <ackk> zyga, sure
[07:46] <ackk> zyga, I don't have a real xenial host to test with unfortunately
[07:47] <zyga> ackk: that's fine
[07:49] <ackk> zyga, also when I tried installing maas snap from edge I didn't hit the issue, so i'm not sure what triggers it. I can run "maas init" and maas works fine, then something gets messed up
[07:49] <ackk> but it might only happen in "try" mode, IDK
[07:49] <zyga> the code where it fails should fail regardless of try mode
[07:49] <zyga> I'd like to get to the bottom of this later today
[07:49] <ackk> zyga, btw is there any chance that the snapfuse issue (taking 100%cpu in containers) could get fixed? that makes it impossible to install maas in a container
[07:50] <ackk> (install from a snap and not from "try')
[07:50] <mborzecki> zyga: pff the libtool patch fails on this https://paste.ubuntu.com/p/mGVnXnF5j6/ :/
[07:50] <zyga> ackk: nobody on our team can fix that
[07:50] <ackk> zyga, is it a kernel or lxd thing?
[07:50] <zyga> ackk: please escalate that to get help
[07:50] <zyga> ackk: perhaps both
[07:50] <zyga> it's a fuse filesystem
[07:50] <zyga> maybe the bottleneck is kernel side
[07:51] <zyga> maybe userspace
[07:51] <ackk> zyga, you're saying it's a bug in squashfuse?
[07:51] <zyga> I don't think any of us really read that code
[07:51] <zyga> ackk: it's certainly not a bug in snapd, we just mount a filesystem
[07:51] <zyga> mborzecki: yeah I ran into that a number of times
[07:51] <zyga> mborzecki: load of garbage :/
[08:00] <mborzecki> duh, obviously there's no way to have misspell skip files :/
[08:01] <zyga> mborzecki: sed it
[08:18] <mup> PR snapd#7398 closed: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7398>
[08:19] <zyga> mvo: I think we should all review from oldest to youngest
[08:19] <zyga> it seems that the last two pages are like attic
[08:24] <zyga> brb, tea
[08:27] <mborzecki> zyga: added a workaround to #7403, other than that, all tests passed
[08:27] <mup> PR #7403: cmd: use libtool for the internal library <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
[08:30] <mvo> a review for 7125 would be great, small, self-contained and open since jul
[08:31] <mborzecki> mvo: looking
[08:45] <zyga> back with tea
[09:09] <mvo> Chipaca: good morning! if you could have a look at 7383 that would be great (should be simple, just a msg tweak)
[09:11]  * Chipaca looks
[09:11] <Chipaca> mvo: good morning! I've been working for the last hour but having to restart x a few times to sort out some things
[09:11] <Chipaca> fun with nvidia :-/
[09:11] <mvo> Chipaca: no worries
[09:11] <zyga> Chipaca: drivers?
[09:11] <mvo> Chipaca: and good luck with X, I kinda given up on nvidia for this reason :(
[09:11] <zyga> mvo: my ubuntu experience with 1030 was very good FWIW
[09:12] <zyga> mvo: not so much with 2080, LTS doesn't have the drivers for it yet,
[09:13] <mvo> zyga: to be fair my experience is ~1-2y old so I may be totally off
[09:14] <zyga> mvo: I think it depends on how recent the OS is, there have been some great strides lately
[09:14] <zyga> mvo: not sure if you remember this but a few weeks ago nvidia has opened a large number of specs for their hardware to aid nouveau
[09:14] <zyga> mvo: it looks like early days of amd shift, when the tactic was to open up, but it was still a long road towards benefits
[09:14] <Chipaca> mvo: zyga: i broke things by trying to update the drivers from a ppa, to get some games running … undoing it was less than fun
[09:15] <Chipaca> i'd forgotten how bad the quality of ppa debs was
[09:15] <zyga> Chipaca: does your system work with 19.10?
[09:15] <zyga> Chipaca: it's a good idea to just try that from a spare partition if it does
[09:15] <Chipaca> zyga: I'm still waiting for confirmation it works with 18.04 :-/
[09:15] <zyga> Chipaca: weekend evening project to check? :-)
[09:16] <Chipaca> nu uh
[09:16] <Chipaca> zyga: i've got way more fun weekend projects than updating a machine that works :-)
[09:16] <zyga> that's fair :-)
[09:16] <zyga> Chipaca: I played one game recently, control, strongly recommend it if you have the 3 evenings to finish it
[09:17] <zyga> anyway, back to reviews :)
[09:18] <mup> PR snapd#7396 closed: tests: don't guess in is_classic_confinement_supported <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7396>
[09:18] <mborzecki> zyga: w8, 3 evenings? is that how long the game is?
[09:19] <zyga> mborzecki: I think I played 6 hours each time
[09:19] <zyga> well into past 3AM :D
[09:19] <zyga> mborzecki: I just finished the main plot, there's more to do but that's enough for me
[09:20] <zyga> mborzecki: or I'm just pretty good at aiming
[09:20] <zyga> ;-)
[09:20] <mborzecki> hahaha
[09:20] <mborzecki> mad quake skillz? :)
[09:20] <zyga> mouse sensitivity set to maximum, field of view 120, those things ;)
[09:21] <zyga> just kidding though
[09:21] <zyga> the game is story driven
[09:21] <zyga> the combat is challenging but doesn't feel like grind
[09:21] <zyga> and unlike most shooters I can remember, it is very rewarding to use the very first revolver you get all the game
[09:21] <zyga> anyway
[09:22] <zyga> something for evening :)
[09:23] <mborzecki> zyga: fwiw, double barrel works in through all of doom too :P
[09:24] <zyga> mborzecki: indeed, but that's an exception, here the game gives you one gun, sharing ammo across all forms, and as you play you unlock more forms that are more suited for specific type of combat; what it doesn't do is to give you a much better gun that obsoletes the first one
[09:24] <Saviq> Chipaca: hey, you seem to know about snapshots, is it expected that `snap restore` does not restart the snap? is there something that can be done about that?
[09:25] <Chipaca> Saviq: yes, it's expected; stop all services / apps before restore, start them after
[09:27] <Saviq> kk
[09:27] <Chipaca> Saviq: that is, if you need to
[09:27] <Chipaca> Saviq: you don't always need to -- same as you don't always need to stop for a 'save'
[09:28] <Saviq> Chipaca: yeah, which is why  it feels like there should be hooks for this :)
[09:29] <Chipaca> Saviq: would a hook be able to know whether an app in the snap is running?
[09:29] <Chipaca> (in general the answer is 'no')
[09:30] <Saviq> Chipaca: an app, no, but a service, yeah
[09:30] <Chipaca> (zyga's work wrt deferring refreshes while apps are running might let us fix that)
[09:31] <Saviq> there's also https://forum.snapcraft.io/t/automatic-snapshot-opt-out/12131 - a `save` hook could reduce the size of the snapshot, but maybe it'd be better to have a whitelist for this particular usecase
[09:33] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7387 ?
[09:33] <mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
[09:34] <pstolowski> mborzecki: sure
[09:34] <mborzecki> thanks!
[10:03] <zyga> jamesh: I finally reviewed https://github.com/snapcore/snapd/pull/6767#pullrequestreview-283483314
[10:03] <mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
[10:03] <jamesh> zyga: thanks.  Looking
[10:04] <zyga> jamesh: I think my only comment that would warrant blocking are related to validation
[10:04] <zyga> jamesh: on non-compliant files in meta/gui/icons
[10:04] <zyga> jamesh: as well as on file sizes in that place
[10:04] <zyga> jamesh: everything else is something that is good for followup
[10:05] <zyga> jamesh: I'm moving on to the next review, please ping me with your opinion
[10:05] <zyga> jamesh: as I said, you have +2 and you can merge as is
[10:05] <zyga> jamesh: but I'm worried about opening a hole
[10:05] <Chipaca> zyga: FWIW we already don't do that sort of validation on icons
[10:05] <Chipaca> zyga: so it's independent from that work
[10:05] <zyga> Chipaca: yes but now we read them into memory
[10:05] <zyga> Chipaca: in this PR
[10:05] <Chipaca> we do?
[10:05] <Chipaca> where?
[10:05] <zyga> ReadFile
[10:06] <Chipaca> why do we ReadFile them?
[10:06]  * Chipaca goes to look
[10:06] <pedronis> because Ensure* does that internally
[10:06] <pedronis> but I made a proposal in one of my comments
[10:06] <zyga> https://github.com/snapcore/snapd/pull/6767/files#diff-1a7d1cbe7825f23c89fbefcac29f347aR82
[10:06] <zyga> here
[10:06] <zyga> perhaps one way to solve this
[10:06] <mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
[10:06] <zyga> is to extend ensure
[10:06] <zyga> to give it a handle that knows what the content is
[10:06] <zyga> and the size
[10:06] <zyga> so they can be stream like
[10:06] <ogra> oh ! gpio-control ? who breeded that ? (thats beautiful ! )
[10:07] <zyga> that's a good idea separately but I would not like to just let this silently merge without pointing it out
[10:07] <zyga> ogra: thank ondra
[10:07]  * ogra thanks ondra 
[10:07] <zyga> I'll keep doing reviews to unblock people, I said my thing
[10:07] <ogra> ondra, beer for you in barcelona !
[10:11] <zyga> pedronis: should I review https://github.com/snapcore/snapd/pull/6705 ?
[10:11] <mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
[10:19] <pedronis> zyga: I'm looking at it right now, going a bit slowly
[10:19] <pedronis> also lunch
[10:19] <zyga> ok, I'll pick up the next one
[10:22] <zyga> mvo: hey, is https://github.com/snapcore/snapd/pull/6839 something that's ready for review?
[10:22] <mup> PR #6839: devicestate: allow remodel to different kernels  <Remodel :train:> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6839>
[10:24] <zyga> jamesh: this needs some comment feedback https://github.com/snapcore/snapd/pull/7073
[10:25] <mup> PR #7073: interfaces: OpenGL/Vulkan drivers provided by a base should be usable <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7073>
[10:26] <jamesh> zyga: I think the way forward for that PR was to relax the AppArmor rules for snaps using a base other than core/core18
[10:26] <zyga> jamesh: indeed, can you please comment on it so that it's clear where we stand?
[10:26] <jamesh> on the assumption that non bootable bases should only contain files that are intended for use by apps
[10:27] <zyga> yeah, I recall the conversation about that in Toronto
[10:28] <mup> PR snapd#7404 opened: cmd/snap: don't append / to snap name just because a dir exists <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7404>
[10:29] <Chipaca> zyga: #7159 is an easy one
[10:30] <mup> PR #7159: tests: add functions to make an abstraction for the snaps <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
[10:30] <zyga> looking quickly
[10:32] <pstolowski> pedronis: #7005 got 2 +1s and i adressed your earlier high-level feedback re having 'snap debug state..', would you like to take another look or can it land?
[10:33] <mup> PR #7005: debug: state-inspect debugging utility <Created by stolowski> <https://github.com/snapcore/snapd/pull/7005>
[10:50] <pedronis> pstolowski: it might be easier to land it and I play with it a bit once is in edge
[10:50] <pstolowski> pedronis: ok, ty
[11:04] <pstolowski> pedronis: i'm thinking of adding some kind of high-level simplified potential-conflict-checking command for it in the future, something rudimentary that doesn't try to replicate existing logic (because that could simply hide an existing problem), but rather list candidates for closer inspection. not sure if/how this will work in practice and how valuable it will be, but sometimes just filtering out irrelevant data
[11:04] <pstolowski> from the state and setting initial focus is helpful
[11:06] <zyga> jamesh: hey, question about https://github.com/snapcore/snapd/pull/7129#pullrequestreview-283531582
[11:06] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[11:06] <zyga> I know it's not your PR but do you know why we need to add a "get set sub-property API"?
[11:06] <mvo> hm, tests are very red, shall we disable 19.10 for now?
[11:06] <zyga> mvo: what is failing if I may ask?
[11:07] <mvo> zyga: let me look again but pretty much everything is red
[11:07] <zyga> like all tests are failing?
[11:08] <zyga> I mean, there must be something that actually fails :)
[11:09] <mvo> zyga: the samples I looked at this morning were 19.10 but let me re-look to see if this is actually still happening
[11:09] <zyga> do you remember if a specific test was at fault?
[11:10] <mvo> zyga: iirc desktop-portal but let me look again
[11:10] <zyga> that fails uniformly though
[11:10] <zyga> it fails on me every day, or close
[11:10]  * mvo nods
[11:10] <zyga> I'd be happier if we can disable the test instead
[11:11] <zyga> and look at it really hard until we really understand why
[11:11] <mvo> https://travis-ci.org/snapcore/snapd/pull_requests <- looks sad
[11:16] <pstolowski> degville: hey! i'm looking for the best place to add documentation for snap unset and snapctl unset (and equivalents with 'set' subcommands followed by exclamation mark). seems like they need to go to https://forum.snapcraft.io/t/configuration-in-snaps/510 and https://forum.snapcraft.io/t/supported-snap-hooks/3795 ; do you know any better spot?
[11:19] <mup> PR snapd#7405 opened: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7405>
[11:23] <jwheare> zyga: re: 7129 my changes are almost entirely just repurposed existing code and style. i don't write go usually so feel free to make any stylistic changes you want
[11:24] <jwheare> the reason i added GetSub was because i couldn't see a way in go to have multiple function heads with different numbers of arguments
[11:24] <jwheare> (unlike say erlang)
[11:25] <jwheare> without eliminating types and then doing dynamic type checks
[11:28] <zyga> jwheare: hey, thank you for explaining that.
[11:29] <zyga> I will look at this with new information after lunch
[11:34] <degville> pstolowski: hello - thanks for looking! I think you're absolutely right about those locations - especially Configuration in snaps. We can always shuffle things around if the words fit somewhere better, but I think they're the best place for now.
[11:35] <pstolowski> degville: great, ty! ok if if i just edit it there (new paragraphs/subsections) and you take a look afterwards?
[11:35] <degville> pstolowski: yep - sounds good!
[11:36] <pstolowski> ok
[11:36] <ondra> ogra always ready for beer :P
[11:38] <ondra> mvo sorry I was at dentist, back now and doing more testing
[11:38] <ondra> mvo so far looks good
[11:38] <ondra> mvo I will push changes from lk-next to PR branch
[11:38] <mvo> ondra: sounds great, thank you
[11:39] <ondra> mvo one more question, there is essential c header file, which should be implemented by corresponding bootloader, I was wondering where to host that header file
[11:40] <ondra> mvo one option is to have it in bootloader/lkenv/snappy-boot.h
[11:40] <Chipaca> hmm, is it always the same two 19.10 tests that are failing?
[11:40] <ondra> mvo do you have any better idea where to host it?
[11:42] <ondra> mvo OK there is problem with seeding with my test snap
[11:43] <ondra> mvo I will debug, but it could be kernel seeding, when it tries to install bootimg
[11:44] <Chipaca> a pox on google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control
[11:55] <ondra> mvo interesting is that it seems to panic when applying core18 security profiles though
[11:57] <ondra> mvo I will need to create image with cloud init to log in though, first boot crash is a bit pain to debug as there is no good way to log in. So I will try update path now
[11:58] <ondra> mvo ignore me, i think it's kernel seeding, it just happens right after core
[12:23] <pstolowski> degville: i updated the snap get/set document, but the one about hooks & snapctl needs some more work i think, it's a little bare when it comes to snapctl
[12:25] <degville> pstolowski: thank you! I'll take a look at set/get.
[12:39] <mup> PR snapd#7406 opened: cmd/snap-confine: keep track of snap instance name and the snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7406>
[12:39] <zyga> thanks!
[12:42] <mborzecki> + '[' no = yes ']'
[12:42] <zyga> test failed
[12:42] <zyga> that's that ;)
[12:42] <zyga> what printed that?
[12:43] <mborzecki> zyga: google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control
[12:43] <zyga> our favourite test
[12:44] <ijohnson> mborzecki: I saw the same thing on one of Chipaca's PR's last night
[12:44] <ijohnson> I think it's a bug with eoan
[12:44] <mborzecki> mhm, mvo has a PR disabling it
[12:44] <mborzecki> for 19.10 at least
[12:44] <ijohnson> mborzecki: also thanks for the review, I responded
[12:45] <mborzecki> ijohnson: many dragons in snapstate handlers :) remember when i first dug into that
[12:46] <ijohnson> yeah indeed!
[12:46] <ijohnson> and yeah also not really sure about the `saveSnapDisabledServices` name either, it feels awkward, but I also need to do the same thing multiple places so I wanted to eliminate code duplication
[12:46] <pedronis> mvo: ondra: commented on the lk PR
[12:47] <ondra> pedronis thank you :)
[12:47] <ondra> mvo found issue, we do not determeng run time mode correctly on device
[12:47] <ondra> determine
[12:48] <mup> PR snapd#7405 closed: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7405>
[12:53]  * ijohnson will miss SU again today, need to go with someone taking the citizenship oath :-)
[12:56] <mvo> pedronis: thank you!
[12:57] <zyga> mvo: https://github.com/snapcore/snapd/pull/7405/files#r320742967 ;-)
[12:57] <mup> PR #7405: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7405>
[12:58] <zyga> geee I wish I made coffee before the call
[13:12] <zyga> jwheare: so, a quick question on Get/Set DBus API
[13:12] <zyga> jwheare: can the "setting" attribute  be like a obj.attr?
[13:13] <zyga> that would allow us to have one get and handle everything with it
[13:13] <zyga> jwheare: or perhaps / as I see the code already uses it
[13:15] <mup> PR snapcraft#2698 opened: dirs: check for existence of required data directories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2698>
[13:20] <ondra> pedronis I asked already mvo, but since you commented on it. I'd like to add c header file into lkenv dir for reference, otherwise I'm struggling to think about better place for it
[13:22] <jwheare> zyga: i tried not to change existing apis
[13:22] <mup> PR snapd#7403 closed: cmd: use libtool for the internal library <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
[13:30] <Chipaca> degville, pedronis: https://twitter.com/jonworth/status/1169185705823735809
[13:33] <jwheare> zyga: the / is used mainly just for logging strings tbh
[13:33] <zyga> jwheare: I'm getting familiar with this area
[13:33] <degville> Chipaca: ugh, thanks... if I squint, it looks like the sphinx. Riddle? Relic of lost civilisation?
[13:33] <zyga> my idea was to drop the Sub methods
[13:33] <zyga> and just allow more to be expressed by the property being interacted with
[13:37] <mvo> zyga: re timeserver-control test - fun: https://paste.ubuntu.com/p/skNwxPPGGn/ - it looks like a version mismatch of the tools with the systemd version running
[13:38] <jwheare> if you'd rather the api just be e.g. Check("default-url-scheme-handler/irc", "ircclient.desktop") or Check("default-web-browser", "browser.desktop") that's your call
[13:38] <pedronis> mvo: fun not
[13:38] <mvo> pedronis: yeah, so the timdatectl from the snap is 229 and does not (apparently) understand what 241 tells it
[13:39] <pedronis> big mess actually, we'll need to think
[13:39] <jwheare> i felt the more explicit separation of property/subproperty was a cleaner api, less magic, but i don't know the project
[13:39] <Chipaca> degville: right click, view image, zoom in -- or look for the post where jon links to the svg :)
[13:40] <jwheare> personally, i don't see more functions as a bad thing, in general
[13:40] <pstolowski> Chipaca: yay, that's very helpful, ty ;)
[13:41] <jwheare> but i have no strong feelings. if you think encoding the subproperty within the property string makes sense go for it :)
[13:45] <sergiusens> pedronis: mvo sorry for insisting, but I wanted confirmation that the snapd snap builds fine with snapcraft from edge to fix  anything before another half complete release (I will start the release process with your green light)
[13:47] <mvo> pstolowski: do you think you could double check if snapcraft from edge is fine with the snapd snap type?
[13:47] <mvo> pstolowski: see the question from sergiusens
[13:49] <sergiusens> ah, right, I did build pstolowski branch, if that is all you need, then we should be good to go (but ssome form of sanity test that could be run would be ideal)
[13:50] <pstolowski> mvo, sergiusens i will
[13:51] <pstolowski> mvo, sergiusens is it critical to check all build methods (lxd, multipass, destructive)?
[13:54] <sergiusens> pstolowski: in general no, unless you use hardcoded paths (I fixed on in a PR last week)... if you do try either multipass (or lxd) and --destructive-mode
[13:56] <zyga> mvo: because of change in formatting?
[13:56] <zyga> I think I saw that
[13:58] <mvo> zyga: yeah, I'm looking at it now
[13:58] <mvo> zyga: hopefully not too hard to fix
[14:00] <pstolowski> sergiusens: ok, thanks, i'm going to check this in a moment (with my branch)
[14:11] <zyga> re
[14:15] <zyga> mvo: any findings?
[14:17] <mvo> zyga: in a meeting, but I see  [  503.301852] audit: type=1400 audit(1567605570.552:74): apparmor="DENIED" operation="capable" profile="snap.test-snapd-timedate-control-consumer.timedatectl-timeserver" pid=31856 comm="timedatectl.rea" capability=12  capname="net_admin"
[14:17] <zyga> missing permissions, it seems
[14:19] <mvo> zyga: yeah, I look some more after the meeting
[14:19] <zyga> thank you
[14:23] <cachio> mborzecki, Chipaca hey, could you please take a look to #7401
[14:23] <mup> PR #7401: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
[14:23] <Chipaca> cachio: yep
[14:23] <cachio> zyga, hey, yesterday I saw you were taking a look to a problem related to the snapd snap right?
[14:24] <Chipaca> cachio: nice
[14:24] <cachio> zyga, it is the only concern I have before promoting this to candidate
[14:25] <zyga> cachio: which specific problem, sorry - there were too many topics lately
[14:26] <cachio> zyga, the one related to maas
[14:26] <zyga> ah
[14:26] <zyga> sorry, yes
[14:26] <zyga> it's not a regression IMO
[14:26] <cachio> zyga, the issue which you were discussing with ackk
[14:26] <zyga> and it's specific to specific development flow
[14:26] <zyga> I'd not block on it
[14:26] <zyga> it's a UX issue, not a behavior change
[14:26] <cachio> zyga, perfect, thanks for the info
[14:28] <zyga> ackk: ^ FYI
[14:29] <mup> PR snapd#7401 closed: tests: add unstable stage for travis execution <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
[14:31] <mup> PR snapcraft#2699 opened: python plugin: add option to process-pipfile-lock for pipenv users <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2699>
[14:33] <mup> PR snapd#7407 opened: tests: run failing tests on ubuntu eoan due to is now set as unestable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7407>
[14:42] <jwheare> zyga: do i interpret your latest comment to mean you're happy with Get and GetSub etc being separate?
[14:42] <zyga> yes, that's right
[14:42] <jwheare> cool
[14:42] <zyga> I'm reviewing technical details now
[14:42] <zyga> it's close I think
[14:53] <mup> PR snapd#7397 closed: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7397>
[14:55] <ackk> zyga, so you know what's causing that issue?
[14:56] <zyga> ackk: no, but if you are around we can work on exploring more
[14:56] <zyga> ackk: we need to switch the host's lxd profile to permissive mode
[14:56] <zyga> ackk: and try strace again
[14:56] <cachio> jamesh, hey, could you please take a look to the comment I left in #7351
[14:56] <ackk> zyga, how do I do (and then revert) that?
[14:56] <mup> PR #7351: tests: retry checking until the written file on desktop-portal-filechooser <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7351>
[14:56] <zyga> ackk: I think you can do that in-memory
[14:56] <zyga> using ...
[14:57] <pstolowski> sergiusens: snapd from my PR built fine with multipass (i took a gooooood while to download all deps). i'm going to check destructive now
[14:57] <zyga> ackk: there's aa-complain
[14:57] <zyga> ackk: but really we want to find the profile on disk
[14:57] <sergiusens> pstolowski: if what it built works,, then we are solid for moving forward :-)
[14:57] <zyga> stgraber: where does lxd keep its apparmor profiles on disk?
[14:57] <zyga> ackk: we need to edit one profile and add one word to make it advisory, not enforced
[14:58] <ackk> zyga, how do I find it? I'm not very familiar with aa
[14:58] <pstolowski> sergiusens: yeah i don't expect problem with destructive since that's already coverted by spread test in my PR.. but i can check manually for piece of mind
[14:58] <zyga> ackk: unfortunately the kernel does not know so we just need to look around, hold on
[14:59] <stgraber> zyga: /var/snap/lxd/common/lxd/security/apparmor/
[14:59] <zyga> stgraber: thank you so much!
[14:59] <zyga> ackk: let's look at that path please
[14:59] <zyga> ackk: we want to change the profile that was denied
[14:59] <zyga> stgraber: perhaps there's an easier way to allow strace inside a container?
[15:00] <zyga> ackk: can you please remind me the DENIED line that you found then?
[15:00] <stgraber> zyga: strace is allowed inside containers
[15:00] <ackk> zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/
[15:00] <zyga> stgraber: we had a ptrace deny, perhaps it's more complex and two things together make it fail
[15:00] <ackk> stgraber, ^
[15:00] <ackk> stgraber, also, hi :)
[15:00] <zyga> peer="unconfined"
[15:01] <zyga> ackk: when you ran snap-confine manually,that was inside the container, right?
[15:01] <zyga> ackk: along with sudo and strace
[15:01] <zyga> all inside?
[15:01] <ackk> yes
[15:01] <zyga> ok
[15:02] <zyga> do I read that right, that snap-confine itself is denying the trace?
[15:04] <zyga> ackk: can you show me how to get to this stage? I can explore this locally somewhat faster perhaps
[15:04] <ackk> zyga, well I'm not sure if you can get to that stage easily with the snap from the store
[15:05] <stgraber> so we do have a ptrace restriction which prevents cross-profile ptracing to avoid cross-container security issues, I wonder if this is somehow triggering there
[15:05] <zyga> ackk: I'm happy to get some fresh stuff from git and play
[15:05] <zyga> stgraber: perhaps, I can just disable everything quickly locally to get to the bottom of the error that is masked behind this
[15:06] <stgraber> ackk: "lxc config set NAME raw.apparmor ptrace," should allow everything
[15:06] <ackk> zyga, so. you'd have to git clone lp:maas; build the snap and snap try it
[15:06] <ackk> stgraber, I assume I need to reboot?
[15:06] <ackk> (the container)
[15:06] <stgraber> yeah
[15:07]  * ackk tries
[15:07] <ackk> thanks
[15:07] <zyga> ackk: cloning
[15:09] <zyga> ackk: so having maas cloned
[15:09] <zyga> snapcraft?
[15:09] <ackk> zyga, of course, after rebooting the container the issue went away :/
[15:09] <zyga> ackk: oh?
[15:09] <zyga> that's interesting
[15:09] <ackk> zyga, yeah, I use --destructive-mode in the container
[15:09] <zyga> can you rebuild maas
[15:09] <zyga> and see if that breaks it again
[15:09] <ackk> sure
[15:09] <zyga> and then, re-run the sudo snap-confine strace line
[15:10]  * Chipaca needs caffeine
[15:10]  * Chipaca looks for something intravenous
[15:13] <mvo> xnox: did timedatectl change in 19.10? when I run "timedatectl  set-ntp no" (or yes) the "timedatectl status" output does not change regardless of yes/no
[15:22] <mvo> xnox: this is GCE so maybe this is relevant
[15:30] <mvo> xnox: aha! so it looks like we have chronyc on GCE
[15:30] <zyga> ooo
[15:30] <zyga> mvo: so ntp is always on?
[15:31] <zyga> ackk: any luck?
[15:32] <mvo> zyga: sort of, yes
[15:32] <mvo> zyga: anyway, I think I know what to do
[15:32] <ackk> zyga, no, I rebuilt and installed the snap (via snap try), but it seems to work so far
[15:32] <ackk> zyga, will try the strace if it happens again
[15:33] <zyga> ackk: thank you
[15:33] <ackk> zyga, still, that snap-confine line fails with permission denied
[15:34] <ackk> although "sudo maas" currently works
[15:34] <zyga> ackk: not with permission denied
[15:34] <zyga> it's confusing
[15:34] <ackk> $ sudo SNAP_INSTANCE_NAME=maas strace -o /tmp/strace.log /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
[15:34] <zyga> if you look at the source
[15:34] <ackk> strace: exec: Permission denied
[15:34] <zyga> it has failed already
[15:34] <zyga> ah, sorry
[15:34] <zyga> that line does fail on strace and lxd
[15:35] <Chipaca> hmm, i'm seeing repeated failures for google:ubuntu-{16,18}.04-64:tests/main/proxy-no-core
[15:35] <zyga> that's strace being unable to execute snap-confine
[15:35] <ackk> $ snap run --strace='--raw -o foo.log' maas upgrade
[15:35] <ackk> /usr/bin/strace: exec: Permission denied
[15:35] <ackk> error: exit status 1
[15:35] <ackk> zyga, ^ this one too
[15:35] <zyga> yes, it's the same thing really
[15:35] <xnox> mvo:  that.
[15:35] <zyga> (snap run call strace)
[15:35] <xnox> mvo:  they asked and we changed default to chrony
[15:35] <xnox> mvo:  on gce
[15:35] <ackk> zyga, ok
[15:35] <JonelethIrenicus> can i change the default folder for snap configuration files?
[15:35] <zyga> what does chrony do?
[15:36] <zyga> JonelethIrenicus: which files?
[15:36] <zyga> but most likely no, it's not very easy to do
[15:36] <JonelethIrenicus> in ubuntu 19.04 it has a snap folder in the home directory
[15:36] <JonelethIrenicus> it isn't a dot file
[15:36] <zyga> there's a bug report for that
[15:36] <JonelethIrenicus> ahh ok
[15:36] <zyga> it's extremely hard to change
[15:36] <zyga> I'm sorry
[15:37] <JonelethIrenicus> all good
[15:37] <JonelethIrenicus> just was curious why it was in my home directory like that
[15:38] <zyga> JonelethIrenicus: this is bug https://bugs.launchpad.net/snapd/?orderby=-heat&start=0
[15:38] <zyga> and I do intend to fix it
[15:38] <zyga> b
[15:38] <zyga> but to fix it properly I need to build enough infra to be able to move it first
[15:38] <JonelethIrenicus> awesome thanks
[15:38] <zyga> without breaking people
[15:38] <zyga> so it's a bit slow
[15:38] <JonelethIrenicus> right
[15:39] <mvo> xnox: thanks, I will fix our test then
[15:39] <zyga> I'm burned out with reviews today
[15:39] <zyga> I'll switch to coding
[15:40]  * Chipaca hugs zyga 
[15:40] <zyga> thanks Chipaca
[15:40] <zyga> writing is easier than reading
[15:40] <zyga> you know what you meant up front :)
[15:42] <ondra> pedronis are you OK for me to resolve comments which I already addressed? like change of error messages? Or are you gonna resolve those yourself?
[15:42] <pedronis> ondra: I can do it
[15:43] <pedronis> Chipaca: mborzecki: I proposed something in #7402 inspired by maciej ideas
[15:43] <ondra> pedronis thanks, just want to clean it a bit, so I can see which comments still need work
[15:43] <mup> PR #7402: daemon, client, cmd/snap: include architecture in 'snap version' <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>
[15:44] <Chipaca> pedronis: we could think of (someday) adding cloud info there also
[15:48] <Chipaca> not sure if there's a uniform way of finding out what cloud you're on (maybe via cloud-init or sth)
[15:49] <ondra> mborzecki do you have good example of gadget yaml to update to update assets
[15:49] <ondra> mborzecki forum post seems to be missing good example
[15:50] <mup> PR snapd#7408 opened: tests: fix interfaces-timeserver-control on 19.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7408>
[15:53] <pedronis> ondra: done
[15:53] <pedronis> Chipaca: we do get that info
[15:53] <tomwardill> hi! I'm trying to install snaps inside a xenial lxd, but getting "system does not fully support snapd: apparmor detected but insufficient permissions to use it". Is there a fix?
[15:53] <ondra> pedronis thanks
[15:53] <pedronis> Chipaca: it's a bit too much info tough, people might want not to tell us
[15:54] <ondra> pedronis what do you think about option to add header file to snapd repo?
[15:55] <ondra> pedronis or what is best place to have that reference header file?
[15:59] <zyga> ondra: would that header file ship with snapd binary
[15:59] <zyga> ondra: or just in the source repo
[15:59] <ondra> zyga just in source
[15:59] <ondra> zyga it is reference which should be used by bootloader
[15:59] <zyga> I see
[15:59] <Chipaca> pedronis: fair
[15:59] <Chipaca> i'm off to the gym, will bbl
[15:59] <ondra> zyga so data structure used by snapd and bootloader is in sync
[16:00] <zyga> ondra: put it in a manual page
[16:00] <zyga> ondra: on the forum :)
[16:00] <ondra> zyga I want it somewhere from where it's easy wget
[16:00] <zyga> ondra: why?
[16:00] <pstolowski> sergiusens, mvo: both multipass and destructive-mode builds worked with type:snapd + build-base:core 👌
[16:00] <zyga> would you expect people to wget it constantly?
[16:00] <zyga> because it changes all the time
[16:01] <ondra> zyga as this is also needed at gadget build time, when device pre-populated env should be generated
[16:01] <zyga> ondra: no, it's not
[16:01] <zyga> ondra: what is needed is the structure or other type it defines
[16:01] <zyga> ondra: hence my question
[16:01] <zyga> ondra: is it expected to change often?
[16:01] <zyga> ondra: what happens when it changes
[16:01] <ondra> zyga no it does not change, but file is used by around, and I want it to be in sync
[16:01] <zyga> ondra: keeping it in easy-wgettable place doesn't seem to solve any issues
[16:01] <zyga> ondra: you cannot have both :)
[16:02] <zyga> ondra: I think that's more important than where it is
[16:02] <zyga> ondra: what happens when, eventually, it must change
[16:02] <ondra> zyga if it changes, it will likely be new file, as it will have new version
[16:02] <zyga> ondra: then you don't need to wget it
[16:02] <zyga> it's fine to document as if it was a manual page
[16:02] <zyga> because it's fixed forever in stone
[16:02] <zyga> just make sure to name it, v1
[16:02] <ondra> zyga so new version will be new file, this file is essentially set in stone once snapd adopts it
[16:03] <ondra> zyga that's why I want single place to get it from
[16:03] <zyga> I think that's the essential information
[16:03] <zyga> thank you
[16:03] <ondra> zyga OK where can I have it, so I can wget it?
[16:03] <zyga> ondra: anywhere, because it's a constant now
[16:04] <zyga> ondra: just make sure not to accidentally make go build it
[16:04] <ondra> zyga so can I add it to snapd repo? :P
[16:04] <zyga> ondra: go is tricky for that
[16:04] <zyga> ondra: include/ perhaps (we don't have it yet)
[16:04] <ondra> zyga if I only add it there, how do I make sure it's not go build?
[16:04] <zyga> ondra: don't add any go files there
[16:04] <ondra> zyga I though to have it right next to go version, so bootloader/lkenv/
[16:05] <zyga> that's not godo
[16:05] <zyga> *good
[16:05] <zyga> it might get pulled for cgo build
[16:05] <ondra> zyga hmm
[16:05] <ondra> zyga so creating include directory?
[16:08] <zyga> ondra: yeah, it seems like that to me
[16:08] <ondra> zyga OK I will add it there
[16:08] <ondra> zyga goog idea
[16:09] <zyga> not a guarantee it will pass
[16:09] <zyga> but let's see
[16:09] <ijohnson> you could be tricky and add it to testdata
[16:09] <zyga> I hope my comments were not snarky in reception
[16:09] <zyga> I really did mean to point the light on the key issue of evolution
[16:10] <zyga> because that's the hard part of this problem
[16:10] <ijohnson> go ignores files in testdata, but it's not really test data so _shrugs_
[16:10] <zyga> sharing an agreed structure is easy
[16:11] <zyga> I'm near EOD
[16:12] <zyga> looking at apparmor bits
[16:14] <zyga> spread is spreading
[16:16]  * ijohnson lunches
[16:43] <mup> PR snapd#7409 opened: Allow a confined Wayland server running in a user session to work with Qt, GTK3 & SDL2 clients <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7409>
[16:45] <diddledan> so you can now run the gimp snap in Windows: https://usercontent.irccloud-cdn.com/file/SXwtQQGd/image.png
[16:58] <zyga> diddledan: is it stable? I had issues with the x server
[16:58] <diddledan> I'm using the x server in mobaxterm
[17:00] <mvo> thanks pstolowski|afk
[17:10] <ondra> Chipaca please re-review my changes, I believe I have address those I commented on
[17:51] <Saviq> sergiusens: is this error expected on a Pi? https://forum.snapcraft.io/t/building-for-core18-multipass-issue/8958/35
[18:19] <Chipaca> ondra: will do (not right now tho)
[18:19] <ondra> Chipaca thanks :)
[18:21] <sergiusens> Saviq: I think ijohnson got the gist of it. This is why the meeting this Friday is important :-)
[18:21] <sergiusens> Saviq: I am leaning to having that same image that is produced for multipass to be used for lxd on all architectures
[18:21]  * ijohnson hopes the meeting on friday ends in snapcraft being able to make me a sandwich 
[18:23] <ogra> Saviq, sergiusens, these images from friendlyarm are an awful hackish mess (and legal should really go after them for claiming this crap is based on UbuntuCore ... ) it is some self-debootstrapped rootfs with configs manually hacked up etc and somce home-brewed BSP kernel binary
[18:24] <Chipaca> ijohnson: it can already make you a sandwich! the yaml is tricky though
[18:24] <sergiusens> ogra: ah, interesting, but I will not go into any legal topic on a public forum :-)
[18:24] <ogra> i wouldnt judge that an "error is expected on a pi" just because it fails on these hacked up vendor images
[18:24] <ijohnson> I bet it uses those silly yaml anchors
[18:25] <ogra> sergiusens, yeah, i shouldnt either it is just the third person on the forum in a month that has issues due to this "based on core" claim ... starts to really annoy me :)
[18:30] <Chipaca> ijohnson: b̥̦̪̞ͅa̞̙̫ͅs̜e̫̬̱̠͈̬̬:̡̣̦ ̙͚̤͓̜̦̫{̷̟̥̱̺ ̝̣͉̦̞̥<҉̙̣̣̰<̪̟̪̘͡:̖̖̼ ͈̘̥̮*̛͈̜̙ͅs͎̺a̦n̙͔̫͓͡d̯w̧̪͖͍͈i̝͈̗̬̣c̷̤͔̻h̹̟͚ ͕̘̗̜̕}̷̳
[18:31] <Chipaca> or something like that
[18:31]  * Chipaca is preparing dinner and might've gotten the zalgo wrong
[18:32] <ijohnson> perfect
[19:17] <zyga> jdstrand: hey, around?
[19:17] <zyga> jdstrand: https://bugs.launchpad.net/snapd/+bug/1842615 came up today, the fix is one liner policy change
[19:17] <mup> Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed <snapd:In Progress by zyga> <https://launchpad.net/bugs/1842615>
[19:17] <zyga> owner /run/user/*/mutter/Xauthority r,
[19:18] <zyga> I was meaning to add it but wanted to run it by you for a quick look
[19:19] <mup> PR snapcraft#2700 opened: schema: build-base support for the kernel type <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2700>
[20:21] <mup> PR snapd#7410 opened: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7410>
[20:23] <cachio> zyga, if you are there could tu please take a look to #7410
[20:23] <mup> PR #7410: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7410>
[20:23] <cachio> it is blocking all the tests on travis
[20:24] <zyga> done
[20:24] <cachio> zyga, thanks!!!
[21:52] <mup> PR snapcraft#2687 closed: colcon plugin: add ability to ignore packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2687>
[21:52] <mup> PR snapcraft#2694 closed: multipass: fix setup exception when multipass is not found in PATH  <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2694>
[21:55] <mup> PR snapcraft#2698 closed: dirs: check for existence of required data directories <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2698>
[22:05]  * Chipaca hugs cachio