| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === shuduo-afk is now known as shuduo | ||
| === chihchun_afk is now known as chihchun | ||
| === JanC_ is now known as JanC | ||
| === kickinz1|eod is now known as kickinz1 | ||
| T-mon | #unity | 08:07 |
|---|---|---|
| === JamesTait is now known as Guest31919 | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === t-mon|2 is now known as T-mon | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| sergiusens | morning | 12:28 |
| sergiusens | kyrofa, is this good to go? https://github.com/ubuntu-core/snapcraft/pull/429 | 12:28 |
| kyrofa | Ah, sorry sergiusens looking now | 12:29 |
| kyrofa | sergiusens, yeah I'm liking this | 12:30 |
| kyrofa | sergiusens, looks like a pip hickup on the webui test? | 12:31 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/801 | 12:34 |
| noizer | Hi guys how is it with the stable release of snappy? | 12:35 |
| zyga | noizer: perhaps next week | 12:39 |
| noizer | zyga: niceee :D | 12:39 |
| zyga | noizer: all depends on how good this week is :) | 12:39 |
| noizer | zyga: Ok but that is just good news! | 12:42 |
| sergiusens | kyrofa, its been like this the whole week | 12:44 |
| ogra_ | sergiusens, yo | 12:44 |
| kyrofa | *grumble* | 12:44 |
| sergiusens | kyrofa, but it works locally and on whatever the official autopackage tests servers are | 12:45 |
| ogra_ | sergiusens, so i'm planning to get rid of the binary initrd-generic package ... | 12:45 |
| sergiusens | it is in my opinion and as elopio pointed out, scalingstack | 12:45 |
| sergiusens | ogra_, why are you so mean? | 12:45 |
| sergiusens | :-) | 12:45 |
| ogra_ | sergiusens, because i cant bear the headdaches that fakechroot gives me :) | 12:46 |
| ogra_ | sergiusens, so the plan is to run update-initramfs during image build before a kernel is installed | 12:46 |
| sergiusens | ogra_, I will unleash the kraken on you by calling ricmm ;-) | 12:46 |
| ogra_ | that should give us the same result but with a lot less hoops | 12:46 |
| ogra_ | hahaha | 12:46 |
| sergiusens | ogra_, that means the image building tool is arch dependant? | 12:47 |
| ogra_ | you download the os snap anyway, right ? | 12:47 |
| sergiusens | yes | 12:47 |
| ogra_ | indeed, it has always been arch dependent | 12:47 |
| ogra_ | so if i make sure the binary ends up in the same place the package did put it i guess we are fine | 12:48 |
| ogra_ | (and if i keep the name) | 12:48 |
| sergiusens | ogra_, oh, so if you don't break the "interface" I really don't care :-) | 12:49 |
| sergiusens | as long as a kernel generic initrd lands there | 12:49 |
| ogra_ | sergiusens, well, long term i'd like to clean that up | 12:49 |
| ogra_ | and keep the initrd in /boot or so | 12:50 |
| sergiusens | which would also allow for step two which is for snappy to deal with that whole lot | 12:50 |
| ogra_ | right | 12:50 |
| ogra_ | for now i only want to get rid of fakechroot in the whole loop | 12:50 |
| ogra_ | (and also save one turnaround cycle in the whole game ... i.e. no extra upload of the package) | 12:51 |
| sergiusens | ogra_, well the discussion with infinity was that the os snap would provide a kernel indep initrd and the kernel snap the one with modules; snappy would DTRT WRT how to deal with that | 12:51 |
| ogra_ | right | 12:51 |
| ogra_ | which is what i'm proposing above | 12:51 |
| sergiusens | ogra_, your plan is sane ;-) | 12:51 |
| ogra_ | i initially went the package route because that makes it easier for porters | 12:51 |
| ogra_ | you only need to pull the one package, not the whole os snap ... but in the end it is more work and more risk on our side to do that | 12:52 |
| sergiusens | ogra_, yeah, and fwiw, I didn't even take a hint on your guidance and just downloaded the os.snap ;-) | 12:53 |
| ogra_ | yeah | 12:54 |
| ogra_ | so evil ! | 12:54 |
| ogra_ | :) | 12:54 |
| zyga | https://github.com/ubuntu-core/snappy/pull/803 | 13:00 |
| zyga | jdstrand: ^ before we get the OS snap to declare those | 13:03 |
| kyrofa | zyga, I have a piece of hardware whose install process in regular ubuntu involves a custom udev rule that runs its own script. Is there a way to do something equivalent in snappy using interfaces? | 13:10 |
| zyga | kyrofa: yes | 13:12 |
| zyga | kyrofa: can you tell me more? | 13:12 |
| kyrofa | zyga, definitely. It's an intel RealSense camera (similar to xbox kinect, gets depth information). The classic installation guide is here: https://github.com/IntelRealSense/librealsense/blob/master/doc/installation.md | 13:13 |
| zyga | ah, I'm familiar with it | 13:13 |
| kyrofa | zyga, I'm hoping I don't actually need to patch uvcvideo, and that the only thing I'll actually need are the udev rules | 13:15 |
| kyrofa | (since I know our kernel folks were working with them recently) | 13:15 |
| zyga | kyrofa: does it require a kernel driver or is current kernel supported? | 13:15 |
| zyga | kyrofa: this looks more like something to fix in the os snap | 13:15 |
| zyga | kyrofa: and then expose as an interface for snaps to use | 13:15 |
| kyrofa | zyga, I'm led to believe our kernel should support it, but I've not verified just yet | 13:15 |
| zyga | kyrofa: in any case, yes, we can do suff with udev | 13:16 |
| zyga | kyrofa: but you need to have a working kernel and you need to define the interface first (how apps would use this device) | 13:16 |
| kyrofa | zyga, alright good deal. I'll get it working in a normal installation first and make sure I understand what's required, then I'll talk to you about the interface. Sound okay? | 13:17 |
| zyga | kyrofa: yes, and once you are ready start a thread on snappy-devel please | 13:17 |
| kyrofa | zyga, sounds good | 13:17 |
| zyga | kyrofa: good | 13:17 |
| zyga | :) | 13:17 |
| === chihchun is now known as chihchun_afk | ||
| kyrofa | sergiusens, I want to talk about https://bugs.launchpad.net/snapcraft/+bug/1537790 real quick | 13:40 |
| ubottu | Launchpad bug 1537790 in Snapcraft "lifecycle: rebuild with snapcraft clean part1; snapcraft build part1 breaks if part1 has an 'after' field" [High,In progress] | 13:40 |
| kyrofa | sergiusens, currently is part1 depends on part2, and you call `snapcraft build part1` it bails since it requires part2. So you have to say `snapcraft build part1 part2` | 13:41 |
| kyrofa | sergiusens, how would you feel about it automatically building dependencies? | 13:42 |
| sergiusens | kyrofa, currently with the new changes you mean? Previously we built through all of them | 14:03 |
| sergiusens | kyrofa, we can do either; I like explicit so you know the implications | 14:04 |
| sergiusens | but implicit is easier | 14:04 |
| kyrofa | sergiusens, nothing new-- this is old. This test, specifically: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/tests/test_lifecycle.py#L30 | 14:04 |
| kyrofa | sergiusens, well, when I implemented the per-part cleaning for instance I made sure dependents were cleaned as well. I should probably either update that to raise for consistency, or update this to build dependencies for consistency. What do you think? | 14:06 |
| kyrofa | per-step, rather | 14:06 |
| sergiusens | kyrofa, ok, let's discuss that during standup | 14:07 |
| kyrofa | sergiusens, sounds good | 14:07 |
| zyga | https://github.com/ubuntu-core/snappy/pull/804 | 14:19 |
| zyga | jdstrand: ^^ probably not super security sensitive | 14:23 |
| zyga | jdstrand: I'm persistently storing intents-to-connect | 14:23 |
| zyga | jdstrand: so that when you upgrade a snap it gets re-connected | 14:23 |
| zyga | jdstrand: there's no policy as to what happens when you remove a snap | 14:23 |
| jdstrand | boy, lots of PRs :) | 14:23 |
| zyga | jdstrand: heh, two days left :) | 14:23 |
| zyga | jdstrand: I have lots of more locally but I'm blocked by bit landing now | 14:24 |
| jdstrand | what's in two days? | 14:24 |
| zyga | jdstrand: weekend | 14:24 |
| zyga | jdstrand: I'd like to have peace of mind :) | 14:24 |
| jdstrand | oh, heh | 14:24 |
| jdstrand | then they pick up again next week, got it :) | 14:24 |
| zyga | and actually work on my hobby compiler | 14:24 |
| zyga | and use snappy to package a few games for my kids | 14:24 |
| zyga | not that they have ssh or gpg keys in ~ | 14:25 |
| jdstrand | it would be nice to not dream about what is left to land every night and wake up at a reasonable time | 14:25 |
| zyga | jdstrand: you can say that again; | 14:25 |
| zyga | but I think we're super close now | 14:26 |
| zyga | the only thing I'm worried about is everything not working in the end :D | 14:26 |
| zyga | because of small issues that will be frustrating to fix for some unexpected reason | 14:26 |
| jdstrand | I suspect those issues will be shallow | 14:27 |
| jdstrand | at least for the existing builtins | 14:27 |
| zyga | unless we forgot something major but I hope we didn't | 14:27 |
| zyga | e.g. mandatory launcher change to fix something that's not fixable otherwise | 14:27 |
| jdstrand | I've been working on the launcher a lot lately | 14:28 |
| jdstrand | I think we are in ok shape wrt the security sandbox and interfaces. I've brought up what I know is missing | 14:29 |
| zyga | jdstrand: pedronis is about to land some changes to how we invoke the launcher | 14:29 |
| zyga | jdstrand: but that will change in a sec so even if we break something, it's temporary | 14:29 |
| jdstrand | zyga: does that require a launcher change? | 14:29 |
| kyrofa | pedronis, are you planning on removing the creation of the user data dir from the binary wrapper as well? | 14:29 |
| jdstrand | or just the scripts/systemd stuff | 14:29 |
| zyga | jdstrand: I don't think so; do you still parse the apparmor profile for snap version? | 14:30 |
| zyga | jdstrand: in any case, I plan to see if this really works soon | 14:30 |
| zyga | jdstrand: so we'll know :) | 14:31 |
| jdstrand | zyga: the launcher doesn't parse the appname or apparmor profile name. it just takes what it is given | 14:32 |
| zyga | jdstrand: then it should work :) | 14:32 |
| jdstrand | zyga: it does a light regex: "^[a-z0-9][a-z0-9+._-]+$" | 14:32 |
| jdstrand | but that is all | 14:33 |
| zyga | mmm, should be fine | 14:33 |
| jdstrand | zyga: is this the snap.<snapname>.<app> change? | 14:33 |
| zyga | jdstrand: not yet | 14:33 |
| zyga | jdstrand: that's what interfaces do | 14:33 |
| * jdstrand wonders what change this is | 14:33 | |
| zyga | jdstrand: just gardening | 14:33 |
| jdstrand | ok | 14:33 |
| zyga | jdstrand: snappy has lots of redundant ideas | 14:33 |
| zyga | jdstrand: we're killing some because it's impossible to make changes otherwise | 14:34 |
| jdstrand | I see | 14:36 |
| * zyga will return ~ 1 hour | 15:01 | |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | elopio, kyrofa seems our issue might be an upstream one https://bitbucket.org/ronaldoussoren/pyobjc/issues/141/error-code-9-with-pip-install-on-osx-10111 http://stackoverflow.com/questions/19632714/installation-error-of-python-package-using-pip | 15:23 |
| sergiusens | I guess we can version lock pyyaml to avoid this | 15:23 |
| kyrofa | sergiusens, good find! | 15:24 |
| === chihchun is now known as chihchun_afk | ||
| === kickinz1 is now known as kickinz1|eod | ||
| mhall119 | sergiusens: is there a way to tell snapcraft the order in which to build parts? Or does it follow the order they are defined in the yaml? | 15:57 |
| elopio | mhall119: you can alter the order with the after keyword. If you don't use that, then it would be the order in which python parses the yaml, which afaik is not always the same. | 16:00 |
| elopio | sergiusens: thanks for the link. | 16:00 |
| mhall119 | thanks elopio | 16:02 |
| sergiusens | mhall119, yaml by definition has no order; if you have dependencies use the `after` key | 16:03 |
| kyrofa | Hey jdstrand what are the security limitations of `kill` in snappy? e.g. if I have a stop command for my service, am I limited in the signals I can send or the pids I can send them to? (I assume yes in the latter at least) | 16:22 |
| jdstrand | kyrofa: you can send any signal to any app in your snap | 16:24 |
| kyrofa | jdstrand, okay good deal | 16:24 |
| jdstrand | kyrofa: you may not send signals to other snaps | 16:24 |
| kyrofa | jdstrand, alright perfect, thank you :) | 16:25 |
| qengho | kyrofa: yeah, I kill in one of mine. No trouble. | 16:26 |
| kyrofa | I do too, just wanted to make sure I understood the limitations | 16:26 |
| qengho | Though, I suspect I should be using systemd somehow to restart or signal it to reload. I don't understand systemd. :( | 16:27 |
| code1o6 | ssls | 17:41 |
| code1o6 | Is manik in today? | 17:41 |
| netphreak | Hi, guys! | 18:24 |
| popey | I have a bunch of snaps on my desktop which fail to launch because the application requires access to the openGL graphics card. It fails out like there's no libGL present - http://paste.ubuntu.com/15658255 - it's not just one app, a few common apps do this. Anyone seen this with graphical snaps? | 18:35 |
| popey | Suggestions for things to try most welcome! 😃 | 18:35 |
| netphreak | Can anyone point me to a snappy gadget .yml for eg. Raspberry pi? | 18:41 |
| * ssweeny saw a thread/discussion somewhere that said for instance if an app was built on a machine with intel graphics it won't work on nvidia and vice-versa until a solution is found | 18:41 | |
| ssweeny | popey, ^^ | 18:41 |
| popey | well that sucks | 18:42 |
| popey | also, I am building on an nvidia machine and trying to run on same machine | 18:42 |
| * popey looks for said thread | 18:42 | |
| ssweeny | a solution is in the works IIRC | 18:42 |
| popey | found it, ta | 18:43 |
| ogra_ | netphreak, https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems | 18:45 |
| netphreak | Superb, thanks ;) | 18:49 |
| netphreak | I suppose one for RPI 3 will appear some time? | 18:49 |
| ogra_ | Yeah... Thereis one on my people.ubuntu.com account but I haven't put up the source yet | 18:50 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/ | 18:51 |
| netphreak | thx, ogra ;) | 18:53 |
| netphreak | Will the rpi3 release support bluetooth? | 18:59 |
| === blr_ is now known as blr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!