[03:53] 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] thank you for the link, popey [04:11] I didn't make the mental connection from the issue page to the acutal page to edit the documentation sheet ;) [04:17] PR snapcraft#1909 closed: dotnet plugin: add dotnet command to path and enable developer scenario for snap === pbek_ is now known as pbek [04:18] popey: I created a pull request at https://github.com/canonical-docs/snappy-docs/pull/390 [04:18] PR canonical-docs/snappy-docs#390: added documentation for version-script [05:04] morning [05:06] good morning :) [05:10] 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] uh, not fun [05:21] my guess it's gdm trying to do wayland [05:22] it locked up in plymouth screen, just when the tw infinity sign stopped spinning [05:47] pedronis: updated https://github.com/snapcore/snapd/pull/5067 [05:47] PR #5067: snap,tests : don't fail if we cannot stat MountFile [05:49] 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] zyga: left you a comment [06:27] btw. somehow also managed to break polkit & gnome-shell agent [06:28] wow, cannot remove the snap either [06:41] mborzecki: Ack, looking [06:41] Fin [06:41] Fun [06:41] Looks like another fix on top [06:44] if anyone wants to give it a try, https://github.com/snapcore/snapd/pull/5034 is simple and easy review [06:44] PR #5034: userd: set up journal logging streams for autostarted apps [06:56] zyga: I pushed a core18 PR, it does now show up in mup yet apparently [06:56] niemeyer: could you please add github.com/snapcore/core18 to the mup announcements? [06:58] ack, looking [07:01] mvo: are you sure about the security-policy-stamp? [07:01] zyga: I can look again [07:01] I mean, I assume you looked [07:01] zyga: the description is definitely wrong [07:01] zyga: we don't have snappy policygen [07:03] zyga: grep -r securtiy-policy-version over the entire image has no hit [07:03] yeah, I'm doing the same thing [07:03] that's a good indication that it is dead [07:04] yeah, looks like 15.04 leftover [07:04] * mvo ods [07:05] mvo: about the writable paths [07:05] 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] zyga: sure [07:05] how did you pick the things to remove? [07:05] and are we going to have tests after this PR? [07:05] zyga: starring at it hard enough [07:05] zyga: right, tests [07:05] zyga: man, you ask a lot! [07:05] ;) [07:05] * mvo hugs zyga [07:06] I'm sorry for asking the hard questions :) === pstolowski|eod is now known as pstolowski [07:06] morning [07:06] 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] pstolowski, mvo: morning guys [07:06] zyga: so ideally a test would ensure that, i.e. we don't break ABI [07:07] hey mborzecki and pstolowski ! good morning [07:07] mvo: sent my full review [07:07] zyga: thank you [07:07] sorry for being hard on that one [07:08] zyga: we could simply remove the entire writable-path in the first go? [07:08] ah, perhaps [07:08] zyga: I mean for the purpose of what we need to archive its irrelevant until we boot from core18 [07:08] question: can we mark this as a non-bootable base? [07:09] zyga: it is right now :) we have no language to mark a base bootable yet [07:09] mvo: ok, let's just add a comment to snap.yaml [07:09] describing that given the lack of language we just say it is not bootable yet [07:09] then +1 [07:09] zyga: cool, will do [07:10] zyga: I need to tweak it a little bit more it seems, travis failed with some odd error [07:13] the error look like the binaries have more recent libc requirement than what is in the image [07:14] mvo: perhaps as a sanity check run tests without your changes [07:16] https://toggl.com/blog/startup-zoo-comic/ [07:16] :D [07:19] good morning, snappy [07:20] hey ho [07:29] travis builds merge the PR branch to master right? [07:29] ... [07:29] I don't think so [07:29] mborzecki: I don't think it does, iirc it just uses whatever is in the PR [07:29] it tests whatever is pushed [07:29] there is an option to test the merged branch but we are not using it [07:34] appears we do merge origin/master before running tests, 'tested' empirically [07:35] interessting, I think this was different in the past [07:35] unit tests in #4844 were failing quite suspiciously [07:35] PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key [07:39] zyga: BrokenSnapError? (we already show that snaps are 'broken') [07:41] I called it Corrupted for now but yeah, Broken looks good [07:50] 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] Interesting [07:51] I suspected that while biking [07:51] I never tested that case [07:51] thank you for finding it :) [07:51] yw :) [07:52] but i'm nowhere close to get my snap working... tcl/tk is tricky [07:53] zyga: nb, snapcraft will not allow snap with experimental features (passthrough for layout) in the store, it displays explicit warning [07:53] heh [07:53] why? [07:53] that's silly [07:53] it was not supposed to be that [07:54] 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] that's what it says [07:55] yeah but that's not what we discussed [07:56] that's snapcraft from beta channel, so perhaps there is time to change it === devil is now known as Guest27019 [07:58] PR snapd#5072 opened: snap,overlord/snapstate: introduce and use BrokenSnapError [07:58] mborzecki: ^ built on top of the earlier one [07:58] ack [07:58] pstolowski: zyga: https://forum.snapcraft.io/t/support-for-passthrough-into-snap-yaml/4698 [07:59] reading the first post reinforces my opinion [08:00] and the message was in the PR that's mentioned in the post [08:00] yeah but it should not prevent sending that to the store [08:00] the store should flag [08:00] but snapcraft should allow it [08:01] indeed, manual review in the store, that's what Jamie said [08:02] pedronis: 5072 is a follow up to 5067 [08:03] zyga: I don't think we can use a single error [08:03] for exampel the check in doMountSnap is really about presence (mounted, not mounted) [08:04] zyga: I pushed a poor mans abi test for now [08:04] I read that [08:04] I wonder what `which cp` says [08:04] what's that cp that broke on us? [08:04] zyga: yeah, something strange in the PATH, when I use /bin/cp its fine [08:06] commented in the passthrough topic [08:06] 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] pedronis: is #5067 ready from your pop? [08:07] PR #5067: snap,tests : don't fail if we cannot stat MountFile [08:07] pov? [08:08] zyga: I don't think you addressed my comment about Path being optional [08:09] oh, I didn't notice that [08:14] done [08:16] thx [08:16] probably mvo should give it a 2nd quick look [08:16] he reviewed an early version [08:20] pedronis: sure, this is 5067? [08:20] yes [08:20] yes [08:25] zyga: commented [08:25] thanks, I'll add notes to both tests [08:26] ta [08:26] 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] zyga: I disabled the core18 writable-path stuff now as well, so we should be good in this area [08:26] must i delete them to remove that error? [08:27] kalikiana: ^ [08:27] 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] eraserpencil: you get those errors after installing your snap? [08:28] yes [08:28] eraserpencil: but those are snapcraft errors [08:28] mvo: done on the "snap try" PR [08:28] looking at core PR now [08:29] sorry, im not following [08:29] eraserpencil: me neither [08:30] eraserpencil: can you show the command you ran [08:30] eraserpencil: your snap builds using snapcraft, yes? [08:30] eraserpencil: and the full error you saw [08:30] yes [08:30] eraserpencil: was that yes to me or to zyga [08:31] erm, it's a snap of a ROS package. The command I ran was to initialise ROS. [08:33] here is the error: https://ghostbin.com/paste/dcdw7 [08:33] mvo: commented [08:34] pedronis: pstolowski: updated #4844 [08:34] PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key [08:37] sorry i was disconnected [08:38] eraserpencil: it looks like the snap is wrong [08:38] it contains build files from snapcraft [08:38] only the prime directory should be snapped [08:38] what does that mean [08:38] not the whole thing [08:38] zyga: hold on [08:38] eraserpencil: could you run a command and show us its output please: [08:38] eraserpencil: which roscore [08:38] eraserpencil: ^ that's the command [08:39] here: /opt/ros/kinetic/bin/roscore [08:39] eraserpencil: you're not running the snap [08:40] eraserpencil: could you run this other command: printf "%q\n" "$PYTHONPATH" [08:40] eraserpencil: (and show us its output) [08:40] Yea, im not. I wanted to run roscore on it's on but snap is tripping it up. [08:40] mborzecki: thanks, looking [08:41] here: /home/nvidia/mov/catkin_ws/devel/lib/python2.7/dist-packages:/opt/ros/kinetic/lib/python2.7/dist-packages [08:42] eraserpencil: ok, I don't know why ros is picking up libraries from under your current directory [08:42] eraserpencil: but, it's not the snap's fault, I figure [08:42] eraserpencil: run roscore from a different directory [08:45] same thing [08:46] eraserpencil: show me please [08:46] erm exact same error [08:47] ok, let me re-read this conversation because I'm getting lost [08:48] eraserpencil: how did you build the snap? [08:49] https://ghostbin.com/paste/d7ox5 [08:50] the error shows that python tried to find packages but found multiple packages of the same name [08:53] eraserpencil: I saw it that way first, but it's not python, it's ros itself [08:53] eraserpencil: and it's not looking in the snap [08:53] ahh, the python plugin for ROS has a script that searches recursively for packages. [08:54] eraserpencil: I think the most productive use of our time would be to wait for kyrofa to be online [08:54] My snap is within the catkin workspace [08:54] ok [08:54] eraserpencil: he's on -0700 so it'll be a while still [08:55] which time line is that? [08:55] eraserpencil: PDT I think [08:57] ok thanks [08:58] btw im having trouble with both demos of https://docs.snapcraft.io/build-snaps/python [09:00] eraserpencil: what sort of trouble? [09:05] https://ghostbin.com/paste/teoza [09:05] for the youtube-dl demo [09:06] let's see... [09:10] 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] eraserpencil: what version of snapcraft do you have? [09:11] 2.4 [09:11] eraserpencil: 2.4, or 2.40? [09:11] 2.40 [09:11] snapcraft just finished building youtube-dl [09:11] so, it works [09:12] eraserpencil: there's something nonstandard about your setup you're not telling us [09:12] really wish i knew. I've tried it on different computers [09:13] eraserpencil: ok, walk me through what you do, step by step [09:14] eraserpencil: first, what distribution are you on? [09:15] mkdir ~/snap [09:15] cd ~/snap [09:15] git clone git clone https://github.com/snapcraft-docs/youtube-dl [09:15] cd youtube-dl [09:15] snapcraft [09:15] Ubuntu 16.04 [09:15] dont do mkdir ~/snap :) [09:15] build your snaps somewhere else. [09:16] 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] good point (although I doubt that's the cause of the errors) [09:17] eraserpencil: repeating those steps here (also 16.04) [09:18] eraserpencil: I didn't get that error [09:19] eraserpencil: is snapcraft version 2.40, or 2.40.1? [09:19] 2.40 [09:19] eraserpencil: from where did you install it? [09:19] i cant rem [09:19] I was installing spotify as a snap [09:20] eraserpencil: dpkg -l snapcraft [09:21] 2.40 [09:21] pstolowski: can you please amend your forum post on layouts with the denial you saw [09:22] it will make it easier to fix [09:22] eraserpencil: looks like you're running it from the deb, ok [09:22] eraserpencil: i've just installed it as well [09:22] zyga: sure [09:23] thank you [09:23] eraserpencil: what does "git version" say? [09:23] Ok, who wants a fun bug for today? snap install isn't pulling in core... http://paste.ubuntu.com/p/KyPhgc5zHs/ [09:23] 2.7.4 [09:24] popey: oh, maybe mvo [09:24] mvo: ^ looks bad [09:25] i removed ~/snap and recloned youtube-dl [09:25] does look good for now [09:25] zyga: Setting up snapd (2.21-2+b1) ... [09:26] eraserpencil: FWIW I cloned it into ~/snap as well and it worked here [09:26] mvo: yes, that's debian [09:26] popey: what does `snap changes` tell you? [09:26] eraserpencil: I'm now trying to downgrade my git to see if it's that [09:26] hmm, did something change wrt to .config access from the apps? I seem to get apparmor denials. [09:26] zyga, popey: ohhh, debian [09:26] mvo: fwiw, installing a snap on its own, not multiple, it installs core [09:26] 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] popey: thats sad [09:27] mvo: that might be 2.21's way though [09:27] popey: I mean, its good that at least in the one-snap case it is DTRT [09:27] Chipaca: yeah [09:27] http://paste.ubuntu.com/p/6ZHDG2Hhtq/ [09:28] but ... [09:28] core 16-2.32.3 4408 stable canonical core [09:28] you have core now [09:28] so what happened [09:28] yeah, now I installed nextcloud [09:28] the second paste is immediately after the first [09:28] i had no core, installed nextcloud (one snap on its own) and now have core [09:28] if you specify multiple snaps you dont get core [09:28] thats my current way to reproduce it [09:28] popey: could you please also pasetbin snap change 1 and snap change 2 ? [09:29] 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] mvo: http://paste.ubuntu.com/p/D6SZypWQPy/ [09:29] popey: ta! [09:29] no, got no core [09:29] popey: yeah, no core at all [09:29] popey: :( [09:30] i can file a bug with steps to reproduce [09:30] ? [09:30] popey: please do [09:30] on it [09:30] popey: I am not sure what we can do about it though, I think we would have to upload a fixed deb [09:31] popey: because the re-exec fix will not be pulled down because there will be no core :/ [09:31] great! I love the sound of an updated snapd in debian ;) [09:31] mvo: popey: 2.21 had the install core only for single snaps [09:31] Chipaca: yes, I vaguely remember it was different code-paths [09:32] mvo: it used ensureUbuntuCore in daemon/api.go [09:32] mvo: instead of a flag in snapstate [09:32] * mvo nods [09:32] does debian let us SRU [09:33] I just reproduced this on debian [09:33] zyga: it's not a bug, it's a missing feature [09:33] Chipaca: it's not a bug it's a hole in the plane [09:33] 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] eraserpencil: ¯\_(ツ)_/¯ [09:34] mvo: can we get to 2.32.5 in debian ;) [09:34] zyga: I mean: 2.21 did not add core to the list when doing a multi-snap install [09:34] 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] zyga: 2.32.5 would be for -backports but I like the sound of it [09:35] back ports sounds good but they are not enabled by default, right? [09:35] 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] https://bugs.launchpad.net/snapd/+bug/1765355 [09:36] Bug #1765355: Installing multiple snaps doesn't install core (debian snapd2.21) [09:36] popey: which debian is this btw [09:36] * popey looks in the bug report [09:36] https://www.raspberrypi.org/downloads/raspberry-pi-desktop/ [09:36] that debian :) [09:37] 9.4 [09:37] Chipaca: it also affects vanilla 9 [09:37] Chipaca: I think its just like our -backports, i.e. "apt install -t foo-backports snapd" [09:37] Chipaca: but I'm not 100% certain [09:37] popey: can you try that ^ [09:37] if they are not enabled its much less appealing :/ [09:38] i see no backports in sources.list [09:38] only stretch and stretch-updates [09:38] same [09:38] I think we want backports anyway [09:38] we can then get more recent snapd cleanly [09:38] with all the non-reexec fixes [09:39] that would add some additional steps to getting snapd on debian [09:40] mvo: zyga: can't we have people opt-in into reexec somehow on debian? I understand we cannot make it the default [09:40] pedronis: sure [09:40] pedronis: but reexec doesn't fix this issue [09:41] pedronis: and on that version it is actually the default [09:41] what's the issue? [09:41] snap install foo bar; # not pulling in core [09:41] ah [09:41] well, too bad [09:42] doing a fix for exactly that will be annoying [09:44] it might be easier to return an error in that case if there is no core [09:45] if we are looking at doing a change only for that [09:45] on top of an old snapd [09:47] PR snapd#5067 closed: snap,tests : don't fail if we cannot stat MountFile [09:48] Chipaca: either how, thanks alot [09:48] lots to ask kyrofa [09:50] https://github.com/mjl-/duit :D [09:50] mvo: your missing UI toolkit for the prompts ;-) [09:53] zyga: oh [10:00] 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] mvo: snapcraft is not yet building using snap pack afaik [10:02] Chipaca: ta [10:02] mvo: for that we need to package the standalone snap helper thing [10:04] hi [10:04] are snaps in LXDs still somewhat problematic ? (on xenial) [10:04] installing them or building them? [10:06] axino: I think so, until 2.32.5 hits xenial (SRU) [10:13] popey: installing [10:14] zyga: OK thanks [10:14] i found just installing squashfuse allowed me to install snaps inside lxd [10:15] PR snapcraft#2090 opened: internal: skip -all-root for base snaps [10:19] popey: that's correct but there are more issues later [10:19] oh ok [10:19] still, it's all fixed and the SRU will be released shortly (hopefully) [10:29] popey: what version of snapd do you have in lxd right now? [10:30] hard to say, i have a ton of lxd containers :) [10:30] Chipaca: left a couple more comments in the snapshots pr [10:31] 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] ah, these are often long standing lxd containers that i forget to apt upgrade [10:33] popey: thats fine, if you experience issues in a fresh (and up-to-date) one, please shout so that we can investigate :) === pstolowski is now known as pstolowski|lunch [10:37] zyga: another (trivial) core18 thing [10:38] ack [10:38] can we do two things [10:38] drop debconf + debconf i18n [10:38] and and and [10:38] if you can measure the size [10:38] 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] install locales-all [10:38] ah, awesome [10:39] zyga: but probably after lunch [10:39] reviewed [10:39] zyga: locales-all? hm, hm, I think it makes sense, let me add it and see what size impact it has [10:45] zyga: looks like it jumps from 24mb to 36mb with locales-all [10:46] 8 megs [10:46] is that with compression [10:46] or without? [10:46] zyga: that is the raw snap size, so with compression [10:47] I wonder if each language contributes the same amount of space [10:47] mborzecki: what are the comments about cleanup about? [10:47] mvo: are those with i18n or just with non LC_MESSAGE things? [10:47] if we drop .mo files is it the same? [10:47] Chipaca: just stating the fact that the code looks good and afaict does not leave garbage behind :) [10:47] mborzecki: ah, phew :-) [10:50] waaaait [10:50]