[08:19] <zyga> good morning
[08:20] <davidcalle> Morning zyga
[08:20] <zyga> davidcalle: hey :-)
[09:58] <OsakaFoo> can I access the snappy store from the web?
[09:59] <ogra_> there is an API
[09:59] <ogra_> but no official webpage .... there is also a community webpage that uses the API at http://uappexplorer.com
[09:59] <ogra_> there you can filter for snaps too
[10:02] <OsakaFoo> oh yeah
[10:02] <OsakaFoo> thanks
[10:03] <OsakaFoo> is it possible to run snaps on ubuntu-touch?
[10:03] <ogra_> not yet, no
[10:04] <OsakaFoo> will that be the future?
[10:04] <ogra_> yes
[10:04] <ogra_> but that reqquires the phones tofirst switch to 16.04 and a systemd base
[10:05] <OsakaFoo> nice
[12:54] <bencc> can I do hot-code upgrade of a package?
[12:54] <bencc> I want to package an erlang release
[12:54] <bencc> erlang let you upgrade the code in a running system
[12:57] <zyga> bencc: how would that work in practice?
[12:57] <zyga> bencc: ship a new snap but not restart services?
[12:57] <zyga> bencc: but instead do *something* (not sure what yet)
[12:59] <bencc> zyga: in erlang you upload the new version of the code and tell the VM to 'replace' the old code with the new code
[13:00] <bencc> erlang is smart to not stop running processes (Erlang processes) but use the new version in the next run
[13:01] <bencc> zyga: nginx let's you update the deb package without restarting the daeomn
[13:02] <bencc> how does a normal snap update work?
[13:08] <zyga> bencc: interesting
[13:08] <zyga> bencc: seems like lisp image in many ways
[13:09] <zyga> bencc: currently snapd would restart the servies
[13:09] <zyga> bencc: but we could think of how to support that
[13:09] <zyga> bencc: can you please open a bug on launchpad.net/snappy and describe this
[13:09] <sergiusens> good morning everyone!
[13:10] <bencc> zyga: sure
[13:10] <bencc> zyga: are there docs on refreshing/upgrading a daemon?
[13:10] <bencc> I can't find it on google
[13:10] <kyrofa> Morning sergiusens!
[13:10] <zyga> bencc: I think it might be possible but it would be interested to know all the edge cases
[13:10] <bencc> how do you upgrade a running webserver like nginx?
[13:11] <bencc> if hot upgrade is not supported now I'll have to wait for ubuntu 16.10 or later?
[13:11] <zyga> bencc: right now, we just install a new snap, activate it (make all the systemd units and security bits) and then we stop/start services
[13:12] <zyga> bencc: but I do see that it would be great if we could, in certain cases, optimize the restart to "reload" that perhaps doesn't kill the processes or induces downtime
[13:12] <zyga> bencc: perhaps once we have hook support we could do that
[13:13] <zyga> bencc: a specific hook could be called on upgrade to tell us if services need to be restarted the hard way
[13:13] <bencc> ok
[13:13] <zyga> bencc: and if not, the hook could do whatever is needed to do a "soft" restart
[13:13] <zyga> bencc: would that be sensible in this case?
[13:13] <bencc> I think so
[13:14] <zyga> great, let's please include this conversation in the bug report
[13:14] <zyga> Thanks!
[13:14] <bencc> in a deb package I'm using the postinst script
[13:15] <bencc> If the erlang server is running, I'm asking it to do hot-code upgrade from the command line
[13:15] <bencc> if it's not running I'm doing normal installation
[13:16] <niemeyer_> jdstrand, tyhicks: Any news on the environ setting issue?
[13:17] <bencc> zyga: do I need to explain about erlang in the bug report?
[13:18] <bencc> it seems that it's a general use case. nginx will need the same as erlang app right?
[13:18] <zyga> bencc: it'd be best
[13:18] <bencc> ok
[13:18] <zyga> bencc: less assumptions about what the readers will understand about erlang
[13:18] <zyga> bencc: yes, I think the generic no-downtime support would be an amazing thing to have
[13:19] <jdstrand> niemeyer_: tyhicks is looking into it. He'll be online in a bit
[13:19] <zyga> jdstrand: hey, you may want to start looking at https://code.launchpad.net/~zyga/ubuntu-core-launcher/snap-run
[13:20] <zyga> jdstrand: right now nothing interesting but I plan to change how snap-run looks on command line
[13:20] <zyga> (more than so far)
[13:20] <bencc> I can use snaps on ubuntu server 16.04. no need for ubuntu core, right?
[13:20] <kyrofa> bencc, indeed
[13:20] <kyrofa> (or desktop)
[13:21] <zyga> bencc: yes, on any ubuntu really :)
[13:22] <bencc> nice
[13:26] <niemeyer_> zyga: It's a bit tricky to be effective at "start looking" :)
[13:27] <niemeyer_> zyga: If you have changes for it, please push them for review as usual and ask jdstrand for a review before landing
[13:27] <niemeyer_> zyga: We can do that after moving to GH
[13:27] <niemeyer_> zyga: But let's move the pristine code, unchanged
[13:28] <niemeyer_> zyga: and have reviews just as usual
[13:28] <bencc> zyga: https://bugs.launchpad.net/snappy/+bug/1584779
[13:28] <bencc> thanks
[13:28] <niemeyer_> jdstrand: Thanks.. this is rolling for a while, and I'm wondering if we have an ETA
[13:29] <jdstrand> I can't say exactly-- I've not been involved in that. I can say there is an apparmor patch and iirc it was 'almost ready'. tyhicks will be online in 30 minutes or so
[13:34] <zyga> jdstrand: https://github.com/ubuntu-core/snap-run/pull/1/files
[13:35] <zyga> niemeyer_: ack, done right now
[13:52] <niemeyer_> jdstrand: Thanks, will catch up with Tyler
[13:53] <niemeyer_> jdstrand: When you have a moment, can you have a look at https://github.com/ubuntu-core/snappy/pull/1201
[13:59] <zyga> slangasek: hey, did you propose a pull request to snappy, for os-release support?
[14:25] <tyhicks> niemeyer_: I'm getting very close to having the patchset done to disable env scrubbing
[14:25] <tyhicks> niemeyer_: should be done in the first half of this week (and then we'll need an SRU)
[14:29] <niemeyer_> tyhicks: Sweet!
[14:29] <zyga> jdstrand: hey, what does reload/load the profile for ubuntu-core-launcher itself
[14:29] <zyga> jdstrand: I just realized that is is apparently nothing in the package
[14:32] <zyga> jdstrand: ah, /etc/apparmor.d/usr.bin.ubuntu-core-launcher is a conffile
[14:32] <zyga> jdstrand: bummer :)
[14:33] <zyga> mvo: how do I remove a conffile from a maintainer script with as little pain as I can?
[14:34] <mvo> zyga: dpkg-maintscript-helper rm_conffile /path/ last-version
[14:35] <zyga> mvo: thank you
[14:45] <abeato> hey, is there any equivalent to the old "snapcraft shell" these days?
[14:45] <ogra_> nope
[14:46] <ogra_> (you mean "snappy shell" i guess)
[14:46] <ogra_> use a classic ubuntu install for now (it will come back)
[14:48] <zyga> abeato: if you want I can give you a quick "gimme classic" shell script that works fairly well
[14:49] <zyga> abeato: I'm sure we'll get proper classic support later on but this is just something that keeps people going
[14:49] <abeato> zyga, that would be great to have :)
[14:49] <zyga> abeato: in a moment, just in a meeting
[14:49] <abeato> (the script)
[14:53] <abeato> sure, thanks
[15:02] <ogra_> mvo, so you want the delta shipped *inside* t3eh os snap ? not as a separate tarball ?
[15:03] <mvo> ogra_: yeah, that was the idea, if its too huge it does not make sense, but lets try it, the nice property of this is that "classic.enable" will work everytime without network
[15:04] <ogra_> yeah, neat ! never thought of it that way
[15:07] <slangasek> zyga: yes I did, why?
[15:09] <mvo> ogra_: its also super nice because we don't need to keep the two parts in sync (base-os and delta), its natually in sync. but yeah, if its too huge we need to rethink it but I am keen to try it
[15:10] <ogra_> yeah, cant realyl be much
[15:23] <Trevinho> jdstrand: hey, can I use strace when not in --dev-mode to check what's wrong?
[15:23] <Trevinho> jdstrand: currently I'm getting a bad system call error
[15:23] <zyga> slangasek: ah, we were just checking if that's you or someone else
[15:23] <zyga> slangasek: thanks for confirming that
[15:23] <zyga> abeato: soon :)
[15:23] <zyga> abeato: testing now
[15:23] <Trevinho> ype=1326 audit(1464016887.003:654): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=16474 comm="strace" exe="/snap/electron-quick-start/100001/usr/bin/strace" sig=31 arch=c000003e syscall=101 compat=0 ip=0x7fec3323356e code=0x0
[15:23] <zyga> jdstrand: how does the ubuntu-core-launcher apparmor profile get compiled and applied on install?
[15:24] <slangasek> zyga: ah, heh :)
[15:24] <ogra_> Trevinho, run "scmp_sys_resolver 101"
[15:24] <ogra_> (on your snappy install)
[15:25] <ogra_> that will tell you which syscal was blocked
[15:25] <Trevinho> ogra_: that needs devmode though
[15:25] <ogra_> scmp_sys_resolver doesnt need dev mode
[15:25] <ogra_> and the blocking should be listed in syslog
[15:26] <abeato> zyga, ack, nw ;)
[15:26] <Trevinho> ogra_:  scmp_sys_resolver 101
[15:26] <Trevinho> bash: /usr/bin/scmp_sys_resolver: Permission denied
[15:26] <Trevinho> this is in a bash launched from a script inside snappy
[15:26] <ogra_> oh
[15:26] <ogra_> i was talking about a bare ssh shell
[15:27] <ogra_> (but i assume yiou are on a desktop machine, sorry, that didnt strike me)
[15:27] <Trevinho> yeah, this is runing ain a VM, but yeah
[15:29] <jdstrand> Trevinho: you can't run strace from within a snap cause it needs ptrace. you can also install 'snappy-debug' then run 'sudo snappy-debug.security scanlog' and it will resolve the syscall for you
[15:29] <jdstrand> or just use scmp_sys_resolver from outside the snap on a device of the same architecture
[15:29] <Trevinho> jdstrand: it's ptrace yeah
[15:32] <Trevinho> ouch... I'm getting the error snap has changes in progress... And I can't remove it :o
[15:32] <Trevinho> what's happening
[15:37] <Trevinho> ogra_: do you happen to know how to fix that? ^
[15:37] <Trevinho> (it's in yakkety)
[15:43] <Trevinho> I can't either use gdb... As syscall 135 (personality) get blocked
[15:53] <sergiusens> zyga mind if I create a storeapi project on gh?
[16:10] <sergiusens> zyga should I take over https://github.com/ubuntu-core/snapcraft/pull/503 ?
[16:11] <zyga> sergiusens: not at all, let's do it
[16:11] <zyga> sergiusens: looking
[16:11] <zyga> sergiusens: yes, please, I didn't notice that feedback at all, I have a backlog of email to read
[16:11] <zyga> sergiusens: and thank you!
[16:12] <sergiusens> zyga sure thing, ping me if you have any questions
[16:12] <zyga> sergiusens: thanks
[16:12] <sergiusens> zyga well thanks for contributing to snapcraft ;-)
[16:12] <zyga> jdstrand: quick question: canbus, should we allow it in the network/network-bind interface or should we have a canbus=yes attribute or a dedicated canbus-network canbus-network-bind interfaces or something entirely different?
[16:13] <zyga> jdstrand: canbus is just a socket FYI
[16:14] <Trevinho> mh, jdstrand you remember that electron hang (when unconfined), right... Not sure I'm debugging it well, but here's where it hangs http://paste.ubuntu.com/16635698/ To my eyes it doesn't say much though... As probably it's just stracing the sh launcher
[16:14] <zyga> jdstrand: though I may have a partial picture: there seem to be two ways to talk to the driver (network iface and character device)
[16:16] <ogra_> Trevinho, that broken lib path looks suspicious
[16:16] <ogra_> (misses the arch in the triplet)
[16:17] <Trevinho> ah mhm
[16:20]  * Trevinho launching the core-laucnher gives me another issue instead http://pastebin.ubuntu.com/16636006/
[16:21] <kyrofa> Trevinho, is the launcher suid root?
[16:21] <jdstrand> zyga: I'm not familiar with canbus. I see that apparmor supports it as a domain type. (eg, 'network can,'). we only have coarse-grained mediation at this time (ie, the level I just mentioned)
[16:22] <Trevinho> kyrofa: not sure... I've just launched what's inside the generated launcher script
[16:22] <zyga> jdstrand: thanks
[16:23] <Trevinho> ah... I'm getting something new now
[16:23] <Trevinho> type=1326 audit(1464020595.183:187): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=30771 comm="electron" exe="/snap/electron-quick-start/100001/lib/node_modules/electron-prebuilt/dist/electron" sig=31 arch=c000003e syscall=141 compat=0 ip=0x7f23a44194a7 code=0x0
[16:24] <Trevinho> 141 = setpriority
[16:24] <jdstrand> zyga: reading only so briefly, this feels like a separate interface. 'network' doesn't convey to me 'Controller Area Network', but maybe others disagree. tyhicks, you may have an opinion
[16:24] <sergiusens> Trevinho that should be fixed in whatever is supposed to be released soon I've been told
[16:25] <Trevinho> sergiusens: ah, nice
[16:25] <jdstrand> Trevinho: yes, I was able to get things running. I thought I mentioned that in a bug/card...
[16:25] <Trevinho> jdstrand: mh, maybe I'm not in that card/bug :)
[16:25] <sergiusens> jdstrand so what do I need to get the chromium/electron bits?
[16:25]  * sergiusens is just back from holidays and trying to catch up with this fast paced world
[16:26] <zyga> sergiusens: I'm back from not having a weekend and I feel the same :)
[16:26] <ogra_> but you had vampires at least !
[16:27]  * zyga enjoys tasty vampires
[16:27] <zyga> raw, not well-made
[16:27] <zyga> ;)
[16:27] <ogra_> but with fresh garlic :)
[16:27] <Trevinho> sergiusens: ah, I pinged you couple of times too :), as I'd like to discuss how to integrate quilt (or any other tool that might handle the sources before building) in snapcraft...
[16:27] <zyga> jdstrand: how can I unload an apparmor profile reliably?
[16:27] <jdstrand> sergiusens: 4 things are needed: the ldpreload library as detailed in bug #1577514 for shm, seccomp arg filtering in the launcher which is pending review, once that lands, updates to the policy for setpriority and seeing if we can allow @{PROC}/@{pid}/oom_score_adj in the default policy
[16:27] <jdstrand> zyga: apparmor_parser -R /path/to/profile
[16:28] <zyga> jdstrand: ahh, path to profile
[16:28] <zyga> I assumed it was the profile name only
[16:28] <zyga> is it possible to remove a profile by name?
[16:28] <sergiusens> Trevinho we actually don't want something that manages patches. It is essentially a forked code base so it is no different
[16:28] <jdstrand> there is another way via the /sys interface that I always forget
[16:28] <zyga> jdstrand: I'm trying to remove ubuntu-core-launcher profile
[16:28] <sergiusens> quilt is really tied to the packaging world
[16:28] <zyga> jdstrand: after the upgrade to snap-run
[16:29] <Trevinho> sergiusens: it's not the same... Sometimes patch stays there forever, while you don't want to upgrade your fork everytime upstream changes things.
[16:29] <zyga> jdstrand: (and in general, how is the profile updated on package update?)
[16:29] <Trevinho> sergiusens: we had some discussion in https://bugs.launchpad.net/snapcraft/+bug/1551716 and there seems to be general consensus to that
[16:30] <beowulf> sergiusens: i don't python so forgive me, but i think this would be nice for the nodejs plugin https://github.com/ubuntu-core/snapcraft/pull/509
[16:30] <jdstrand> zyga: fyi, I have quite a few open PRs for policy updates related to sdoc. you said to ping you, so I'm pinging you
[16:30] <jdstrand> https://github.com/ubuntu-core/snappy/pull/1193
[16:30] <Trevinho> sergiusens: I come up with an hackish quilt build plugin, but it requires some yaml code which is not really so nice.
[16:30] <jdstrand> actually, maybe it is just that one
[16:30] <jdstrand> meh, I thought I fixed my procmail...
[16:31] <sergiusens> beowulf I get a 404 there
[16:31] <sergiusens> but happy to look
[16:32] <beowulf> sergiusens: github is having service hiccups, it's a pr to add node-engine to yaml, allowing the dev to set which node version the package uses
[16:33] <Trevinho> sergiusens: what I expect is also to be able to run some kind of tools to refactor the code before building in a dynamic way... sometimes you need to replace strings or names... and Well, having to keep a fork for that is not really the best thing. When you only want the $latest_upstream_code + $local_customization
[16:35] <jdstrand> zyga: yeah, nm. I mean, feel free to look at that gsettings one but unping-- the others all made it and just didn't hit my inbox
[16:42] <zyga> jdstrand: looking at 1193
[16:44] <sergiusens> Trevinho a patchset you need to maintain is exactly a fork though
[16:45] <sergiusens> Trevinho every time you need to update your upstream you need to reapply the patch on top, it is no different that always doing `git rebase master`
[16:46] <Trevinho> sergiusens: it is, but it's different we way we manage it... And this would allow to use the same patcheset for both debian-based distro and for snappy pkgs
[16:46] <sergiusens> Trevinho running a tool now is completely different than a patchset, right?
[16:46] <sergiusens> Trevinho well, then check my comment on the bug ;-) I am not against adding a debian source package as a valid `source` entry, totally for that fwiw
[16:46] <Trevinho> sergiusens: well, the thing is that in the current method, we can just launch snapcraft and get the latest source and the current patchest... If that doesn't apply we can redo it
[16:48] <sergiusens> Trevinho I really think you are thinking of this from a packager's point of view; we want our snapcraft.yaml's to essentially live upstream somewhere too
[16:49] <sergiusens> beowulf sounds good, we had that in the pipes; one thing we also need to add is choosing to npm in production mode or dev mode (prod being the default).
[16:51] <Trevinho> sergiusens: I know it has to be upstream too... Indeed. But I'd love it to be flexible and thus it to adapt to both scencarios, since we can.
[16:52] <beowulf> sergiusens: yes, but you can set that via env so i didn't think it was such an issue
[16:52] <beowulf> sergiusens: or does that not work with the plugin?
[16:54] <jdstrand> zyga: so, with the change to snap-run, all pending MPs need to be migrated?
[16:55] <zyga> jdstrand: yep
[16:56] <jdstrand> tyhicks: actually, I guess this is changing more-- https://github.com/ubuntu-core/snap-run/pull/1/files should ctually reference snapcore and not ubuntu-core
[16:56] <zyga> jdstrand: I can help if anyone gets stuck
[16:57] <niemeyer_> jdstrand: One more for your review requeue: https://github.com/ubuntu-core/snappy/pull/1202/files
[17:02] <sergiusens> beowulf it does. I am thinking more of something like using builders. I am now sort of wanting to introduce the `environment` keyword for parts as we are doing for `apps`
[17:06] <beowulf> sergiusens: right, makes sense
[17:28] <josepht> sergiusens: have you considered having a part plugin which could pull parts from repos similar to apps sources?
[17:56] <niemeyer_> Is Claudio Andre around here?
[17:58] <niemeyer_> jdstrand: ping
[18:08] <sergiusens> josepht apps sources?
[18:09] <jdstrand> niemeyer_: hey
[18:09] <niemeyer_> jdstrand: Heya
[18:09] <niemeyer_> jdstrand: Any further points on the pulseaudio interface or do you think we can merge it now without any bad consequences?
[18:10] <niemeyer_> jdstrand: Other than the recording issue we debated already
[18:10] <jdstrand> I think it is ok so long as we are pursuing that SRU. lemme double check
[18:13] <jdstrand> niemeyer_: ok, policy-wise, it's fine as-is. Note that this is still only for 'classic' which I'm not sure is what you intended for it (perhaps that was another PR...)
[18:14] <jdstrand> (snap/implicit.go)
[18:15] <jdstrand> I think since this is simple file rules, the policy would work for core too
[18:16] <jdstrand> and I know the devices guys have a pulseaudio snap towards the bottom of their list (though, that list is getting shorter and shorter)
[18:16] <jdstrand> anyway, I'm not saying we should block on that, just adding some context
[18:18] <niemeyer_> jdstrand: Yeah, not ideal, but we shouldn't block on being classic only.. that's the only env we have users ATM, so okay for the time being
[18:19] <niemeyer_> jdstrand: The opposite is more of a problem (an interface that does _not_ work on classic)
[18:19] <josepht> sergiusens: sorry parts sources.  What I'm referring to is for shared parts (i.e. those on the wiki currently)
[18:22] <niemeyer_> jdstrand: About that opencl interface, do you know what usually lands on that /etc directory?
[18:22] <niemeyer_> jdstrand: Is that hardware specific, or just app config?
[18:23] <niemeyer_> jdstrand: I assumed it was hardware-specific, but I was jumping to conclusions too soon
[18:25] <jdstrand> niemeyer_: I'm not familiar with opencl. I two may have jumped to comclusions. Looking at the rules, I assumed that debs provided /etc/OpenCL/... and those files configured how binaries worked and that they were in /etc because it is something an admin would normally do
[18:26] <jdstrand> too*
[18:26] <jdstrand> for example, my laptop doesn't have that directory
[18:27] <zyga> niemeyer_: opencl has a stream of packages, some belong in the os snap (or app snap), some in the kernel snap, some of that manifests itself as /etc/OpenCL
[18:27] <zyga> niemeyer_: we should really get someone that knows opencl inside out to assist on that one
[18:49] <niemeyer_> zyga: Well, we just need some basic info to get unblocked
[18:49] <niemeyer_> zyga: As long as we don't do anything silly, it's okay to have a seed interface in
[18:54] <zyga> niemeyer_: I agree
[18:55] <zyga> niemeyer_: I can ask, I know a canonicaler that knows more
[18:55] <niemeyer_> zyga: Sweet, thanks
[18:56] <Saviq> sergiusens, ah, just realized - if launched from the dash, I'm getting multiple instances of Tg, but that's probably a unity7 bug (that's why I had more of them running)
[19:01] <niemeyer_> jdstrand: Simon responded on #1202, can you please have a look to see if it looks sane now, or if we should unblock it on something else?
[19:01] <niemeyer_> jdstrand: Sorry for bothering more than usual today.. we're trying to clean up the long-standing queue
[19:09] <jdstrand> done
[19:09] <jdstrand> np
[19:15] <beowulf> zyga: hi! do you know any reason why ubuntu-image.sh shouldn't work right now? https://pastebin.canonical.com/157054/
[19:21] <pmp> I followed the two threads on the ML regarding kernel builds for raspi2/3 - however I didn't find the answer I'm looking for:
[19:22] <pmp> Where can I find the snap.yaml + the instruction to snap my own kernel/modules for a raspi2 - using the current method?
[19:23] <pmp> I know you guys are changing things for the better, but I'd like to get along on my project - too impatient
[19:25] <kyrofa> pmp have you seen http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ ?
[19:28] <pmp> kyrofa: great. Do you also know where I can find the snapcraft.yaml for raspi2;s kernel currently in use ?
[19:31] <kyrofa> pmp that I don't know. ogra_ might
[19:31] <pmp> how does snapcraft find the right cross-compiler?
[19:31] <kyrofa> fg
[19:31] <thomi> sergiusens: Are you back from your holiday? I wonder if you could comment on https://bugs.launchpad.net/click-reviewers-tools/+bug/1582513 please?
[19:32] <kyrofa> pmp it has a list of supported architectures
[19:33] <kyrofa> pmp, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/_options.py#L27 for example
[19:34] <pmp> kyrofa: great article, answers a lot of questions
[19:34] <kyrofa> pmp, thank sergiusens :)
[19:34] <pmp> sergiusens: thanks ;-0
[19:35] <pmp> It'll be nice to have an overview somewhere of all the blog-articles done by you guys.
[19:35] <pmp> Or announce everyone of them on the mailing list in addition
[19:37] <zyga> beowulf: hey
[19:37] <zyga> beowulf: looking
[19:38] <zyga> beowulf: not really.. is that most up-to-date version?
[19:38] <zyga> beowulf: maybe store changed on us in some way
[19:38] <beowulf> zyga: should be, let me check ...
[19:38] <zyga> beowulf: (in any case, you will be happy to know the real ubuntu-image is being written, should be usable in around a week)
[19:39] <beowulf> zyga: great :)
[19:39] <beowulf> zyga: yes, it's the latest with the 5s sleep
[19:39] <zyga> beowulf: no root, faster implementation, etc etc
[19:39] <zyga> beowulf: but still depends on working store ;)
[19:39] <zyga> beowulf: though it will have an offline more
[19:40] <zyga> beowulf: lots of goodies
[19:41] <zyga> beowulf: building one myself for 'pc'
[19:41] <zyga> beowulf: so far builds fine
[19:42] <zyga> beowulf: can you check syslog
[19:42] <zyga> beowulf: I bet your kernel oops'ed
[19:42] <zyga> beowulf: reboot and re-run
[19:42] <zyga> beowulf: new ubuntu-image won't rely on any kernel feaatures so it should never crash like that
[19:44] <beowulf> zyga: sorry, i have wasted your time, i keep forgetting this doesn't work in a container :(
[19:45] <beowulf> zyga: i'm in a xenial container, it works when i'm on the host (i already knew this, sorry!)
[19:49] <zyga> beowulf: no worries, if this can be detected somehow can you please open a pull request with a quick test and a message saying something appropriate?
[19:51] <sergiusens> pmp you are welcome I guess :-)
[19:51] <sergiusens> thomi looked and I am thinking of taking the hit right now to solve this
[19:52] <thomi> sergiusens: thanks! It'd be great to be able to upload my snap
[19:58] <beowulf> zyga: stackoverflow and online-services suggest `sudo grep -qa container=lxc /proc/1/environ`... will have a go at a pr later
[20:07] <mhall119> hey guys, where does the "unity7" interface come from, and how would one go about creating something similar but for another desktop environment?
[20:08] <kyrofa> mhall119, you probably want this series of blog posts: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
[20:08] <kyrofa> mhall119, but to quickly answer your question, that interface is part of snapd itself
[20:09] <kyrofa> mhall119, so making new ones involves writing some go
[20:09] <jdstrand> kgunn: I saw your response on qt webengine and was curious why oxide wasn't mentioned?
[20:09] <kyrofa> mhall119, the blog posts will have a bit more information
[20:09] <kgunn> jdstrand: just didn't think of it ;)
[20:10]  * jdstrand nods
[20:10] <kgunn> jdstrand: i guess i was trying to get mir out there....
[20:10] <jdstrand> I wasn't sure if there was some reason why it couldn't be used
[20:11] <kgunn> jdstrand: it could certainly be a potential stack configuration for the fellow's  use case
[20:11] <kgunn> would be even better if we had native chrome-mir ;)
[20:11] <kgunn> better=one less thing to pull into the snap
[20:16] <mhall119> kyrofa: is that the long-term design, or a temporary measure to get the unity7 interface?
[20:17] <zyga> beowulf: fantastic, thank you
[20:17] <zyga> mhall119: hey, it comes from snapd itself, it's added to the core snap when running on classic
[20:18] <zyga> mhall119: that's long term design for *classic*
[20:18] <zyga> mhall119: tell me what you want and I can tell you what you need to get there
[20:18] <mhall119> zyga: ok, so what's the long term design for non-unity7 classic desktops?
[20:18] <mhall119> zyga: my specific use case is kubuntu, where they will likely need a kframeworks5 interface
[20:18] <zyga> mhall119: that depends on what they need, many will work with unity7
[20:19] <zyga> mhall119: unity7 is really granting you right to use various unit7 specific APIs
[20:19] <mhall119> so as not to include every KDE dependency in their packages
[20:19] <zyga> mhall119: for packaging apps for KDE I'd start with x11 for the desktop part
[20:19] <zyga> mhall119: and with the (not implemented yet) content sharing interface for kde runtime
[20:19] <zyga> mhall119: though for that, I'd like to first start with one fat test snap (fat as in having everything, not being multi-arch)
[20:20] <zyga> mhall119: that we can then split into two while keeping it functioning as before
[20:20] <zyga> mhall119: though perhaps another approach is required for proper kde support
[20:20] <zyga> mhall119: (as in real access to classic KDE services and libraries)
[20:20] <zyga> mhall119: for that we need some features that are under development by the security team and by snappy core team (bind mounts)
[20:21] <zyga> mhall119: then we could do interesting new things
[20:21] <zyga> mhall119: sadly I can only offer you one approach today: pick a simple kde app, make a very fat snap and run it in devmode, add x11 and see if it runs, then let's get started on the delta
[20:22] <zyga> mhall119: then as those new generic features show up in the stack (content sharing and bind mounts) we can design a better interface that would make it possible to have a simple kde app just be a single snap with very little extra stuff bundled
[20:22] <zyga> mhall119: note that unity7 doesn't give you any runtime libraries, just dbus permission and some basic "talk to x11" bits
[20:23] <mhall119> zyga: you lost me, how would the content-sharing interface be used for the runtime?
[20:24] <zyga> mhall119: sorry, there's a lot of context I assume you have, let me do it with more explanations
[20:25] <zyga> mhall119: the content sharing interface grants you access to files from another snap as if they were your own
[20:25] <mhall119> is content-sharing like content-hub on the phone,or something totally different?
[20:25] <zyga> mhall119: so you can take one big snap and split it into arbitrary chunks and have the result work just as the original
[20:25] <zyga> mhall119: it's not lile the content hub
[20:25] <mhall119> ok, that's where the confusion hit me :)
[20:25] <zyga> mhall119: tink of runtime sharing for instance (java, kde, qt, etc etc etc)
[20:26] <mhall119> yes, that's what I want
[20:26] <mhall119> a platform in a snap, basically
[20:26] <zyga> mhall119: yep
[20:26] <zyga> mhall119: there are a few things we need to implement before that is possible
[20:26] <zyga> mhall119: permission side is simple, but we need to inform the consumers of where to find the shared parts
[20:26] <zyga> mhall119: and we need to re-construct some magic to make it seem seamless (shared libraries, executables, etc)
[20:27] <mhall119> zyga: ack, ok, this is all making sense now
[20:27] <zyga> mhall119: those are just generic new features of snapd and snap-run (nee ubuntu-core-launcher) that need to happen first
[20:27] <zyga> mhall119: I bet we'll get some kde specific interface over time but that's the first approach I would have
[20:27] <zyga> mhall119: something to let us understand kde better
[20:28] <mhall119> zyga: ack, I'm working on kcalc right now, will be back once I have it working
[20:29] <zyga> mhall119: cool, cheersr, I'll ping you each time something new lands towards that goal
[20:44] <mhall119> thanks zyga
[21:04] <sergiusens> elopio reproduced on x86: bug #1551570
[21:05] <beowulf> hi, i want my package 'start' command to be executed in the package folder (where package.json lives, it's an node package), how do i tell snapcraft to do that? add in a wrapper script and `cd /path/to/package && npm start`? how do i get the path?
[21:15] <qengho> beowulf: Yes, you need a wrapper. $SNAP is the snap/ when you packaged with snapcraft. I'd "cd $SNAP; exec foo/start". You can be sure $SNAP exists.
[21:16] <qengho> beowulf: beowulf perhaps with doublequote $@ doublequote at the end, in your wrapper.
[21:31] <sergiusens> kyrofa and elopio what do you think about this https://github.com/ubuntu-core/snapcraft/pull/510 (just getting started, but I am liking how it is working out)
[21:37] <sergiusens> thomi may I ask you to play with https://bugs.launchpad.net/snapcraft/+bug/1582513/comments/8 ?
[21:37] <sergiusens> zyga also want to look at that ^ ?
[21:37] <thomi> sergiusens: sure thing
[21:46] <beowulf> qengho: thanks!
[21:48] <thomi> sergiusens: Any chance you could build a .deb and stick it somewhere? It seems snapcraft doesn't install easily into a virtualenv?
[21:56] <sergiusens> thomi yeah, I inherited this like it is, I need to work on a requirements.txt to make this work well
[21:56] <sergiusens> thomi scp from people.canonical.com:/home/sergiusens/snapcraft_2.8.8_all.deb
[21:58] <sergiusens> thomi btw, I made some changes to your yaml http://paste.ubuntu.com/16644344/ (using the public git and relative `command`)
[21:59] <thomi> huh, cool. I don't know about 'command'
[22:02] <sergiusens> thomi so instead of using a relative command (`usr/bin/gmailfilter`) using the one in $PATH ($SNAP/bin in this case) as gmailfilter is in $PATH
[22:02] <sergiusens> that last one is just personal preference fwiw
[22:02] <thomi> huh, Interesting, thanks
[22:07] <zyga> sergiusens: looking
[22:07] <zyga> sergiusens: use the ... what in ubuntu core?
[22:07] <zyga> python?
[22:12] <thomi> sergiusens: wow - 55MB to 144KB
[22:14] <zyga> thomi: same will be possible with a (say) python3.canonical snap and content sharing
[22:15] <thomi> sergiusens: however, the snaps now consistently fail review because the checksums do not match
[22:15] <thomi> sergiusens: security-snap-v2_squashfs_repack_checksum is the failing check
[22:16] <sergiusens> thomi heh, that I think is a mksquashfs bug jdstrand was looking into
[22:16] <thomi> :(
[22:16] <sergiusens> zyga the python, yes
[22:16] <sergiusens> thomi yeah, not sure what triggers even
[22:17] <sergiusens> zyga do you know the bug number for the checksum thing?
[22:17] <zyga> sergiusens: I cannot wait to do that :)
[22:17] <zyga> sergiusens: no, sorry
[22:17] <sergiusens> zyga do what?
[22:17] <zyga> sergiusens: write the content sharing iface
[22:18] <sergiusens> zyga you have been saying that for a year already it feels like :-)
[22:19]  * sergiusens heads off to aikido practice, will bbl
[22:19] <zyga> sergiusens: it's a loong way ;-)
[22:19] <zyga> in reality it requires a few features that are in the pipe
[22:20] <sergiusens> jdstrand when you are around, do we have a bug for that mksquashfs thing?
[22:37] <elopio> sergiusens: cool, you simplifyied the code a lot.
[22:38] <elopio> just the "pass" in the tests makes me feel uneasy ;)
[22:40] <zyga> elopio: yes, it should have been a docstring, then pass is optional ;)
[22:42] <elopio> zyga: no me simpatizas.
[23:00] <wililupy> question: how do I purge a snap from 16.04?
[23:24] <zyga> wililupy: snap remove $snap_name
[23:24] <zyga> wililupy: that's all you need
[23:24] <wililupy> zyga: I did that, but when I try to install an updated one that I am working on it says it can't mount revision 100001
[23:25] <wililupy> zyga and it still shows it in /writable/system-data/snap but not in snap list
[23:25] <wililupy> also in /var/lib/snapd/snaps and /var/lib/snapd/state.json
[23:27] <zyga> wililupy: hmm
[23:27] <zyga> wililupy: is that an all-snap image or a snappy-on-classic
[23:27] <zyga> wililupy: if all-snap can you refresh ubuntu-core?
[23:27] <wililupy> zyga: I just ran snap refresh ubuntu-core
[23:28] <wililupy> zyga: still get the same error.
[23:32] <mhall119> zyga: I got it running in --devmode at least
[23:32] <mhall119> zyga: see https://github.com/ubuntu/snappy-playpen/tree/kcalc/kcalc
[23:33] <mhall119> specifically the apparmor complaints, I have no idea what it's doing or why, but it seems strange for a calculator
[23:36] <wililupy> zyga: when I tried to remove the snap, I did get an error: https://pastebin.canonical.com/157073/