| === 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 | ||
| zyga | good morning | 08:19 |
|---|---|---|
| davidcalle | Morning zyga | 08:20 |
| zyga | davidcalle: hey :-) | 08:20 |
| === vrruiz_ is now known as rvr | ||
| OsakaFoo | can I access the snappy store from the web? | 09:58 |
| ogra_ | there is an API | 09:59 |
| === chihchun is now known as chihchun_afk | ||
| 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 | 09:59 |
| OsakaFoo | oh yeah | 10:02 |
| OsakaFoo | thanks | 10:02 |
| OsakaFoo | is it possible to run snaps on ubuntu-touch? | 10:03 |
| ogra_ | not yet, no | 10:03 |
| 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:04 |
| OsakaFoo | nice | 10:05 |
| === chihchun_afk is now known as chihchun | ||
| === alex-abreu is now known as alex-abreu|off | ||
| 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:54 |
| 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:57 |
| 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 | 12:59 |
| bencc | erlang is smart to not stop running processes (Erlang processes) but use the new version in the next run | 13:00 |
| bencc | zyga: nginx let's you update the deb package without restarting the daeomn | 13:01 |
| bencc | how does a normal snap update work? | 13:02 |
| zyga | bencc: interesting | 13:08 |
| zyga | bencc: seems like lisp image in many ways | 13:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| niemeyer_ | jdstrand, tyhicks: Any news on the environ setting issue? | 13:16 |
| bencc | zyga: do I need to explain about erlang in the bug report? | 13:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| zyga | bencc: yes, on any ubuntu really :) | 13:21 |
| bencc | nice | 13:22 |
| niemeyer_ | zyga: It's a bit tricky to be effective at "start looking" :) | 13:26 |
| 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:27 |
| niemeyer_ | zyga: and have reviews just as usual | 13:28 |
| bencc | zyga: https://bugs.launchpad.net/snappy/+bug/1584779 | 13:28 |
| ubottu | Launchpad bug 1584779 in Snappy "Upgrade a running snap without restarting it" [Undecided,New] | 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:28 |
| 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:29 |
| zyga | jdstrand: https://github.com/ubuntu-core/snap-run/pull/1/files | 13:34 |
| zyga | niemeyer_: ack, done right now | 13:35 |
| === chihchun is now known as chihchun_afk | ||
| niemeyer_ | jdstrand: Thanks, will catch up with Tyler | 13:52 |
| niemeyer_ | jdstrand: When you have a moment, can you have a look at https://github.com/ubuntu-core/snappy/pull/1201 | 13:53 |
| zyga | slangasek: hey, did you propose a pull request to snappy, for os-release support? | 13:59 |
| 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:25 |
| 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:29 |
| zyga | jdstrand: ah, /etc/apparmor.d/usr.bin.ubuntu-core-launcher is a conffile | 14:32 |
| zyga | jdstrand: bummer :) | 14:32 |
| zyga | mvo: how do I remove a conffile from a maintainer script with as little pain as I can? | 14:33 |
| mvo | zyga: dpkg-maintscript-helper rm_conffile /path/ last-version | 14:34 |
| zyga | mvo: thank you | 14:35 |
| abeato | hey, is there any equivalent to the old "snapcraft shell" these days? | 14:45 |
| ogra_ | nope | 14:45 |
| ogra_ | (you mean "snappy shell" i guess) | 14:46 |
| ogra_ | use a classic ubuntu install for now (it will come back) | 14:46 |
| zyga | abeato: if you want I can give you a quick "gimme classic" shell script that works fairly well | 14:48 |
| 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:49 |
| abeato | sure, thanks | 14:53 |
| ogra_ | mvo, so you want the delta shipped *inside* t3eh os snap ? not as a separate tarball ? | 15:02 |
| 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:03 |
| ogra_ | yeah, neat ! never thought of it that way | 15:04 |
| slangasek | zyga: yes I did, why? | 15:07 |
| 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:09 |
| ogra_ | yeah, cant realyl be much | 15:10 |
| 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:23 |
| slangasek | zyga: ah, heh :) | 15:24 |
| ogra_ | Trevinho, run "scmp_sys_resolver 101" | 15:24 |
| ogra_ | (on your snappy install) | 15:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:32 |
| Trevinho | ogra_: do you happen to know how to fix that? ^ | 15:37 |
| Trevinho | (it's in yakkety) | 15:37 |
| Trevinho | I can't either use gdb... As syscall 135 (personality) get blocked | 15:43 |
| sergiusens | zyga mind if I create a storeapi project on gh? | 15:53 |
| sergiusens | zyga should I take over https://github.com/ubuntu-core/snapcraft/pull/503 ? | 16:10 |
| 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:11 |
| 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:12 |
| zyga | jdstrand: canbus is just a socket FYI | 16:13 |
| 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:14 |
| ogra_ | Trevinho, that broken lib path looks suspicious | 16:16 |
| ogra_ | (misses the arch in the triplet) | 16:16 |
| Trevinho | ah mhm | 16:17 |
| * Trevinho launching the core-laucnher gives me another issue instead http://pastebin.ubuntu.com/16636006/ | 16:20 | |
| 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:21 |
| Trevinho | kyrofa: not sure... I've just launched what's inside the generated launcher script | 16:22 |
| zyga | jdstrand: thanks | 16:22 |
| 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:23 |
| 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:24 |
| 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:25 | |
| 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:26 |
| * 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 |
| ubottu | bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] https://launchpad.net/bugs/1577514 | 16:27 |
| jdstrand | zyga: apparmor_parser -R /path/to/profile | 16:27 |
| 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:28 |
| 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:29 |
| ubottu | Launchpad bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New] | 16:29 |
| 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:30 |
| sergiusens | beowulf I get a 404 there | 16:31 |
| sergiusens | but happy to look | 16:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| zyga | jdstrand: looking at 1193 | 16:42 |
| sergiusens | Trevinho a patchset you need to maintain is exactly a fork though | 16:44 |
| 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:45 |
| 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:46 |
| 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:48 |
| 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:49 |
| 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:51 |
| 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:52 |
| jdstrand | zyga: so, with the change to snap-run, all pending MPs need to be migrated? | 16:54 |
| zyga | jdstrand: yep | 16:55 |
| 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:56 |
| niemeyer_ | jdstrand: One more for your review requeue: https://github.com/ubuntu-core/snappy/pull/1202/files | 16:57 |
| 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:02 |
| beowulf | sergiusens: right, makes sense | 17:06 |
| josepht | sergiusens: have you considered having a part plugin which could pull parts from repos similar to apps sources? | 17:28 |
| niemeyer_ | Is Claudio Andre around here? | 17:56 |
| niemeyer_ | jdstrand: ping | 17:58 |
| sergiusens | josepht apps sources? | 18:08 |
| 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:09 |
| 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:10 |
| 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:13 |
| jdstrand | (snap/implicit.go) | 18:14 |
| jdstrand | I think since this is simple file rules, the policy would work for core too | 18:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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:22 |
| niemeyer_ | jdstrand: I assumed it was hardware-specific, but I was jumping to conclusions too soon | 18:23 |
| 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:25 |
| jdstrand | too* | 18:26 |
| jdstrand | for example, my laptop doesn't have that directory | 18:26 |
| 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:27 |
| 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:49 |
| zyga | niemeyer_: I agree | 18:54 |
| zyga | niemeyer_: I can ask, I know a canonicaler that knows more | 18:55 |
| niemeyer_ | zyga: Sweet, thanks | 18:55 |
| 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) | 18:56 |
| 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:01 |
| jdstrand | done | 19:09 |
| jdstrand | np | 19:09 |
| beowulf | zyga: hi! do you know any reason why ubuntu-image.sh shouldn't work right now? https://pastebin.canonical.com/157054/ | 19:15 |
| 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:21 |
| pmp | Where can I find the snap.yaml + the instruction to snap my own kernel/modules for a raspi2 - using the current method? | 19:22 |
| pmp | I know you guys are changing things for the better, but I'd like to get along on my project - too impatient | 19:23 |
| kyrofa | pmp have you seen http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ ? | 19:25 |
| pmp | kyrofa: great. Do you also know where I can find the snapcraft.yaml for raspi2;s kernel currently in use ? | 19:28 |
| 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:31 |
| ubottu | Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New] | 19:31 |
| kyrofa | pmp it has a list of supported architectures | 19:32 |
| kyrofa | pmp, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/_options.py#L27 for example | 19:33 |
| pmp | kyrofa: great article, answers a lot of questions | 19:34 |
| kyrofa | pmp, thank sergiusens :) | 19:34 |
| pmp | sergiusens: thanks ;-0 | 19:34 |
| 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:35 |
| zyga | beowulf: hey | 19:37 |
| zyga | beowulf: looking | 19:37 |
| 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:38 |
| 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:39 |
| zyga | beowulf: lots of goodies | 19:40 |
| zyga | beowulf: building one myself for 'pc' | 19:41 |
| zyga | beowulf: so far builds fine | 19:41 |
| 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:42 |
| beowulf | zyga: sorry, i have wasted your time, i keep forgetting this doesn't work in a container :( | 19:44 |
| beowulf | zyga: i'm in a xenial container, it works when i'm on the host (i already knew this, sorry!) | 19:45 |
| 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:49 |
| 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:51 |
| thomi | sergiusens: thanks! It'd be great to be able to upload my snap | 19:52 |
| beowulf | zyga: stackoverflow and online-services suggest `sudo grep -qa container=lxc /proc/1/environ`... will have a go at a pr later | 19:58 |
| 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:07 |
| 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:08 |
| 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:09 |
| * 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:10 |
| 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:11 |
| mhall119 | kyrofa: is that the long-term design, or a temporary measure to get the unity7 interface? | 20:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| mhall119 | zyga: you lost me, how would the content-sharing interface be used for the runtime? | 20:23 |
| zyga | mhall119: sorry, there's a lot of context I assume you have, let me do it with more explanations | 20:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| mhall119 | zyga: ack, I'm working on kcalc right now, will be back once I have it working | 20:28 |
| zyga | mhall119: cool, cheersr, I'll ping you each time something new lands towards that goal | 20:29 |
| mhall119 | thanks zyga | 20:44 |
| sergiusens | elopio reproduced on x86: bug #1551570 | 21:04 |
| ubottu | 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 |
| 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:05 |
| 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:15 |
| qengho | beowulf: beowulf perhaps with doublequote $@ doublequote at the end, in your wrapper. | 21:16 |
| 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:31 |
| sergiusens | thomi may I ask you to play with https://bugs.launchpad.net/snapcraft/+bug/1582513/comments/8 ? | 21:37 |
| ubottu | Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New] | 21:37 |
| sergiusens | zyga also want to look at that ^ ? | 21:37 |
| thomi | sergiusens: sure thing | 21:37 |
| beowulf | qengho: thanks! | 21:46 |
| thomi | sergiusens: Any chance you could build a .deb and stick it somewhere? It seems snapcraft doesn't install easily into a virtualenv? | 21:48 |
| 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:56 |
| sergiusens | thomi btw, I made some changes to your yaml http://paste.ubuntu.com/16644344/ (using the public git and relative `command`) | 21:58 |
| thomi | huh, cool. I don't know about 'command' | 21:59 |
| 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:02 |
| zyga | sergiusens: looking | 22:07 |
| zyga | sergiusens: use the ... what in ubuntu core? | 22:07 |
| zyga | python? | 22:07 |
| thomi | sergiusens: wow - 55MB to 144KB | 22:12 |
| zyga | thomi: same will be possible with a (say) python3.canonical snap and content sharing | 22:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| sergiusens | zyga you have been saying that for a year already it feels like :-) | 22:18 |
| * 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:19 |
| sergiusens | jdstrand when you are around, do we have a bug for that mksquashfs thing? | 22:20 |
| elopio | sergiusens: cool, you simplifyied the code a lot. | 22:37 |
| elopio | just the "pass" in the tests makes me feel uneasy ;) | 22:38 |
| zyga | elopio: yes, it should have been a docstring, then pass is optional ;) | 22:40 |
| elopio | zyga: no me simpatizas. | 22:42 |
| === 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 | ||
| wililupy | question: how do I purge a snap from 16.04? | 23:00 |
| 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:24 |
| 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:25 |
| 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:27 |
| wililupy | zyga: still get the same error. | 23:28 |
| 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:32 |
| mhall119 | specifically the apparmor complaints, I have no idea what it's doing or why, but it seems strange for a calculator | 23:33 |
| wililupy | zyga: when I tried to remove the snap, I did get an error: https://pastebin.canonical.com/157073/ | 23:36 |
| === sarnold_ is now known as sarnold | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!