[01:10] <titan_king> Hello, anybody tried installing snappy in Fedora?
[01:12] <titan_king> The copr repo for feodra , Zyngacore/snapcraft does not work
[04:58] <Rumple> What's the deal with --classic snaps on the stable branch? Is there any other way to access /sys/ without --classic?
[07:11] <titan_king2> Does snapcraft support Fedora?
[07:12] <titan_king2> The copr seems to be down
[08:01] <pshod> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
[08:01] <pshod> used the pi3 image from here
[08:01] <pshod> cannot get the bluetooth to work
[08:02] <pshod> help help help!
[08:10] <pshod> bluetotooth service not found
[08:10] <pshod> when ran systemctl bluetooth status
[08:10] <mup> PR snapd#2975 closed: overlord/snapstate: small cleanup of ensureForceDevmodeDropsDevmodeFromState <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2975>
[09:26] <mup> PR snapd#2951 closed: interfaces: use seccomp specs <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2951>
[09:35] <pshod> running core on pi3
[09:35] <pshod> unable to get the bluetooth working
[09:35] <pshod> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
[09:35] <pshod> using the img from here.
[09:35] <pshod> help!
=== JamesTait is now known as Guest83668
=== Guest83668 is now known as JamesTait
=== gbisson_ is now known as gbisson
[09:55] <soffokl_> Hello everyone. Can someone point me to the description of installation Ubuntu Core on Google Compute Engine?
[09:56] <soffokl_> Is it really possible to make such installation?
[09:57] <soffokl_> On AWS EC2 found image ubuntu-core16, but failed to find something similar on GCE :(
[10:05] <mup> PR snapd#2984 opened: interfaces: seccomp test helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/2984>
[10:19] <pshod> how to load a service in core env?
[10:19] <pshod> installed classic env in it
[10:19] <kalikiana_> soffokl_: Unfortunately the instructions that existed seem to have disappeared from the snappy websites. But you can use a custom image.
[10:20] <kalikiana_> (There was https://www.ubuntu.com/desktop/snappy#snappy-google in a previous iteration)
[11:28] <pshod> NEED TO MAKE BLUETOOTH WORK ON CORE NOW!
[11:28] <pshod> help help help!
[11:31] <mup> PR snapd#2985 opened: hookstate: disable configure hook for core on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/2985>
[12:03] <caribou> Hello, what is the best approach to copy a file from the parts/{part}/build directory to the parts/{part}/install directory using an install scriptlet ?
[12:04] <caribou> I wanted to use the $SNAPCRAFT_PART_INSTALL as a target but I can't figure out if there is the equivalent source environment variable
=== hikiko is now known as hikiko|ln
[12:21] <caribou> nevermind, found it
[13:01] <popey> caribou: i use "cp -a * $SNAPCRAFT_PART_INSTALL" in my scriptlet, what did you decide on?
=== hikiko|ln is now known as hikiko
[13:16] <Son_Goku> is zyga back from the grave yet?
[13:17] <Son_Goku> mvo: hey, the 2.23 release tag doesn't match what you did last week
[13:17] <Son_Goku> it's way older
[13:26] <cachio> jdstrand, hi
[13:30] <Son_Goku> mvo: please fix, because there's tons of stuff missing in the 2.23 download I get from GitHub :(
[13:31] <mvo> Son_Goku: in a meeting right now, but what is going wrong?
[13:31] <Son_Goku> mvo: the 2.23 tag published on GitHub is invalid
[13:31] <mvo> Son_Goku: I check in a little bit
[13:31] <Son_Goku> it's over two weeks old
[13:31] <Son_Goku> whereas you just committed 2.23 a few days ago
[13:32] <Son_Goku> so things like my SELinux policy and whatnot are missing
[13:32] <mvo> Son_Goku: yes, definitely wrong, sorry for that, let me fix
[13:32] <Son_Goku> as well as all of zyga's merged fixes for CentOS/Fedora
[13:34] <mvo> Son_Goku: sorry for that! please checkout 2.23 again
[13:36] <Son_Goku> mvo: yay, thanks
[13:36] <Son_Goku> looks right now
[13:36] <Son_Goku> mvo: is the vendored tarball supposed to have an inner directory "snappy.upstream"?
[13:36] <Son_Goku> I would have figured it'd be snapd-2.23
[13:37] <mvo> Son_Goku: yeah, its an artifcat of the way dpkg-buildpackage did it, I really should fix that, can do after the meeting :)
[13:37] <Son_Goku> mvo: do you know when zyga will get back?
[13:38] <mvo> Son_Goku: I think 2 more days
[13:38] <Son_Goku> okay, thanks
[13:38] <Rumple> What's the deal with --classic snaps on the stable branch? Is there any other way to access /sys/ without --classic?
[13:44] <didrocks> cjwatson: hey! it seems that all my npm install --global are failing in launchpad (while they do pass on my machine). Can be that I have some in a local cache, but I don't know if there can be some proxy issue IS-side. (https://launchpadlibrarian.net/309867959/buildlog_snap_ubuntu_xenial_amd64_chuck-norris-webserver_BUILDING.txt.gz) (Note that the same package did build successfully on the 27th FYI)
[13:45] <cjwatson> (the snap proxy isn't IS-side)
[13:46] <didrocks> ah ok :)
[13:46] <cjwatson> didrocks: I dunno, a chmod ENOENT doesn't seem very snap proxy-ish, and it does manage to download other files
[13:46] <cjwatson> have you tried snapcraft cleanbuild?
[13:47] <didrocks> cjwatson: sorry, yeah, I didn't scroll high enough, I was stuck in the "npm install"
[13:47] <didrocks> cjwatson: it's probably my side, need to try in cleanbuild, I always forget about this option as my lxd container was broken for a while. Sorry to have bothered you :)
[13:48] <cjwatson> np - let me know if you still can't get it to work, but it looks more likely to be a bug in the package's build system to me
[13:49] <didrocks> cjwatson: agreed
[13:53] <mvo> Son_Goku: should be fixed now
[14:06] <jdstrand> cachio: hey
[14:07] <cachio> jdstrand, I was creating some performance tests for dbus
[14:07] <cachio> jdstrand, trying to validate dbus performance, then I found something interesting
[14:08] <cachio> jdstrand, I created some scripts in python and one snap which is running these scripts
[14:08] <cachio> when I run the python scripts I get about 50% more of performance compared with the snap execution
[14:09] <cachio> both are executing the same scripts
[14:09] <Son_Goku> mvo: much better :D
[14:09] <jdstrand> cachio: this is testing the performance of starting a script?
[14:10] <cachio> jdstrand, no, it is measuring the bandwidth when I sent 20k signals
[14:11] <cachio> jdstrand, I is creating a client and a server and the client is creating the signals and the server is counting all the signals that are arriving to the specific address
[14:11] <jdstrand> cachio: did you factor out the startup cost of starting the snap command?
[14:12] <cachio> jdstrand, no, how can I do that?
[14:13] <cachio> I am not sure if I should
[14:13] <cachio> because the test start when the first message arrives to the server
[14:14] <cachio> the server is getting metrics from the first message to the last
[14:15] <caribou> popey: well, I just realized that the file I had to copy was in the . directory so cp sos.conf $SNAPCRAFT_PART_INSTALL/etc did the trick
[14:15] <jdstrand> cachio: I'm asking all this for two reasons. 1) tyhicks did extensive testing of dbus performance with the apparmor patches and found performed extremely well for normal and beyond use cases and 2) launching a snap command is not lightwight-- there is ipc to snapd involved, an exec(), reading several files, setting up a seccomp filter, setting up namespaces, etc, etc, then another exec()
[14:16] <jdstrand> cachio: ok, so if the test is first message to last, that should be ok. if it includes time to get to first message, then it is measuring too much
[14:17] <jdstrand> cachio: I don't know your test, but if it is waiting for the first message and that appears in the results, a simple way to adjust that would be to starting your timing on the 2nd message
[14:18] <jdstrand> cachio: and to be clear-- your test is a) start command b) send messages c) stop command and *not* a) start command b) send message c) stop command d) goto 'a'
[14:19] <cachio> jdstrand, the tests are:
[14:20] <mup> Bug #1670371 opened: Configure hook breaks content interface plug <Snappy:New> <https://launchpad.net/bugs/1670371>
=== fnordahl_ is now known as fnordahl
[14:20] <cachio> 1- start command  in parallel(2- spammer will send x signals 3- handler will receive those signals and report metrics) 3- stop command
[14:21] <cachio> jdstrand, so the start should not interfere in the tests results
[14:23] <caribou> oops, I think I may have run into a bug with the --classic confinement :
[14:23] <jdstrand> cachio: to be 100% sure, we can avoid the launcher and isolate apparmor
[14:23] <caribou> if I run the cmd, it appends the same argument over and over (see http://pastebin.ubuntu.com/24124987/)
[14:24] <caribou> I don't get that in --devmode
[14:24] <jdstrand> cachio: you can do: aa-exec <name of profile> -- /path/to/script <args>
[14:24] <cachio> jdstrand, sure
[14:24] <jdstrand> cachio: aa-exec is sufficiently lightweight to not skew the results. <name of profile> would be snap.name.command
[14:25] <caribou> could be tied to a denied AppArmor profile request to rw on /dev/tty
[14:25] <jdstrand> cachio: and also to be 100% clear-- you comparisons are all on the same machine, correct?
[14:26] <cachio> jdstrand, yes
[14:26] <cachio> real hardware
[14:27] <jdstrand> caribou: the /dev/tty denial is likely harmless, but you can add '/dev/tty rw,' to /var/lib/snapd/apparmor/profiles/nap.your.profile and reload with 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/nap.your.profile'
[14:27] <jdstrand> er, snap.your.profile
[14:28] <caribou> jdstrand: yeah, was reading on of your comment on a previous bug
[14:28] <caribou> jdstrand: so might not be tied to the CLI option repeating itself forever like the pastebin shows
[14:28] <caribou> jdstrand: let me try that first
[14:29] <jdstrand> caribou: it wouldn't be impossible that it is tied to it, would just be surprised
[14:30] <caribou> jdstrand: looks quite similar to LP: #1664427
[14:30] <mup> Bug #1664427: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:Incomplete> <https://launchpad.net/bugs/1664427>
[14:31] <jdstrand> cachio: fyi, the tests tyhicks did were several years ago, and it was a similar test iirc (he would have the details)-- thousands and thousands in a short time span. iirc it was around 1% overhead, but I could be making that up
[14:34] <caribou> jdstrand: well, it's the snap-confine profile that rejects it
[14:34] <jdstrand> caribou: ah, well, then yes, add it there
[14:35] <jdstrand> caribou: but, are you running from your snap a command in /snap/bin?
[14:35] <jdstrand> caribou: cause that is allowed in classic but not devmode or strict
[14:36] <jdstrand> caribou: I also think that is the problem in bug #1664427
[14:36] <mup> Bug #1664427: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:Incomplete> <https://launchpad.net/bugs/1664427>
[14:36] <caribou> jdstrand: well, that's a python script I just invoke it as "command: sosreport"
[14:37] <caribou> jdstrand: and that's the classic mode that is failing, not devmode
[14:39] <mup> PR snapd#2986 opened: tests: specify the core version to be unsquashfs'ed in the failover tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2986>
[14:39] <jdstrand> oh right, 1664427 was also with classic. any way, feel free to add that rule to /etc/apparmor.d/usr.lib.snapd.snap-confine. I suspect it won't fix the issue
[14:43] <cachio> jdstrand, http://paste.ubuntu.com/24125055/
[14:44] <cachio> jdstrand, I ran in my machine the tests, using aa-exec, running the snap command and running python
[14:45] <cachio> I see like a 20% of difference if yo usee the metric 'messages_sec'
[14:46] <caribou> jdstrand: you're right, has nothing to do with it
[14:47] <jdstrand> cachio: at this point I'm going to point you at tyhicks for historical context. he may bounce it back to me
[14:47] <jdstrand> cachio: he should be online in a few minutes
[14:51] <cachio> jdstrand, sure, tx
[14:55] <popey> jdstrand: you just rejected my ffscreencast snap - can I point you to https://bugs.launchpad.net/snapcraft/+bug/1670162 ? I don't believe it needs a .desktop file.
[14:55] <mup> Bug #1670162: publish complains about desktop file un-necessarily <Canonical Click Reviewers tools:New> <Snapcraft:Triaged> <Software Center Agent:New> <https://launchpad.net/bugs/1670162>
=== cachio is now known as cachio_lunch
[14:56] <jdstrand> popey: if it is a cli tool, why does it need x11?
[14:57] <popey> jdstrand: it's a screen capture tool.
[14:57] <popey> uses x11 utils etc
[14:59] <cjwatson> kyrofa: snap proxy timeout is now two hours rather than one
[15:03] <mup> PR snapd#2592 closed: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592>
[15:04] <jdstrand> popey: can you request for manual review?
[15:05] <mup> Bug #1670384 opened: refresh to same revision yields broken SNAP_USER_DIR <Snappy:New> <https://launchpad.net/bugs/1670384>
[15:12] <popey> jdstrand: done
[15:16] <mup> PR snapd#2987 opened: store: download from authenticated URL if there is a device session set <Created by matiasb> <https://github.com/snapcore/snapd/pull/2987>
[15:29] <mup> Bug #1670397 opened: On Debian Stretch (9) /snap/bin is not added to path <Snappy:New> <https://launchpad.net/bugs/1670397>
[15:33] <popey> thanks jdstrand
[15:52] <tyhicks> hi cachio
[15:52] <tyhicks> cachio: I'm not sure if I still have my old performance testing data
[15:53] <jdstrand> pmcgowan: hey, do you have a branch with snapcraft.yaml for your webdemo snap?
[15:53] <tyhicks> cachio: what does messages_sec represent?
[15:54] <pmcgowan> jdstrand, I do, I havent pushed the latest but could
[15:54] <pmcgowan> jdstrand, which bug you interested in
[15:55] <mup> PR snapd#2980 closed: client, daemon: move "snap list" name filtering into snapd <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2980>
[15:56] <barry> i'm trying to build a snap out of only ubuntu packages (mostly a custom command around nmap).  i'm running into trouble with missing shared libraries.  is there some snapcraft plugin that would automatically include dependent libraries or do i have to code that up myself?  i was thinking an 'apt' plugin might be nice for use cases like that
[15:57] <jdstrand> pmcgowan: the denials included in bug #1667480
[15:57] <mup> Bug #1667480: browser-support needs to be an implicit interface, not implicit classic <snapd-interface> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1667480>
[15:58] <jdstrand> pmcgowan: I fixed all of those already, but then I was wanting to test on dragonboard and saw some other stuff I want to investigate
[15:58] <jdstrand> pmcgowan: I have r19 from the store
[15:59] <pmcgowan> ok the last branch is ok then, https://code.launchpad.net/~pat-mcgowan/+junk/webdemo
[15:59] <pmcgowan> jdstrand, ^
[16:00] <jdstrand> pmcgowan: thanks!
=== JamesTait is now known as Guest7558
=== cachio_lunch is now known as cachio
[16:14] <mup> Bug #1670397 changed: On Debian Stretch (9) /snap/bin is not added to path <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1670397>
[16:18] <tyhicks> cachio: I found my old benchmarks
[16:18] <tyhicks> cachio: they were done on a nexus 7 phone
[16:19] <tyhicks> cachio: at that time, the focus was click confinement and we expected that the common case would be a confined click application (client) talking to an unconfined trusted helper (daemon/service)
[16:19] <tyhicks> cachio: measured overhead using the dbus-ping-pong test was steady at about 10%
[16:20] <tyhicks> cachio: it sounds like you're confining both the client and the server in your benchmarks so that may explain the additional overhead
[16:21] <cachio> tyhicks, in some machines I got the 50% of overhead
[16:21] <cachio> tyhicks, i am not sure it is known
[16:22] <cachio> I mean, if this overhead is what you expect or it is so much
[16:23] <cachio> tyhicks, do you want to see the test code?
[16:23] <cachio> just to verify the tests are ok ¡
[16:23] <cachio> ifconfig
[16:24] <tyhicks> cachio: yes, please share the test code with me
[16:24] <tyhicks> cachio: 50% overhead should definitely not be happening
[16:25] <tyhicks> cachio: I landed that code years ago and haven't been involved since so something may have changed
[16:25] <cachio> tyhicks, http://paste.ubuntu.com/24125526/
[16:25] <cachio> I have a snap here
[16:25] <cachio> http://bazaar.launchpad.net/~sergio-j-cazzolato/ubuntu-performance-tests/trunk/files/head:/resources/apps/kpi-dbus-tests/
[16:25] <cachio> tyhicks, the snap uses these py files
[16:26] <cachio> tyhicks, the I run the tests running python3 <script> <params> and through the snap
[16:27] <cachio> if you want to install the snap it is stored in edge
[16:29] <tyhicks> cachio: thanks - I have to run off to a meeting now but will try take a closer look by tomorrow
[16:30] <cachio> tyhicks, sure
[16:30] <tyhicks> cachio: is this just something interesting that you noticed or is there a real world snap that is affected by the performance?
[16:32] <cachio> thibautr__, well I did similar tests for python code and external libraries, to see if the confinment was affecting its performance, and in that case the results are pretty similar running with and without confinment
[16:32] <cachio> tyhicks,  well I did similar tests for python code and external libraries, to see if the confinment was affecting its performance, and in that case the results are pretty similar running with and without confinment
[16:33] <timothy> hi, why did you MOVED a git tag? =.=
[16:33] <cachio> tyhicks, so I am trying to measure and detect where the performance is degraded
[16:35] <tyhicks> cachio: got it - I think you've narrowed in on it and, to some point, the degradation is expected
[16:35] <tyhicks> cachio: we just want to make sure that the degradation is still within the acceptable bounds
[16:36] <cachio> tyhicks, exactly
[16:36] <timothy> the "new" tag of release 2.23 is not releaseable on archlinux :(
[16:36] <timothy> since we don't have libcap static
[16:37] <timothy> neither fedora
[16:48] <BjornT> hi. could someone please unblock my snap bjornt-prometheus-node-exporter? it says it's pending review
[16:59] <kyrofa> timothy, that might be worth a mailing list post
[17:04] <mup> PR snapd#2988 opened: tests: do *not* nuke the entire /etc/systemd/system/snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/2988>
=== Guest7558 is now known as JamesTait
[17:37] <Pharaoh_Atem> timothy: the tag was a mistake and should have been deleted weeks ago
[17:37] <Pharaoh_Atem> it was just fixed this morning
[18:06] <mup> PR snapd#2988 closed: tests: do *not* nuke the entire /etc/systemd/system/snapd.conf.d dir when changing store settings <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2988>
[18:41] <cholcombe> so i'm building a Go snap for the first time and it's complaining about some package context stuff
[18:43] <cholcombe> http://paste.ubuntu.com/24126216/
[18:43] <cholcombe> i have no idea what i'm doing :) any help is appreciated
[18:53] <kyrofa> cholcombe, looks like it's coming from the vendored gorilla
[18:54] <kyrofa> cholcombe, are you using godep?
[18:55] <kyrofa> cholcombe, because it looks like it wants you to use a Makefile
[18:56] <kyrofa> cholcombe, maybe one of their standalone tarballs would be better: https://github.com/heketi/heketi/wiki/Standalone-Installation
[19:05] <cholcombe> kyrofa: hmm ok
[19:05] <cholcombe> yeah i saw that Makefile
[19:06] <cholcombe> they've got a dockerfile also that i can follow
[19:06] <cholcombe> kyrofa: no i wasn't using godep.  let me paste my snapcraft file
[19:07] <cholcombe> kyrofa: http://paste.ubuntu.com/24126310/
[19:07] <kyrofa> cholcombe, yeah I suggest you follow their README and wiki for installation guides
[19:08] <cholcombe> kyrofa: not a good candidate for a snap?
[19:08] <kyrofa> cholcombe, not necessarily, just saying you're not building it in a manner they suggest
[19:08] <cholcombe> sure
[19:09] <kyrofa> cholcombe, nowhere do they say `go get` will work
[19:09] <cholcombe> that's true
[19:09] <kyrofa> The fact that they use a Makefile typically implies to me that `go get` will _not_ work
[19:09] <cholcombe> the docker file does a go get it looks like
[19:09] <cholcombe> ok
[19:09] <cholcombe> kyrofa: https://hub.docker.com/r/heketi/heketi/~/dockerfile/
[19:10] <cholcombe> if i remember correctly this is just a gluster CLI wrapper
[19:10] <kyrofa> cholcombe, they're go-getting godep; they clone heketi
[19:10] <cholcombe> oh yeah i see it.  they call make
[19:11] <cholcombe> crap
[19:11] <kyrofa> cholcombe, welcome to go
[19:11]  * kyrofa runs
[19:11] <cholcombe> i heard it was a mess
[19:11] <kyrofa> Yeah, not my favorite
[19:12] <cholcombe> that reminds me.  i wonder if that snapcraft release has been made that allows you to install a snap to build a snap
[19:14] <jdstrand> ogra_: hey, so I installed 'classic' on the dragonboard, but apt-get update gives me: http://paste.ubuntu.com/24126359/
[19:15] <jdstrand> ogra_: apt-key and gnupg are present. I can kinda workaround this by using 'sudo apt-get -o APT::Sandbox::User=root ...' but that is icky. is this known?
[19:24] <kyrofa> jdstrand, what revision of the core snap was used when `sudo classic` was first run?
[19:24] <jdstrand> r397
[19:24] <jdstrand> that's too low
[19:24] <jdstrand> hmm
[19:25] <kyrofa> That seems super old...
[19:25] <kyrofa> 1337 is stable amd64, I'd expect a number closer to that
[19:25] <jdstrand> yeah. I though I snap refershed
[19:25] <jdstrand> thought*
[19:25] <jdstrand> $ sudo snap refresh
[19:25] <jdstrand> All snaps up to date.
[19:25] <kyrofa> ...
[19:26]  * kyrofa fires up my dragonboard
[19:26] <jdstrand> $ sudo snap refresh core --stable
[19:26] <jdstrand> that pulled down 1268
[19:26] <jdstrand> weird
[19:26] <kyrofa> Oh, dang. That seems like a bug
[19:27] <kyrofa> Unless you were on a channel that for some reason never was updated?
[19:28] <jdstrand> I just pulled it down from cdimage based on https://developer.ubuntu.com/core/get-started/dragonboard-410c
[19:28] <jdstrand> and it didn't update automatically
[19:29] <kyrofa> Huh... weird
[19:29] <jdstrand> indeed
[19:29] <kyrofa> That might be worth trying again
[19:29] <jdstrand> well, I'm updated now
[19:29] <kyrofa> Hahaha
[19:29] <kyrofa> I just mean to figure out if there's a bug there
[19:30] <kyrofa> If you have time
[19:30] <jdstrand> I've added a todo
[19:47] <jdstrand> kyrofa (cc ogra_): looks like if I upgrade the core snap, then install classic, then install classic from --edge, 'sudo apt-get update' still has an issue. I'll file a bug
[19:47] <kyrofa> jdstrand, after you updated the core snap, you removed the classic snap?
[19:48] <kyrofa> (and then re-installed it)
[19:48] <jdstrand> yep
[19:48] <jdstrand> and it unshashfs'd, etc
[19:48] <kyrofa> Yeah sounds like a bug then
[19:56] <jdstrand> kyrofa (cc ogra_): fyi, https://bugs.launchpad.net/snappy/+bug/1670475
[19:56] <mup> Bug #1670475: apt-secure complaints with classic snap <Snappy:New> <https://launchpad.net/bugs/1670475>
[19:58] <mup> Bug #1670475 opened: apt-secure complaints with classic snap <Snappy:New> <https://launchpad.net/bugs/1670475>
[21:16] <kyrofa> jdstrand, does snap-confine set things up such that the snap is mounted in /snap/<name>/<revision> even if in reality (e.g. fedora) it's not mounted there?
[21:16] <kyrofa> Wow that was a terribly-phrased question
[21:16] <kyrofa> jdstrand, I mean in the snap's execution context, does it appear there even if it isn't actually there on the host?
[21:18] <jdstrand> kyrofa: I've not played with fedora at all. my understanding is that the snap will see a consistent runtime. on fedora, you could install the hello-world snap then do 'hello-world.env|grep SNAP' and see what snapd is exporting
[21:18] <kyrofa> jdstrand, alright. I don't have an install handy, but perhaps Pharaoh_Atem is around?
[21:18] <Pharaoh_Atem> ?
[21:19] <kyrofa> Pharaoh_Atem, snapd doesn't actually mount snaps in /snap on fedora, right?
[21:19] <Pharaoh_Atem> absolutely not
[21:19] <Pharaoh_Atem> it better not
[21:19] <kyrofa> Pharaoh_Atem, does it appear like it from the snap's perspective?
[21:19] <Pharaoh_Atem> it should look like any other snap from the inside
[21:19] <kyrofa> Pharaoh_Atem, any chance you're in a position to install the `hello` snap and run the test jdstrand just suggested?
[21:20] <Pharaoh_Atem> with the latest snapd?
[21:20] <kyrofa> It doesn't have to be latest, but post November would be ideal
[21:21] <jdstrand> kyrofa: it looks like snap confine honors a configure option, SNAP_MOUNT_DIR and so it would *not* be /snap/foo/current/... but instead /wherever/it/is/on/fedora/snap/foo/current
[21:22] <Pharaoh_Atem> latest I've got is snapd 2.16 with snap-confine 1.0.44
[21:22] <Pharaoh_Atem> only started working on getting new snapd working today
[21:22] <Pharaoh_Atem> since mvo tagged it properly today
[21:22] <kyrofa> Pharaoh_Atem, good enough for me if you don't mind
[21:22] <Pharaoh_Atem> sure, give me a sec
[21:22]  * jdstrand isn't sure it is good enough, but I guess we'll see
[21:22] <jdstrand> 1.0.44 is Oct/Nov iirc
[21:23] <kyrofa> jdstrand, yeah that makes sense. I knew that it supported mounting in other areas, my real question is: what does that look like to the snap?
[21:25] <Son_Goku> jdstrand, kyrofa: what do you want me to do?
[21:26] <Son_Goku> I have my Fedora system with snapd 2.16 and snap-confine 1.0.44
[21:26] <kyrofa> Son_Goku, install the `hello` snap, and run `hello.env | grep SNAP` and pastebin the output
[21:27] <jdstrand> it looks like SNAP_MOUNT_DIR is only for finding the core snap. snap-confine builds up the runtime environment from the core snap. I see that it will mount on /snap in the runtime environment but that what is mounted is configrable based on SNAP_MOUNT_DIR
[21:28] <jdstrand> kyrofa: ^
[21:28] <jdstrand> we'll know if my quick read is correct soon enough :)
[21:28] <Son_Goku> hello.env doesn't exist?
[21:28] <Son_Goku> I see hello and hello.universe
[21:28] <kyrofa> Wha...
[21:29] <jdstrand> it's hello-world
[21:29] <kyrofa> jdstrand, oh darnit
[21:29] <kyrofa> Son_Goku, sorry, I lied
[21:29] <kyrofa> Son_Goku, try hello-world :P
[21:30] <Son_Goku> kyrofa, jdstrand: https://paste.fedoraproject.org/paste/idScR6VoZkXLzjq21KyatV5M1UNdIGYhyRLivL9gydE=
[21:31] <kyrofa> Son_Goku, thank you very much :)
[21:31] <Son_Goku> no problem
[21:31] <Son_Goku> also keep in mind that snapd and snap-confine are permanently in devmode
[21:31] <jdstrand> Son_Goku: that is with snap-confine 1.0.44 and snapd 2.16?
[21:31] <Son_Goku> yes
[21:32] <jdstrand> kyrofa: I think newer code will do something different
[21:32] <Son_Goku> sources here: http://pkgs.fedoraproject.org/cgit/rpms/snap-confine.git/tree/
[21:32] <kyrofa> jdstrand, what do you think... too old to be a valid test?
[21:32] <Son_Goku> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/
[21:32] <kyrofa> jdstrand, fair enough
[21:32] <Son_Goku> well, I'm working on snapd 2.23
[21:32] <Son_Goku> without zyga, I have to kinda do it myself :/
[21:32] <kyrofa> Son_Goku, if you get that to a working point, I'd be curious to see the same test if you're able
[21:32] <Son_Goku> sure
[21:33] <jdstrand> kyrofa: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L356
[21:33] <Pharaoh_Atem> back to my workstation
[21:33] <kyrofa> jdstrand, indeed, that does look relevant
[22:05] <erimsa> Hello
[22:06] <kyrofa> Hello erimsa, welcome!
[22:07] <erimsa> I have lots of questions about snappy and ubuntu core
[22:08] <erimsa> but I think it is too new using for a commercial product
[22:08] <kyrofa> erimsa, please ask away :)
[22:08] <erimsa> thanks
[22:09] <erimsa> I want to use it for industrial batch controllers
[22:10] <erimsa> a headless system a webserver in
[22:10] <erimsa> it
[22:10] <kyrofa> Sure
[22:11] <erimsa> First, Can I create a snap package from existing executables ?
[22:11] <kyrofa> erimsa, definitely
[22:11] <kyrofa> erimsa, snaps are just squashfs images. They can contain whatever you like, organized however you like
[22:11] <erimsa> I couldnt find any documentation for that
[22:12] <erimsa> Ahh ok then
[22:12] <kyrofa> erimsa, do you have just a tarball or binaries/libraries, then?
[22:12] <erimsa> Yes, binaries
[22:13] <erimsa> I have to run Codesys "PLC runtime"
[22:13] <nacc> the dump plugin?
[22:13] <erimsa> in Ubuntu Core
[22:13] <erimsa> OK I see
[22:13] <nacc> erimsa: was just a thought, for copying binaries into the snap -- kyrofa knows way more than I :)
[22:14] <kyrofa> nacc, yeah I'm throwing a quick example together using just that
[22:14] <erimsa> You are saying use "dump plugin"
[22:14] <erimsa> for that
[22:14] <kyrofa> erimsa, yeah I'll show you
[22:14] <erimsa> OK Im waiting
[22:14] <nacc> erimsa: right, the 'dump' plugin takes a source (as defined in the snapcraft.yaml) and verbatim copies it into the snap squashfs
[22:15] <kyrofa> erimsa, take a look at this: http://pastebin.ubuntu.com/24127222/
[22:15] <kyrofa> erimsa, of specific note, the last four lines
[22:16] <kyrofa> erimsa, there you see `plugin: dump` as nacc is suggesting
[22:16] <kyrofa> erimsa, that will download the tarball (assuming it's a URL) and extract it into the snap
[22:16] <erimsa> Ok I will try it in a few days
[22:16] <erimsa> In beagle bone black
[22:16] <nacc> erimsa: and to be clear, that does assume the tarball's binaries have no dependencies themselves in the snap -- if they do, then you need to have those specified in your snapcraft.yaml
[22:16] <kyrofa> erimsa, you need a little more metadata there to actually expose a binary to be callable (add the `apps` section that you'll see in the docs/tutorials)
[22:17] <kyrofa> nacc, good catch
[22:17] <erimsa> I think I getting to close to understand
[22:17] <erimsa> Im
[22:17] <kyrofa> erimsa, if for example your tarball depends on some debian packages, you can add them there using `stage-packages` (which you'll also see in the docs/tutorials)
[22:18] <erimsa> Can you send me link for that tutorials ?
[22:18] <erimsa> There are lots web page
[22:18] <erimsa> s
[22:18] <nacc> http://snapcraft.io/
[22:18] <nacc> probably docs -> build snaps
[22:19] <erimsa> Second Question
[22:19] <erimsa> We need our own Custom Store
[22:20] <erimsa> for snap packages
[22:20] <erimsa> Is that possible ?
[22:21] <kyrofa> erimsa, there are a few possibilities for that. Can you explain what you're trying to accomplish with that? Or just a "we want it under our own roof" type of thing?
[22:24] <erimsa> Im working for a company that produces industrial controllers for food,chemisty,textile industries
[22:24] <erimsa> And using Debian Linux as OS for devies
[22:25] <erimsa> We have really problems with package versioning and installing in fields
[22:25] <erimsa> I m trying to solve kind of problems
[22:26] <kyrofa> erimsa, sure-- I mean specifically what you're looking for/trying to accomplish with a "custom store"
[22:27] <erimsa> Lets say I decided to use Ubuntu Core and Snap technology
[22:28] <erimsa> Our Snap packages should not be open for everyone
[22:28] <erimsa> Publicly
[22:28] <erimsa> It should be private to keep them
[22:29] <kyrofa> erimsa, first of all, you can have private packages in the official store
[22:29] <erimsa> I didnt know that
[22:30] <erimsa> Official means Canonical Store ?
[22:30] <kyrofa> Indeed, the Ubuntu Store
[22:30] <erimsa> I see
[22:31] <erimsa> We have lots of devices around the world ,
[22:31] <kyrofa> erimsa, if you need more control than that we do have an "on-premises store" offering, but I'm not the guy to talk to about that. I can put you in touch with the people who are, though
[22:31] <erimsa> Yes definitly
[22:32] <erimsa> If you can give me email address I can write then
[22:33] <kyrofa> erimsa, if you shoot me your email address in a private message I can send an introduction if you like
[22:33] <erimsa> OK
[22:40] <mup> PR snapd#2989 opened: many: some opensuse patches that are ready to go into master <Created by zyga> <https://github.com/snapcore/snapd/pull/2989>
[22:50] <mup> PR snapd#2990 opened: cmd: link libcap dynamically <Created by zyga> <https://github.com/snapcore/snapd/pull/2990>
[22:55] <mup> PR snapd#2991 opened: packaging: add opensuse permissions files <Created by zyga> <https://github.com/snapcore/snapd/pull/2991>