=== devil is now known as Guest63080 === Guest63080 is now known as devil_ === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:19] good morning [08:20] Morning zyga [08:20] davidcalle: hey :-) === vrruiz_ is now known as rvr [09:58] can I access the snappy store from the web? [09:59] there is an API === chihchun is now known as chihchun_afk [09:59] but no official webpage .... there is also a community webpage that uses the API at http://uappexplorer.com [09:59] there you can filter for snaps too [10:02] oh yeah [10:02] thanks [10:03] is it possible to run snaps on ubuntu-touch? [10:03] not yet, no [10:04] will that be the future? [10:04] yes [10:04] but that reqquires the phones tofirst switch to 16.04 and a systemd base [10:05] nice === chihchun_afk is now known as chihchun === alex-abreu is now known as alex-abreu|off [12:54] can I do hot-code upgrade of a package? [12:54] I want to package an erlang release [12:54] erlang let you upgrade the code in a running system [12:57] bencc: how would that work in practice? [12:57] bencc: ship a new snap but not restart services? [12:57] bencc: but instead do *something* (not sure what yet) [12:59] 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] erlang is smart to not stop running processes (Erlang processes) but use the new version in the next run [13:01] zyga: nginx let's you update the deb package without restarting the daeomn [13:02] how does a normal snap update work? [13:08] bencc: interesting [13:08] bencc: seems like lisp image in many ways [13:09] bencc: currently snapd would restart the servies [13:09] bencc: but we could think of how to support that [13:09] bencc: can you please open a bug on launchpad.net/snappy and describe this [13:09] good morning everyone! [13:10] zyga: sure [13:10] zyga: are there docs on refreshing/upgrading a daemon? [13:10] I can't find it on google [13:10] Morning sergiusens! [13:10] bencc: I think it might be possible but it would be interested to know all the edge cases [13:10] how do you upgrade a running webserver like nginx? [13:11] if hot upgrade is not supported now I'll have to wait for ubuntu 16.10 or later? [13:11] 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] 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] bencc: perhaps once we have hook support we could do that [13:13] bencc: a specific hook could be called on upgrade to tell us if services need to be restarted the hard way [13:13] ok [13:13] bencc: and if not, the hook could do whatever is needed to do a "soft" restart [13:13] bencc: would that be sensible in this case? [13:13] I think so [13:14] great, let's please include this conversation in the bug report [13:14] Thanks! [13:14] in a deb package I'm using the postinst script [13:15] If the erlang server is running, I'm asking it to do hot-code upgrade from the command line [13:15] if it's not running I'm doing normal installation [13:16] jdstrand, tyhicks: Any news on the environ setting issue? [13:17] zyga: do I need to explain about erlang in the bug report? [13:18] it seems that it's a general use case. nginx will need the same as erlang app right? [13:18] bencc: it'd be best [13:18] ok [13:18] bencc: less assumptions about what the readers will understand about erlang [13:18] bencc: yes, I think the generic no-downtime support would be an amazing thing to have [13:19] niemeyer_: tyhicks is looking into it. He'll be online in a bit [13:19] jdstrand: hey, you may want to start looking at https://code.launchpad.net/~zyga/ubuntu-core-launcher/snap-run [13:20] jdstrand: right now nothing interesting but I plan to change how snap-run looks on command line [13:20] (more than so far) [13:20] I can use snaps on ubuntu server 16.04. no need for ubuntu core, right? [13:20] bencc, indeed [13:20] (or desktop) [13:21] bencc: yes, on any ubuntu really :) [13:22] nice [13:26] zyga: It's a bit tricky to be effective at "start looking" :) [13:27] zyga: If you have changes for it, please push them for review as usual and ask jdstrand for a review before landing [13:27] zyga: We can do that after moving to GH [13:27] zyga: But let's move the pristine code, unchanged [13:28] zyga: and have reviews just as usual [13:28] zyga: https://bugs.launchpad.net/snappy/+bug/1584779 [13:28] Launchpad bug 1584779 in Snappy "Upgrade a running snap without restarting it" [Undecided,New] [13:28] thanks [13:28] jdstrand: Thanks.. this is rolling for a while, and I'm wondering if we have an ETA [13:29] 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] jdstrand: https://github.com/ubuntu-core/snap-run/pull/1/files [13:35] niemeyer_: ack, done right now === chihchun is now known as chihchun_afk [13:52] jdstrand: Thanks, will catch up with Tyler [13:53] jdstrand: When you have a moment, can you have a look at https://github.com/ubuntu-core/snappy/pull/1201 [13:59] slangasek: hey, did you propose a pull request to snappy, for os-release support? [14:25] niemeyer_: I'm getting very close to having the patchset done to disable env scrubbing [14:25] niemeyer_: should be done in the first half of this week (and then we'll need an SRU) [14:29] tyhicks: Sweet! [14:29] jdstrand: hey, what does reload/load the profile for ubuntu-core-launcher itself [14:29] jdstrand: I just realized that is is apparently nothing in the package [14:32] jdstrand: ah, /etc/apparmor.d/usr.bin.ubuntu-core-launcher is a conffile [14:32] jdstrand: bummer :) [14:33] mvo: how do I remove a conffile from a maintainer script with as little pain as I can? [14:34] zyga: dpkg-maintscript-helper rm_conffile /path/ last-version [14:35] mvo: thank you [14:45] hey, is there any equivalent to the old "snapcraft shell" these days? [14:45] nope [14:46] (you mean "snappy shell" i guess) [14:46] use a classic ubuntu install for now (it will come back) [14:48] abeato: if you want I can give you a quick "gimme classic" shell script that works fairly well [14:49] abeato: I'm sure we'll get proper classic support later on but this is just something that keeps people going [14:49] zyga, that would be great to have :) [14:49] abeato: in a moment, just in a meeting [14:49] (the script) [14:53] sure, thanks [15:02] mvo, so you want the delta shipped *inside* t3eh os snap ? not as a separate tarball ? [15:03] 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] yeah, neat ! never thought of it that way [15:07] zyga: yes I did, why? [15:09] 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] yeah, cant realyl be much [15:23] jdstrand: hey, can I use strace when not in --dev-mode to check what's wrong? [15:23] jdstrand: currently I'm getting a bad system call error [15:23] slangasek: ah, we were just checking if that's you or someone else [15:23] slangasek: thanks for confirming that [15:23] abeato: soon :) [15:23] abeato: testing now [15:23] 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] jdstrand: how does the ubuntu-core-launcher apparmor profile get compiled and applied on install? [15:24] zyga: ah, heh :) [15:24] Trevinho, run "scmp_sys_resolver 101" [15:24] (on your snappy install) [15:25] that will tell you which syscal was blocked [15:25] ogra_: that needs devmode though [15:25] scmp_sys_resolver doesnt need dev mode [15:25] and the blocking should be listed in syslog [15:26] zyga, ack, nw ;) [15:26] ogra_: scmp_sys_resolver 101 [15:26] bash: /usr/bin/scmp_sys_resolver: Permission denied [15:26] this is in a bash launched from a script inside snappy [15:26] oh [15:26] i was talking about a bare ssh shell [15:27] (but i assume yiou are on a desktop machine, sorry, that didnt strike me) [15:27] yeah, this is runing ain a VM, but yeah [15:29] 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] or just use scmp_sys_resolver from outside the snap on a device of the same architecture [15:29] jdstrand: it's ptrace yeah [15:32] ouch... I'm getting the error snap has changes in progress... And I can't remove it :o [15:32] what's happening [15:37] ogra_: do you happen to know how to fix that? ^ [15:37] (it's in yakkety) [15:43] I can't either use gdb... As syscall 135 (personality) get blocked [15:53] zyga mind if I create a storeapi project on gh? [16:10] zyga should I take over https://github.com/ubuntu-core/snapcraft/pull/503 ? [16:11] sergiusens: not at all, let's do it [16:11] sergiusens: looking [16:11] sergiusens: yes, please, I didn't notice that feedback at all, I have a backlog of email to read [16:11] sergiusens: and thank you! [16:12] zyga sure thing, ping me if you have any questions [16:12] sergiusens: thanks [16:12] zyga well thanks for contributing to snapcraft ;-) [16:12] 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] jdstrand: canbus is just a socket FYI [16:14] 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] 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] Trevinho, that broken lib path looks suspicious [16:16] (misses the arch in the triplet) [16:17] ah mhm [16:20] * Trevinho launching the core-laucnher gives me another issue instead http://pastebin.ubuntu.com/16636006/ [16:21] Trevinho, is the launcher suid root? [16:21] 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] kyrofa: not sure... I've just launched what's inside the generated launcher script [16:22] jdstrand: thanks [16:23] ah... I'm getting something new now [16:23] 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] 141 = setpriority [16:24] 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] Trevinho that should be fixed in whatever is supposed to be released soon I've been told [16:25] sergiusens: ah, nice [16:25] Trevinho: yes, I was able to get things running. I thought I mentioned that in a bug/card... [16:25] jdstrand: mh, maybe I'm not in that card/bug :) [16:25] 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] sergiusens: I'm back from not having a weekend and I feel the same :) [16:26] but you had vampires at least ! [16:27] * zyga enjoys tasty vampires [16:27] raw, not well-made [16:27] ;) [16:27] but with fresh garlic :) [16:27] 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] jdstrand: how can I unload an apparmor profile reliably? [16:27] 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] bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] https://launchpad.net/bugs/1577514 [16:27] zyga: apparmor_parser -R /path/to/profile [16:28] jdstrand: ahh, path to profile [16:28] I assumed it was the profile name only [16:28] is it possible to remove a profile by name? [16:28] Trevinho we actually don't want something that manages patches. It is essentially a forked code base so it is no different [16:28] there is another way via the /sys interface that I always forget [16:28] jdstrand: I'm trying to remove ubuntu-core-launcher profile [16:28] quilt is really tied to the packaging world [16:28] jdstrand: after the upgrade to snap-run [16:29] 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] jdstrand: (and in general, how is the profile updated on package update?) [16:29] sergiusens: we had some discussion in https://bugs.launchpad.net/snapcraft/+bug/1551716 and there seems to be general consensus to that [16:29] Launchpad bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New] [16:30] 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] 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] https://github.com/ubuntu-core/snappy/pull/1193 [16:30] sergiusens: I come up with an hackish quilt build plugin, but it requires some yaml code which is not really so nice. [16:30] actually, maybe it is just that one [16:30] meh, I thought I fixed my procmail... [16:31] beowulf I get a 404 there [16:31] but happy to look [16:32] 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] 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] 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] jdstrand: looking at 1193 [16:44] Trevinho a patchset you need to maintain is exactly a fork though [16:45] 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] 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] Trevinho running a tool now is completely different than a patchset, right? [16:46] 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] 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] 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] 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] 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] sergiusens: yes, but you can set that via env so i didn't think it was such an issue [16:52] sergiusens: or does that not work with the plugin? [16:54] zyga: so, with the change to snap-run, all pending MPs need to be migrated? [16:55] jdstrand: yep [16:56] 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] jdstrand: I can help if anyone gets stuck [16:57] jdstrand: One more for your review requeue: https://github.com/ubuntu-core/snappy/pull/1202/files [17:02] 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] sergiusens: right, makes sense [17:28] sergiusens: have you considered having a part plugin which could pull parts from repos similar to apps sources? [17:56] Is Claudio Andre around here? [17:58] jdstrand: ping [18:08] josepht apps sources? [18:09] niemeyer_: hey [18:09] jdstrand: Heya [18:09] jdstrand: Any further points on the pulseaudio interface or do you think we can merge it now without any bad consequences? [18:10] jdstrand: Other than the recording issue we debated already [18:10] I think it is ok so long as we are pursuing that SRU. lemme double check [18:13] 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] (snap/implicit.go) [18:15] I think since this is simple file rules, the policy would work for core too [18:16] 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] anyway, I'm not saying we should block on that, just adding some context [18:18] 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] jdstrand: The opposite is more of a problem (an interface that does _not_ work on classic) [18:19] sergiusens: sorry parts sources. What I'm referring to is for shared parts (i.e. those on the wiki currently) [18:22] jdstrand: About that opencl interface, do you know what usually lands on that /etc directory? [18:22] jdstrand: Is that hardware specific, or just app config? [18:23] jdstrand: I assumed it was hardware-specific, but I was jumping to conclusions too soon [18:25] 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] too* [18:26] for example, my laptop doesn't have that directory [18:27] 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] niemeyer_: we should really get someone that knows opencl inside out to assist on that one [18:49] zyga: Well, we just need some basic info to get unblocked [18:49] zyga: As long as we don't do anything silly, it's okay to have a seed interface in [18:54] niemeyer_: I agree [18:55] niemeyer_: I can ask, I know a canonicaler that knows more [18:55] zyga: Sweet, thanks [18:56] 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] 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] jdstrand: Sorry for bothering more than usual today.. we're trying to clean up the long-standing queue [19:09] done [19:09] np [19:15] zyga: hi! do you know any reason why ubuntu-image.sh shouldn't work right now? https://pastebin.canonical.com/157054/ [19:21] 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] Where can I find the snap.yaml + the instruction to snap my own kernel/modules for a raspi2 - using the current method? [19:23] I know you guys are changing things for the better, but I'd like to get along on my project - too impatient [19:25] pmp have you seen http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ ? [19:28] kyrofa: great. Do you also know where I can find the snapcraft.yaml for raspi2;s kernel currently in use ? [19:31] pmp that I don't know. ogra_ might [19:31] how does snapcraft find the right cross-compiler? [19:31] fg [19:31] 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:31] Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New] [19:32] pmp it has a list of supported architectures [19:33] pmp, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/_options.py#L27 for example [19:34] kyrofa: great article, answers a lot of questions [19:34] pmp, thank sergiusens :) [19:34] sergiusens: thanks ;-0 [19:35] It'll be nice to have an overview somewhere of all the blog-articles done by you guys. [19:35] Or announce everyone of them on the mailing list in addition [19:37] beowulf: hey [19:37] beowulf: looking [19:38] beowulf: not really.. is that most up-to-date version? [19:38] beowulf: maybe store changed on us in some way [19:38] zyga: should be, let me check ... [19:38] 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] zyga: great :) [19:39] zyga: yes, it's the latest with the 5s sleep [19:39] beowulf: no root, faster implementation, etc etc [19:39] beowulf: but still depends on working store ;) [19:39] beowulf: though it will have an offline more [19:40] beowulf: lots of goodies [19:41] beowulf: building one myself for 'pc' [19:41] beowulf: so far builds fine [19:42] beowulf: can you check syslog [19:42] beowulf: I bet your kernel oops'ed [19:42] beowulf: reboot and re-run [19:42] beowulf: new ubuntu-image won't rely on any kernel feaatures so it should never crash like that [19:44] zyga: sorry, i have wasted your time, i keep forgetting this doesn't work in a container :( [19:45] zyga: i'm in a xenial container, it works when i'm on the host (i already knew this, sorry!) [19:49] 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] pmp you are welcome I guess :-) [19:51] thomi looked and I am thinking of taking the hit right now to solve this [19:52] sergiusens: thanks! It'd be great to be able to upload my snap [19:58] zyga: stackoverflow and online-services suggest `sudo grep -qa container=lxc /proc/1/environ`... will have a go at a pr later [20:07] 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] mhall119, you probably want this series of blog posts: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html [20:08] mhall119, but to quickly answer your question, that interface is part of snapd itself [20:09] mhall119, so making new ones involves writing some go [20:09] kgunn: I saw your response on qt webengine and was curious why oxide wasn't mentioned? [20:09] mhall119, the blog posts will have a bit more information [20:09] jdstrand: just didn't think of it ;) [20:10] * jdstrand nods [20:10] jdstrand: i guess i was trying to get mir out there.... [20:10] I wasn't sure if there was some reason why it couldn't be used [20:11] jdstrand: it could certainly be a potential stack configuration for the fellow's use case [20:11] would be even better if we had native chrome-mir ;) [20:11] better=one less thing to pull into the snap [20:16] kyrofa: is that the long-term design, or a temporary measure to get the unity7 interface? [20:17] beowulf: fantastic, thank you [20:17] mhall119: hey, it comes from snapd itself, it's added to the core snap when running on classic [20:18] mhall119: that's long term design for *classic* [20:18] mhall119: tell me what you want and I can tell you what you need to get there [20:18] zyga: ok, so what's the long term design for non-unity7 classic desktops? [20:18] zyga: my specific use case is kubuntu, where they will likely need a kframeworks5 interface [20:18] mhall119: that depends on what they need, many will work with unity7 [20:19] mhall119: unity7 is really granting you right to use various unit7 specific APIs [20:19] so as not to include every KDE dependency in their packages [20:19] mhall119: for packaging apps for KDE I'd start with x11 for the desktop part [20:19] mhall119: and with the (not implemented yet) content sharing interface for kde runtime [20:19] 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] mhall119: that we can then split into two while keeping it functioning as before [20:20] mhall119: though perhaps another approach is required for proper kde support [20:20] mhall119: (as in real access to classic KDE services and libraries) [20:20] mhall119: for that we need some features that are under development by the security team and by snappy core team (bind mounts) [20:21] mhall119: then we could do interesting new things [20:21] 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] 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] mhall119: note that unity7 doesn't give you any runtime libraries, just dbus permission and some basic "talk to x11" bits [20:23] zyga: you lost me, how would the content-sharing interface be used for the runtime? [20:24] mhall119: sorry, there's a lot of context I assume you have, let me do it with more explanations [20:25] mhall119: the content sharing interface grants you access to files from another snap as if they were your own [20:25] is content-sharing like content-hub on the phone,or something totally different? [20:25] 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] mhall119: it's not lile the content hub [20:25] ok, that's where the confusion hit me :) [20:25] mhall119: tink of runtime sharing for instance (java, kde, qt, etc etc etc) [20:26] yes, that's what I want [20:26] a platform in a snap, basically [20:26] mhall119: yep [20:26] mhall119: there are a few things we need to implement before that is possible [20:26] mhall119: permission side is simple, but we need to inform the consumers of where to find the shared parts [20:26] mhall119: and we need to re-construct some magic to make it seem seamless (shared libraries, executables, etc) [20:27] zyga: ack, ok, this is all making sense now [20:27] mhall119: those are just generic new features of snapd and snap-run (nee ubuntu-core-launcher) that need to happen first [20:27] mhall119: I bet we'll get some kde specific interface over time but that's the first approach I would have [20:27] mhall119: something to let us understand kde better [20:28] zyga: ack, I'm working on kcalc right now, will be back once I have it working [20:29] mhall119: cool, cheersr, I'll ping you each time something new lands towards that goal [20:44] thanks zyga [21:04] elopio reproduced on x86: bug #1551570 [21:05] bug 1551570 in Snapcraft "autopkgtests fail in armhf with sudo: no tty present and no askpass program specified" [Medium,Triaged] https://launchpad.net/bugs/1551570 [21:05] 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] 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] beowulf: beowulf perhaps with doublequote $@ doublequote at the end, in your wrapper. [21:31] 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] thomi may I ask you to play with https://bugs.launchpad.net/snapcraft/+bug/1582513/comments/8 ? [21:37] Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New] [21:37] zyga also want to look at that ^ ? [21:37] sergiusens: sure thing [21:46] qengho: thanks! [21:48] sergiusens: Any chance you could build a .deb and stick it somewhere? It seems snapcraft doesn't install easily into a virtualenv? [21:56] thomi yeah, I inherited this like it is, I need to work on a requirements.txt to make this work well [21:56] thomi scp from people.canonical.com:/home/sergiusens/snapcraft_2.8.8_all.deb [21:58] thomi btw, I made some changes to your yaml http://paste.ubuntu.com/16644344/ (using the public git and relative `command`) [21:59] huh, cool. I don't know about 'command' [22:02] 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] that last one is just personal preference fwiw [22:02] huh, Interesting, thanks [22:07] sergiusens: looking [22:07] sergiusens: use the ... what in ubuntu core? [22:07] python? [22:12] sergiusens: wow - 55MB to 144KB [22:14] thomi: same will be possible with a (say) python3.canonical snap and content sharing [22:15] sergiusens: however, the snaps now consistently fail review because the checksums do not match [22:15] sergiusens: security-snap-v2_squashfs_repack_checksum is the failing check [22:16] thomi heh, that I think is a mksquashfs bug jdstrand was looking into [22:16] :( [22:16] zyga the python, yes [22:16] thomi yeah, not sure what triggers even [22:17] zyga do you know the bug number for the checksum thing? [22:17] sergiusens: I cannot wait to do that :) [22:17] sergiusens: no, sorry [22:17] zyga do what? [22:17] sergiusens: write the content sharing iface [22:18] 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] sergiusens: it's a loong way ;-) [22:19] in reality it requires a few features that are in the pipe [22:20] jdstrand when you are around, do we have a bug for that mksquashfs thing? [22:37] sergiusens: cool, you simplifyied the code a lot. [22:38] just the "pass" in the tests makes me feel uneasy ;) [22:40] elopio: yes, it should have been a docstring, then pass is optional ;) [22:42] zyga: no me simpatizas. === yp is now known as Guest72068 === leftyfb_ is now known as leftyfb === Michaela is now known as Mikaela === |svij| is now known as svij === Guest72068 is now known as ypwong === wililupy_ is now known as wililupy [23:00] question: how do I purge a snap from 16.04? [23:24] wililupy: snap remove $snap_name [23:24] wililupy: that's all you need [23:24] 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] zyga and it still shows it in /writable/system-data/snap but not in snap list [23:25]