[03:53] <elopio> jamespage: I was going to tell you that vault is on snapcrafters with some fancy (or hacky) stepped upgrade. But I see you have the latest commit there. Let me know if I can help.
[04:10] <pbek_> thank you for the link, popey
[04:11] <pbek_> I didn't make the mental connection from the issue page to the acutal page to edit the documentation sheet ;)
[04:17] <mup> PR snapcraft#1909 closed: dotnet plugin: add dotnet command to path and enable developer scenario for  snap <enhancement> <Created by rakeshsinghranchi> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1909>
[04:18] <pbek> popey: I created a pull request at https://github.com/canonical-docs/snappy-docs/pull/390
[04:18] <mup> PR canonical-docs/snappy-docs#390: added documentation for version-script <Created by pbek> <https://github.com/canonical-docs/snappy-docs/pull/390>
[05:04] <mborzecki> morning
[05:06] <zyga> good morning :)
[05:10] <mborzecki> wanted to try opensuse TW with snapd and nvidia last night, dd'ed gnome live image to usb stick, ran it, zypper dup'ed, installed snapd & NVIDIA (nvidia now maintains a repo with the packages!!) and got a hard lock up, most probably nvidia related :/
[05:19] <zyga> uh, not fun
[05:21] <mborzecki> my guess it's gdm trying to do wayland
[05:22] <mborzecki> it locked up in plymouth screen, just when the tw infinity sign stopped spinning
[05:47] <zyga> pedronis: updated https://github.com/snapcore/snapd/pull/5067
[05:47] <mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[05:49] <jamespage> elopio: hi - popey sorted me out with pertinent access yesterday afternoon - I think I'm all set now aside from some minor confusion around how build.snapcraft.io permissions work
[06:25] <mborzecki> zyga: left you a comment
[06:27] <mborzecki> btw. somehow also managed to break polkit & gnome-shell agent
[06:28] <mborzecki> wow, cannot remove the snap either
[06:41] <zyga> mborzecki: Ack, looking
[06:41] <zyga> Fin
[06:41] <zyga> Fun
[06:41] <zyga> Looks like another fix on top
[06:44] <mborzecki>  if anyone wants to give it a try, https://github.com/snapcore/snapd/pull/5034 is simple and easy review
[06:44] <mup> PR #5034: userd: set up journal logging streams for autostarted apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
[06:56] <mvo> zyga: I pushed a core18 PR, it does now show up in mup yet apparently
[06:56] <mvo> niemeyer: could you please add github.com/snapcore/core18 to the mup announcements?
[06:58] <zyga> ack, looking
[07:01] <zyga> mvo: are you sure about the security-policy-stamp?
[07:01] <mvo> zyga: I can look again
[07:01] <zyga> I mean, I assume you looked
[07:01] <mvo> zyga: the description is definitely wrong
[07:01] <mvo> zyga: we don't have snappy policygen
[07:03] <mvo> zyga: grep -r securtiy-policy-version over the entire image has no hit
[07:03] <zyga> yeah, I'm doing the same thing
[07:03] <zyga> that's a good indication that it is dead
[07:04] <zyga> yeah, looks like 15.04 leftover
[07:04]  * mvo ods
[07:05] <zyga> mvo: about the writable paths
[07:05] <mvo> zyga: I will poke at it a bit to see if I can remove more but iirc that wasn't working last time
[07:05] <mvo> zyga: sure
[07:05] <zyga> how did you pick the things to remove?
[07:05] <zyga> and are we going to have tests after this PR?
[07:05] <mvo> zyga: starring at it hard enough
[07:05] <mvo> zyga: right, tests
[07:05] <mvo> zyga: man, you ask a lot!
[07:05] <mvo> ;)
[07:05]  * mvo hugs zyga 
[07:06] <zyga> I'm sorry for asking the hard questions :)
[07:06] <pstolowski> morning
[07:06] <mvo> zyga: so the short term goal is just to get a base out that is stable enough, i.e. we don't remove packages from it
[07:06] <mborzecki> pstolowski, mvo: morning guys
[07:06] <mvo> zyga: so ideally a test would ensure that, i.e. we don't break ABI
[07:07] <mvo> hey mborzecki and pstolowski ! good morning
[07:07] <zyga> mvo: sent my full review
[07:07] <mvo> zyga: thank you
[07:07] <zyga> sorry for being hard on that one
[07:08] <mvo> zyga: we could simply remove the entire writable-path in the first go?
[07:08] <zyga> ah, perhaps
[07:08] <mvo> zyga: I mean for the purpose of what we need to archive its irrelevant until we boot from core18
[07:08] <zyga> question: can we mark this as a non-bootable base?
[07:09] <mvo> zyga: it is right now :) we have no language to mark a base bootable yet
[07:09] <zyga> mvo: ok, let's just add a comment to snap.yaml
[07:09] <zyga> describing that given the lack of language we just say it is not bootable yet
[07:09] <zyga> then +1
[07:09] <mvo> zyga: cool, will do
[07:10] <mvo> zyga: I need to tweak it a little bit more it seems, travis failed with some odd error
[07:13] <zyga> the error look like the binaries have more recent libc requirement than what is in the image
[07:14] <zyga> mvo: perhaps as a sanity check run tests without your changes
[07:16] <zyga>  https://toggl.com/blog/startup-zoo-comic/
[07:16] <zyga> :D
[07:19] <kalikiana> good morning, snappy
[07:20] <zyga> hey ho
[07:29] <mborzecki> travis builds merge the PR branch to master right?
[07:29] <zyga> ...
[07:29] <zyga> I don't think so
[07:29] <mvo> mborzecki: I don't think it does, iirc it just uses whatever is in the PR
[07:29] <zyga> it tests whatever is pushed
[07:29] <zyga> there is an option to test the merged branch but we are not using it
[07:34] <mborzecki> appears we do merge origin/master before running tests, 'tested' empirically
[07:35] <mvo> interessting, I think this was different in the past
[07:35] <mborzecki> unit tests in #4844 were failing quite suspiciously
[07:35] <mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
[07:39] <mborzecki> zyga: BrokenSnapError? (we already show that snaps are 'broken')
[07:41] <zyga> I called it Corrupted for now but yeah, Broken looks good
[07:50] <pstolowski> zyga: i found my problem with layouts from yesterday; it was in the fact the i expected it to create extra directory levels before actual mountpoint (maybe it should? are the devs expected to know what existis in the fs?). once it bound /usr/lib/tclk to $SNAP/usr/lib/tclk, it didn't complain anymore
[07:51] <zyga> Interesting
[07:51] <zyga> I suspected that while biking
[07:51] <zyga> I never tested that case
[07:51] <zyga> thank you for finding it :)
[07:51] <pstolowski> yw :)
[07:52] <pstolowski> but i'm nowhere close to get my snap working... tcl/tk is tricky
[07:53] <pstolowski> zyga: nb, snapcraft will not allow snap with experimental features (passthrough for layout) in the store, it displays explicit warning
[07:53] <zyga> heh
[07:53] <zyga> why?
[07:53] <zyga> that's silly
[07:53] <zyga> it was not supposed to be that
[07:54] <pstolowski> The 'passthrough' property is being used to propagate experimental properties to snap.yaml that have not been validated. The snap cannot be released to the store.
[07:54] <pstolowski> that's what it says
[07:55] <zyga> yeah but that's not what we discussed
[07:56] <pstolowski> that's snapcraft from beta channel, so perhaps there is time to change it
[07:58] <mup> PR snapd#5072 opened: snap,overlord/snapstate: introduce and use BrokenSnapError <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
[07:58] <zyga> mborzecki: ^ built on top of the earlier one
[07:58] <mborzecki> ack
[07:58] <mborzecki> pstolowski: zyga: https://forum.snapcraft.io/t/support-for-passthrough-into-snap-yaml/4698
[07:59] <zyga> reading the first post reinforces my opinion
[08:00] <mborzecki> and the message was in the PR that's mentioned in the post
[08:00] <zyga> yeah but it should not prevent sending that to the store
[08:00] <zyga> the store should flag
[08:00] <zyga> but snapcraft should allow it
[08:01] <pstolowski> indeed, manual review in the store, that's what Jamie said
[08:02] <zyga> pedronis: 5072 is a follow up to 5067
[08:03] <pedronis> zyga: I don't think we can use a single error
[08:03] <pedronis> for exampel the check in doMountSnap is really about presence (mounted, not mounted)
[08:04] <mvo> zyga: I pushed a poor mans abi test for now
[08:04] <zyga> I read that
[08:04] <zyga> I wonder what `which cp` says
[08:04] <zyga> what's that cp that broke on us?
[08:04] <mvo> zyga: yeah, something strange in the PATH, when I use /bin/cp its fine
[08:06] <pstolowski> commented in the passthrough topic
[08:06] <mvo> zyga: I was wondering earlier if the tar got things messed up, i.e. unpacking to the wrong dir but it was not that
[08:07] <zyga> pedronis: is #5067 ready from your pop?
[08:07] <mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
[08:07] <zyga> pov?
[08:08] <pedronis> zyga: I don't think you addressed my comment about Path being optional
[08:09] <zyga> oh, I didn't notice that
[08:14] <zyga> done
[08:16] <pedronis> thx
[08:16] <pedronis> probably mvo should give it a 2nd quick look
[08:16] <pedronis> he reviewed an early version
[08:20] <mvo> pedronis: sure, this is 5067?
[08:20] <zyga> yes
[08:20] <pedronis> yes
[08:25] <mvo> zyga: commented
[08:25] <zyga> thanks, I'll add notes to both tests
[08:26] <mvo> ta
[08:26] <eraserpencil> after successfully running snapcraft and installing the resultant snap with --dangerous --devmode flags, I get this error saying Multiple packages found with the same name "xxx" in snap/parts, snap/prime, and snap/stage
[08:26] <mvo> zyga: I disabled the core18 writable-path stuff now as well, so we should be good in this area
[08:26] <eraserpencil> must i delete them to remove that error?
[08:27] <zyga> kalikiana: ^
[08:27] <mvo> zyga: if you could have a final look before the merge that would be appreciated, then I can go ahead and build a new core and talk to the desktop team about the details
[08:27] <Chipaca> eraserpencil: you get those errors after installing your snap?
[08:28] <eraserpencil> yes
[08:28] <Chipaca> eraserpencil: but those are snapcraft errors
[08:28] <zyga> mvo: done on the "snap try" PR
[08:28] <zyga> looking at core PR now
[08:29] <eraserpencil> sorry, im not following
[08:29] <Chipaca> eraserpencil: me neither
[08:30] <zyga> eraserpencil: can you show the command you ran
[08:30] <Chipaca> eraserpencil: your snap builds using snapcraft, yes?
[08:30] <zyga> eraserpencil: and the full error you saw
[08:30] <eraserpencil> yes
[08:30] <Chipaca> eraserpencil: was that yes to me or to zyga
[08:31] <eraserpencil> erm, it's a snap of a ROS package. The command I ran was to initialise ROS.
[08:33] <eraserpencil> here is the error: https://ghostbin.com/paste/dcdw7
[08:33] <zyga> mvo: commented
[08:34] <mborzecki> pedronis: pstolowski: updated #4844
[08:34] <mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
[08:37] <eraserpencil> sorry i was disconnected
[08:38] <zyga> eraserpencil: it looks like the snap is wrong
[08:38] <zyga> it contains build files from snapcraft
[08:38] <zyga> only the prime directory should be snapped
[08:38] <eraserpencil> what does that mean
[08:38] <zyga> not the whole thing
[08:38] <Chipaca> zyga: hold on
[08:38] <Chipaca> eraserpencil: could you run a command and show us its output please:
[08:38] <Chipaca> eraserpencil: which roscore
[08:38] <Chipaca> eraserpencil: ^ that's the command
[08:39] <eraserpencil> here: /opt/ros/kinetic/bin/roscore
[08:39] <Chipaca> eraserpencil: you're not running the snap
[08:40] <Chipaca> eraserpencil: could you run this other command: printf "%q\n" "$PYTHONPATH"
[08:40] <Chipaca> eraserpencil: (and show us its output)
[08:40] <eraserpencil> Yea, im not. I wanted to run roscore on it's on but snap is tripping it up.
[08:40] <pstolowski> mborzecki: thanks, looking
[08:41] <eraserpencil> here: /home/nvidia/mov/catkin_ws/devel/lib/python2.7/dist-packages:/opt/ros/kinetic/lib/python2.7/dist-packages
[08:42] <Chipaca> eraserpencil: ok, I don't know why ros is picking up libraries from under your current directory
[08:42] <Chipaca> eraserpencil: but, it's not the snap's fault, I figure
[08:42] <Chipaca> eraserpencil: run roscore from a different directory
[08:45] <eraserpencil> same thing
[08:46] <Chipaca> eraserpencil: show me please
[08:46] <eraserpencil> erm exact same error
[08:47] <Chipaca> ok, let me re-read this conversation because I'm getting lost
[08:48] <Chipaca> eraserpencil: how did you build the snap?
[08:49] <eraserpencil> https://ghostbin.com/paste/d7ox5
[08:50] <eraserpencil> the error shows that python tried to find packages but found multiple packages of the same name
[08:53] <Chipaca> eraserpencil: I saw it that way first, but it's not python, it's ros itself
[08:53] <Chipaca> eraserpencil: and it's not looking in the snap
[08:53] <eraserpencil> ahh, the python plugin for ROS has a script that searches recursively for packages.
[08:54] <Chipaca> eraserpencil: I think the most productive use of our time would be to wait for kyrofa to be online
[08:54] <eraserpencil> My snap is within the catkin workspace
[08:54] <eraserpencil> ok
[08:54] <Chipaca> eraserpencil: he's on -0700 so it'll be a while still
[08:55] <eraserpencil> which time line is that?
[08:55] <Chipaca> eraserpencil: PDT I think
[08:57] <eraserpencil> ok thanks
[08:58] <eraserpencil> btw im having trouble with both demos of  https://docs.snapcraft.io/build-snaps/python
[09:00] <Chipaca> eraserpencil: what sort of trouble?
[09:05] <eraserpencil> https://ghostbin.com/paste/teoza
[09:05] <eraserpencil> for the youtube-dl demo
[09:06] <Chipaca> let's see...
[09:10] <Chipaca> eraserpencil: I'm not sure what you're doing exactly, but I just made a directory, entered it, copied the youtube-dl snapcraft.yaml, and run snapcraft, and it's compiling libavcodec and stuff after successfully getting the source
[09:10] <Chipaca> eraserpencil: what version of snapcraft do you have?
[09:11] <eraserpencil> 2.4
[09:11] <Chipaca> eraserpencil: 2.4, or 2.40?
[09:11] <eraserpencil> 2.40
[09:11] <Chipaca> snapcraft just finished building youtube-dl
[09:11] <Chipaca> so, it works
[09:12] <Chipaca> eraserpencil: there's something nonstandard about your setup you're not telling us
[09:12] <eraserpencil> really wish i knew. I've tried it on different computers
[09:13] <Chipaca> eraserpencil: ok, walk me through what you do, step by step
[09:14] <Chipaca> eraserpencil: first, what distribution are you on?
[09:15] <eraserpencil> mkdir ~/snap
[09:15] <eraserpencil> cd ~/snap
[09:15] <eraserpencil> git clone git clone https://github.com/snapcraft-docs/youtube-dl
[09:15] <eraserpencil> cd youtube-dl
[09:15] <eraserpencil> snapcraft
[09:15] <eraserpencil> Ubuntu 16.04
[09:15] <popey> dont do mkdir ~/snap :)
[09:15] <popey> build your snaps somewhere else.
[09:16] <popey> it will get all very confusing once you install a snap and the ~/snap directory will then contain a youtube-dl directory which contains the runtime data for the app
[09:17] <Chipaca> good point (although I doubt that's the cause of the errors)
[09:17] <Chipaca> eraserpencil: repeating those steps here (also 16.04)
[09:18] <Chipaca> eraserpencil: I didn't get that error
[09:19] <Chipaca> eraserpencil: is snapcraft version 2.40, or 2.40.1?
[09:19] <eraserpencil> 2.40
[09:19] <Chipaca> eraserpencil: from where did you install it?
[09:19] <eraserpencil> i cant rem
[09:19] <eraserpencil> I was installing spotify as a snap
[09:20] <Chipaca> eraserpencil: dpkg -l snapcraft
[09:21] <eraserpencil> 2.40
[09:21] <zyga> pstolowski: can you please amend your forum post on layouts with the denial you saw
[09:22] <zyga> it will make it easier to fix
[09:22] <Chipaca> eraserpencil: looks like you're running it from the deb, ok
[09:22] <Chipaca> eraserpencil: i've just installed it as well
[09:22] <pstolowski> zyga: sure
[09:23] <zyga> thank you
[09:23] <Chipaca> eraserpencil: what does "git version" say?
[09:23] <popey> Ok, who wants a fun bug for today? snap install isn't pulling in core... http://paste.ubuntu.com/p/KyPhgc5zHs/
[09:23] <eraserpencil> 2.7.4
[09:24] <zyga> popey: oh, maybe mvo
[09:24] <zyga> mvo: ^ looks bad
[09:25] <eraserpencil> i removed ~/snap and recloned youtube-dl
[09:25] <eraserpencil> does look good for now
[09:25] <mvo> zyga: Setting up snapd (2.21-2+b1) ...
[09:26] <Chipaca> eraserpencil: FWIW I cloned it into ~/snap as well and it worked here
[09:26] <zyga> mvo: yes, that's debian
[09:26] <mvo> popey: what does `snap changes` tell you?
[09:26] <Chipaca> eraserpencil: I'm now trying to downgrade my git to see if it's that
[09:26] <thresh> hmm, did something change wrt to .config access from the apps?  I seem to get apparmor denials.
[09:26] <mvo> zyga, popey: ohhh, debian
[09:26] <popey> mvo: fwiw, installing a snap on its own, not multiple, it installs core
[09:26] <thresh> like [94066.971259] audit: type=1400 audit(1524129374.572:1024): apparmor="DENIED" operation="link" profile="snap.vlc.vlc" name="/home/thresh/snap/vlc/273/.config/vlc/vlc-qt-interface.conf" pid=9800 comm="vlc" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 target="/home/thresh/snap/vlc/273/.config/vlc/#270577332"
[09:26] <mvo> popey: thats sad
[09:27] <Chipaca> mvo: that might be 2.21's way though
[09:27] <mvo> popey: I mean, its good that at least in the one-snap case it is DTRT
[09:27] <mvo> Chipaca: yeah
[09:27] <popey> http://paste.ubuntu.com/p/6ZHDG2Hhtq/
[09:28] <zyga> but ...
[09:28] <zyga> core       16-2.32.3      4408  stable    canonical     core
[09:28] <zyga> you have core now
[09:28] <zyga> so what happened
[09:28] <popey> yeah, now I installed nextcloud
[09:28] <popey> the second paste is immediately after the first
[09:28] <popey> i had no core, installed nextcloud (one snap on its own) and now have core
[09:28] <popey> if you specify multiple snaps you dont get core
[09:28] <popey> thats my current way to reproduce it
[09:28] <mvo> popey: could you please also pasetbin snap change 1 and snap change 2 ?
[09:29] <mvo> popey: it might be that you get ubuntu-core in the first transaction that re-execs, does the ubuntu-core -> core transition behind your back
[09:29] <popey> mvo: http://paste.ubuntu.com/p/D6SZypWQPy/
[09:29] <mvo> popey: ta!
[09:29] <popey> no, got no core
[09:29] <mvo> popey: yeah, no core at all
[09:29] <mvo> popey: :(
[09:30] <popey> i can file a bug with steps to reproduce
[09:30] <popey> ?
[09:30] <mvo> popey: please do
[09:30] <popey> on it
[09:30] <mvo> popey: I am not sure what we can do about it though, I think we would have to upload a fixed deb
[09:31] <mvo> popey: because the re-exec fix will not be pulled down because there will be no core :/
[09:31] <popey> great! I love the sound of an updated snapd in debian ;)
[09:31] <Chipaca> mvo: popey: 2.21 had the install core only for single snaps
[09:31] <mvo> Chipaca: yes, I vaguely remember it was different code-paths
[09:32] <Chipaca> mvo: it used ensureUbuntuCore in daemon/api.go
[09:32] <Chipaca> mvo: instead of a flag in snapstate
[09:32]  * mvo nods
[09:32] <Chipaca> does debian let us SRU
[09:33] <zyga> I just reproduced this on debian
[09:33] <Chipaca> zyga: it's not a bug, it's a missing feature
[09:33] <zyga> Chipaca: it's not a bug it's a hole in the plane
[09:33] <Chipaca> eraserpencil: I can't reproduce your issue,  even with the same versions of git and snapcraft and doing it in the same directory on the same ubuntu
[09:33] <Chipaca> eraserpencil: ¯\_(ツ)_/¯
[09:34] <zyga> mvo: can we get to 2.32.5 in debian ;)
[09:34] <Chipaca> zyga: I mean: 2.21 did not add core to the list when doing a multi-snap install
[09:34] <mvo> Chipaca, zyga debian has pretty strict policies, but we can always try if the diff is not too terrible we have a chance. or we put an updated snapd into the debian backports repository
[09:35] <mvo> zyga: 2.32.5 would be for -backports but I like the sound of it
[09:35] <zyga> back ports sounds good but they are not enabled by default, right?
[09:35] <Chipaca> mvo: is backports an enabled-by-default-but-not-used job? ie a flag to apt away from working, or does it need enabling?
[09:36] <popey> https://bugs.launchpad.net/snapd/+bug/1765355
[09:36] <mup> Bug #1765355: Installing multiple snaps doesn't install core (debian snapd2.21) <snapd:New> <https://launchpad.net/bugs/1765355>
[09:36] <Chipaca> popey: which debian is this btw
[09:36]  * popey looks in the bug report
[09:36] <popey> https://www.raspberrypi.org/downloads/raspberry-pi-desktop/
[09:36] <popey> that debian :)
[09:37] <popey> 9.4
[09:37] <zyga> Chipaca: it also affects vanilla 9
[09:37] <mvo> Chipaca: I think its just like our -backports, i.e. "apt install -t foo-backports snapd"
[09:37] <mvo> Chipaca: but I'm not 100% certain
[09:37] <Chipaca> popey: can you try that ^
[09:37] <mvo> if they are not enabled its much less appealing :/
[09:38] <popey> i see no backports in sources.list
[09:38] <popey> only stretch and stretch-updates
[09:38] <zyga> same
[09:38] <zyga> I think we want backports anyway
[09:38] <zyga> we can then get more recent snapd cleanly
[09:38] <zyga> with all the non-reexec fixes
[09:39] <popey> that would add some additional steps to getting snapd on debian
[09:40] <pedronis> mvo: zyga: can't we have people opt-in into reexec somehow on debian? I understand we cannot make it the default
[09:40] <zyga> pedronis: sure
[09:40] <zyga> pedronis: but reexec doesn't fix this issue
[09:41] <zyga> pedronis: and on that version it is actually the default
[09:41] <pedronis> what's the issue?
[09:41] <zyga> snap install foo bar; # not pulling in core
[09:41] <pedronis> ah
[09:41] <pedronis> well, too bad
[09:42] <pedronis> doing a fix for exactly that will be annoying
[09:44] <pedronis> it might be easier to return an error in that case if there is no core
[09:45] <pedronis> if we are looking at doing a change only for that
[09:45] <pedronis> on top of an old snapd
[09:47] <mup> PR snapd#5067 closed: snap,tests : don't fail if we cannot stat MountFile <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5067>
[09:48] <eraserpencil> Chipaca: either how, thanks alot
[09:48] <eraserpencil> lots to ask kyrofa
[09:50] <zyga> https://github.com/mjl-/duit :D
[09:50] <zyga> mvo: your missing UI toolkit for the prompts ;-)
[09:53] <mvo> zyga: oh
[10:00] <mvo> kalikiana: quick question: is the snapcraft that is used in LP building using snap pack? I asked because it looks like for core18 it breaks permissions, i.e. it maps everything to root. I think we need to ensure that bases are not using "-all-root"
[10:01] <Chipaca> mvo: snapcraft is not yet building using snap pack afaik
[10:02] <mvo> Chipaca: ta
[10:02] <Chipaca> mvo: for that we need to package the standalone snap helper thing
[10:04] <axino> hi
[10:04] <axino> are snaps in LXDs still somewhat problematic ? (on xenial)
[10:04] <popey> installing them or building them?
[10:06] <zyga> axino: I think so, until 2.32.5 hits xenial (SRU)
[10:13] <axino> popey: installing
[10:14] <axino> zyga: OK thanks
[10:14] <popey> i found just installing squashfuse allowed me to install snaps inside lxd
[10:15] <mup> PR snapcraft#2090 opened: internal: skip -all-root for base snaps <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2090>
[10:19] <zyga> popey: that's correct but there are more issues later
[10:19] <popey> oh ok
[10:19] <zyga> still, it's all fixed and the SRU will be released shortly (hopefully)
[10:29] <mvo> popey: what version of snapd do you have in lxd right now?
[10:30] <popey> hard to say, i have a ton of lxd containers :)
[10:30] <mborzecki> Chipaca: left a couple more comments in the snapshots pr
[10:31] <mvo> popey: ok, the sru with the fix should be in -updates at tihs point so if that was something you experienced recently it would be great to know what version the snapd deb had
[10:32] <popey> ah, these are often long standing lxd containers that i forget to apt upgrade
[10:33] <mvo> popey: thats fine, if you experience issues in a fresh (and up-to-date) one, please shout so that we can investigate :)
[10:37] <mvo> zyga: another (trivial) core18 thing
[10:38] <zyga> ack
[10:38] <zyga> can we do two things
[10:38] <zyga> drop debconf + debconf i18n
[10:38] <zyga> and and and
[10:38] <zyga> if you can measure the size
[10:38] <mvo> zyga: I will probably do two more and then it should be fine. all related to uids - remove the apt user and make the two systemd users auto-created instead of hardcoded
[10:38] <zyga> install locales-all
[10:38] <zyga> ah, awesome
[10:39] <mvo> zyga: but probably after lunch
[10:39] <zyga> reviewed
[10:39] <mvo> zyga: locales-all? hm, hm, I think it makes sense, let me add it and see what size impact it has
[10:45] <mvo> zyga: looks like it jumps from 24mb to 36mb with locales-all
[10:46] <zyga> 8 megs
[10:46] <zyga> is that with compression
[10:46] <zyga> or without?
[10:46] <mvo> zyga: that is the raw snap size, so with compression
[10:47] <zyga> I wonder if each language contributes the same amount of space
[10:47] <Chipaca> mborzecki: what are the comments about cleanup about?
[10:47] <zyga> mvo: are those with i18n or just with non LC_MESSAGE things?
[10:47] <zyga> if we drop .mo files is it the same?
[10:47] <mborzecki> Chipaca: just stating the fact that the code looks good and afaict does not leave garbage behind :)
[10:47] <Chipaca> mborzecki: ah, phew :-)
[10:50] <Chipaca> waaaait
[10:50] <Chipaca> mborzecki: why is snapshotmgr in that PR
[10:50] <Chipaca> oh dammit i pushed the whole thing D:
[10:50] <mborzecki> Chipaca: hah, no clue ;)
[10:50] <Chipaca> mborzecki: sorry, will fix
[10:51] <Chipaca> uh, probably with a --force
[10:51] <mborzecki> Chipaca: and i was like, nice, new stuff for review ;)
[10:51] <Chipaca> that was meant to go in the _next_ batch
[10:51] <Chipaca> this one was already over the 1k
[10:52] <Chipaca> … i guess i can leave it if you've already reviewed it
[10:52] <Chipaca> nah, it'd be messy. cleaning it up.
[10:55] <Chipaca> that should do it
[10:57] <mborzecki> Chipaca: no worries, i went though cachio's pr in the morning, i think yours was shorter
[10:57] <Chipaca> heh
[10:57] <Chipaca> wait, QA is supposed to be about raising the bar, not lowering it :-p
[11:04] <mvo> zyga: one more for core18 and then I consider that bit finished for today
[11:04] <zyga> ok
[11:05] <zyga> mvo: ok
[11:05] <zyga> mvo: nothing about locale?
[11:08] <jamesh> zyga: finally got a green tick on https://github.com/snapcore/snapd/pull/3963
[11:08] <mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
[11:11] <zyga> I read all the changes you made since
[11:11] <zyga> now reading the whole diff again
[11:13] <zyga> jamesh: any reason file bind mounts are not using sec.BindMount?
[11:13] <zyga> kind == "" || kind == "file" would work IMO
[11:14] <jamesh> zyga: at the moment, Secure.OpenPath uses the O_DIRECTORY flag, so it would fail.
[11:15] <zyga> ah, indeed
[11:15] <jamesh> zyga: it would be pretty easy to get BindMount to work for files, but I thought it would be better to do that as a follow up branch rather than making this one bigger
[11:15] <zyga> yeah, I agree
[11:16] <zyga> +1
[11:16] <zyga> mborzecki: can you do a 2nd review please
[11:17] <jamesh> the last few spread test failures were down to "su" on Ubuntu and Debian being different to the other distros.  I've got something working everywhere now though
[11:17] <zyga> jdstrand: I believe the non-persistent per-user mount namespaces are okay now. Can you have look please.
[11:17] <zyga> yeah, saw that, interesting; I would say it would be easier of spread ran as a user but it's too late for that
[11:24] <thresh> out of curiousity, am I the only one experiencing way longer build times than previously with snapcraft?  my builds get "stuck" on "Preparing to build $foo", with snapcraft using 100% for minutes, apparently reading every file there is?
[11:25] <thresh> this is happening since a couple of weeks at least
[11:25] <thresh> e.g. now it takes an hour to do a build, while at the end of March the builds took around 40 minutes
[11:26] <thresh> this is reproducible on every machine I have, with snapcraft 2.40 from Xenial
[11:27] <thresh> https://jenkins.videolan.org/job/vlc-nightly/job/vlc-nightly-snap/buildTimeTrend shows the trend pretty nicely
[11:28] <Chipaca> jamesh: zyga: how is su different?
[11:29] <jamesh> Chipaca: we have the version from shadow, and everyone else uses the one from util-linux
[11:29] <Chipaca> ah
[11:29] <jamesh> Chipaca: shadow's su allows --login and --preserve-environment together, while util-linux's one ignores -p if used with -l
[11:30] <Chipaca> we are rather brilliant at that, aren't we
[11:31] <Chipaca> we should find a distro that's linux with no gnu tools just for extra fun
[11:31] <Chipaca> anyway, lunch now because meeting later
[11:31] <jamesh> do you want to port snapd to OpenBSD? :)
[11:31]  * Chipaca afk
[11:31] <mup> PR snapd#5034 closed: userd: set up journal logging streams for autostarted apps <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
[11:31] <Chipaca> jamesh: is there openbsd/linux?
[11:32] <jamesh> they've got something even better: openbsd/openbsd
[11:33] <Chipaca> 'starch linux'
[11:34] <mup> PR snapd#5070 closed: debian: update LP bug for the 2.32.5 SRU <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5070>
[11:36] <mborzecki> Chipaca: starch linux - sticky when wet
[11:36] <pstolowski> Son_Goku: hi Neal! can you help push https://bugzilla.redhat.com/show_bug.cgi?id=1567819 through?
[11:38] <mup> PR snapd#5073 opened: set up journal streams in user session application autostart (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5073>
[11:43] <Chipaca> mborzecki: it's dead now i think, but it was a statically-linked arch-based thing
[11:50] <Son_Goku> pstolowski, yes I can
[11:50] <Son_Goku> I've taken the review (though note *any* Fedora packager can review another Fedora package)
[11:51] <Son_Goku> so even zyga and kyrofa could have done it
[11:51] <zyga> mmm,
[11:52] <Son_Goku> the only thing *I* can do is sponsor new packagers in
[11:53] <seb128> thresh, did you report a bug or post on the forum about it?
[11:55] <thresh> seb128, I found a similar thread on the forums saying it's a feature https://forum.snapcraft.io/t/snapcraft-builds-taking-a-long-time-in-snap-vs-run-from-source/4280/3
[11:56] <pstolowski> Son_Goku: thanks, I see; but surely some "core" fedora dev need to bless it for landing even if it has reviews of other packages, right? is that your role?
[11:57] <seb128> thresh, is there any chance you could try if .41 fixes your issue?
[11:57] <thresh> seb128, is it in xenial already?
[11:57] <Son_Goku> pstolowski, nope
[11:57] <thresh> I suppose I could if it's packaged.
[11:57] <Son_Goku> only because you don't have any packages in fedora am I required to step in at all
[11:57] <seb128> thresh, in xenial-proposed at the moment
[11:57] <Son_Goku> pstolowski: that's what FE-NEEDSPONSOR is about
[11:58] <zyga> pstolowski: fedora is very open for contribution
[11:58] <seb128> thresh, https://launchpad.net/ubuntu/+source/snapcraft/2.41
[11:58] <seb128> thresh, you can download the debs on https://launchpad.net/ubuntu/+source/snapcraft/2.41/+build/14770947
[11:59] <Son_Goku> pstolowski: forget everything you learned about the bureaucracy of Debian and Ubuntu
[11:59] <Son_Goku> almost none of it applies to Fedora
[12:00] <pstolowski> Son_Goku: :D
[12:01] <zyga> the only issues we may encounter is if we wish to influence the default kernel configuration
[12:02] <zyga> so if we want to enable apparmor in the kernel, that's not going to fly easily and we'd have to discuss this and how it would be supported
[12:03] <Chipaca> does hangouts not work with the snapped firefox?
[12:03] <thresh> thanks seb128, trying it now
[12:04] <seb128> thresh, great, let us know if it works better!
[12:04] <zyga> Chipaca: it should work with the ESR thing
[12:04] <zyga> but not with normal ff
[12:04] <mborzecki> off to pick up the kids, bb for standup
[12:04] <zyga> because die plugins, die
[12:23] <mvo> zyga: fwiw, duit looks exceedingly cool
[12:23] <mvo> zyga: at least from a quick glance
[12:23] <zyga> it's a "send yaml to C helper" design
[12:26] <mvo> zyga: the wrapper pointer is interessting but I'm sure people will hate it
[12:26] <Son_Goku> pstolowski: https://bugzilla.redhat.com/show_bug.cgi?id=1567819#c8
[12:26] <zyga> I wasn't suggesting we actually use it
[12:26] <zyga> just that I found it interesting
[12:27] <zyga> pedronis: updated #5072
[12:27] <mup> PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
[12:27] <zyga> let me know if that's what you had on your mind
[12:28] <zyga> I think it's close to the original idea where we just held an internal error reference
[12:28] <pstolowski> Son_Goku: great, thanks a lot! will do the reviews
[12:28] <zyga> but I agree this is cleaner as an interface
[12:28] <zyga> oh, I misread part of your review
[12:28] <zyga> I'll make NotFoundError public again and restore that part of the code
[12:30] <mup> PR snapd#5057 closed: tests: bring back one missing test in snap-service-stop-mode <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5057>
[12:34] <zyga> pedronis: corrected now
[12:37] <pedronis> zyga: I'm in a meeting atm
[12:41]  * kalikiana lunch
[13:00] <Chipaca> current meeting overrunning
[13:08] <mup> PR snapd#5074 opened: interfaces/apparmor: add test case for tricky writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
[13:08] <Chipaca> i'll be a minute
[13:10] <thresh> seb128, no, it didnt change it at all, still 65 minutes per time(1)
[13:10] <seb128> :/
[13:10] <seb128> sergio is not around
[13:10] <seb128> Chipaca, do you know who knows about snapcraft and could help thresh with a regression that impact vlc builds?
[13:16] <Chipaca> seb128: kalikiana? kyrofa ?
[13:17] <seb128> Chipaca, thanks
[13:17] <seb128> kalikiana, kyrofa, can you help thresh?
[13:38] <zyga> jdstrand: hey, around?
[13:41] <kalikiana> thresh: Looking at the backlog... so as of 2.40 builds take a lot longer than before?
[13:41] <thresh> kalikiana, yep, correct.
[13:44] <jdstrand> zyga: hey, yes
[13:44] <zyga> jdstrand: something interesting came up wrt layouts
[13:45] <zyga> jdstrand: I summarised it in this short comment: https://github.com/snapcore/snapd/pull/5074#issuecomment-382728218
[13:45] <mup> PR #5074: interfaces/apparmor: add test case for tricky writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
[13:45] <jdstrand> zyga: did you also say pr 3963 could be reviewed?
[13:45] <mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
[13:46] <zyga> yes
[13:46] <zyga> please do, though that's a bigger cookie :)
[13:48] <jdstrand> zyga: I commented on 5074. I did not review the pr
[13:49] <kalikiana> thresh: Considering it's not a classic snap the forum post you linked shouldn't matter...  Do you happen to know what version it was that became so slow?
[13:49] <thresh> kalikiana, what version of what exactly?
[13:50] <thresh> kalikiana, snapcraft?  2.40 from ubuntu xenial repos.
[13:50] <kalikiana> thresh: Lemme re-phrase. You said with 2.40 it became slow. What were you using before?
[13:51] <thresh> kalikiana, it was 2.39.3+really2.35.
[13:55] <kalikiana> Okay
[13:55] <kalikiana> thresh: Is this just building vlc from git?
[13:56] <kalikiana> Going from the log
[13:56] <thresh> kalikiana, plus some contribs;  essentially yes.  https://jenkins.videolan.org/job/vlc-nightly/job/vlc-nightly-snap/
[13:56] <kalikiana> Yeah. Just checking what's needed to repro
[13:57] <thresh> the slowest part is "Preparing to build vlc" -- the build stays there for 15-20 minutes afaict
[13:57] <mup> PR snapd#5060 closed: tests: detect kernel oops during tests and abort tests in this case <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5060>
[13:58] <thresh> we're building in the docker images, containing needed packages since I don't allow jenkins users to be in a sudo group.  The image is registry.videolan.org:5000/vlc-ubuntu-xenial.
[14:07] <seb128> sergiusens, hey, ^ do you have any idea about that vlc issue?
[14:09] <sergiusens> seb128 thresh: `Preparing build` is basically unpacking all the stage-packages to their destination
[14:09] <seb128> sergiusens, is that known to be longer/having an issue since 2.40? thresh said it was working fine with 2.39.3+really2.35
[14:10] <sergiusens> how many stage-packages are we talking about. I have an item to improve the messaging there
[14:10] <sergiusens> seb128: we have no known issues on this side
[14:10] <sergiusens> is it slow just on that docker container or out of it as well?
[14:11] <thresh> jenkins@0792d2e4c997:~$ find .cache/snapcraft/stage-packages/ -type f -name "*.deb" | wc -l
[14:11] <thresh> 419
[14:12] <thresh> I never tried out of a docker container;  could try with an lxd, but not right now and on a very different power-wise machine
[14:14] <thresh> but that also happens on my laptop with an nvme, I wouldnt imagine that unpacking a few hundred megabytes of .debs should take that much time
[14:15] <mvo> cachio: 2.32.5 is in *-proposed now, no rush though with the verification
[14:15] <sergiusens> seb128: the only potential change we have is we went from calling dpkg-deb to using a python implementationdebian.arfile
[14:15] <sergiusens> thresh: ^
[14:16] <sergiusens> I will run some numbers against that, but I cannot do that today
[14:16] <thresh> I do see python proccess doing a lot of read/write under strace, yes
[14:16] <seb128> thresh, I recommend you open a post on the forum which can be used for debugging/discussion
[14:16] <seb128> the python thing might be much slower than dpkg-deb?
[14:16] <sergiusens> seb128: we do track bugs too you know ;-)
[14:17] <seb128> sergiusens, you mean you prefer  bug report on launchpad? or that rather you don't need me in that discussion? ;)
[14:17] <thresh> heheh
[14:17] <seb128> sergiusens, I started responding because nobody picked up his question earlier
[14:17] <sergiusens> seb128: we do not have a need for that feature anymore given the last PR I am working on, so we could potentially move back to dpkg-deb without much thought
[14:18] <thresh> and you are most welcome for that, seb128
[14:18] <seb128> :)
[14:18] <sergiusens> seb128, thresh: a bug report makes it not fall through the cracks, that's all
[14:18] <seb128> sergiusens, it does for the snappy team, that's why I asked to use the forum ... but good to know snapcraft is better at that :)
[14:19] <sergiusens> the forum is nice to have something like this initial conversation we just had on irc :-)
[14:19] <seb128> right
[14:35] <zyga> jdstrand: quick feedback, I wrote a helper that constructs the /{,funky/{,paths}}
[14:35] <zyga> and this is the apparmor profile after the change
[14:36] <zyga> xmas-tree-ified profile https://www.irccloud.com/pastebin/UWVbEfBd/
[14:36] <zyga> Looking at line like: ...     "  mount fstype=tmpfs options=(rw) tmpfs -> /{,usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}}/,\n" +
[14:36] <zyga> makes me say, use right-recursion and isProbablyPresent to avoid some of the things
[14:37] <zyga> as this essentially allows tmpfs over /
[14:39] <jdstrand> zyga: heh, just make sure you have a test that runs apparmor_parser on the resulting profile :)
[14:40] <zyga> haha
[14:40] <zyga> well, layouts tests will do
[14:40] <zyga> but yeah
[14:40] <zyga> but I was wondering if / should be off limits somehow
[14:40] <zyga> so that we allow at most /foo but not /
[14:40] <zyga> this profile will certainly make apparmor parser more busy ;)
[14:42] <jdstrand> zyga: so you have /{,usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}}/
[14:42] <jdstrand> zyga: why not /usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}/ ?
[14:42] <zyga> yes
[14:42] <zyga> that's my thinking
[14:42] <zyga> I can easily adjust that
[14:42] <zyga> and we cannot do things on / directly anyway
[14:42] <zyga> I added xmasTree function
[14:42] <jdstrand> right
[14:43] <zyga> I'll add trunkedXmasTree
[14:43] <jdstrand> zyga: btw, 3963 is approved
[14:43] <zyga> woot, thank you
[14:43] <zyga> I have some things on top I will try to propose but probably not today (or late)
[14:44] <zyga> I want to use the sun and go biking with my wife
[14:44] <jdstrand> zyga: well, I'm still working on other things
[14:44] <jdstrand> with critical priority, so... take your time :)
[14:44] <zyga> sure, thank you for the feedback! :)
[14:50] <jdstrand> np :)
[15:03] <zyga> jdstrand this with variable trunk size https://www.irccloud.com/pastebin/3SkvTtEr/
[15:03] <zyga> There are some things that can be simplified now
[15:03] <zyga> ...     "  /snap/tricky/42/{,usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}}/** rw,\n" +
[15:03] <zyga> ...     "  /snap/tricky/42/usr/lib/tcltk/x86_64-linux-gnu/ rw,\n" +
[15:03] <zyga> I think we can essentially stop making the non-xmas versions
[15:04] <zyga> as they represent the same assumption
[15:04] <jdstrand> neat
[15:04] <zyga> I'm happy how it looks like
[15:04] <zyga> the trunk length depends on what we do
[15:04] <zyga> so for $SNAP it is 3
[15:04] <zyga> but for target it is 1
[15:04] <zyga> so /snap/name/rev is expected to be there
[15:04] <zyga> but on the other side we just expect /toplevel
[15:06] <mup> PR snapd#5075 opened: snap/env: fix env duplication logic <Created by didrocks> <https://github.com/snapcore/snapd/pull/5075>
[15:08] <mup> PR snapcraft#2090 closed: internal: skip -all-root for base snaps <bug> <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2090>
[15:32] <pedronis> zyga: should I pick up pushing my small comment fixes to #5072 if you are busy with other things?
[15:32] <mup> PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
[15:33] <mvo> sergiusens: \o/ for merging the -allroot pr
[15:44] <zyga> pedronis: re, please! thank you
[15:45] <pedronis> zyga: ok, will do
[15:45] <zyga> sorry, I was focusing on apparmor and I didn't notice the ping
[15:52] <sergiusens> mvo: glad to make you happy
[16:04] <zyga> pstolowski: I fixed the bug you found locally, I will re-run spread and push the fix :)
[16:06] <pedronis> mvo:  the failure here looks weird:  https://travis-ci.org/snapcore/snapd/builds/368626305?utm_source=github_status&utm_medium=notification
[16:06] <pstolowski> zyga: very nice, thank you! i'm honored you considered this case tricky ;)
[16:07] <pedronis> mvo:  Reading package lists...
[16:07] <pedronis> E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list
[16:07] <pedronis> in the lxd test
[16:07] <zyga> pedronis: ha
[16:07] <zyga> we had that once before
[16:07] <zyga> I wonder how that happens
[16:07] <zyga> it went away on re-try
[16:07] <zyga> seems like sed gone wrong
[16:07] <pedronis> ok, anyway about to repush
[16:07] <zyga> 's'ecurity
[16:11] <pedronis> zyga: pushed
[16:12] <zyga> thanks
[16:29] <mup> PR snapcraft#2091 opened: meta: soften warning about using passthrough <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2091>
[16:45] <rogpeppe> quick question: is it possible to give a snap the privilege to be able to open a web page in the user's browser (without using classic confinement) ?
[16:49] <sergiusens> rogpeppe: if the app uses xdg-open that should already work
[17:12] <matiasb> sergiusens, o/ fyi, this one https://github.com/snapcore/snapcraft/pull/2086 finally completed and passed its travis run, we are trying to get the store changes rolled out this afternoon
[17:12] <mup> PR snapcraft#2086: tests: update metadata store integration test, no previous push required <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/2086>
[17:26] <sergiusens> matiasb: ack
[17:37] <jdstrand> roadmr (cc Wimpress, sergiusens, niemeyer): hey, can you pull r1026 of the review-tools? this has the refresh-mode and stop-mode work
[17:37] <kyrofa> Is the store down?
[17:37] <jdstrand> JamieBennett: fyi ^
[17:37] <roadmr> no
[17:37] <jdstrand> roadmr: no? :P
[17:38] <roadmr> jdstrand: yes to you, no to kyrofa  :)
[17:38] <jdstrand> :)
[17:38] <kyrofa> Looks like api.snapcraft.io is
[17:38] <roadmr> kyrofa: correction, looks like it *is* down
[17:39] <cprov> deadly slow
[17:42] <cprov> and it's back to normal request timing, investigating what caused the blip
[17:43] <roadmr> cprov: oh is it?
[17:46] <jdstrand> roadmr: oh, thanks btw :)
[17:46] <roadmr> jdstrand: np, I'm submitting the merge proposal now
[17:47] <jdstrand> \o/
[18:32] <jdstrand> roadmr: fyi, upstream electron-builder claims to have fixed the resquashfs, so in r1027 I updated the resquash error output to reference the fixed version. r1027 is not urgent, but if it can piggyback on r1026 from earlier, that would be cool
[18:33] <jdstrand> roadmr: sorry for the quick extra request
[18:33] <jdstrand> roadmr: we still have a partner issue and I'd like for electron-builder to have a chance to get out there, so don't want to turn on enforcement just yet
[18:34] <jdstrand> roadmr: but having r1027 in place when we do would be good
[18:55] <roadmr> jdstrand: no problem! I'll put 1027 in, probably willjust leapfrog 1026 which is already queued
[18:58] <jdstrand> roadmr: cool, thanks
[19:46] <cratliff> Hey, I asked this on the forum a while ago and didn't get a response: Some of the different gadget snaps don't have associated licenses, under the license field on launchpad they say "I don't know" Are they available for use?
[20:17] <sergiusens> kenvandine: today was the day for core18 in stable, do you know if that happened?
[20:17] <sergiusens> or was it 7 days from now?
[20:21] <sergiusens> cratliff: which gadget in particular? I suspect that ogra_ could help, but you should be able to use the ones from Canonical just fine, as usual, IANAL ;-)
[20:24] <cratliff> pc_amd64 in particular, but others don't have licenses as well.  I mean, I thought so, because it's used in demos and tutorials published on your website.  IANAL either, but my understanding is no license should be treated as proprietary.
[20:56] <nacc> who do I talk to about modifying the publisher entry for a snap?
[21:09] <mup> PR snapcraft#2092 opened: schema: allow refresh-mode and stop-mode <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2092>
[21:14] <sergiusens> matiasb: can you confirm that https://github.com/snapcore/snapcraft/pull/2086 works against production?
[21:14] <mup> PR snapcraft#2086: tests: update metadata store integration test, no previous push required <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/2086>
[21:14] <sergiusens> nacc: on the forum or maybe noise][ or roadmr can help
[21:15] <nacc> sergiusens: thanks, will do
[21:17] <matiasb> sergiusens, it will work as soon as we rollout, which is in the queue; in any case the failing test is really a restriction we lifted store-side, so we are not breaking anything just enabling something that wasn't possible before
[21:20] <sergiusens> thanks for confirming matiasb
[21:21] <matiasb> np