[01:01] <kenvandine> hey hellsworth
[01:35] <hellsworth> hey sorry for the ping. it was an accident :)
[04:52] <zyga> Good morning
[06:01] <Aavar> Good morning :)
[06:12]  * zyga resumes work
[06:21] <zyga> it rains heavily today
[06:45] <zyga> pstolowski|afk: https://github.com/zyga/snapd-peer-demo <- something I made at the sprint, suggestions welcome
[06:46]  * zyga breaks for breakfast
[07:12] <pstolowski> morning
[07:12] <zyga> hey Pawel
[07:39] <pstolowski> zyga: the peer demo looks nice, and serves as a useful example for practical use of interface hooks
[07:39] <zyga> pstolowski: yeah, I'll write a short blog post about it
[08:10] <pstolowski> zyga: btw, in that peer demo you could have interface hooks on the slot side too. i'd also consider renaming foo/bar to something more descriptive, e.g. provider/consumer
[08:13] <zyga> I used to have it symmetric but I abandoned that idea
[08:13] <zyga> yeah, the names are terrible :D
[08:13] <zyga> in practice that will be juju and microk8s
[08:13] <zyga> or the other way around
[08:13] <zyga> one can then take advantage of the other
[08:13] <zyga> by reusing cached images
[08:13] <zyga> or some other content that is big and costly to download
[08:14] <zyga> I worked on this with Ian from the Juju team
[08:14] <zyga> Ian Booth
[08:15] <pstolowski> zyga: i see; you could have just placeholders for the slot hooks, so that it's visibile they are there and could do something.
[08:39] <pstolowski> ogra: ping
[08:57] <jamesh> zyga: when you've got time, could you give https://github.com/snapcore/snapd/pull/7042 another look over? I think the main blocker was your concerns over the number of mounts
[08:57] <mup> PR #7042: interfaces: add an interface granting access to AppStream metadata <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7042>
[08:57] <zyga> jamesh: looking
[08:57] <zyga> ah, I remember that
[09:01] <zyga> jamesh: +1, let me look at spread
[09:01] <zyga> jamesh: I commented in the thread with you and jamie
[09:04] <jamesh> IIRC, the spread failure was unrelated to my code changes.  I didn't get round to asking someone to restart that job
[09:06] <Aavar> zyga, kenvandine: Regarding my problem with graphical snaps. I did try a few things yesterday and discovered something that might or might not be related.
[09:06] <zyga> oh, what did you discover?
[09:06] <zyga> jamesh: restarted
[09:07] <Aavar> I added a new user and that users home-directory (and everything in it) was owned by my original user.
[09:07] <Aavar> zyga, after chowning the files the snaps where still not working.
[09:08] <Aavar> I allso tried to stop lightdm and start from startx, but still the same.
[09:09] <Aavar> zyga, I don't know if that tells you anything else than that my system if fucked :P
[09:09] <zyga> I'm still totally puzzled by what may be wrong on your system
[09:09] <zyga> can you do one more experiment
[09:09] <zyga> add a new user that is independent from your current user
[09:09] <zyga> and see if that works
[09:09] <jamesh> zyga: I wrote up a proposal for another problem we've run into on the desktop team here: https://forum.snapcraft.io/t/proposal-allow-snaps-to-specify-their-exact-desktop-file-id/12689
[09:09] <Aavar> zyga, that is what I did :)
[09:10] <zyga> Aavar: but not owned by your user
[09:10] <zyga> that's really the same exact user
[09:10] <zyga> (same uid)
[09:10] <zyga> nothing else matters in snapd world
[09:10] <jamesh> zyga: I'm still working on session agent/user daemons/dbus activation right now, but it would be useful to get some feedback on the proposal at some point
[09:10] <zyga> jamesh: ah, I think we were expecting this
[09:10] <zyga> jamesh: I'll have a read but I think you need to discuss with samuele next week
[09:10] <zyga> jamesh: I'm working on a fix for device cgroup and mount namespace (as always)
[09:11] <zyga> jamesh: I think the proposal is sensible, we just need a way to control it properly
[09:11] <jamesh> zyga: we finally found a use case where this is a blocker rather than just inconvenient :-)
[09:11] <Aavar> zyga, I'm sorry. I don't thing you understood. I did create a new user named "control" (via the gui in ubuntu) and the system added /home/control but it was owned by "aavar:aavar". I have no idea why...
[09:11] <Aavar> I can try to add another user via the terminal.
[09:12] <zyga> oooh
[09:12] <zyga> I see
[09:12] <zyga> I misunderstood you
[09:12] <zyga> wow that's really weird
[09:13] <zyga> hmm
[09:13] <Aavar> zyga, I added a new user now via terminal and that did not happen.
[09:13] <Aavar> Let me log back in
[09:13] <zyga> jamesh: ^ Aavar is debugging an issue where none of the graphical snaps can start
[09:13] <zyga> cannot talk to x
[09:13] <zyga> we are kind of lost, perhaps you have some ideas
[09:14] <zyga> jamesh: what should snapd do for parallel installs in the new desktop proposal?
[09:14] <jamesh> zyga: I wonder if this is abstract namespace X socket vs. /tmp/.X11-unix X socket?
[09:14] <zyga> jamesh: the denial has addr=null
[09:14] <zyga> Aavar: ^ am I correct? (dmesg | grep DENIED)
[09:15] <zyga> at the same time DISPLAY is set correctly
[09:15] <zyga> Aavar: what is your desktop shell? gnome shell?
[09:15] <jamesh> zyga: parallel installs would not be supported by my proposal.  But in the notification case, the app would need to own a bus name matching the desktop file ID.
[09:15] <jamesh> and that is also not parallel install friendly
[09:15] <zyga> I agree
[09:16] <zyga> I think we should be able to say "this snap does not support parallel installs"
[09:16] <zyga> I think it's a topic for next week when the architect is back
[09:16] <zyga> maciej is also away this week, attending Flock
[09:17] <jamesh> Fair enough: I just want to make sure it is on the radar.  I've got other work to complete in the mean time
[09:18] <zyga> ack
[09:19] <Aavar> zyga: still the same result with a new user. I guess I have to wait for kenvandine :)
[09:19] <zyga> Aavar: ^ are you on gnome-shell?
[09:20] <Aavar> zyga: now i'm on unity, but I tried with gnome-shell (bot wayland and X11)
[09:21] <zyga> hmmm
[09:22] <Aavar> zyga: i'm sorry. I am not familiar with gnome. Is gnome-shell the same as gnome3?
[09:22] <zyga> yeah
[09:22] <zyga> I really don't know what is affecting your system
[09:22] <zyga> if you were anywhere close I'd love to have a look and inspect it myself
[09:22] <zyga> but I guess that is hard
[09:23] <Aavar> zyga: yeah :)
[09:24] <Aavar> I think, if kenvandine or someone dont find anything useful in the next few days I will reinstall.
[09:35] <jamesh> Aavar: one last thing to help with debugging: could you provide a paste of the output of "ss -lxp | grep X11"
[09:37] <Aavar> jamesh: brb, lunch :)
[10:06] <Aavar> jamesh: p/qZ6hVy2YXF/
[10:07] <Aavar> hmm..
[10:07] <Aavar> jamesh: https://paste.ubuntu.com/p/qZ6hVy2YXF/
[10:16] <jamesh> Aavar: okay.  That basically disproves my theory from earlier about the abstract socket not being available
[10:16] <jamesh> zyga: looks like your restart cleared the test failure for https://github.com/snapcore/snapd/pull/7042.  Thanks
[10:16] <mup> PR #7042: interfaces: add an interface granting access to AppStream metadata <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7042>
[10:17] <jamesh> is there anything else needed before merging it?
[10:18] <Aavar> jamesh, so that shows that the socket is open?
[10:19] <zyga> jamesh: let me look but I think that's good now
[10:19] <jamesh> Aavar: the command lists listening unix domain sockets.  The /tmp/.X11-unix/X0 socket is one you can see in the file system, while the @/tmp/.X11-unix/X0 socket is an "abstract namespace socket"
[10:19] <zyga> jamesh: it's in
[10:20] <jamesh> Aavar: an unconfined app can connect to either, while a snap app is blocked from connecting to the first.
[10:20] <mup> PR snapd#7042 closed: interfaces: add an interface granting access to AppStream metadata <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7042>
[10:20] <jamesh> zyga: thanks!
[10:20] <jamesh> Aavar: if the abstract namespace socket was missing for some reason, that would explain your problems
[10:22] <Aavar> btw, jamesh, zyga: When I log in via console or ssh (not x) it gives me an error: xhost:  unable to open display ""
[10:22] <Aavar> Isn't that also weird?
[10:23] <jamesh> Aavar: that is normal if the DISPLAY environment variable isn't set
[10:24] <Aavar> jamesh: ok :)
[10:24] <zyga> Aavar: yeah, that is to be expected
[10:26] <zyga> brb
[10:28] <zyga> Actually. A longer break is needed
[10:56]  * pstolowski lunch
 not sure if this is the right place but here goes   xubuntu 18.04 when i remove a snap as soon as it finishes my desktop goes black and then the login screen comes up     any1 have a solution for this
[11:28] <jonzen> sorry  didnt identify
[11:30] <jonzen> more info   sony laptop  i7 quad 4gb
[11:47] <zyga> jonzen: hey
[11:48] <jonzen> yessir
[11:48] <zyga> jonzen: can you please tell us what kind of GPU are you using?
[11:48] <zyga> jamesh: is your system using wayland?
[11:48] <zyga> jonzen: ^
[11:48] <zyga> kenvandine: ^ looks like desktop session crashes on udev trigger/settle
[11:48] <jonzen> nvidia
[11:48] <jonzen> how do i find out about wayland
[11:49] <zyga> jonzen: open a terminal and run: echo $XDG_SESSION_TYPE
[11:49] <jonzen> x11
[11:51] <zyga> can you pastebin your journal log? you can do that with journalctl | pastebinit # you may need to install pastebinit first
[11:51] <jonzen> ok  gimme a min  i will do
[11:52] <zyga> thank you
[11:52] <jonzen> http://paste.ubuntu.com/p/JVQ6dsSJyV/  your very welcome
[12:00] <zyga> Aug 08 06:23:28 pd-VPCF133FX xfce4-notifyd[23765]: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
[12:02] <zyga> hmm, I'm not an expert on X stuff, can you please report a bug on snapd
[12:03] <zyga> you can do that on bugs.launchpad.net/snapd
[12:03] <zyga> make sure to include your system version and other relevant stuff; you may be able to report the bug with apport
[12:03] <zyga> which may provide more relevant information
[12:03] <zyga> I understand that it is somehow snapd that is causing this but it seems X has crashed
[12:03] <jonzen> should i put this pastebin in?
[12:03] <zyga> or perhaps not X
[12:03] <zyga> but the session in xfce
[12:04] <zyga> yes, as an attachment
[12:04] <jonzen> ok  will do   ty very much for your help
[12:07]  * zyga goes for a walk
[12:13] <jonzen> zyga  ty again   i did as you asked
[12:17] <mup> PR snapd#7200 closed: recovery: update to latest fde-utils <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7200>
[12:25] <mup> PR snapd#7222 opened: tests: show just the last log as part of the debug output when check journal logs <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7222>
[12:40] <mup> PR core-build#51 opened: Use /var/lib/snapd/seed/snaps/ as fallback when mounting core and kernel <Created by stolowski> <https://github.com/snapcore/core-build/pull/51>
[13:01] <ogra> pstolowski, you pung ? (sorry. at a sprint this week)
[13:01] <pstolowski> ogra: hey, ah i didn't realize you're at the sprint; i'min the standup atm, will you have a moment for a HO later today?
[13:02] <ogra> pstolowski, hmm, we have a training, might be late for you when i have a free spot
[13:03] <ogra> (and i actually have to go to class now ... perhaps drop an email with a quick summary)
[13:03] <pstolowski> ogra: i'll open a forum topic, perhaps you can reply there and help, ty
[13:46] <ijohnson> hey jdstrand, zyga when y'all get a chance could you re-review https://github.com/snapcore/snapd/pull/7010 ? it is pretty straight forward I think and the tests are finally all green :-)
[13:46] <mup> PR #7010: interfaces/docker-support: add controls-device-cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7010>
[13:46] <jdstrand> ijohnson: hey, yes
[13:46] <ijohnson> thanks jdstrand
[13:51] <zyga> I’m off for lunch now
[14:19] <zyga> ijohnson: I’ll review when I am back but it feels like +1
[14:19] <ijohnson> ack, thanks zyga
[14:40] <ijohnson> hey cachio, I'm unable to reproduce this error in spread tests with qemu locally, any idea what might be different about the google spread machines than qemu?
[14:40] <ijohnson> see https://pastebin.canonical.com/p/zsQVWhP2CP/ and https://travis-ci.org/snapcore/snapd/jobs/569057960
[14:41] <ijohnson> it seems like some kind of path error where python3 thinks it should be reading from the core snap and not from the snap itself (and indeed those files it's trying to access exist in the snap and load fine on my system and in qemu 16.04)
[14:44] <cachio> ijohnson, checking
[14:45] <cachio> ijohnson, we use different images on qemu and gce
[14:46] <cachio> let me cehck which python we have
[14:46] <cachio> ijohnson, do you have a qemu instnace opened?
[14:46] <ijohnson> right, but inside the snap it sholdn't matter which version of python?
[14:47] <ijohnson> one second let me reboot it (I think it's off
[14:47] <ijohnson> could I boot the google image with qemu locally if I downloaded it?
[14:48] <cachio> ijohnson, I didn't try that
[14:48] <cachio> but should be possible
[14:49] <cachio> but not sure if you have the permissions to download the image
[14:49] <cachio> me neither
[14:49] <ijohnson> ah okay
[14:49] <cachio> it is using /usr/lib/python3.6/lib-dynload/termios.cpython-36m-x86_64-linux-gnu.s
[14:49] <ijohnson> still it's very odd that in one image a strictly confined snap tries to load python libs from the core snap, and that in another image it's loading python libs from the application snap
[14:49] <cjp256> who would be the chrome sandbox goto expert here? :)  I've got an electron 5 app I am trying to confine strict, but it gets cranky when I remove the chrome-sandbox binary and add --no-sandbox.  It runs fine in devmode, but otherwise fails with `audit: type=1400 audit(1565112543.140:3117): apparmor="DENIED" operation="open" profile="snap.<app>.<app>" name="/proc/8998/setgroups" pid=8998 comm="<app>" requested_mask="w"
[14:49] <cjp256> denied_mask="w" fsuid=1000 ouid=1000`  - i'm curious if anyone has ideas... it does look like the program bails after reading /proc/cpuinfo
[14:50] <cachio> ijohnson, is it install as classic snapd o devmode?
[14:50] <ijohnson> it's installed strict
[14:50] <ijohnson> cachio: see https://github.com/snapcore/snapd/pull/7214/files#diff-82c7f368687a491cb7edc7d848e2b57eR16
[14:50] <mup> PR #7214: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7214>
[14:51] <ijohnson> actually I should probably have you review that spread test anyways since I'm still new on the spread tests
[14:51] <ijohnson> alright I requested a review from you on that PR
[14:52] <ijohnson> cjp256: do you have browser-support interface connected with allow-sandbox: true
[14:52] <cachio> ijohnson, please check the python version which is being used on qemu
[14:52] <cachio> it is the main difference
[14:52] <ijohnson> cachio: almost done preparing the image, will check in a minute
[14:53] <ijohnson> cachio: it's python 3.5.2
[14:54] <cachio> ijohnson, could you try updating python
[14:54] <cachio> and see if this is hte problem?
[14:54] <ijohnson> the version of python3 in the snap though is python 3.6.8
[14:56] <ijohnson> cachio: I ran apt update && apt upgrade and still can't reproduce the problem
[14:57] <ijohnson> I guess the version of python didn't change from the upgrade though
[14:58] <cachio> ijohnson, lets try this
[14:59] <cachio> run the test on google but in the spread.yaml
[14:59] <cjp256> ijohnson: i was trying to do it without allow-sandbox, but if that's the required route, that'll have to do for now.  Mostly curious if anyone else has had problems without allow-sandbox and using --no-sandbox?
[14:59] <cachio> add the image
[14:59] <cachio> image: ubuntu-os-cloud/ubuntu-1604-lts
[14:59] <cachio> to the ubuntu-16.04-64 system
[14:59] <cachio> and run the test
[14:59] <cachio> this is a pristine image
[15:00] <cachio> which is more similar to qemu
[15:00] <ijohnson> cachio: I have to get into a meeting right now actually, but where should I add that? to the system spec under qemu in the spread.yaml?
[15:01] <cachio> ijohnson, in the spread.yaml in the google backend where you have all the systems
[15:01] <cachio> you should configure https://paste.ubuntu.com/p/yw3wVnBvFR/
[15:01] <ijohnson> ah and then launch the google system instead of qemu
[15:02] <cachio> and run the test on google system
[15:02] <ijohnson> ack, I'll let you know how it goes when I'm done with my meeting
[15:02] <cachio> ijohnson, so we can see if the problem is related either to google image or to the preparation of the suite
[15:02] <ijohnson> cjp256: AFAICT that access only is allowed with allow-sandbox: true unfortunately
[15:03] <cjp256> alright, thanks ijohnson :)
[15:26] <mup> PR snapcraft#2656 closed: appstream: xslt support for ul nested in p <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2656>
[15:27] <pstolowski> i've created a forum topic re firstboot & initrd: https://forum.snapcraft.io/t/firstboot-seeding-failure-scenario-possible-fixes-and-boot-process-confusion-question/12698
[15:29] <jdstrand> cjp256: you shouldn't remove the chrome-sandbox binary. just let it have 755 permissions and use --no-sandbox.
[15:29] <jdstrand> iirc
[15:29] <jdstrand> popey_ and Wimpress may have other tips
[15:30] <diddledan> wimpy's on his holidays right now, so only popey :-)
[15:33] <cjp256> jdstrand: I'll give that a shot, thanks!
[15:36]  * cachio lunch
[16:08] <mup> Bug #1839498 opened: xdgopenproxy: Outdated github.com/godbus/dbus dependency <Snappy:New> <https://launchpad.net/bugs/1839498>
[16:26] <zyga> re
[16:26] <zyga> pstolowski|afk: thank you for creating the topic
[16:26] <zyga> ijohnson: looking now, sorry, took family out for dinner
[16:27] <ijohnson> no worries zyga, thanks for the review
[16:38] <zyga> ijohnson: I sent one comment but I need to make coffee to review this properly
[16:39] <zyga> ijohnson: tomorrow I'd love to share my thoughts on the device cgroup topic
[16:39] <zyga> ijohnson: we can perhaps join before or stay after the call
[16:39] <ijohnson> oh actually what you commented on should be removed from the PR
[16:39] <ijohnson> I missed that in my cleanup to address jdstrand's comment
[16:39] <ijohnson> s
[16:39] <ijohnson> but yes we can discuss more about the device cgroup tomorrow after SU
[16:42] <zyga> right
[16:42] <zyga> it is unconditional now
[16:42] <ijohnson> so that message shouldn't have been there at all
[16:42] <zyga> indeed
[16:42]  * zyga checks the coffee pot
[16:44] <zyga> when away from home I use this portable thing that you can just put on the stove
[16:44] <ijohnson> nice
[16:47] <ijohnson> I also have to step away for ~30 minutes
[17:32] <ijohnson> cachio: I was able to reproduce the issue on that clean google image you provided, however I then realized that the shebang was hard-coding /usr/bin/python3, when I launch netplan with $SNAP/usr/bin/python3 then the issue goes away
[17:32] <ijohnson> so I don't think it was an issue with the build env, it was an issue with my test snap rather
[17:32] <ijohnson> and how that was calling python
[17:33] <cachio> ijohnson, great, I am reviewing the test btw
[17:33] <ijohnson> thank you
[17:33] <cachio> ijohnson, mp
[17:33] <cachio> ijohnson, happy to help
[17:33]  * ijohnson lunches
[17:41] <mup> PR snapcraft#2657 closed: Release changelog for 3.7.2 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2657>
[18:28] <mup> PR core-build#50 closed: initramfs: run recover mode if trigger is detected <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/core-build/pull/50>
[18:31] <zyga> re
[18:55] <mup> PR snapd#7223 opened: recovery: update fde-utils <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7223>
[19:11]  * cachio afk
[20:27] <mup> PR snapd#7221 closed: tests: split the sbuild test in 2 depending on the type of build <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7221>
[20:37] <cjp256> I'm having a little trouble with multipass on Windows - anyone have any pointers? couldn't find much useful in the event logs... :) https://www.irccloud.com/pastebin/qHKIdUdC/
[20:38] <cjp256> probably more appropriate for #multipass I imagine
[20:46] <ijohnson> cachio: thanks for the review on the PR, I addressed your points, can you re-review when you get a chance?