[00:32] <swluo> helo?
[00:32] <swluo> anyone here?
[00:46] <swluo> hello?
[00:56] <oky> hi swluo
[00:58] <swluo> hey
[00:58] <swluo> i was wondering if you could help me out with some library issues that i've been having
[00:59] <swluo> is there any ways of editing the default SNAP_LIBRARY_PATH
[00:59] <swluo> i'm getting errors when trying to load my shared libraries
[01:09] <swluo> hey qengho
[01:10] <swluo> hey jjohansen
[01:10] <jjohansen> hey swluo
[01:11] <swluo> hey man i was wondering if you can quickly help me out
[01:11] <swluo> do you know if you can edit the default path of the SNAP_LIBRARY_PATH
[01:11] <swluo> i'm having issues loading shared libraries
[01:12] <jjohansen> swluo: sorry that is one I don't know
[01:12] <swluo> mhmm thanks
[01:12] <swluo> too bad
[01:13] <swluo> the documentation could be a lot better for snap
[01:13] <swluo> is it because its soo new?
[01:13] <jjohansen> swluo: is this on trusty?
[01:13] <swluo> nah 16.04
[01:13] <swluo> like i can run it from command line just fine
[01:14] <jjohansen> swluo: yeah snap is a moving target, so its hard to get good docs just yet
[01:14] <swluo> but when i use the snap command it gives me library not ffound
[01:14] <swluo> ahah yeah true true fair enough.
[01:15] <swluo> "cannot open shared object file: No such file or directory."
[01:15] <swluo> and i can't even make symlink for the default path with is annoying as well
[01:16] <jjohansen> oh yes, confinement is great until it gets in the way, and then its at a minimum annoying, and usually a right pita
[01:17] <oky> swluo: it's a symlinked binary and you have the libraries (shared objects) also being packaged?
[01:17] <swluo> well ok like in the .yaml
[01:18] <swluo> i've delcared build-packages: [libsdl2-dev]
[01:18] <swluo> which should give me the proper libraries that it needs
[01:18] <swluo> so i didn't package it together
[01:18] <swluo> will that work?
[01:18] <oky> i wouldn't know if it does or not. maybe you can look at what is in $LD_LIBRARY_PATH from inside your env
[01:19] <swluo> aha its funny cause i tried that
[01:19] <oky> if you open your snap, does it have the .so files that you'd expect?
[01:19] <swluo> from the docs "snap run --shell <snap>.<command>"
[01:19] <swluo> this commant should let me look at the env. but it also gives me errors
[01:19] <swluo> no it does not. because i'm assuming its already downloaded
[01:21] <oky> swluo: well, in most system, 'build packages' would not be included in the final output
[01:21] <oky> for example, in debian, you have build deps which are only required for building the package (but not required for installing it), i might check if that is what is happening here
[01:22] <oky> swluo: just fyi, i am new to snap, so i am not a reliable source of ideas / debugging
[01:22] <swluo> yeah no worries
[01:22] <swluo> anything helps
[01:22] <swluo> just need to bounch ideas off someone
[01:22] <swluo> like do you think it possible to just bundle the library with the snap?
[01:22] <swluo> and somehow refer it then
[01:23] <oky> swluo: can you check if it is building a statically linked binary or a dynamic library?
[01:23] <swluo> its a dynamic library
[01:23] <swluo> like i can't run it using the snap command
[01:23] <swluo> but if i use the absolute path
[01:23] <swluo> it runs just fine
[01:23] <swluo> "concentration  /snap/concentration/x13/run: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory"
[01:24] <swluo> so if i go "/snap/concentration/x13/run" it works
[01:25] <oky> swluo: in your command wrapper, dump env using 'env' command and inspect the vars. compare your current LD PATH and see if where libSDL2 resides now is in the snap's paths
[01:25] <oky> are you running as root or regular user? and is this a snap you are running via the 'try' command or is it installed?
[01:27] <swluo> i'm regular user
[01:27] <swluo> and its being installed everytime
[01:28] <oky> swluo: i just did a search on google for 'snapcraft libsdl2' and came across your SO question, lol
[01:28] <swluo> yeah ahaha!
[01:28] <swluo> i'm at a hackathon soo time is kinda important
[01:29] <mup> PR snapcraft#1106 opened: tests: check the CLA on all the commits <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1106>
[01:29] <swluo> anyways how do you do a dump?
[01:29] <swluo> from the command wrapper
[01:29] <oky> swluo: add the line 'env'
[01:32] <oky> swluo: ok, so: can you check to see if your stage/ has the library files? if it does (and the prime/ does not), you need to manually specify that they are copied over into the prime/
[01:32] <swluo> i don't have any stage library files
[01:32] <oky> where do they exist at all? how is it building?
[01:33] <swluo> so i think i might need to manually copy it into prime
[01:33] <swluo> its building all from parts
[01:33] <swluo> its all building from just one make file
[01:33] <oky> yeah, at each stage, you can specify which files to copy over to the next (or something like that)
[01:34] <swluo> interesting yeah ok i'll try that thanks
[01:34] <swluo> so basically we're back to the original idea of just shipping the library file with teh snap then
[01:34] <swluo> ahah
[01:34] <oky> that's how it would have to be done, though...
[01:34] <oky> unless you are creating a statically linked binary
[01:35] <swluo> mhmm ok maybe i'm just understanding it inocrrectly then
[01:35] <oky> i think (and i'm not certain) that snaps are supposed to be runnable standalone (as though all necessary libraries are included with them)
[01:35] <swluo> mhmm no that makes sense let me try some things out
[01:35] <swluo> you've been great
[01:35] <swluo> cheers
[01:38] <oky> swluo: plz let me know if you get it working, good luck at the hackathon!
[01:38] <swluo> yeah i'll update it here
[01:38] <swluo> are you a fulltimer or a student?
[01:40] <oky> swluo: fte
[01:41] <swluo> where you working? i'm coop at blackberry rn ahahahah
[01:41] <oky> swluo: at one of those big companies that no one likes
[01:42] <oky> there are so many of them, now that i think about it
[01:42] <swluo> ahahaha would you do something else if you could?
[01:43] <oky> swluo: why do you ask?
[01:43] <swluo> idk if this is the stuff i want to do in the future
[01:43] <oky> swluo: i'm in charge of my self, atm, so i'm fine with how things are - i would not trade it, perhaps excepting for 50 mil
[01:43] <swluo> like i'm good at it and its good money
[01:44] <swluo> but i "love it"
[01:44] <swluo> don't*
[01:44] <oky> swluo: take your computer to a relationship counselor
[01:44] <oky> tell the counselor that you've fallen out of love and need to rekindle the spark
[01:44] <swluo> and like i'm just starting sooo its aiiyaaah
[01:44] <swluo> mhmm rando strangers on the internet that my mom says i shouldn't talk to?
[01:45] <oky> swluo: you should read "Disciplined Minds: A Critical Look at Salaried Professionals and the Soul-battering System That Shapes Their Lives"
[01:46] <oky> or at least the wiki page on it
[01:46] <swluo> damn the first review on amazon hit me like a truck.
[01:46] <swluo> thanks for the advice ahah
[01:46] <oky> actually, nvm - wiki page is terrible
[01:47] <swluo> i just brought the book
[01:47] <swluo> ... see this is what happens when you have too much money and no girlfriend to spend it
[01:57] <swluo> btw oky thanks
[01:58] <swluo> i figured it out you're right
[01:58] <swluo> i included all the libraries using a stage
[01:58] <swluo> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/
[01:58] <swluo> cheers
[02:00] <oky> haha, awesome
[03:01] <diddledan> just updated corebird-diddledan to corebird-1.4.2
[07:19] <mup> PR snapd#2788 closed: store,osutil: use new osutil.ExecutableExists(exe) check to only use deltas if xdelta3 is present <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2788>
[07:31] <mup> PR snapd#2780 closed: tests: increase snap-service kill-timeout <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2780>
[07:36] <mup> PR snapd#2760 closed: merge release 2.22.1 into master <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2760>
[08:10] <mardy> pstolowski: hi! Got a minute to talk about interface hooks?
[08:12] <pstolowski> mardy, hi! sure
[08:13] <mardy> pstolowski: so, I finally succeeded in getting my hook invoked :-)
[08:14] <pstolowski> mardy, great! :)
[08:14] <mardy> pstolowski: now the next question is, how to get information about the client, from within the hook of the socket
[08:15] <mardy> pstolowski: I tried with "snapctl get", but it failed to read the attributes set on the plug
[08:16] <mardy> pstolowski: I'm running this: snapctl get --plug :online-accounts manifest
[08:17] <mardy> pstolowski: where "online-accounts" is the name of the interface, and manifest is an attribute set on this interface in the plug
[08:18] <pstolowski> mardy, can you show me a complete hooks/ content?
[08:18] <mardy> pstolowski: and I get this on stderr, when connecting: error: cannot add authorization: open /home/mardy/.snap/auth.json: permission denied
[08:19] <pstolowski> mardy, that should generally work in my branch (i've a spread test with similar setup)
[08:19] <mardy> pstolowski: I'll push the branch in a minute, I'll ping you
[08:21] <mardy> pstolowski: bzr branch lp:~mardy/webapps-core/iface-hook-test
[08:22] <mardy> pstolowski: the socket is snap/amazon/snapcraft.yaml
[08:22] <mardy> pstolowski: the plug is snap/facebook/snapcraft.yaml
[08:23] <pstolowski> mardy, socket == slot ;)
[08:23]  * pstolowski was slightly confused for a moment
[08:23] <mardy> pstolowski: indeed :-)
[08:31] <pstolowski> mardy, no hooks files there, did you forgot to commit them?
[08:32] <mardy> pstolowski: ehm... :-)
[08:35] <mardy> pstolowski: ok, please pull again
[08:37] <mup> PR snapd#2791 opened: store: use xdelta3 from core if available and not on the regular system <Created by mvo5> <https://github.com/snapcore/snapd/pull/2791>
[08:52] <pstolowski> mardy, ok
[08:52] <pstolowski> mardy, so, the problem is
[08:53] <pstolowski> mardy, you want plug and slot names there, not the interface names; so this will be 'oa', not online-accounts. that applies both to the :names you pass to snapctl, and to the names of the files under hooks/
[08:56] <pstolowski> mardy, or rename oa to online-accounts
[08:56] <mardy> pstolowski: right, makes sense
[08:57] <mardy> pstolowski: thanks a lot, I'll try that
[08:58] <pstolowski> mardy, np. see my test snaps under tests/lib/snaps/basic-iface-hooks-* (in my MP) if in doubt
[08:59] <mardy> pstolowski: btw, would it be possible to get an implicit attribute with snapctl, which is the name of the connecting snap?
[09:00] <mardy> pstolowski: I mean, suppose that that plug doesn't declare any attributes; could the slot hook still infer some info about who's trying to connect?
[09:01] <mardy> pstolowski: the use-case is that we want to make sure that the client really is what it claims to be
[09:02] <pstolowski> mardy, i see what you mean. yes that's easy to do, i wonder if env variables would be good for that. i'll bring it up with niemeyer
[09:03] <mardy> pstolowski: thanks
[09:53] <mup> PR snapd#2763 closed: store: retry on 502 http response as well <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2763>
[10:04] <mup> PR snapd#2761 closed: vendor: move gettext.go back to github.com/ojii/gettext.go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2761>
[11:22] <adamlove> hi
[11:44] <mup> PR snapcraft#1106 closed: tests: check the CLA on all the commits <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1106>
[11:47] <mup> PR snapcraft#1105 closed: tests: rename the integration test snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1105>
[11:56] <mup> PR snapcraft#1099 closed: catkin plugin: don't pass args to setup.sh <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1099>
[12:05] <mup> PR snapcraft#1107 opened: meta: correct the deprecation for `setup/gui` use <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1107>
[12:33] <lool> ogra_: heya
[12:33] <ogra_> lool, yo
[12:33] <lool> ogra_: what's the cleanest way to put a GRUB config snippet (override kernel cmdline) with the x86 images?
[12:34] <ogra_> create your own gadget
[12:34] <lool> is there no local way?
[12:34] <ogra_> well, you asked for the cleanest :)
[12:34] <lool> (I need it to survive upgrades)
[12:34] <ogra_> you can surely just hack up /boot/grub/grub.cfg
[12:34] <lool> ogra_: hehe, yes
[12:34] <ogra_> we dont update bootloader configs on gadget upgrade currently
[12:35] <ogra_> so whatever you do there should persist
[12:35] <lool> ogra_: would you have an upboard by any chance?
[12:35] <ogra_> nope, never heard of it
[12:35] <lool> kind of a rpi from intel
[12:35] <lool> http://www.up-board.org/
[12:36] <lool> v2 isn't out yet
[12:36] <ogra_> ah
[12:38] <lool> some guys using it have trouble forcing the CPU to max freq, I'm trying to let them set cmdline options to disable it
[12:41] <ogra_> lool, wont work ... we force the ondemand governor
[12:41] <ogra_> from an ancient init.d script
[12:42] <ogra_> (see /etc/init.d/ondemand )
[12:42] <lool> ogra_: well unless we disable it from the kernel cmdline, no?
[12:42] <ogra_> so the CPU will always scale down .. what they could do is build their own kernel with only performance in it
[12:43] <lool> I was actually thinking of disabling the underlying implementation rather than the governor, /me digs the name
[12:43] <ogra_> the script reads /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
[12:43] <lool> intel_pstate=disable
[12:43] <ogra_> if you can make it not appear there it should work
[12:44] <lool> ogra_: for some reason, they can't even set the "performance" governor on this board (it appears, but can't be selected)
[12:44] <lool> my devices here use ACPI, but they have a more recent Intel embedded CPU which does this pstate stuff
[12:44] <ogra_> hmm, thats weird ...
[12:45] <ogra_> yeah, i'm not very familiar with pstate vs cpufreq yet ... i'd ask cking
[12:46] <ogra_> (i dont really have newer intel systems here, only ARMs :) )
[12:47] <lool> well ARM is the new Intel!
[12:47] <lool> soon we'll be looking at some other architecture which is more embedded and wants to displace ARM!  ;-)
[12:47] <ogra_> hehe
[12:50] <zyga> lool: let's skip mips and go to risc ;-)
[12:50] <ogra_> no risc, no fun
[12:51] <zyga> but low-risk risc is fun
[12:52] <davmor2> lool: just get a reflex hammer and strike arms elbow that'll displace it
[12:54] <lool> zyga: I was thinking something lower tech like stones
[12:54] <lool> take two piles of stones together to make an addition
[12:54] <lool> remove stones to make a substraction
[12:54] <lool> throw stones to make a function call
[12:54] <zyga> ubuntu for forests and quarries?
[13:04] <mup> PR snapd#2792 opened: tests: add spread test for delta downloads <Created by mvo5> <https://github.com/snapcore/snapd/pull/2792>
[13:28] <mup> PR snapd#2779 closed: tests: gruntwork backend and suite; task for sync snapd with vendor <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2779>
[13:49] <zioproto> hello #snappy. Can I get help here in pushing packages to the Ubuntu Store ? I have this package with confinement classic that I cant push
[13:59] <zioproto> anyone can help me with this ? :) https://myapps.developer.ubuntu.com/dev/click-apps/6815/rev/4/
[14:00] <uijnoinompo> join
[14:41] <popey> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 is this expected behaviour? People have to enable each alias individually?
[14:41] <mup> Bug #1662181: Aliases didn't enable out of the box <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662181>
[14:42] <popey> zioproto: hello, i think jdstrand is the one to ask about that - I note he already replied to one of your uploads though.
[14:43] <morphis> ogra_: when did we drop ppp from the core snap?
[14:43] <morphis> ogra_: we have a dependency on it from the modem-manager snap
[14:43] <morphis> that is why we created the ppp interface
[14:44] <zioproto> popey, do you mean 'This snap is using 'classic' confinement. At this time we have the technical implementation for how to implement classic confinement but the processes for when to grant acceptance in the store is still being worked out. This is actively being discussed and we'll get back to you once the store acceptance policies are defined.'   ????
[14:44] <zioproto> popey, that is a bot answering
[14:45] <popey> zioproto: no, jdstrand is a person :)
[14:46] <popey> ooh, speak of the devil
[14:46] <popey> jdstrand: when you have a moment, zioproto is asking about https://myapps.developer.ubuntu.com/dev/click-apps/6815/rev/4/
[14:54] <jdstrand> popey: that is actually something for ev
[14:56] <popey> ah okay.
[14:56] <popey> thanks
[14:56] <jdstrand> np
[15:04] <zioproto> who is ev ?
[15:05] <zyga> zioproto: evan, why?
[15:05] <popey> zioproto: I'm discussing with him, I'll get back to you asap
[15:05] <zioproto> okay
[15:06] <zyga> jdstrand: hey, I'm ill today; if you have some time please look at C patches, otherwise I'm semi-useless and not making much code
[15:06] <zyga> jdstrand: I know that the kernel has a way to convey bind mounts to userspace now
[15:06] <zyga> jdstrand: I'm coding a routine that does that
[15:11] <mup> PR snapd#2793 opened: Add Maliit input method interface <Created by Elleo> <https://github.com/snapcore/snapd/pull/2793>
[15:11] <mup> PR snapcraft#1103 closed: meta: support for the environment keyword <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103>
[15:14] <jdstrand> zyga: hope you get better soon
[15:16] <zyga> thanks
[15:17] <mup> PR snapcraft#897 closed: pluginhandler: use an alternate location to organize <Created by josepht> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/897>
[15:17] <mup> PR snapcraft#1064 closed: pluginhandler: support colliding with directories <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1064>
[15:19] <jdstrand> mterry: hey, working through the unity8-session store reviews. note that until the PR lands, I don't think we should issue a snap declaration for unity8 (I'm not sure of the side effects that would have on systems without unity8). I see you already are using only 'mir', and I issued a snap declaration for that
[15:20] <mterry> jdstrand: sorry, you mean allowing unity8-session snap to have those slots?
[15:20] <jdstrand> mterry: I also see that you are using top-level 'slots'. This gives all commands PermanentSlot policy for the mir server. I'm quite sure you do not want this. Please add 'slots: [ mir ]' to the command that needs it
[15:20] <mup> PR snapcraft#904 closed: cleanbuild: use pylxd instead of lxd command line <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/904>
[15:21] <jdstrand> mterry: unity8-session is now allowed to use slot mir
[15:21] <jdstrand> mterry: I think we should wait for it to slot unity8 until the PR lands
[15:21] <mterry> jdstrand: yeah that was because I needed to talk to tedg_ about which of the commands actually need it, but noted
[15:21] <mterry> jdstrand: yah agreed -- I took out the slot
[15:24] <jdstrand> mterry: you are going to receive a few rejection emails until we hit the upload that only slots mir
[15:25] <mterry> Huh...  I was under the impression I had already built and uploaded one of those
[15:25] <jdstrand> it's going to take a few minutes
[15:25]  * mterry rebuilds a new snap
[15:25] <mterry> I mean, I did that on Friday
[15:26] <jdstrand> mterry: you did, but the way the store works is this is a queue of uploads. I need to reject each one that is queued before it
[15:26] <mterry> oh ah
[15:26]  * mterry doesn't build a new snap then
[15:27] <jdstrand> it'll be a few minutes before we are there (fyi, the store team will be improving this process for reviewers)
[15:35] <ogra_> kgunn, http://imgur.com/a/ddqjQ Pi2 ubuntu-core running the unity8-session snap !!!
[15:36] <ogra_> (right monitor)
[15:36] <kgunn> nice!
[15:37] <ogra_> there are font issues and the top panel is completely transparent .... tha console is also spilled with lots of failing/respawning  upstart jobs
[15:37] <kgunn> ogra_: i didn't think pi2 had the right stuff for gpu...
[15:37] <ogra_> but its the first time i get something on display with that snap
[15:37] <kgunn> only pi3
[15:37] <kgunn> very cool
[15:37] <ogra_> i made sure both do now :)
[15:37] <ogra_> after all the changes were identical
[15:37] <kgunn> and yeah, lots of spew
[15:37] <kgunn> re upstart jobs
[15:37] <ogra_> yep
[15:56] <jdstrand> nessita: fyi, bug #1662218
[15:56] <mup> Bug #1662218: Please email store reviewers with changes to classic confinement <Software Center Agent:New> <https://launchpad.net/bugs/1662218>
[15:56] <jdstrand> nessita: and hi!
[16:00] <nessita> jdstrand, hi! I would have thought we did that already, but let me check and/or raise the issue. Thanks!
[16:00] <nessita> roadmr, ^
[16:01] <jdstrand> nessita (roadmr): if you look at the 'Package declaration update' email, it lists plugs, slots, auto-aliases and refresh-control, but not classic. I can't recall ever seeing and email for changes to classic confinement
[16:01] <roadmr> right nessita jdstrand maybe we did that for the other things and not classic... ugh sorry
[16:04] <cory_fu> jdstrand: Thanks for the approval on the juju-crashdump snap.  I had a question re: your comment about LP builds.
[16:05] <cory_fu> I tried to have it build on LP, but it's failing except on ppc64el: https://code.launchpad.net/~johnsca/+snap/juju-crashdump
[16:06] <jdstrand> cory_fu: that seems like a question for the LP team based on, for example, https://launchpadlibrarian.net/305075153/buildlog_snap_ubuntu_xenial_arm64_juju-crashdump_BUILDING.txt.gz
[16:07] <cjwatson> known bug
[16:07] <cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1650946
[16:07] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946>
[16:08] <cory_fu> cjwatson: Ok, thanks
[16:09] <cory_fu> How long after releasing a snap to the stable channel should I be able to see it in `snap find`?  Is there something I can run locally to force a refresh?
[16:09] <cjwatson> Planning to attack that later this week; just need to get an ack from Sergio on the basic approach first
[16:13] <balloons> nessita, might you be able to transfer ownership of the juju snap between ubuntu one accounts?
[16:13] <nessita> balloons, hello! yes, I can do that. What would be the target account?
[16:14] <nessita> balloons, also, please send me an email with the request so I can keep track of the transfers, I'd need source account and target account, with some consent from the target account in there
[16:17] <balloons> nessita, will do. I'll cc both accounts and yourself so you can see consent
[16:18] <nessita> balloons, thank you!
[16:28] <aisrael> stokachu, here
[16:28] <stokachu> whats the best way to get someone who is has ubuntu-core snap installed migrated to the latest core snap?
[16:29] <stokachu> they're on snapd 2.21
[16:29] <stokachu> he can't remove the ubuntu-core snap and snap refresh/install does not seem to handle upgrading from ubuntu-core to core
[16:30] <stokachu> would a simple apt-get remove snapd and reinstall work?
[16:34] <stokachu> zyga, ^ any idea here?
[16:35] <aisrael> stokachu, I removed and reinstalled and now I can install core (previously installed snaps were gone)
[16:35] <stokachu> aisrael, ok cool
[16:35] <stokachu> may be worth trying to reinstall conjure-up now
[16:35] <stokachu> before you do a build
[16:36] <stokachu> aisrael, ^
[16:36] <ogra_> stokachu, yes, that works but removes all already installed snaps alongside ... so handle with care ;)
[16:37] <stokachu> ogra_, is there any upgrade path?
[16:37] <aisrael> stokachu, There were a few leftover symlinks in bin I had to remove. With those gone, conjure-up installed and works
[16:37] <stokachu> aisrael, \o/
[16:37] <ogra_> mvo works on that ... not sure whats the target release for it though
[16:42] <mvo> stokachu: you want to transition ubuntu-core to core?
[16:42] <stokachu> mvo, yea we had a user aisrael who still had ubuntu-core on his system
[16:42] <ogra_> they already did by reinstalling snapd ...
[16:43] <stokachu> mvo, yea he reinstalled snapd which wasn't an issue for him but i was curious what the upgrade path is
[16:43] <mvo> stokachu: please try the snapd from -proposed or run "snap refresh --candidate ubuntu-core" for re-exec magic
[16:43] <stokachu> mvo, ah ok, ill make a note if anyone else runs into that
[16:43] <mvo> stokachu: thank you, please do. keen to get feedback on the auto-migration :)
[16:43] <stokachu> mvo, is there a way i can manually reproduce?
[16:44] <stokachu> can i snap install ubuntu-core on a fresh xenial system with 2.21?
[16:44] <mvo> stokachu: so far it works well but it seems relatively few people are astill having ubuntu-core
[16:44] <stokachu> mvo, yea this was the first case i ran into where someone was still on ubuntu-core
[16:44] <mvo> stokachu: yes, if you have nothing installed you can snap install ubuntu-core
[16:44] <stokachu> mvo, cool ill give it a shot and let you know if i run into an issue
[16:44] <mvo> stokachu: then you can upgrade your snapd or install a newer ubuntu-core that contains the re-exec magic and it will auto-transition you
[16:44] <mvo> stokachu: great, thank you
[16:45] <stokachu> mvo, ah so his issue was he couldnt snap install ubuntu-core
[16:45] <stokachu> or snap refresh ubuntu-core
[16:45] <mvo> stokachu: ohh
[16:46] <stokachu> mvo, snap refresh just told him no updates available
[16:46] <mvo> aisrael: hey, if you were affected by the problem with not being able to install/refresh ubuntu-core, could you please pastebin "journalctl -u snapd" (or mail that output to me). that hopefully gives me a clue why the system behaved strangely
[16:47] <mvo> stokachu: snap changes should show a transition, it may take up to 10min though to start
[16:48] <stokachu> mvo, oh i learned a new command
[16:48] <mvo> stokachu: please paste the snap --version output here so that I can check if the version you have supports the auto migration already
[16:48] <stokachu> snap    2.21
[16:48] <stokachu> snapd   2.21
[16:48] <stokachu> series  16
[16:48] <stokachu> ubuntu  16.04
[16:48] <mvo> stokachu: snap changes is cool, you can also see the individual changes via "snap change N" (with N being the one you want to see)
[16:49] <mvo> stokachu: aha, that is not recent enough, you will need 2.22.X, either from xenial-proposed or "sudo snap refresh --candidate ubuntu-core"
[16:49] <mvo> stokachu: with either one of those the next snap --version output should be higher
[16:49] <stokachu> mvo, ah that is it then
[16:49] <stokachu> yea we're both on 2.21 still
[16:50] <mvo> stokachu: aha, ok. the journal output for snapd from the broken system should have hints what went wrong. i need to leave for dinner now but you can mail it to me at mvo (at) ubuntu.com
[16:51] <mvo> and I have a look (or I will read scrollback when I return :)
[16:51] <stokachu> mvo, sure ill get another system going
[16:53] <test__> ping elopio: test from quassel-webserver snap
[17:04] <stokachu> mvo, https://gist.github.com/battlemidget/e55498a759f14b865c2bfe1e410a022c thats where i ended up at
[17:08] <mvo> stokachu: thanks, lets talk tomorrow but I think snapd 2.22.X will fix it automatically for you
[17:08]  * mvo waves and leaves for dinner
[17:08] <mup> PR snapcraft#1108 opened: Add support for LTS Channels <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1108>
[17:09] <stokachu> yea installing snapd 2.22 from proposed cleaned up my core snaps without an issue
[17:09] <stokachu> doh he left already
[17:16] <cory_fu> I released my snap to the stable channel a couple of hours ago, but still can't install it.  Re-released via snapcraft per the docs and it still doesn't work.  http://pastebin.ubuntu.com/23942129/  Any suggestions?
[17:17] <ogra_> cory_fu, did you check on the store page ?
[17:18] <cory_fu> ogra_: I originally released it via https://myapps.developer.ubuntu.com/dev/click-apps/6876/ and it still says that it's published
[17:18] <ogra_> and it is published in the stable channel ?
[17:18] <cory_fu> ogra_: Yes (see pastebin)
[17:19] <cory_fu> ogra_: NB: it is a classic snap, if that makes a difference
[17:19] <ogra_> oh, it surely does ... i think classic snaps need manual approval in the sotre
[17:19] <ogra_> *store
[17:19] <cory_fu> ogra_: It was approved by jdstrand
[17:20] <mhall119> jdstrand: browser-support is triggering a manual review for a daemin app, I believe I needed it for NodeJS (or somethingJS) that's used by the daemon
[17:20] <mhall119> is there a security concern about allowing that interface for daemons without review?
[17:21]  * mhall119 thinking back, I believe it wasn't NodeJS itself, but something else couchdb does with js, so maybe there aren't that many cases where this will happen
[17:36] <cory_fu> ogra_: Any other advice?  :/
[17:36] <ogra_> cory_fu, well, if the version shows a green box in the UI and you have a channel listed in the details of the version then i dont know
[17:42] <cory_fu> ogra_: Oh, I figured it out!  I had only released the ppc64el version that had managed to successfully build on LP, so it wasn't showing up for me due to arch mismatch
[17:42] <ogra_> aha !
[17:42] <ogra_> yeah, i see it :)
[17:43] <ogra_> congrats !
[17:43] <cory_fu> ogra_: Thanks, and thanks for your help
[17:43] <ogra_> the store UI is an adventure game at times :)
[17:44] <cory_fu> :)  It told me the info I needed, but it just wasn't very prominent
[17:44] <ogra_> yep
[18:02] <mup> PR snapcraft#1109 opened: LP #1662240 (define post-stop-command) <Created by elespike> <https://github.com/snapcore/snapcraft/pull/1109>
[18:06] <jdstrand> mhall119: note, this is a warning, not an error (no difference for human review of course). the browser-support interface is a transitional interface for full-on web browsers (eg, chrome, firefox, webbrowser-app, etc) and it would be unusual for a server to embed a complete web browser. can you remove 'browser-support' and show me the denials?
[18:17] <mup> PR snapcraft#1107 closed: meta: correct the deprecation for `setup/gui` use <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1107>
[18:22] <jdstrand> mterry: ok, all revisions with only slots: mir are approved but not released
[18:22] <jdstrand> (and the other rejected)
[18:23] <mhall119> jdstrand: = Seccomp =
[18:23] <mhall119> Time: Feb  6 13:22:11
[18:23] <mhall119> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=32209 comm="couchjs" exe="/snap/couchdb/x15/rel/couchdb/bin/couchjs" sig=31 arch=c000003e 141(setpriority) compat=0 ip=0x7f465ca61177 code=0x0
[18:23] <mhall119> Syscall: setpriority
[18:23] <mhall119> Suggestion:
[18:23] <mhall119> * add one of 'browser-support, process-control' to 'plugs'
[18:23] <mterry> jdstrand: I don't think I have access myself to the store page -- will future auto-uploads pass through without the manual review process?
[18:23] <mhall119> fwiw, it's only happening when I try to run couchdb's builtin health check
[18:23] <mterry> jdstrand: (thanks for clearing the queue btw)
[18:24] <jdstrand> mterry: yes. if you want, I think I can press the 'release' button
[18:24] <mterry> jdstrand: sure that saves a rebuild, thanks!
[18:25] <jdstrand> mhall119: use process-control instead, not that 2.23 will have policy that may allow you to drop process-control
[18:25] <jdstrand> s/not/note/
[18:27] <mhall119> thanks jdstrand
[18:28] <linuxhiker> Is there a way to see what platforms a particular snap is available for?
[18:29] <jdstrand> mterry: ok, released all to 'edge'
[18:30] <mterry> cheers
[18:36] <linuxhiker> Would that be a no?:D
[18:41] <mup> PR snapd#2784 closed: image: check kernel/gadget publisher vs model brand, warn on store disconnected snaps  <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2784>
[19:05] <balloons> stokachu, did you see my note about bash completion with your snap?
[19:13] <stokachu> balloons, nah
[19:13] <stokachu> balloons, you get it working?
[19:13] <balloons> stokachu, I couldn't get what you'd check in to build, but I believe it will work with the addition I made
[19:14] <stokachu> balloons, you got a diff or PR for me?
[19:14] <balloons> stokachu, sure. Let me find the repo
[19:17] <stokachu> balloons, if we get this working are we advertising pure snaps for the next release announcement?
[19:17] <balloons> it has my vote stokachu
[19:17] <stokachu> yay
[19:17] <stokachu> balloons, im getting a testsuite done this week too
[19:20] <stokachu> balloons, ill take a diff to whatever is easier for you
[19:20] <stokachu> or just the entire file and ill merge it
[19:21] <balloons> stokachu, basically you are missing the bash completion file for 'juju'. It needs to be named 'juju'
[19:21] <balloons> as that is what it will go looking for. The 2 bins we're shipping (well, one bin for you I guess?) is juju and juju-2
[19:21] <balloons> found the diff
[19:22] <balloons> stokachu, https://pastebin.canonical.com/178372/. You can see I had trouble with the source dump location. But I trust the rest more or less makes sense
[19:22] <balloons> stokachu, essentially cp etc/bash_completion.d/juju-2 $SNAPCRAFT_PART_INSTALL/usr/share/bash-completion/completions/juju
[19:23] <balloons> I *think* that will make it work
[19:24] <stokachu> ah i think i did that earlier
[19:24] <stokachu> lemme double check
[19:26] <stokachu> balloons, building again but i did already do this one min
[19:26] <stokachu> balloons, make sure you're using snapcraft from master
[19:26] <stokachu> just git clone https://github.com/snapcore/snapcraft; and access snapcraft/bin/snapcraft
[19:28] <stokachu> balloons, once you do that then clone https://github.com/conjure-up/conjure-up and try to build again
[19:28] <stokachu> that should work
[19:31] <balloons> stokachu, ahh, the snap/snapcraft is supported now
[19:31] <stokachu> yea
[19:32] <balloons> cool, so I can play more if needed
[19:32] <stokachu> yea im building the latest now and going to test it again
[19:45] <stokachu> balloons, yea that change didnt work either :(
[19:45] <stokachu> no idea what im missing
[19:46] <Blu2> ohmygiraffe update :D
[19:46] <stokachu> anyone else familiar with bash completion inside a snap?
[19:47] <mcphail> stokachu: I've been wondering how to implement that!
[19:47] <stokachu> we copy our files here: https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L63-L65, and source them https://github.com/conjure-up/conjure-up/blob/master/snap/wrappers/juju#L8-L9
[19:47] <stokachu> mcphail, yea we're hitting some kind of issue even after we source the completion
[19:48] <stokachu> mcphail, ^ should give you some kind of idea of how we're doing it if youre curious
[19:48] <stokachu> just doesn't work quite yet
[19:48] <mcphail> stokachu: cheers! I'll have a look
[19:49] <mcphail> stokachu: that way isn't going to work, though, is it? Surely that will just source the completion from the subshell, rather than the shell you're using to call the program?
[19:50] <stokachu> mcphail, ah
[19:50] <stokachu> yea bash completion would need access to the binary and not the wrapper
[19:51] <stokachu> hmmmm, what if i put it in /etc/bash_completions.d/
[19:51] <mcphail> stokachu: completion is done by the shell you use to call the snap. But completion isn't loaded into that shell. You'd need access to a completions directory, as you say
[19:52] <mcphail> (and that isn't allowed, afaik)
[19:52] <stokachu> mcphail, we use a classic snap so maybe we can?
[19:52] <mcphail> stokachu: aah. I haven't looked at classic snaps yet
[19:53] <stokachu> does bash completion have a ENV variable we can alter?
[19:53] <Blu2> I noticed that snaps are not allowed to link to a website using the default browser
[19:53] <stokachu> i couldnt find anything in the docs about it
[19:54] <mcphail> stokachu: you know /etc/bash_completions.d/ is deprecated for all packages anyway?
[19:54] <stokachu> mcphail, ah i do now :)
[19:54] <mcphail> `pkg-config --variable=completionsdir bash-completion
[19:54] <mcphail> should give the up-to-date one
[19:55] <stokachu> ah perfect
[19:55] <stokachu> so we put those completion in that directory now
[19:55] <stokachu> but that's within the snap
[19:56] <mcphail> Yes. Nothing useful is going to see that
[19:57] <stokachu> and there doesn't seem to be a way to make bash completion look in an alternative directory
[19:57] <mcphail> I think there needs to be a hook for completions
[19:58] <balloons> stokachu, I also got the snap built, but it's not providing juju
[19:58] <stokachu> balloons, you gotta run snap alias
[19:59] <stokachu> balloons, and make sure you dont have the deb juju installed otherwise it'll make you think you got it working :)
[19:59] <balloons> stokachu, sorry snap lied: snap list aliases error: no matching snaps installed. Trying again, I suddenly see the aliases for conjure-up and lxd
[19:59] <stokachu> balloons, ah
[20:01] <balloons> stokachu, nothing in /usr/share/bash-completion/completions/
[20:01] <balloons> so the hook didnt work. this is the problem I had
[20:01] <stokachu> balloons, yea they would be in $SNAP/usr/share/bash-completion/completions
[20:01] <balloons> they can't go there. They need to be in the right place
[20:02] <stokachu> so you could try taking out $SNAPCRAFT_PART_INSTALL
[20:02] <stokachu> it'd have to go in a different hook though not the install
[20:03] <stokachu> i think mcphail is correct though there needs to be a hook for it
[20:04] <stokachu> they have to live outside of the snap
[20:04] <stokachu> balloons, we could put it in the hooks/configure script
[20:04] <balloons> stokachu, yes, I was trying in the configure hook
[20:05] <balloons> I thought you were too
[20:05] <stokachu> oh lemme check
[20:05] <stokachu> maybe i did
[20:05] <balloons> I just hit build, I've no idea :p
[20:06] <stokachu> building now i didnt have it in there
[20:10] <stokachu> balloons, pushed a new update to the master branch
[20:10] <stokachu> that copies the files to the hosts system
[20:11] <stokachu> balloons, so that section where it's detecting which juju binary to use
[20:12] <stokachu> balloons, https://github.com/juju/juju/blob/staging/etc/bash_completion.d/juju-2.0#L339-L350
[20:12] <stokachu> balloons, do you need to add the /snap/bin/juju path too?
[20:13] <stokachu> balloons, yea changing the last line's path to /snap/bin/juju makes it all work
[20:14] <balloons> for realz?
[20:14] <stokachu> balloons, yep
[20:14] <balloons> woot
[20:14] <stokachu> balloons, so if you could get the updated completions pushed to branch 2.1 ill rebuild with it all
[20:14] <stokachu> or i can just include it as a file in the snap
[20:15] <stokachu> i can also make a new section and just pull from juju master for the completion stuff
[20:15] <mup> PR snapcraft#1101 closed: misc: consistently use a dash for copyright years <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1101>
[20:16] <balloons> stokachu, hmm, let's have a think
[20:16] <balloons> I need the same for the juju snap
[20:17] <stokachu> balloons, yea
[20:21] <stokachu> balloons, worse case i can do some sed magic to replace /usr/bin/juju with /snap/bin/juju
[20:23] <balloons> stokachu, ok, so it's what I was thinking. We should just add a check for /snap/bin/juju as well
[20:23] <balloons> It checks $gopath as well for example
[20:25] <stokachu> balloons, yea
[20:26] <mup> PR snapd#2789 closed: overlord/devicestate: backoff between retries if the server seems to have refused the serial-request <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2789>
[20:28] <balloons> stokachu, awesome. So we have a complete snap story then?
[20:28] <stokachu> balloons, yep just as soon as you update the bash completion in the upstream code
[20:28] <stokachu> i can pull that down and install it
[20:28] <balloons> I'll make a PR with it and the tweaked snap
[20:29] <stokachu> balloons, cool once that lands we'll be in good shape
[20:29] <balloons> stokachu, did you push what worked for you for conjure-up?
[20:29] <stokachu> ill create a seperate section to pull from master for it as well unless you think it'll make it into the beta5 branch?
[20:29] <stokachu> balloons, yea thats pushed upstream
[20:30] <mcphail> stokachu: you got it working?
[20:30] <stokachu> mcphail, yea, basically what you said we had to put it in the hooks/configure in the snap build
[20:30] <stokachu> and install it to /usr/share/bash../
[20:31] <mcphail> stokachu: aah. Is tehre any way to clean it up if the snap is removed? Thinking we really do need some form of hook
[20:33] <stokachu> mcphail, unfortunately there isn't a cleanup hook for snaps, it has been asked a few times to incorporate that so i think that discussion is ongoing
[20:33] <stokachu> a uninstall hook would be nice
[20:33] <stokachu> i think the fear is making building snaps to complicated by going down that road
[20:33] <mcphail> stokachu: shame. Would be nice to have that. I'll need to check out these classic snaps. Seems to give more freedom
[20:34] <stokachu> mcphail, yea tons of freedom though at a cost like what you see here
[20:34] <mcphail> Ideally, it would be good to have a hook to deal with completions/man pages etc
[20:35] <stokachu> mcphail, so i think mayb esomething like https://github.com/snapcore/snapd/wiki/Content-Interface
[20:36] <stokachu> though i don tknow if that addresses the issue of putting it outside the $SNAP
[20:39] <mcphail> stokachu: Don't think that is a complete solution, but is certainly a start. Would be interesting to have a virtual filesystem overlaid on the completions directory which would give access to these slots
[20:40] <stokachu> that would be cool
[20:41] <stokachu> balloons, ping me when you get a pr up so i can subscribe to it
[21:02] <Fohlen> heya there. I have an application that builds a binary folder with plenty of assets it as well needs to start the executable in the bin* folder. I didn't yet understand how am I supposed to copy the folder from my parts into the stage and the command does not ship a make install command
[21:03] <mup> PR snapd#2794 opened: tests/lib/fakestore/refresh: some more info when we fail to copy asserts <Created by pedronis> <https://github.com/snapcore/snapd/pull/2794>
[21:04] <qengho> Fohlen: Hi! Is the build system unique?
[21:05] <Fohlen> qengho: it's conan
[21:05] <Fohlen> and produces cmake in the end
[21:05] <Fohlen> https://www.conan.io/
[21:05] <qengho> Ah, I know cmake.
[21:05] <Fohlen> basically what I would like snap to do is copy the bin folder and make it executable
[21:07] <qengho> Fohlen: Put your snapcraft.yaml in a pastebin so we can see. Someone, perhaps not me, might have an idea what you need to do.
[21:08] <Fohlen> http://pastebin.com/HEb3z1Sv
[21:12] <mup> PR snapcraft#1110 opened: Show error messages for snap processing errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1110>
[21:15] <robert_ancell> Is ./run_checks no longer used for snapd? It's reporting bad formatting in master
[21:25] <qengho> Fohlen: Hi. First, you probably don't need your "stage-packages" as staged packages, because those are ones that go into your snap. You only need most of those for building. That's a different object, "build-packages:", I think.
[21:26] <qengho> Fohlen: Then, your filesets: object doesn't do anything. That just gives some things a name "binaries", and you don't use that name anywhere.
[21:30] <Fohlen> qengho: http://pastebin.com/Dfebej1d
[21:30] <Fohlen> trying this now.
[21:39] <mup> PR snapd#2795 opened: Only add aliases field when we have aliases <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2795>
[21:48] <mup> PR snapd#2794 closed: tests/lib/fakestore/refresh: some more info when we fail to copy asserts <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2794>
[21:48] <oky> which org is behind snapcraft, btw?
[21:49] <oky> is it canonical? what is yocto?
[21:51] <mup> PR snapcraft#1111 opened: tests: rename the waf test snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1111>
[22:21] <kyrofa> oky, indeed, canonical is behind snapcraft
[22:27] <oky> kyrofa: ok, interesting. is there a discussion of the potential downsides of snapcraft that i can refer to? just things to know before i use it
[22:27] <oky> (common pitfalls would be useful, too)
[22:28] <kyrofa> oky, all the docs are on snapcraft.io
[22:28] <oky> i think i've read a lot of them, curious to find things like project philosophy and motivation
[22:28] <oky> (i do see snapping philosophy doc, don't worry)
[22:29] <kyrofa> oky, perhaps its README would be helpful? https://github.com/snapcore/snapcraft
[22:30] <oky> kyrofa: it is, yes - but it seems like perhaps there were a lot of design docs or internal discussion that
[22:30] <oky> is unavailable
[22:31] <kyrofa> oky, I'm not really sure what you're looking for then, I'm sorry
[22:32] <oky> kyrofa: things like: "what is current support on other distributions", "what are potential downsides of using snaps", "how do pin a snap to a specific version", "who is doing the vetting"
[22:32] <kyrofa> oky, snapcraft is only a packager of snaps. It sounds like you're looking for the philosophies behind snaps themselves
[22:32] <oky> i really like what i am seeing about snaps, they appear to be recipes that create statically installable packages akin to .dmg files
[22:32] <oky> kyrofa: yes, that must be it
[22:33] <kyrofa> That's like expecting pbuilder to document the rational behind the deb format
[22:33] <oky> kyrofa: so, there's a seperate site for docs on snaps?
[22:33] <oky> kyrofa: i'm not blaming or accusing, just looking for more info - and yes, i am confused about the two names. i've seen snappy, snap, snapd and snapcraft. the only docs i've read are the snapcraft ones
[22:34] <kyrofa> oky, there isn't one place that answers all your questions, but I can point you in a few different directions to obtain answers
[22:34] <oky> kyrofa: thanks!
[22:35] <kyrofa> oky, first of all, the current distro support matrix is here: https://github.com/snapcore/snapd/wiki/Distributions
[22:36] <mup> PR snapcraft#1112 opened: core: setup core to support classic confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1112>
[22:36] <kyrofa> oky, as far as potential downsides, there are a few AskUbuntu questions about them but the answer is really opinion-based
[22:37] <kyrofa> oky, there are a few downsides I can list off: dependencies are bundled so they tend to be larger than, say, a deb would be. Developing them can be a little different because, as you noted, they are read-only images with defined writable areas and not all software is used to working that way
[22:39] <kyrofa> I'm not sure pinning is supported, but there are some features coming that will get you closer
[22:39] <kyrofa> As far as who is doing the vetting, I'm not quite sure I understand the question
[22:40] <oky> kyrofa: the concern with 'pinning' is regarding having a set of packagers with expertise vetting their work vs. anyone self publishing. with packagers, its a little more assured that new version should not break things, but self publishing leads to weirdness with deps between parts, etc
[22:40] <kyrofa> oky, there are no dependencies with snaps, at least not in that sense
[22:40] <oky> pinning (or custom repos) appears to be a compromise to sticking to a specific version (and having that version available at some later data, ideally), which is why i asked about it
[22:41] <oky> kyrofa: even if there are no direct deps or compile time, there inevitably will be deps or linked packages (imo)
[22:41] <kyrofa> oky, of course, but they're contained within the same snap
[22:41] <oky> kyrofa: interesting, ok - so, the store would have many different versions for each package depending on the config desired
[22:42] <oky> kyrofa: thanks for taking the time
[22:43] <kyrofa> oky, that depends on the package I suppose
[22:43] <kyrofa> oky, for example, there's a Nextcloud snap that bundles mysql and apache. There is _not_ a nextcloud snap that uses nginx instead
[22:44] <kyrofa> Nothing is stopping that, but nextcloud only supports that one setup
[22:44] <oky> kyrofa: i'm thinking of an example more like: package + data dependencies. maybe there is a package of geoip data and you can buy addon packs
[22:45] <oky> anyways, it's all tangential - not that important to my other questions
[22:46] <kyrofa> oky, that's probably a use-case for the (very limited) sharing that can happen between snaps. That's called the `content` interface
[22:46] <oky> it seems like the snaps should ideally prevent lots of bugs and make it so that security flaws in out dated libraries are still contained in what damage they can do
[22:46] <kyrofa> Indeed
[22:46] <oky> so in the end, its still an improvement in security (maybe)
[22:46] <kyrofa> That's the idea anyway
[22:47] <oky> i was trying to imagine what happens when the next large networking bug comes along and threatens a bunch of packages
[22:50] <kyrofa> oky, well, let's walk through that using the Nextcloud example
[22:51] <kyrofa> oky, let's say the bug was so bad as to grant a shell with the Apache permissions
[22:51] <bdmurray> lsb_release crashes on Ubuntu Core 16 - where should that be reported?
[22:51] <kyrofa> Which is pretty much as bad as it can get
[22:51] <kyrofa> What happens?
[22:52] <bdmurray> http://pastebin.ubuntu.com/23944029/
[22:52] <oky> kyrofa: how does nextcloud enforce that the user is 'apache' user?
[22:52] <oky> i'm looking through https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml to see how they manage permissions
[22:52] <kyrofa> oky, nope, it's root
[22:53] <kyrofa> oky, however, even though it's root it's still under confinement
[22:53] <kyrofa> oky, which means they can access the network and the writable areas of the snap
[22:53] <kyrofa> oky, they can't alter anything contained within the snap because it's by definition read-only
[22:53] <oky> kyrofa: and the confinement is via SElinux? ima? app armor?
[22:54] <kyrofa> appamor, seccomp, and cgroups
[22:54] <kyrofa> oky, the worst they can do is mess with the data of the nextcloud snap. They can't touch the rest of the system
[22:57] <kyrofa> oky, and there's nothing they can do to prevent the next snap update from happening, which would hopefully contain a fix
[22:57] <oky> kyrofa: and does app armor support integrity checks via hardware? (TPM, for example)
[22:58] <kyrofa> That I don't know
[22:58] <oky> ok, it's also tangential
[22:58] <mup> PR snapd#2796 opened: Fix checks failing on code formatting <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2796>
[22:59] <kyrofa> oky, also, to clarify terminology: snapd is the daemon behind the snap format. It's in charge of mounting snaps into place, running their services, handling updates, etc
[22:59] <oky> kyrofa: thanks for all the info, i'm looking forward to seeing wider adoption on other platforms
[22:59] <kyrofa> oky, snapcraft is a packager. It allows one to create snaps
[22:59] <kyrofa> oky, "snappy" is just referring to the whole system
[22:59] <oky> kyrofa: ok, i'll try to remember their distinct usages
[23:18] <mup> Bug #1662357 opened: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):New> <https://launchpad.net/bugs/1662357>
[23:30] <mup> PR snapcraft#1111 closed: tests: rename the waf test snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1111>