[04:32] amurray: out of interest, was there some project in particular you wanted debug symbols for? [04:33] 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] we definitely want debug symbols for the snaps seeded on the desktop [04:39] but there's not much to be done when they want a full design for snapcraft+store+snapd before considering any changes [04:52] 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] 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] jamesh: i hear you [04:56] 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] PR snapcraft#2229: elf: extract build ID and presence of debug info [05:13] morning [05:13] wow, +11C outside :/ [05:39] Good morning [05:40] Wow, I have a few more so not that drastic yet [05:40] Brrrrrr [05:43] zyga: hey [05:48] Doing school walk, be in the office soon [06:03] 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] FYI https://pastebin.ubuntu.com/p/bSjqrJDhtf/ [06:05] I tried to search for LP bug reports at one point but it didn't sound they'd be broken for everyone [06:05] Ubuntu defaults to X.org still so that makes it a bit different of course [06:06] Mirv: is Xwayland listening on the abstract namespace socket? [06:07] 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] i.e. @/tmp/.X11-unix/X0 in addition to /tmp/.X11-unix/X0 [06:07] I think you can check with ss. Let me work out the invocation [06:08] "ss -xl | grep X11" might be the best way to check [06:09] I see two listening sockets locally [06:09] zyga: ^^ opensuse & wayland [06:10] there's @ too: https://pastebin.ubuntu.com/p/QVKJpjP26R/ [06:11] I'm not sure then. The non-abstract socket is definitely blocked by snap confinement though [06:11] ok, let's wait for zyga then. I'm in no hurry, just starting my work day, happy to help debugging. [06:23] back in the office now [06:24] aha, I see the chatter about wayland and suse [06:24] I _guess_ I'm running tumbleweed under X11, let me recheck [06:26] logged back under wayland [06:27] it fails on [06:28] (and now no copy-paste, fun) [06:28] on /run/user/1000/mutter/Xauthority [06:28] I recall seeing this in a PR recently [06:28] hold on [06:31] Mirv: confirmed, adding an extra rule for that makes it work [06:31] Mirv: is there a bug report? I'll handle the rest [06:43] * zyga needs to work on reviews today [06:44] good morning mvo [06:44] hey zyga [06:44] zyga: good morning! I also need to do reviews [06:45] mvo: hey [06:46] hey mborzecki [06:48] morning! question about the content interface, is it possible to share only a file, or it must be a full folder? [06:48] abeato: currently it must be a file but I have a patch to share single files stashed [06:49] er [06:49] must be a directory [06:49] :D [06:49] 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] shocket [06:50] sockets are more tricky [06:50] not sure it'd work for sockets [06:50] I have not tried [06:51] hm, right, well, but in the end it is a file, right? mount bind should work too? [06:51] ish, [06:52] sockets have a tricky apparmor side [06:52] anyway, it's a matter of checking [06:52] right [06:59] PR snapd#7403 opened: cmd: use libtool for the internal library === pstolowski|afk is now known as pstolowski [07:02] morning [07:02] zyga: there was not, I now filed bug #1842615 [07:02] Bug #1842615 opened: Wayland apps not starting under openSUSE Tumbleweed [07:03] Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed [07:03] pstolowski: hey [07:04] zyga: awesome :) meanwhile I checked the problem does not affect openSUSE Leap 15.0, so just Tumbleweed [07:04] zyga: can you take a look at https://github.com/snapcore/snapd/pull/7387 ? [07:04] PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM [07:17] Mirv: thank you [07:17] mborzecki: yeah but I'll start with older PRs first [07:17] or I'll starve them again :) [07:19] 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] ackk: that's interesting, can you mkdir /root/snap/maas/x1 yourself? [07:20] ackk: or will you get a EROFS error? [07:20] Mirv: I've updated the bug report and I'll be sending a PR to fix it later today [07:20] zyga, the dir already exists [07:20] ackk: is it a mount point? [07:20] ackk: can you write through it? [07:21] $ sudo ls -ld /root/snap/maas/x1 [07:21] drwxr-xr-x 1 root root 12 Sep 4 06:59 /root/snap/maas/x1 [07:21] Bug #1842615 changed: Wayland apps not starting under openSUSE Tumbleweed [07:21] zyga, yeah I can write it as root [07:21] I mean, write a file in it [07:21] it's not a mountpoint [07:21] let me look again [07:21] that's odd [07:22] ackk: can you please try this: [07:23] sudo strace -o /tmp/strace.log SNAP_INSTANCE_NAME=maas [07:23] /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true [07:24] not sure if free of typos [07:24] but give it a try [07:24] I'd like to see strace run of snap-confine [07:24] to see what was the error it failed on [07:25] zyga, that's all a single command right? [07:25] correct [07:25] strace: Can't stat 'SNAP_INSTANCE_NAME=maas': No such file or directory [07:25] that can't go there, it seems [07:26] I guess before the strace? [07:26] sorry, my bad [07:26] yes [07:26] :) [07:26] $ 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] strace: exec: Permission denied [07:26] thank you zy_ga! [07:27] zyga, ^ [07:27] ackk: _hmm_ [07:27] did I get strace wrong somehow [07:28] ackk: and it didn't leave any log, did it? [07:29] zyga, just http://paste.ubuntu.com/p/5VW47nhgv9/ [07:29] why would it do that? [07:29] is that under lxd? [07:29] perhaps thats why :/ [07:30] can you check on your host, if you got a denial in dmesg? [07:30] hello [07:30] ackk: one more idea [07:31] I get this error: error: cannot add authorization: open /users/jonm/.snap/auth.json: permission denied [07:31] when my $HOME is on NFS [07:31] ackk: can you install an older snapd and check if this happens? [07:31] Jonno_FTW: hey, can you tell us the command you ran? [07:31] Jonno_FTW: and snap version, please [07:31] zyga, like, stable? [07:32] yes [07:32] sudo snap install redis-desktop-manager, snap version 2.39.2-1.fc30 [07:32] 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] aha, fedora [07:32] yep [07:32] mborzecki: ^ can you render ideas on how to check denials for selinux + nfs? [07:33] mvo I will, once I test them :) [07:33] I'm just flashing test image [07:33] zyga: ackk: snap run --strace='--raw -o foo.log' maas if you can hit ^C in time [07:33] mborzecki: that likely wont help if lxd is in control on top and denies it already [07:33] mborzecki: I meant the case above from Jonno_FTW [07:34] Jonno_FTW: can you try ausearch -m AVC and look for anything with recent time stamp [07:34] mvo it is booting, so image prepare is working, I just want to run few core refresh tests [07:34] mvo I already tested snapd snap update and that worked as well [07:35] mborzecki: there's nothing recent [07:35] certainly nothing from around the time I started using snap (like 30m ago) [07:37] zyga, I can't switch to stable snapd as maas uses the system-usernames [07:38] ackk: well, just for a test, it doesn't really have to work all the way [07:38] just to see if this is something in 2.41 [07:38] Jonno_FTW: for the record, the error when you do snap login right? [07:38] s/error when/error pops up when/ [07:38] zyga, mborzecki https://paste.ubuntu.com/p/D7Ddt4rZ6X/ [07:39] zyga, well it doesn't work at all as I get https://paste.ubuntu.com/p/rJ4pWKvQkC/ from snapd [07:39] what's /snap/snap/bin/maas/current?! [07:39] ackk: try without /snap/bin/maas, just maas [07:39] I think that's snap run getting confused [07:39] zyga, that's the first try there [07:40] right, I just mean that /snap/snap is clearly wrong [07:41] $ snap run --strace='--raw -o foo.log' maas upgrade [07:41] /usr/bin/strace: exec: Permission denied [07:41] error: exit status 1 [07:41] ackk: on lxd host, can you run dmesg | grep DENIED [07:41] I'm sure it's lxd [07:45] zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/ [07:45] ackk: that's excellent [07:45] so that is confirmed [07:45] ackk: to move forward we should figure out how to switch lxd's own profile on your host into permissive mode [07:46] then we can debug forther [07:46] *further [07:46] ackk: do you think we can postpone until lxd developers are online? [07:46] zyga, sure [07:46] zyga, I don't have a real xenial host to test with unfortunately [07:47] ackk: that's fine [07:49] 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] but it might only happen in "try" mode, IDK [07:49] the code where it fails should fail regardless of try mode [07:49] I'd like to get to the bottom of this later today [07:49] 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] (install from a snap and not from "try') [07:50] zyga: pff the libtool patch fails on this https://paste.ubuntu.com/p/mGVnXnF5j6/ :/ [07:50] ackk: nobody on our team can fix that [07:50] zyga, is it a kernel or lxd thing? [07:50] ackk: please escalate that to get help [07:50] ackk: perhaps both [07:50] it's a fuse filesystem [07:50] maybe the bottleneck is kernel side [07:51] maybe userspace [07:51] zyga, you're saying it's a bug in squashfuse? [07:51] I don't think any of us really read that code [07:51] ackk: it's certainly not a bug in snapd, we just mount a filesystem [07:51] mborzecki: yeah I ran into that a number of times [07:51] mborzecki: load of garbage :/ [08:00] duh, obviously there's no way to have misspell skip files :/ [08:01] mborzecki: sed it [08:18] PR snapd#7398 closed: boot, etc: simplify BootParticipant (etc) usage [08:19] mvo: I think we should all review from oldest to youngest [08:19] it seems that the last two pages are like attic [08:24] brb, tea [08:27] zyga: added a workaround to #7403, other than that, all tests passed [08:27] PR #7403: cmd: use libtool for the internal library [08:30] a review for 7125 would be great, small, self-contained and open since jul [08:31] mvo: looking [08:45] back with tea [09:09] 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] 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] fun with nvidia :-/ [09:11] Chipaca: no worries [09:11] Chipaca: drivers? [09:11] Chipaca: and good luck with X, I kinda given up on nvidia for this reason :( [09:11] mvo: my ubuntu experience with 1030 was very good FWIW [09:12] mvo: not so much with 2080, LTS doesn't have the drivers for it yet, [09:13] zyga: to be fair my experience is ~1-2y old so I may be totally off [09:14] mvo: I think it depends on how recent the OS is, there have been some great strides lately [09:14] 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] 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] 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] i'd forgotten how bad the quality of ppa debs was [09:15] Chipaca: does your system work with 19.10? [09:15] Chipaca: it's a good idea to just try that from a spare partition if it does [09:15] zyga: I'm still waiting for confirmation it works with 18.04 :-/ [09:15] Chipaca: weekend evening project to check? :-) [09:16] nu uh [09:16] zyga: i've got way more fun weekend projects than updating a machine that works :-) [09:16] that's fair :-) [09:16] Chipaca: I played one game recently, control, strongly recommend it if you have the 3 evenings to finish it [09:17] anyway, back to reviews :) [09:18] PR snapd#7396 closed: tests: don't guess in is_classic_confinement_supported [09:18] zyga: w8, 3 evenings? is that how long the game is? [09:19] mborzecki: I think I played 6 hours each time [09:19] well into past 3AM :D [09:19] mborzecki: I just finished the main plot, there's more to do but that's enough for me [09:20] mborzecki: or I'm just pretty good at aiming [09:20] ;-) [09:20] hahaha [09:20] mad quake skillz? :) [09:20] mouse sensitivity set to maximum, field of view 120, those things ;) [09:21] just kidding though [09:21] the game is story driven [09:21] the combat is challenging but doesn't feel like grind [09:21] and unlike most shooters I can remember, it is very rewarding to use the very first revolver you get all the game [09:21] anyway [09:22] something for evening :) [09:23] zyga: fwiw, double barrel works in through all of doom too :P [09:24] 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] 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] Saviq: yes, it's expected; stop all services / apps before restore, start them after [09:27] kk [09:27] Saviq: that is, if you need to [09:27] Saviq: you don't always need to -- same as you don't always need to stop for a 'save' [09:28] Chipaca: yeah, which is why it feels like there should be hooks for this :) [09:29] Saviq: would a hook be able to know whether an app in the snap is running? [09:29] (in general the answer is 'no') [09:30] Chipaca: an app, no, but a service, yeah [09:30] (zyga's work wrt deferring refreshes while apps are running might let us fix that) [09:31] 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] pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7387 ? [09:33] PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM [09:34] mborzecki: sure [09:34] thanks! [10:03] jamesh: I finally reviewed https://github.com/snapcore/snapd/pull/6767#pullrequestreview-283483314 [10:03] PR #6767: wrappers: allow snaps to install icon theme icons [10:03] zyga: thanks. Looking [10:04] jamesh: I think my only comment that would warrant blocking are related to validation [10:04] jamesh: on non-compliant files in meta/gui/icons [10:04] jamesh: as well as on file sizes in that place [10:04] jamesh: everything else is something that is good for followup [10:05] jamesh: I'm moving on to the next review, please ping me with your opinion [10:05] jamesh: as I said, you have +2 and you can merge as is [10:05] jamesh: but I'm worried about opening a hole [10:05] zyga: FWIW we already don't do that sort of validation on icons [10:05] zyga: so it's independent from that work [10:05] Chipaca: yes but now we read them into memory [10:05] Chipaca: in this PR [10:05] we do? [10:05] where? [10:05] ReadFile [10:06] why do we ReadFile them? [10:06] * Chipaca goes to look [10:06] because Ensure* does that internally [10:06] but I made a proposal in one of my comments [10:06] https://github.com/snapcore/snapd/pull/6767/files#diff-1a7d1cbe7825f23c89fbefcac29f347aR82 [10:06] here [10:06] perhaps one way to solve this [10:06] PR #6767: wrappers: allow snaps to install icon theme icons [10:06] is to extend ensure [10:06] to give it a handle that knows what the content is [10:06] and the size [10:06] so they can be stream like [10:06] oh ! gpio-control ? who breeded that ? (thats beautiful ! ) [10:07] that's a good idea separately but I would not like to just let this silently merge without pointing it out [10:07] ogra: thank ondra [10:07] * ogra thanks ondra [10:07] I'll keep doing reviews to unblock people, I said my thing [10:07] ondra, beer for you in barcelona ! [10:11] pedronis: should I review https://github.com/snapcore/snapd/pull/6705 ? [10:11] PR #6705: bootloader: little kernel support [10:19] zyga: I'm looking at it right now, going a bit slowly [10:19] also lunch [10:19] ok, I'll pick up the next one [10:22] mvo: hey, is https://github.com/snapcore/snapd/pull/6839 something that's ready for review? [10:22] PR #6839: devicestate: allow remodel to different kernels [10:24] jamesh: this needs some comment feedback https://github.com/snapcore/snapd/pull/7073 [10:25] PR #7073: interfaces: OpenGL/Vulkan drivers provided by a base should be usable <⛔ Blocked> [10:26] 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] jamesh: indeed, can you please comment on it so that it's clear where we stand? [10:26] on the assumption that non bootable bases should only contain files that are intended for use by apps [10:27] yeah, I recall the conversation about that in Toronto [10:28] PR snapd#7404 opened: cmd/snap: don't append / to snap name just because a dir exists [10:29] zyga: #7159 is an easy one [10:30] PR #7159: tests: add functions to make an abstraction for the snaps [10:30] looking quickly [10:32] 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] PR #7005: debug: state-inspect debugging utility [10:50] pstolowski: it might be easier to land it and I play with it a bit once is in edge [10:50] pedronis: ok, ty [11:04] 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] from the state and setting initial focus is helpful [11:06] jamesh: hey, question about https://github.com/snapcore/snapd/pull/7129#pullrequestreview-283531582 [11:06] PR #7129: userd: allow setting default-url-scheme-handler [11:06] I know it's not your PR but do you know why we need to add a "get set sub-property API"? [11:06] hm, tests are very red, shall we disable 19.10 for now? [11:06] mvo: what is failing if I may ask? [11:07] zyga: let me look again but pretty much everything is red [11:07] like all tests are failing? [11:08] I mean, there must be something that actually fails :) [11:09] 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] do you remember if a specific test was at fault? [11:10] zyga: iirc desktop-portal but let me look again [11:10] that fails uniformly though [11:10] it fails on me every day, or close [11:10] * mvo nods [11:10] I'd be happier if we can disable the test instead [11:11] and look at it really hard until we really understand why [11:11] https://travis-ci.org/snapcore/snapd/pull_requests <- looks sad [11:16] 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] PR snapd#7405 opened: tests: disable interfaces-timeserver-control on 19.10 [11:23] 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] 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] (unlike say erlang) [11:25] without eliminating types and then doing dynamic type checks [11:28] jwheare: hey, thank you for explaining that. [11:29] I will look at this with new information after lunch [11:34] 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] degville: great, ty! ok if if i just edit it there (new paragraphs/subsections) and you take a look afterwards? [11:35] pstolowski: yep - sounds good! [11:36] ok [11:36] ogra always ready for beer :P [11:38] mvo sorry I was at dentist, back now and doing more testing [11:38] mvo so far looks good [11:38] mvo I will push changes from lk-next to PR branch [11:38] ondra: sounds great, thank you [11:39] 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] mvo one option is to have it in bootloader/lkenv/snappy-boot.h [11:40] hmm, is it always the same two 19.10 tests that are failing? [11:40] mvo do you have any better idea where to host it? [11:42] mvo OK there is problem with seeding with my test snap [11:43] mvo I will debug, but it could be kernel seeding, when it tries to install bootimg [11:44] a pox on google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control [11:55] mvo interesting is that it seems to panic when applying core18 security profiles though [11:57] 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] mvo ignore me, i think it's kernel seeding, it just happens right after core [12:23] 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]