| General-Beck | Who can tell what kind of error? http://paste.ubuntu.com/15822298/ | 00:22 |
|---|---|---|
| kyrofa | General-Beck, looks like that error is specific to the service you're trying to install | 00:24 |
| kyrofa | General-Beck, and it's restarted several times fast enough that systemd just stopped trying | 00:24 |
| General-Beck | the fact that the restart is clear, but the error indicated `ubuntu-core-launcher ERROR: Error upgrading parity data: CannotLockVersionFile` | 00:26 |
| General-Beck | code https://github.com/ethcore/parity-snappy/tree/master/snap | 00:50 |
| General-Beck | I think I know the reason | 00:58 |
| test | ping elopio | 02:38 |
| === test is now known as Guest70089 | ||
| Guest70089 | ping elopio | 02:42 |
| Guest70089 | ping elopio | 02:49 |
| === chihchun_afk is now known as chihchun | ||
| netphreak | hi, guys! | 04:21 |
| ypwong | installed snapd and ubuntu-clock-app-mvo, but when launching ubuntu-clock-app-mvo.clock it complains "can not find a snappy os" | 04:52 |
| ypwong | What do I miss? | 04:52 |
| Mikaela | ypwong: some snap which started with ubuntu, which name I don't remember, something about core or base | 04:55 |
| ypwong | Mikaela, you're right, install ubuntu-core snap and now it can be run | 05:11 |
| ypwong | but now got "QXcbConnection: Could not connect to display :0" | 05:12 |
| === devil is now known as Guest28671 | ||
| === Guest28671 is now known as devil__ | ||
| === not_phunyguy is now known as phunyguy | ||
| zyga | good morning | 06:08 |
| === sgclark_sleeping is now known as sgclark | ||
| === attente_ is now known as attente | ||
| zyga | mvo: telegram seems to be down | 07:16 |
| zyga | mvo: I've posted a trivial branch https://github.com/ubuntu-core/snappy/pull/936 | 07:16 |
| zyga | mvo: and I found a bug (maybe) when we install the 1st snap and automatically install ubuntu-core with it, we don't seem to have a task for setup-snap-security | 07:17 |
| zyga | mvo: so iface manager doesn't ever see ubuntu-core | 07:17 |
| zyga | mvo: so we don't add implicit slots and get all the auto-connection magic to happen | 07:17 |
| mvo | zyga: interessting, the code should do exactly the same as for the first download, hmmm | 07:17 |
| zyga | mvo: try it, wipe your state, then install hello-world | 07:18 |
| zyga | mvo: and list interfaces | 07:18 |
| zyga | mvo: (on master) | 07:18 |
| zyga | mvo: (maybe merge the branch above so that it's not painful if snapd doesn't start | 07:18 |
| zyga | mvo: then restart snapd and it will see ubuntu-core interfaces (I do a scan on startup) | 07:18 |
| mvo | zyga: I'm not disputing that you see this :) I'm just puzzled why it happens | 07:18 |
| * zyga would love _some_ logging to be there for tasks | 07:19 | |
| mvo | zyga: yeah, I think we need a verbose mode in the taskrunner for exactly this, at least see what is in the queue and running etc | 07:21 |
| zyga | mvo: yeah, I think we could just log all runner activity in general, by default, it's not like it's going to hurt | 07:21 |
| zyga | mvo: and now it's walking blind all the time, I have a patch that sprinkles logging everywhere for development but it's silly to need such a thinig and not have it merged | 07:21 |
| zyga | mvo: fyi, telegram sends every other message I wrote; I'll switch to irc for now | 07:25 |
| zyga | (the remaining messages are marked as queued) | 07:25 |
| davidcalle | Morning o/ | 07:27 |
| davidcalle | zyga: Telegram has finally realized this group was using half of its bandwith ;) | 07:29 |
| zyga | davidcalle: and 90% of the cat photo traffic ;) | 07:29 |
| davidcalle | zyga, quick question about something I'm not sure to fully understand with Snappy. Why do we have "ack" and interfaces connectivity commands since snaps should be doing this on their own at install time? Is it for testing? | 07:31 |
| zyga | davidcalle: snappy auto-connects certain interfaces that are deemed safe or important, e.g. network, network-bind, x11 and unity7 | 07:32 |
| zyga | davidcalle: for other interfaces we will add auto-connection when assertions are in place | 07:32 |
| zyga | davidcalle: because those interfaces give a lot of power | 07:32 |
| zyga | davidcalle: and lastly users still can disconnect anything they want | 07:32 |
| davidcalle | I see | 07:33 |
| zyga | davidcalle: later on with hardware interfaces you will need to pick stuff, e.g. which GPIO pin goes to "mr blinky" snap | 07:33 |
| zyga | davidcalle: this is why plugs and slots have interface type -- there will be multiple interoperable ways to connect snaps to hardware | 07:33 |
| davidcalle | Yeah, makes sense then | 07:34 |
| zyga | davidcalle: e.g. a rasbperry pi 2 camera slot could be connected to only one snap at a time and you can pick which one gets it | 07:34 |
| fgimenez | good morning | 07:46 |
| zyga | fgimenez: morning :) | 07:46 |
| fgimenez | hey zyga :) | 07:47 |
| fgimenez | hi @mvogt :) it seems that today udf doesn't accept origins/developers for generating images, ie each snap flag without the '.canonical' at the end, is that going to stay, should we change integration tests and snappy-cloud-image? | 07:47 |
| fgimenez | mvo, ^ | 07:47 |
| mvo | fgimenez: I think that is a store change that triggered this behavior. you need to always use the short name now, right? only "ubuntu-core" works but not "ubuntu-core.canonical". is that what you see? | 07:49 |
| fgimenez | mvo, yes, "sudo ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pc-linux --gadget canonical-pc --developer-mode -o /tmp/tmp.HBTcxb4rHN/udf.raw" works | 07:49 |
| mvo | fgimenez: ok, please modify it for now so that it uses the short names. at some later point we will support long names again but thats not a concern right now (this will happen once publisher != developer which is not the case right now) | 07:51 |
| fgimenez | mvo, ok thx, on it | 07:51 |
| morphis_ | ogra_`: do we alreay support the raspberry pi 3 with snappy today? | 07:52 |
| zyga | fgimenez: hmm, I should update ubuntu-image then | 07:53 |
| mvo | yay, tests are green again | 07:53 |
| mvo | once https://github.com/ubuntu-core/snappy/pull/938 gets merged | 07:54 |
| zyga | mvo: merged | 07:56 |
| zyga | mvo: can you run "go test" in daemon/ for me it seems to hang... | 07:57 |
| zyga | ah, no it's just slow | 07:59 |
| zyga | sorry :) | 07:59 |
| zyga | mvo: latest u-d-f fails to find OS snap | 08:08 |
| zyga | ah, ignore me | 08:09 |
| Gunther_ | Good morning | 08:09 |
| Gunther_ | If a snapcraft.yaml contains multiple 'parts', is it possible to refer from 'part2' to the build or install directories of 'part1'? | 08:11 |
| didrocks | Gunther_: hey! you can if set you parts2 to be "after: parts1" (this is withing the stenza of parts2) and set for instance with the copy plugin: files: file1: ../../parts1/build for instance | 08:13 |
| Gunther_ | didrocks: thanks I will try that | 08:15 |
| === EkePoetry is now known as ToyKeeper | ||
| didrocks | yw! keep us posted :) | 08:16 |
| Gunther_ | didrocks: My idea is to use this to separate a kernel build from the build of a customized device driver. The device driver (part2) refering to the kernel source tree (part1) | 08:19 |
| didrocks | Gunther_: yeah, that should be doable this way then. | 08:23 |
| * zyga has connect + security working, fights through mock layers to let daemon tests go | 08:29 | |
| zyga | mvo: I have a simple daemon branch for review, do you have a moment? | 09:22 |
| zyga | Chipaca: ^ ditto | 09:23 |
| zyga | https://github.com/ubuntu-core/snappy/pull/942 | 09:24 |
| zyga | mvo: https://github.com/ubuntu-core/snappy/pull/943/files | 09:29 |
| morphis__ | ogra_: ping | 09:39 |
| zyga | morphis__: once you know about pi3 support please ping me, I'd like to support it in ubuntu-image | 09:41 |
| morphis__ | zyga: will do :-) | 09:51 |
| zyga | mvo: around? | 09:55 |
| zyga | mvo: (I don't know if you see my pings on telegram) | 09:55 |
| ogra_ | zyga, morphis, there is still a bug that makes the serial console on the pi2 unusable with the pi3 enabled uboot ... not sure we'll get that fixed before 16.04 release (but luckily nothing in the gadget comes from the archive so we will surely get it fixed by snappy release) http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/ | 09:56 |
| morphis | ogra_: sounds great! | 09:56 |
| ogra_ | long term plan is to have the 32bit image work on both ... and eventually have a 64bit img additionally | 09:57 |
| morphis | ogra_: one other thing, is http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ supposed to be the new place for daily snappy images? | 09:57 |
| ogra_ | morphis, well, the store is ... but yes, these snaps go to the store | 09:58 |
| morphis | ogra_: for snaps, yes, the store is the place, but talking about .img files I can flash | 09:59 |
| ogra_ | ah | 09:59 |
| ogra_ | no, thats a 15-04 dir ... | 09:59 |
| ogra_ | sorry missed that you had the wrong path in there | 09:59 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 10:00 |
| ogra_ | thats the path for the roilling dailies | 10:00 |
| ogra_ | we will release underneath http://cdimage.ubuntu.com/ubuntu-snappy/ though ... in a 16.04 subdir | 10:00 |
| ogra_ | (with img files) | 10:01 |
| morphis | ogra_: ok, so what do I take from daily-preinstalled to flash? xenial-preinstalled-core-amd64.tar.gz for example? | 10:01 |
| ogra_ | sudo ../ubuntu-device-flash core --developer-mode --channel edge --os xenial-preinstalled-core-amd64.os.snap --kernel xenial-preinstalled-core-amd64.kernel.snap --gadget canonical-pc.canonical -o test.img | 10:03 |
| ogra_ | that creates test.img which you can flash | 10:04 |
| ogra_ | you need the u-d-f from http://people.canonical.com/~mvo/all-snaps/ for that | 10:04 |
| morphis | ogra_: so u-d-f with support for that wasn't yet released? | 10:04 |
| ogra_ | oh, there is a "rolling" missing in the command | 10:04 |
| ogra_ | sudo ../ubuntu-device-flash core rolling --channel edge --os xenial-preinstalled-core-amd64.os.snap --kernel xenial-preinstalled-core-amd64.kernel.snap --gadget canonical-pc.canonical -o test.img | 10:05 |
| ogra_ | sadly not ... mvo is planning an SRU i think | 10:05 |
| morphis | hm | 10:05 |
| ogra_ | (effectively there is a new tool in the works but that wont make the release most likely) | 10:06 |
| morphis | ogra_: tool to replace u-d-f-? | 10:06 |
| ogra_ | kernal and gadget snaps are still supposed to be re-designed in the next weeks as well, so the code will still change in u-d-f | 10:06 |
| ogra_ | yes, a tool to replace u-d-f | 10:06 |
| morphis | interesting | 10:08 |
| morphis | ogra_: however, will we end up with actual .img files for the release? | 10:08 |
| ogra_ | perhaps :) | 10:09 |
| morphis | ok | 10:10 |
| ogra_ | (it doesnt make much sense to have imgs when the gadget and kernel snaps are comepletely redesigned ... perhaps in an incompatible way so that you need to re-flash) | 10:10 |
| morphis | I see | 10:10 |
| daker | ogra_: hi, anyidea how can i compile an armhf snap ? | 10:11 |
| ogra_ | daker, do you have an armhf board ? | 10:11 |
| daker | yes rpi2 & bbb | 10:11 |
| ogra_ | with a snappy install ? | 10:11 |
| daker | not yet | 10:12 |
| daker | does snappy/snapcraft comes with the ubuntu-core img ? | 10:12 |
| daker | snapcraft 1.x i mean :D otherwise i have to rewrite the snapcraf yaml again | 10:13 |
| ogra_ | oh | 10:13 |
| ogra_ | 1.x | 10:13 |
| * ogra_ hasnt used that in ages :P | 10:14 | |
| ogra_ | thats a bit tricky ... you need to compile natively ... in 16.04 we have the classic shell on the snappy image for that | 10:14 |
| ogra_ | (you can then just apt-get what you need and build your stuff) | 10:14 |
| ogra_ | i suspect in 15.04 you need to grab an ubuntu-core tarball (not the snappy one) and do it in a chroot in there | 10:15 |
| ogra_ | from http://cdimage.ubuntu.com/ubuntu-core/daily/current/ | 10:15 |
| Gunther_ | hmm is someone interested in reviewing a kmodule.py plugin for snapcraft? http://paste.ubuntu.com/15826883/ | 10:17 |
| zyga | Gunther_: send it to sergiusens_ on github | 10:18 |
| Gunther_ | ok | 10:18 |
| Gunther_ | zyga: as pull request? | 10:22 |
| pedronis | niemeyer: telegram is not quite working for european people atm, they said it was fixed but seems back to not working again | 10:31 |
| niemeyer | pedronis: Ah, I thought everybody was taking a good rest :-) | 10:36 |
| niemeyer | zyga: Some feedback on #943 | 10:36 |
| niemeyer | zyga: 942 is in | 10:39 |
| niemeyer | zyga: 943 has a few comments | 10:40 |
| niemeyer | mvo: 941 is missing update-pot it seems | 10:44 |
| mvo | niemeyer: let me fix that | 10:49 |
| mvo | niemeyer: thank you | 10:50 |
| Gunther_ | is there an easy way to look into a .snap package? | 10:59 |
| ogra_ | Gunther_, mount it ... it is a squashfs file ;) | 11:00 |
| Gunther_ | too much work :) | 11:00 |
| ogra_ | haha | 11:00 |
| ogra_ | you can also use unsquashfs indeed | 11:01 |
| ogra_ | i think "unsquashfs -l" lists the content without unsquashing | 11:02 |
| Gunther_ | mounting worked great :) | 11:04 |
| zyga | re | 11:14 |
| zyga | niemeyer: hey! | 11:14 |
| zyga | niemeyer: looking, thanks | 11:14 |
| zyga | niemeyer: refreshed https://github.com/ubuntu-core/snappy/pull/943 | 11:21 |
| zyga | niemeyer: have a look please, we can get connect/disconnect security working after that :) | 11:21 |
| niemeyer | Looking | 11:22 |
| * zyga worries that communication breaking down today is the most unfortunate thing that could have occured; is telegram working for anyone? | 11:22 | |
| niemeyer | zyga: Yeah, most people are in I think | 11:24 |
| zyga | niemeyer: I pinged mvo, pedronis and Chipaca without effect | 11:25 |
| zyga | maybe just not looking at irc notificaction (desktop integration) | 11:25 |
| niemeyer | zyga: I see their messages, but not your pings | 11:25 |
| zyga | niemeyer: I also tried in snappy-internal | 11:25 |
| zyga | niemeyer: as long as I can talk to you we're good :) | 11:26 |
| niemeyer | zyga: I don't see your pings in snappy-internal either | 11:26 |
| zyga | hmmm | 11:26 |
| * zyga restarts irc | 11:26 | |
| * zyga loves technology | 11:26 | |
| niemeyer | zyga: I think it'd be trivial to have SetupCallback recording the calls instead of the fake public value | 11:27 |
| niemeyer | zyga: But it's okay to do that later | 11:27 |
| zyga | irc should have a "no emergency calls" disclaimer | 11:27 |
| zyga | niemeyer: yes, I agree, I'll try to do that today after all the feature work is in place | 11:27 |
| niemeyer | zyga: It's okay, let's focus on the release.. this is an easy TODO for next week after things have calmed down | 11:27 |
| niemeyer | zyga: It's in | 11:28 |
| zyga | perfect, now for the meat | 11:29 |
| zyga | niemeyer: https://github.com/ubuntu-core/snappy/pull/948 | 11:35 |
| zyga | niemeyer: that's getting us 90% there | 11:35 |
| zyga | niemeyer: I'll work on setup-snap-security to be fully operational | 11:35 |
| zyga | niemeyer: and on remove-snap-security | 11:35 |
| zyga | niemeyer: along with some tests for both | 11:35 |
| zyga | niemeyer: _after_ that I'd like to get developer mode working | 11:36 |
| zyga | niemeyer: and switch connect/disconnect to async REST | 11:36 |
| zyga | niemeyer: and lastly kill bits needed only for old security (some branches for that are already up, I have more but I didn't finish it) | 11:36 |
| niemeyer | zyga: I can do the async rest thing immediately | 11:36 |
| zyga | niemeyer: please do, thanks! | 11:36 |
| niemeyer | zyga: Will look at the branch first | 11:36 |
| zyga | niemeyer: does the plan above look good, anything to shuffle or change? | 11:36 |
| niemeyer | zyga: What's still pending about setup-snap-security? | 11:37 |
| zyga | niemeyer: we still disconnect and don't reconnect | 11:37 |
| niemeyer | zyga: In which sense? | 11:37 |
| zyga | niemeyer: there's a TODO in the code that needs to be changed; to support upgrades we disconnect and remove the snap from the repo; then add it back (the new one) and autoconnect but we don't restore connection that were made explicitly | 11:38 |
| zyga | niemeyer: and perhaps auto-connect should not reconenct something that was disconnected by the user | 11:38 |
| zyga | niemeyer: that's all for setup (plus tests) | 11:38 |
| zyga | niemeyer: for remove AFAIR we don't remove the connection from the state (+ tests) | 11:39 |
| zyga | niemeyer: I feel I can do those very quickly with the testing helpers I now have | 11:39 |
| niemeyer | zyga: Sounds good.. quite a few items there.. best to do those piecemeal | 11:40 |
| zyga | yep, that's my plan! | 11:40 |
| niemeyer | zyga: For autoconnect, | 11:40 |
| niemeyer | zyga: Indeed we shouldn't reconnect.. it's easy to do that by, before disconnecting the former snap, obtaining a list of all the interface which are automatic but not established | 11:41 |
| niemeyer | zyga: Then, use that as a blacklist when reconnecting | 11:41 |
| zyga | niemeyer: mmm, yep, that sounds doable | 11:41 |
| niemeyer | zyga: Also an easy fix after it's all working | 11:42 |
| zyga | yep | 11:42 |
| === devil is now known as Guest8551 | ||
| === Guest8551 is now known as devil_ | ||
| zyga | niemeyer: I have setup-snap-security, how about we land https://github.com/ubuntu-core/snappy/pull/948 | 12:15 |
| kyrofa | Good morning | 12:36 |
| zyga | kyrofa: hey | 12:37 |
| kyrofa | Hey zyga :) . How are things going? | 12:38 |
| zyga | kyrofa: irc/telegram is flaky today | 12:38 |
| zyga | kyrofa: almost all interface features are implemented, just last few bits and I'm happy | 12:38 |
| kyrofa | zyga, excellent! | 12:38 |
| kyrofa | zyga, we're releasing snapcraft with that interface change pretty quick (if not already done) | 12:39 |
| zyga | kyrofa: sounds like a good day :) | 12:39 |
| kyrofa | zyga, indeed! | 12:43 |
| sergiusens_ | kyrofa, zyga it just passed adt, so it is making its way out of proposed | 12:43 |
| kyrofa | sergiusens_, morning! Thanks for the update :) | 12:44 |
| zyga | sergiusens: great news | 12:44 |
| zyga | niemeyer, mvo: what is the release plan for today? | 12:44 |
| sergiusens | kyrofa yeah, and I just built shout irc and running it in the snappy dimmension :-) | 12:44 |
| sergiusens | chatting from a browser now :-) | 12:45 |
| kyrofa | sergiusens, nice-- so the network interfaces are working now? | 12:45 |
| mvo | zyga: definitely | 12:46 |
| mvo | zyga: a release | 12:46 |
| mvo | zyga: later today, evening most likely. anything I should wait for? | 12:46 |
| zyga | mvo: I should be done with essentials in < 1 hour (all implemented, pending review) | 12:47 |
| zyga | mvo: I'll do more apparmor work and I'll try to get developer mode in | 12:47 |
| ogra_ | sergiusens, hah, now install my ircproxy snap and chain them :P (wont work, fully relies on snappy config :/ ) | 12:47 |
| zyga | niemeyer: all done on https://github.com/ubuntu-core/snappy/pull/948 | 12:48 |
| mvo | zyga: sounds great | 12:48 |
| sergiusens | kyrofa seems so | 12:48 |
| sergiusens | ogra_ I want to install shout on some server somewhere eventually (but I need to solve https without snappy config) | 12:49 |
| zyga | with developer mode we could at least install some desktop snaps in devel mode and see what's missing to get them fully confined | 12:49 |
| ogra_ | sergiusens, yeah, it is rather awful to lose snappy config :/ ... only one of my packages doesnt use it | 12:49 |
| kyrofa | ogra_, yeah when I saw that email I immediately thought of you | 12:50 |
| * ogra_ hopes it will be back soon | 12:50 | |
| mvo | zyga: yes | 12:50 |
| sergiusens | kyrofa so now more cleanups ahead | 12:53 |
| kyrofa | sergiusens, the example tests still fail-- have you tried shout on snappy instead of snappy dimension recently? | 12:53 |
| sergiusens | kyrofa we need a new `ubuntu-core` for that | 13:02 |
| kyrofa | Ah, okay gotcha | 13:02 |
| zyga | niemeyer: https://github.com/ubuntu-core/snappy/pull/948/commits/bf0ce588cace658bd20a09850a453e2ef973911e | 13:02 |
| zyga | niemeyer: https://github.com/ubuntu-core/snappy/pull/948/commits/ec305bef724e84519150160265ecdcbe3e3240ab | 13:06 |
| zyga | niemeyer: both done (perhaps stale browser diff?) | 13:06 |
| === mariogrip_ is now known as mariogrip | ||
| zyga | niemeyer: ^^ I don't know if you saw those two commits above | 13:41 |
| zyga | niemeyer: is that what you meant earlier or is something missing still? | 13:41 |
| niemeyer | zyga: Did you get my comments in Telegram? | 13:42 |
| niemeyer | zyga: Or are you still having connectivity issues/ | 13:42 |
| niemeyer | ? | 13:42 |
| zyga | niemeyer: no | 13:42 |
| zyga | niemeyer: apparently so | 13:42 |
| niemeyer | Gustavo Niemeyer, [14.04.16 09:56] | 13:42 |
| niemeyer | @zyga_pl We don't have any logic at all that does per snap backends, I believe, and it doesn't even sound like a great idea | 13:43 |
| niemeyer | Gustavo Niemeyer, [14.04.16 09:56] | 13:43 |
| niemeyer | @zyga_pl The boilerplate being added everywhere as a side effect is unnecessary | 13:43 |
| niemeyer | Gustavo Niemeyer, [14.04.16 09:57] | 13:43 |
| nothal | niemeyer: No such command! | 13:43 |
| nothal | niemeyer: No such command! | 13:43 |
| niemeyer | @zyga_pl So securityBackends can actually be simply []interfaces.SecurityBackend, no function calls | 13:43 |
| nothal | niemeyer: No such command! | 13:43 |
| niemeyer | nothal: shh! | 13:43 |
| ogra_ | poor bot :) | 13:43 |
| zyga | niemeyer: ahh | 13:43 |
| === beuno_ is now known as beuno | ||
| zyga | niemeyer: you are right, this will be killed with old-security | 13:43 |
| niemeyer | zyga: The comments described that | 13:43 |
| niemeyer | zyga: Even with code :) | 13:43 |
| zyga | niemeyer: if you want I can do it right now | 13:44 |
| niemeyer | zyga: Yeah, I think it'd be useful | 13:44 |
| niemeyer | zyga: As I see it growing legs elsewhere | 13:44 |
| zyga | niemeyer: it is one of the places that still had connection to old-security having special needs | 13:44 |
| zyga | one moment | 13:44 |
| daker | ogra_: thanks i will test that | 13:45 |
| zyga | niemeyer: pushed | 13:48 |
| sergiusens | zyga jdstrand hey, would it be sensible to allow something like $EDITOR? | 13:55 |
| zyga | sergiusens: what do you mean? | 13:55 |
| zyga | sergiusens: for a snap to run $EDITOR? | 13:55 |
| sergiusens | zyga shout has this facility where it you can do `shout config` which just runs `$EDITOR <path-to-config>` which is sort of nice given snap directories | 13:56 |
| zyga | hmmm | 13:57 |
| jdstrand | that isn't going to work great | 13:57 |
| zyga | sergiusens: we cannot expand $EDITOR that the user has | 13:57 |
| zyga | sergiusens: we'd have to whitellist a range of editors but that would never work reliably | 13:57 |
| jdstrand | cause EDITORs write all over the place | 13:57 |
| * jdstrand agress with zyga | 13:57 | |
| sergiusens | jdstrand right, so my solution is to provide a minimal editor in my snap and set $EDITOR up to use that, right? | 13:58 |
| jdstrand | that is why we don't allow it now | 13:58 |
| zyga | sergiusens: it could be done with an editor interface | 13:58 |
| jdstrand | sergiusens: sure, you could do that | 13:58 |
| zyga | sergiusens: not sure if the UX for that would be good though | 13:58 |
| jdstrand | sergiusens: you then can configure the editor to point at whatever files are in your snap/writable by your snap | 13:58 |
| sergiusens | zyga and editor interface (or a vim.tiny or nano one) which only allows read/write to SNAP_<dirs> if possible would be great | 13:59 |
| jdstrand | I did something like that for a personal snap of mine | 13:59 |
| jdstrand | I shipped vim and setup all the various .vimrc, etc to look in the right places | 13:59 |
| zyga | sergiusens: then the OS snap would create a range of slots of type 'editor' and you could pick the one that gets to run but without hooks that'd still suck | 13:59 |
| jdstrand | well | 13:59 |
| jdstrand | that interface would require support from the os snap | 14:00 |
| sergiusens | jdstrand ok, sounds good, I'm going to see if I can find something more light weight and less dep heavy | 14:00 |
| sergiusens | yeah, longer term, it would be nice to think of something for this, I don't mind today | 14:00 |
| jdstrand | ie, if nano and vim.tiny, then we'd have to ship nano and vim.tiny in the os that worked under the confinement provided by the interface | 14:00 |
| jdstrand | I guess the snap could ship its own nano or vim.tiny | 14:01 |
| jdstrand | but then what good is the interface. just set your editor to work in your writable areas | 14:01 |
| === sergiusens74 is now known as sergiusens | ||
| zyga | mvo: around? | 14:22 |
| zyga | I need a 2nd +1 on https://github.com/ubuntu-core/snappy/pull/948 | 14:22 |
| sborovkov | Hi. How do I debug application in the snap? Do I have to bundle gdb-server with snap, and run it instead of application? Or is there some simpler way? | 14:26 |
| jdstrand | dholbach: I'm making some updates to https://docs.google.com/spreadsheets/d/1xBHxFwBNk3HjomnxzOjrohy-E3eyjAGX8ZLvXPqOG84/edit#gid=0 | 14:34 |
| dholbach | thanks a lot jdstrand! | 14:37 |
| jdstrand | dholbach: I see a lot of old-security in the snap-playpen, so fixing that as I come across it | 14:37 |
| zyga | jdstrand: I have 90% of security side of interfaces implemented; should be released today | 14:38 |
| dholbach | jdstrand, thanks... most of the contents of the branch is old... it's from last week! | 14:38 |
| zyga | jdstrand: I'll try to get developer mode as well | 14:38 |
| dholbach | dpm, ^ | 14:38 |
| zyga | jdstrand: can you quickly review https://github.com/ubuntu-core/snappy/pull/933 | 14:39 |
| zyga | jdstrand: (trivial) | 14:39 |
| dpm | awesome, thanks jdstrand! | 14:39 |
| zyga | jdstrand: without old-security I'd like to simplify that futher still but this needs to land first | 14:39 |
| halfline | hey i have some questions about snappy if anyone is game ! 1) it's like a container system for applications right? 2) is the underlying technology different for server apps and desktop apps, or is it all the same under the hood? | 14:39 |
| === stgraber_ is now known as stgraber | ||
| ysionneau | sergiusens: hi! sorry to bother you with this again but any idea on my ubuntu-device-flash issue I posted on the mailing list? | 14:39 |
| zyga | halfline: 2) same thing 1) not exactly (we don't use most namespaces AFAIR) | 14:40 |
| halfline | zyga: and how does it relate to docker? similar technology but different implementation ? | 14:43 |
| zyga | halfline: it has the same perception; we don't put apps in a container | 14:43 |
| zyga | halfline: we use apparmor and seccomp to sandbox them | 14:43 |
| halfline | zyga: ah okay thanks | 14:43 |
| zyga | halfline: we use some namespaces but just for confinement | 14:44 |
| halfline | but not a chroot | 14:44 |
| jdstrand | halfline: the reason why is we want snaps to be more integrated into the system (but in controlled ways) than a docker or lxd container. note that docker and lxd work great on snappy if you like those technologies | 14:45 |
| jdstrand | we do not use a file namespace-- apparmor handles that | 14:45 |
| halfline | jdstrand: gotcha ! thanks much | 14:46 |
| * zyga will start collecting FAQs | 14:46 | |
| zyga | jdstrand: can I also remove (harcode) /snap as INSTALL_DIR or is that used by any of the include files? | 14:55 |
| jdstrand | zyga: INSTALL_DIR is used by policy. I suggest not removing it unless you want to update the policy files to sub in a go variable. I don't think there is any benefit to doing that work | 14:57 |
| zyga | jdstrand: right, I remember something like that being mentioned, fine with me | 14:57 |
| zyga | jdstrand: can I at least drop /gadget from it? | 14:57 |
| jdstrand | zyga: if /gadget no longer exists | 14:58 |
| zyga | niemeyer: ^^ opinion on keeping /gadget in the policy as a place where snaps can be installed? (I think it's not needed but I'd like to check) | 14:58 |
| jdstrand | I don't know the status of what gadgets are doing | 14:58 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/955 | 14:59 |
| zyga | jdstrand: (without any changes to INSTALL_DIR) | 14:59 |
| jdstrand | zyga: btw, autoconnect is working nice in 1.9.2 | 14:59 |
| sergiusens | kyrofa https://github.com/ubuntu-core/snapcraft/pull/451 | 14:59 |
| zyga | jdstrand: cool! | 14:59 |
| niemeyer | zyga: Huh | 14:59 |
| niemeyer | zyga: What's /gadget? | 14:59 |
| zyga | niemeyer: it's a directory where snaps can be installed to according to the apparmor template | 15:00 |
| zyga | niemeyer: it feels like some really old leftover | 15:00 |
| jdstrand | in days past, gadget snaps were installed in /gadget | 15:01 |
| jdstrand | aiui | 15:01 |
| jdstrand | if all snaps are in /snap, then fine to remove /gadget | 15:01 |
| * jdstrand just didn't know the status of gadget snaps | 15:01 | |
| * zyga has huge lag on internal IRC | 15:04 | |
| Gunther_ | Could somebody provide me with a snapcraft.yaml for a standard xenial kernel (amd64)? Mine is currently stuck after grub with "grep: /proc/device-tree/model: No such file or directory" | 15:06 |
| noizer | Hi, is there any news over the new stable version? | 15:08 |
| noizer | Or will it be next week the release? | 15:10 |
| niemeyer | zyga, jdstrand: Yeah, let's kill it | 15:10 |
| zyga | niemeyer: ack, will do | 15:11 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | noizer, snappy images will happen later | 15:11 |
| niemeyer | fgimenez, elopio: Any news about the int tests? | 15:11 |
| niemeyer | FileNotFoundError: [Errno 2] No such file or directory: '/home/jenkins-slave/workspace/github-snappy-integration-tests-cloud/jenkins-github-snappy-integration-tests-cloud-1676/output/artifacts/results.subunit' | 15:12 |
| ogra_ | noizer, all focus for the 16.04 release is to make snaps fully work on desktop and server ... then the focus turns back to images | 15:12 |
| fgimenez | niemeyer, yep, they are currently broken because of scalingstack failures, IS is already looking into it | 15:12 |
| niemeyer | fgimenez: Super, thank you | 15:13 |
| noizer | ogra_: Ok | 15:13 |
| fgimenez | niemeyer, yw, i'll ping you when ready | 15:14 |
| niemeyer | fgimenez: Appreciated, thanks! | 15:14 |
| noizer | ogra_: Wil the image be ready this month for the raspberry pi 3? | 15:15 |
| zyga | niemeyer: while we wait for unit tests to pass on the other branch: https://github.com/ubuntu-core/snappy/pull/955/files | 15:15 |
| Gunther_ | Other question: I installed a defect kernel.snap. The system boot fails, but grub successfully returns to the last kernel. When I try to remove the defect kernel snap, I get "snappy package cannot be removed" | 15:15 |
| zyga | niemeyer: this is just removal of old security and changes to internal-only apparmor variables to make more sense | 15:15 |
| ogra_ | noizer, no promises ... but yeah, pi3 is on my prio list | 15:15 |
| ogra_ | it will definitely be ready by snappy release | 15:16 |
| noizer | Ok | 15:16 |
| zyga | niemeyer: and (more importantl actually) we can now look at this :-) https://github.com/ubuntu-core/snappy/pull/950/files | 15:16 |
| noizer | ogra_: Will libsnaps be available in the stable release? | 15:18 |
| ogra_ | libsnaps ? | 15:19 |
| sergiusens | ogra_to compress ;-) | 15:21 |
| zyga | niemeyer: https://github.com/ubuntu-core/snappy/pull/958 | 15:23 |
| noizer | ogra_: I though i heard about a snap where you can put all your libraries in and that your snaps can uses this libraries | 15:25 |
| sergiusens | Chipaca do you have your branch handy where you worked on the store api changes? I need to do the same | 15:25 |
| ogra_ | noizer, you mean snapcraft ? | 15:26 |
| noizer | ogra_: nono :p Ok I imagined it. So maybe a good thing to add later on. So that maybe make an other type of snap. the meaning of this snap can be a Library snap so that an other snap can use this library. this can be as an advantage that the developer dont need to download always the library thats he needed when he making different snaps | 15:28 |
| zyga | noizer: that will be done wtih interfaces | 15:29 |
| zyga | noizer: but it's not supported yet | 15:29 |
| ogra_ | noizer, oh, that ... i think thats already possible ... but only for your own snaps | 15:29 |
| ogra_ | ah ... zyga is surely more up to date here :) | 15:29 |
| zyga | noizer: we will probably prototype that with the SDK runtime | 15:30 |
| zyga | noizer: I don't know now | 15:30 |
| edsiper | hi, where are the Snappy images for the Dragonboard 410c ? | 15:30 |
| zyga | edsiper: you can use https://github.com/zyga/devtools but I don't think we guarantee that they work this week | 15:30 |
| noizer | zyga: ogra_ Will there be later on in the development of snappy. be possible to share it with other users that develops snaps? | 15:30 |
| elopio | fgimenez: I'm following the discussion in #ubuntu-on-air. It's interesting. | 15:31 |
| zyga | noizer: perhaps not, use snapcraft for that, we don't want to get into deb dependency | 15:31 |
| ogra_ | yeah, very unlikely | 15:31 |
| noizer | zyga ogra_ ok thx for the information. | 15:32 |
| noizer | ogra_: zyga I needed this information because i have tomorrow a meeting with Maarten Ectors. Do you know him? | 15:33 |
| ogra_ | not personally ... but yeah | 15:34 |
| zyga | noizer: sorry, I'm busy now I cannot help you; we're working on the release still | 15:34 |
| noizer | ogra_: zyga Ok keep up the good work! | 15:35 |
| almejo | I guys. :D I have a technical question. I develop an app for desktop. This app is started from the browser when the user clicks a button. For this I developed a plugin in c++ to start my app. I can not use firefox addons becouse it needs zero interaction of the user. My question is: can I bundle a Firefox plugin and a Gui App in a single snap package? Can firefox plugins be bundled in a snap? | 15:46 |
| edsiper | zyga, ok, thanks | 15:48 |
| zyga | almejo: this was just answered by beuno in ubuntu-on-air | 15:48 |
| almejo | yes.. I was writing here just when he was talking and lost half of the answer :(... | 15:49 |
| almejo | thanks guys for your time | 15:49 |
| dholbach | sergiusens, Running snapcraft for one package seems to fail because of apt issues (404, or some less secure hashes, etc.), when I try 'snapcraft cleanbuild' I get: http://paste.ubuntu.com/15832645/ | 15:51 |
| dholbach | I guess I'm doing something wrong, I ran 'sudo lxd init' and lxd is working for autopkgtest stuff for me | 15:51 |
| dholbach | or kyrofa ^ :) | 15:53 |
| * kyrofa jolts awake | 15:53 | |
| sergiusens | dholbach I need to see what broke since the latest lxd release and why this stopped working | 15:54 |
| sergiusens | dholbach I think I am creating instance names that are too long | 15:55 |
| sergiusens | dholbach about the 404; check your sources lists or run with `--enable-geoip` | 15:56 |
| kyrofa | dholbach, yeah can you use apt okay? | 15:56 |
| dholbach | sergiusens, I think it's because of PPAs and stuff like that | 15:56 |
| jdstrand | dholbach, davidcalle, popey, mhall119: fyi, I went through a bunch of the apps in https://docs.google.com/spreadsheets/d/1xBHxFwBNk3HjomnxzOjrohy-E3eyjAGX8ZLvXPqOG84/edit#gid=0 and updated the bzr trees for snapcraft.yaml for various things of yours | 15:57 |
| jdstrand | dholbach, davidcalle, popey, mhall119: and I updated the notes and pastebins when things were different | 15:58 |
| dholbach | jdstrand, wow wow wow! | 15:58 |
| dholbach | thanks a lot | 15:58 |
| dholbach | sergiusens, with enable-geoip it now works | 15:58 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/962 | 16:00 |
| zyga | jdstrand: simplified version of earlier approach | 16:00 |
| popey | jdstrand: thanks | 16:01 |
| sergiusens | dholbach that means that one of your apt sources is not in perfect condition wrt gpg keys ;-) | 16:02 |
| dholbach | ok | 16:03 |
| morphis | jdstrand, zyga: I am currently trying to get the network-manager snap back working and also create a itnerface definiton for it, however I see the small bash script we have in fron of starting the actual daemon causing a segfault | 16:05 |
| zyga | niemeyer, mvo: I have all the essentials and I can now work on developer mode CLI or on respecting disconnect when looking at auto-connection | 16:05 |
| morphis | jdstrand, zyga: https://paste.ubuntu.com/15833025/ | 16:05 |
| zyga | morphis: looking | 16:05 |
| sergiusens | jdstrand mind looking at https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/6/ | 16:05 |
| morphis | jdstrand, zyga: I am wondering if that is due to not having any confinement in place | 16:05 |
| zyga | morphis: BTW, can you look at the bluez template and update it to match changes made here: https://github.com/ubuntu-core/snappy/pull/955 | 16:06 |
| morphis | ssweeny: ^^ | 16:06 |
| zyga | morphis: [ 7.637370] audit: type=1400 audit(1460649837.912:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="network-manager.sideload_nmcli_LWMlnkcXLVbp" pid=711 comm="apparmor_parser" ?? how did it get unconfined | 16:06 |
| zyga | morphis: how are you testing this? | 16:07 |
| zyga | morphis: with 1.9.2? | 16:07 |
| morphis | zyga: 1.9.2? | 16:07 |
| ssweeny | zyga, morphis I'll take a look after my current meeting | 16:07 |
| zyga | which version of snappy | 16:07 |
| zyga | ssweeny: thanks | 16:07 |
| morphis | zyga: where do I find the version? | 16:07 |
| zyga | morphis: can you try with master now? it has connect/disconnect support | 16:07 |
| zyga | morphis: if dpkg then it's too old | 16:07 |
| zyga | morphis: until we release again | 16:07 |
| jdstrand | sergiusens: that's a funky snap name | 16:09 |
| zyga | morphis: you may want to merge in a few branches: | 16:09 |
| morphis | zyga: mazon.de | 16:09 |
| sergiusens | jdstrand shout? :-) | 16:09 |
| morphis | narf | 16:09 |
| morphis | zyga: https://git.launchpad.net/~morphis/+git/nm-snap/tree/ is what I use | 16:09 |
| jdstrand | Download: ts3xPzy5QRvFDfdApSp1SPRIsqQGQbok_6.snap | 16:09 |
| morphis | zyga: I suspect the old-security stuff doesn't work anymore | 16:09 |
| jdstrand | sergiusens: approved | 16:09 |
| ogra_ | jdstrand, i see that everywhere now | 16:09 |
| zyga | morphis: no, I mean, latest version of snappy itself | 16:09 |
| zyga | morphis: correct, you need to make an interface now | 16:10 |
| morphis | zyga: ok | 16:10 |
| zyga | morphis: old-security is officially dead | 16:10 |
| morphis | ok | 16:10 |
| morphis | zyga: so where do I find the snappy version? | 16:10 |
| morphis | snappy --version doesn't exist | 16:10 |
| jdstrand | zyga: in a call and then an appt. will review 962 after | 16:10 |
| zyga | morphis: if it is installed from dpkg/apt then it is probably too old | 16:10 |
| zyga | morphis: you have to build from source or wait for today's release | 16:11 |
| zyga | jdstrand: thanks | 16:11 |
| morphis | zyga: no, running a kvm x86 instance here with an image created by u-d-f | 16:11 |
| zyga | morphis: hmm, then use my devtools to put more recent snappy inside | 16:11 |
| morphis | zyga: can you give me the link again? | 16:11 |
| zyga | morphis: that should at least eliminate issues related to snappy being out of date | 16:11 |
| zyga | morphis: sure, github.com/zyga/devtools | 16:12 |
| zyga | morphis: look at refresh-bits --help | 16:12 |
| zyga | morphis: note that this assumes you can built snappy with "go build" (gopath set, deps pulled, etc) | 16:12 |
| morphis | I see | 16:12 |
| sergiusens | jdstrand ty; btw the checks say "valid click package"; is that known? | 16:12 |
| zyga | morphis: if you want to track bleeding edge that helps | 16:12 |
| zyga | morphis: if you want more stability then wait one more day but this would let you develop the interface right now so I think it is useful | 16:13 |
| niemeyer | zyga: devmode would be my vote | 16:13 |
| morphis | zyga: absolutely | 16:14 |
| niemeyer | zyga: Hmm | 16:14 |
| zyga | niemeyer: I'm already on it | 16:14 |
| morphis | let me get started with this | 16:14 |
| niemeyer | zyga: Cool | 16:14 |
| Chipaca | sergiusens: yes, 1 sec | 16:14 |
| jdstrand | sergiusens: that is a store thing. beuno, see sergiusens question ^ | 16:14 |
| Chipaca | sergiusens: it's not a pretty branch | 16:14 |
| sergiusens | Chipaca thanks, my os.snap download logic broke in snapcraft :-) | 16:14 |
| sergiusens | Chipaca there is no such thing as useful and pretty code ;-) | 16:15 |
| Chipaca | sergiusens: https://github.com/ubuntu-core/snappy/pull/928 | 16:15 |
| sergiusens | dholbach my suspicion is you installed the bluejeans deb ;-) | 16:15 |
| sergiusens | Chipaca ty! | 16:16 |
| dholbach | sergiusens, I didn't | 16:16 |
| beuno | jdstrand, sergiusens, hm | 16:16 |
| Chipaca | sergiusens: I mean, it's not at all clear from looking at the branch what is the important change and what is dross | 16:17 |
| josepht | Mikaela: nmap 7.12SVN-0.4 should fix your issue | 16:17 |
| beuno | roadmr, hi! | 16:17 |
| roadmr | hey :) | 16:17 |
| jdstrand | beuno: fyi: https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/6/ | 16:17 |
| beuno | 12:12 < sergiusens> jdstrand ty; btw the checks say "valid click package"; is that known? | 16:17 |
| beuno | 12:14 < jdstrand> sergiusens: that is a store thing. beuno, see sergiusens question ^ | 16:17 |
| jdstrand | beuno: under '3 passes': OK Is a valid click package | 16:17 |
| beuno | roadmr, seems our code has "click" hardcoded there | 16:17 |
| roadmr | beuno: let me check the strings | 16:18 |
| beuno | thanks roadmr | 16:18 |
| Mikaela | josepht: stupid question, but how do I update? | 16:18 |
| beuno | Unexpected output from click-review. click-review | 16:18 |
| beuno | also, maybe we should rename that :) | 16:18 |
| josepht | Mikaela: for me it was 'snap refresh --channel edge nmap' | 16:18 |
| roadmr | beuno: they do, yes. | 16:18 |
| Mikaela | josepht: thanks, I will check soon | 16:18 |
| beuno | roadmr, can you queue that up, without panicking anyone? :) | 16:19 |
| zyga | roadmr: hey, long time no see, how are you | 16:19 |
| roadmr | beuno: so should it say it's a valid $TYPE package, where $TYPE in ['click', 'snap'] ? | 16:19 |
| roadmr | zyga: hey! | 16:19 |
| Chipaca | sergiusens: if I had to sum it up in a single line diff, it'd be: | 16:20 |
| Chipaca | - curl -s -H "accept: application/hal+json" -H "X-Ubuntu-Release: 15.04-core" https://search.apps.ubuntu.com/api/v1/package/8nzc1x4iim2xj1g2ul64.chipaca | 16:20 |
| Chipaca | +curl -s -H "accept: application/hal+json" -H "X-Ubuntu-Release: rolling-core" -H "X-Ubuntu-Device-Channel: edge" 'https://search.apps.ubuntu.com/api/v1/search?q=package_name:"8nzc1x4iim2xj1g2ul64"' | 16:20 |
| Chipaca | sergiusens: oops, add a /edge after the .chipaca in the - line | 16:20 |
| sergiusens | Chipaca so search 15.04 first? or was that a typo? | 16:21 |
| Chipaca | sergiusens: in 15.04, do that; in 16, do this | 16:21 |
| Chipaca | sergiusens: s/rolling-core/16-core/ if you wish :-) | 16:21 |
| Chipaca | sergiusens: basically we never hit the details uri, now; just do an exact search by name | 16:22 |
| Chipaca | sergiusens: then shout if you get anything other than 1 package in the results | 16:22 |
| Chipaca | sergiusens: and where you used to be able to specify channel in the query, now it goes in a header | 16:23 |
| sergiusens | Chipaca but package_name looks like a hash in that example :-P | 16:23 |
| sergiusens | ack on channel | 16:23 |
| Chipaca | sergiusens: don't diss the famous 8nzc1x4iim2xj1g2ul64. | 16:23 |
| sergiusens | oh, right! | 16:24 |
| Chipaca | :-) | 16:24 |
| zyga | niemeyer, Chipaca: the API for side-loading snaps just shoves the snap across the connection, is there a way to pass developer mode flag there? multipart? different endpoints?) | 16:24 |
| Chipaca | zyga: it already passes other flagas | 16:24 |
| Chipaca | flags* | 16:24 |
| zyga | Chipaca: oh? Where? | 16:24 |
| Chipaca | zyga: two different ways :-) | 16:25 |
| Chipaca | zyga: give me a mo' | 16:25 |
| zyga | Chipaca: I'm looking at client.InstallSnapFile | 16:25 |
| zyga | Chipaca: shall I use headers for that? | 16:25 |
| Chipaca | zyga: https://github.com/ubuntu-core/snappy/blob/master/daemon/api.go#L764 | 16:25 |
| Chipaca | zyga: ah, look at daemon.sideloadSnap | 16:25 |
| Chipaca | zyga: the flags might not be exposed to the client | 16:26 |
| Chipaca | zyga: there are two ways of side-loading a snap, and only one of them is "just shoving it across" :-) | 16:26 |
| niemeyer | zyga: We'll probably want to distinguish between discard-snap-conns and disable-snap-security | 16:26 |
| Chipaca | zyga: the other involves following an rfc :-D | 16:26 |
| * niemeyer looks at some more code | 16:26 | |
| sergiusens | Chipaca I don't see a download_url when I run curl -s -H "accept: application/hal+json" -H "X-Ubuntu-Release: rolling-core" -H "X-Ubuntu-Device-Channel: edge" 'https://search.apps.ubuntu.com/api/v1/search?q=package_name:"ubuntu-core"' | 16:27 |
| zyga | Chipaca: client is just pushing one across, how should I pass a flag there? header? | 16:28 |
| zyga | Chipaca: it seems that current client doesn't use multipart | 16:28 |
| sergiusens | Chipaca I do if I follow the href in there though | 16:28 |
| zyga | niemeyer: what do you mean by discard-snap-conns? | 16:28 |
| Chipaca | sergiusens: ah | 16:28 |
| Chipaca | sergiusens: you'll need to specify all the fields you want | 16:28 |
| niemeyer | zyga: Please finish your conversation with Chipaca first.. we'll need some focused attention on this | 16:28 |
| zyga | ok | 16:29 |
| nessita | sergiusens, you can request specific fields, with: https://search.apps.ubuntu.com/api/v1/search?q=package_name:"ubuntu-core"&fields=package_name,download_url,binary_size | 16:29 |
| Chipaca | sergiusens: we have to do some fun things with reflect, but from python it's probably just "".join($type.__dict__.keys()) :-p | 16:29 |
| nessita | etc | 16:29 |
| sergiusens | nessita do we still have an anon download url for ubuntu-core? or can we download using download_url without a login? | 16:30 |
| Chipaca | zyga: https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#input | 16:30 |
| Chipaca | zyga: headers | 16:30 |
| zyga | Chipaca: thanks! | 16:30 |
| nessita | sergiusens, we still have the anon url, but that will be removed soon for new snaps, all downloads needs to be authenticated | 16:30 |
| nessita | sergiusens, so yes, we still have the anon url, but hopefully no code relies on that | 16:31 |
| sergiusens | nessita even ubuntu-core? I thought beuno said the os snap would not require a login | 16:31 |
| Chipaca | nessita: that's not right | 16:31 |
| Chipaca | i think? | 16:31 |
| Chipaca | nessita: or your definition of "soon" is more generous than mine :-D | 16:31 |
| nessita | Chipaca, tell me more | 16:31 |
| nessita | Chipaca, soon == as soon as matiasb work lands? | 16:32 |
| Chipaca | nessita: any snaps that come with the system need to be updated with just the system's creds, which does not (yet) count as authenticated | 16:32 |
| Chipaca | nessita: because if nobody has authenticated, we still want to update whatever is on there | 16:32 |
| nessita | Chipaca, yes, there is a hand waving in there; we expect this to be the minimal amount of cases | 16:33 |
| Chipaca | right | 16:33 |
| sergiusens | right, things in the model assertion shouldn't require auth | 16:33 |
| Chipaca | sergiusens: well, the model assertion should count as auth maybe :-) | 16:33 |
| Chipaca | *handwaving intensifies* | 16:33 |
| nessita | sergiusens, "the final plan" assumes there will be a device authentication in all cases | 16:33 |
| Chipaca | nessita: but it being minimal does not mean we should delete the code that does it :-D | 16:33 |
| Chipaca | unitl device authentication is a thing | 16:34 |
| Chipaca | until* | 16:34 |
| nessita | and user authentication for most cases | 16:34 |
| nessita | Chipaca, yes, agreed, and I understand you are being so explicit due to recent events, and I thank that | 16:34 |
| Chipaca | nessita: no, it's just me being my usual ornery self | 16:34 |
| niemeyer | Chipaca: It'd probably be nicer to offer a consistent JSON document either as the header or as one of the parameters.. | 16:34 |
| niemeyer | Chipaca: So we can have a parameter in the InstallSnap(File).. | 16:35 |
| nessita | Chipaca, removal of anon, if any, will be announced and coordinated. What I was trying to warm sergiusens is not to rely on that for the common case (as a concept) | 16:35 |
| niemeyer | Chipaca: (which is consistent with everything else..) | 16:35 |
| niemeyer | Not sure if I can get to that today.. | 16:35 |
| Chipaca | sergiusens: nessita: https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go#L390 | 16:36 |
| Chipaca | sergiusens: nessita: that's what snap is doing today | 16:36 |
| Chipaca | niemeyer: sorry, i'm tracking n+1 conversations, where n is the number i can track | 16:36 |
| Chipaca | niemeyer: what was this about? sideloading? | 16:37 |
| niemeyer | Chipaca: Sorry, yeah.. | 16:38 |
| Chipaca | niemeyer: sending json as a header sounds like a bad idea | 16:38 |
| niemeyer | Chipaca: The form, feels a bit off from everything else | 16:38 |
| niemeyer | (in the API) | 16:38 |
| Chipaca | niemeyer: it's the only method that isn't json, because sending binary in json would be zany | 16:39 |
| niemeyer | Chipaca: Well, the multipart seems fine and elegant | 16:39 |
| nessita | Chipaca, where/who shall I contact about a few comments on that code? | 16:39 |
| nessita | I see some issues but would not like to increase to n+2 your current conversations | 16:39 |
| ogra_ | nessita, ho would i do a port to a new SoC if i cant obtain the ubuntu-core snap unauthenticated ? | 16:39 |
| Chipaca | nessita: matiasb might already have code that changes that i pointed at | 16:40 |
| Chipaca | nessita: maybe start there | 16:40 |
| nessita | ogra_, hi! what is a SoC? | 16:40 |
| Chipaca | nessita: s/that i pointed/what i pointed/ | 16:40 |
| * ogra_ thinks the os snap should be excluded from auth reqs. | 16:40 | |
| asac | ogra_: how does the overlay dtb feature work on pi2? | 16:40 |
| ogra_ | nessita, a new "board" | 16:40 |
| asac | we put the dtbs in the /boot/ dir and then it automatically picks it up? | 16:40 |
| niemeyer | nessita: System on Chip, Summer of Code, Something of Curiosity | 16:40 |
| ogra_ | asac, you need to extract the tarball in /boot | 16:40 |
| ogra_ | asac, err /boot/uboot | 16:40 |
| ogra_ | asac, then you can define it in config.txt | 16:41 |
| nessita | ogra_, so there are (will be) 2 levels of authentication: device and user. The former will be (when available) mandatory for all opertaions | 16:41 |
| ogra_ | nessita, the point is that for bringing up new hardware i need to be able to freely create my gadget and kernel snaps and combine them with the os snap ... for that i somehow need to get the os snap | 16:41 |
| niemeyer | zyga: Some comments on 958, including a high-priority one | 16:42 |
| asac | ogra_: how do we define that in config.txt? | 16:42 |
| nessita | ogra_, for anything that is not check for updates for existing snaps (and download those) user authentication will be required | 16:42 |
| asac | cant see a field with list of dtbs | 16:42 |
| nessita | ogra_, I understand there is a factory process that solves this, but not 100% familiar with the details | 16:42 |
| ogra_ | asac, https://www.raspberrypi.org/documentation/configuration/config-txt.md | 16:43 |
| nessita | ogra_, as in, the board will be shipped with an initial snap that will be updateable with device auth only | 16:43 |
| ogra_ | asac, or rather https://www.raspberrypi.org/documentation/configuration/device-tree.md | 16:43 |
| ogra_ | nessita, as some home guy who wants to get his favourite board supported i wont use some factory process | 16:44 |
| ogra_ | there needs to be some community friendly process | 16:44 |
| zyga | niemeyer: looking | 16:44 |
| Chipaca | ogra_: "factory process" does not mean for a factory | 16:45 |
| Chipaca | ogra_: necessarily | 16:45 |
| Chipaca | ogra_: and all these steps need to be fleshed out still | 16:45 |
| ogra_ | Chipaca, yeah, i got catched by the buzzword :) | 16:45 |
| niemeyer | zyga: Is 955 ready for merging? It looks good, but was it tested for real? | 16:45 |
| niemeyer | zyga: Lots changing on the core template there | 16:45 |
| ogra_ | Chipaca, sounds like a sprint topic :) | 16:45 |
| nessita | ogra_, I don't have the fine details for that use case, (nor sure anyone has) | 16:45 |
| Chipaca | ogra_: yeap | 16:45 |
| ogra_ | nessita, well, that usecase is my everyday job ;) | 16:46 |
| Chipaca | ogra_: also, you might be interested in chasing up on "embryonic state", if my memory serves | 16:46 |
| niemeyer | Why do we not have integration tests for 955? | 16:46 |
| zyga | niemeyer: I thin 955 is okay, bulk of the changes are automatic | 16:46 |
| zyga | niemeyer: I'll give it a round of real testing with and without developer mode and if anything is off we can still correct that today | 16:46 |
| niemeyer | zyga: Okay, I'll merge because integration test infrastructure is on holiday today, but please verify that in practice so mvo doesn't pack something broken | 16:47 |
| zyga | niemeyer: understood | 16:47 |
| === chihchun_afk is now known as chihchun | ||
| zyga | niemeyer: https://github.com/ubuntu-core/snappy/pull/958#discussion_r59752350 | 16:56 |
| zyga | niemeyer: I just want to clarify if I understand the proposed tasks correctly | 16:56 |
| dpm | jdstrand, thanks a lot for looking into this! Would you mind expanding on "the other issues are due to packaging"? On bug 1570435, that is | 16:59 |
| ubottu | bug 1570435 in Snappy Desktop Examples "Desktop example ubuntu-clock-app is broken" [Undecided,New] https://launchpad.net/bugs/1570435 | 16:59 |
| * zyga wonders what is the difference between os snap and core snap | 16:59 | |
| ogra_ | is there one ?= | 17:00 |
| sergiusens | Chipaca nessita I get 401s when trying to download | 17:02 |
| Chipaca | sergiusens: you're doing it wrong then :-) | 17:03 |
| * sergiusens ponders just downloading from cdimage | 17:03 | |
| ogra_ | sergiusens, i'd do that | 17:03 |
| Chipaca | sergiusens: what're you trying to download? (or how?) | 17:03 |
| ogra_ | Chipaca, ubuntu-core | 17:04 |
| ogra_ | the os snap | 17:04 |
| niemeyer | zyga: See reply | 17:04 |
| Chipaca | ogra_: ok; from where? | 17:04 |
| Chipaca | sergiusens: ? | 17:05 |
| ogra_ | srote vs http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 17:05 |
| ogra_ | *store | 17:05 |
| Chipaca | right | 17:05 |
| Chipaca | that's what i'm wanting to know | 17:05 |
| ogra_ | cdimage is indeed a little newer | 17:05 |
| Chipaca | that thing that's on the right of the vs? is a url | 17:05 |
| Chipaca | i want that, for the left of the vs | 17:05 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ vs store | 17:06 |
| ogra_ | better ? | 17:06 |
| ogra_ | :) | 17:06 |
| Chipaca | ogra_: I'm going to send you a weaponized emoji | 17:06 |
| Chipaca | ogra_: :-D | 17:06 |
| ogra_ | lol ... you telegram kiddos ... so spoiled | 17:06 |
| sergiusens | Chipaca https://github.com/ubuntu-core/snapcraft/pull/452 | 17:06 |
| Chipaca | sergiusens: you're using download_url without being authenticated | 17:07 |
| nessita | sergiusens, what URL is giving you 401? | 17:07 |
| Chipaca | nessita: download_url :-) | 17:07 |
| * ogra_ notes how good it feels to have everyone back in one place :) (sad that telegram will work again at some point and yall will be gone again *sniff*) | 17:07 | |
| nessita | Chipaca, great answer | 17:07 |
| sergiusens | Chipaca I am authenticated | 17:07 |
| Chipaca | sergiusens: get anon_download_url as well, and/or do the dance | 17:07 |
| Chipaca | sergiusens: no you're not :-p | 17:07 |
| sergiusens | nessita I am authenticated | 17:07 |
| nessita | sergiusens, then your credentials are likely incorrect/expired | 17:08 |
| sergiusens | Chipaca I just uploaded a snap | 17:08 |
| sergiusens | nessita ^ | 17:08 |
| nessita | sergiusens, are you using staging or prod? | 17:08 |
| sergiusens | prod | 17:08 |
| ogra_ | sergiusens, the question is ... did your money transfer arrive yet | 17:08 |
| sergiusens | right | 17:08 |
| nessita | sergiusens, what package did you upload? | 17:08 |
| sergiusens | shout | 17:08 |
| sergiusens | 30 minutes or so ago | 17:09 |
| nessita | noise][, can you confirm CUD is working fine in prod for authenticated snap downloads? | 17:09 |
| nessita | sergiusens, checking | 17:09 |
| Chipaca | sergiusens: what revision? | 17:09 |
| zyga | niemeyer: read and replied; I don't know what should happen right now; | 17:09 |
| Chipaca | sergiusens: anyway, nessita and you can figure it out | 17:09 |
| Chipaca | i've got to start thinking about dinner | 17:10 |
| niemeyer | zyga: The problem is actually rather simple, I think | 17:10 |
| noise][ | nessita: should be, but lemme double check | 17:10 |
| niemeyer | zyga: We can have multiple snaps with the same name but different revisions installed in the system at any one point | 17:10 |
| zyga | niemeyer: yep, agreed | 17:11 |
| niemeyer | zyga: When a user sets up connections for a given snap, the natural expectation I think is that it will last for the duration of that snap being in the system | 17:11 |
| nessita | sergiusens, any chance you can print your request with the url and headers? | 17:11 |
| noise][ | nessita: looks good from what I can tell. Note that download-snap will redirect | 17:11 |
| nessita | noise][, yes, but sergiusens says he got a 401 | 17:12 |
| niemeyer | zyga: Imagine you've just installed firefox 2 and 1 is still installed.. if we remove firefox 1 for whatever reason, should we kill the connections for firefox altogether, despite the fact that firefox 2 is not only available but active (!)? | 17:12 |
| zyga | niemeyer: yes, that I agree with; what I don't know what to do about is the fact that don't keep multiple profiles (per revision) so remove-snap-security task is not scoped correctly (neither is setup-snap-security) | 17:12 |
| nessita | sergiusens, you 100% is a 401 and not a 302? | 17:12 |
| sergiusens | nessita no I am not fwiw | 17:12 |
| sergiusens | I'm not familiar with this api pindonga used | 17:12 |
| niemeyer | zyga: We don't need multiple profiles per revision. that would also be awkward.. | 17:13 |
| sergiusens | anon download url seems to work fine | 17:13 |
| niemeyer | zyga: Imagine you ask to drop a connection for firefox 2.. and then for whatever reason in two weeks decide to use firefox 1 again | 17:13 |
| nessita | sergiusens, I was referring to the download request; is that something that pindonga did as well? | 17:13 |
| niemeyer | zyga: I switched the revision, not my authorization | 17:13 |
| niemeyer | zyga: I'd not expect interface connections to be magically given back to the snap because I rolled back | 17:13 |
| sergiusens | nessita I did the download request, it is in the branch I shared above | 17:13 |
| zyga | niemeyer: right, I understand this; what I'm saying is that I don't quite understand what the tree tasks you've listed are responsible for | 17:14 |
| niemeyer | zyga: What we need right now is really simple: we need to disentangle the discarding of user-driven connection information from the removal of a particular snap from the system | 17:14 |
| nessita | sergiusens, yes, but I'm asking if you can retry and print the exact url you are hitting and the headers you are passing | 17:14 |
| niemeyer | zyga: Okay, again | 17:14 |
| nessita | sergiusens, not the code, but the specific values you are sendinf | 17:14 |
| zyga | niemeyer: that sounds like interfaces are not a part of that, if you remove a snap that is not the one that's active, security is not affected | 17:14 |
| niemeyer | zyga: setup-profiles.. put the profiles in the system | 17:14 |
| niemeyer | zyga: remove-profiles.. remove profiles from the system for a given snap | 17:15 |
| noise][ | nessita: sergiusens: FYI, auth on CUD is still oauth unless i have missed something | 17:15 |
| niemeyer | zyga: discard-conns.. drop connection information for a given snap | 17:15 |
| zyga | niemeyer: okay | 17:15 |
| zyga | niemeyer: how would remove-profiles be used by $ snap install $ snap remove and $ snap refresh? | 17:15 |
| niemeyer | zyga: setup-profiles and remove-profiles will _just_ add and remove profiles to the system | 17:15 |
| zyga | niemeyer: right, I understand what you mean, I'm trying to match that to snap operation | 17:16 |
| zyga | *operations | 17:16 |
| niemeyer | zyga: setup-profiles will also auto-connect, actually, because that's a handy place to do it | 17:16 |
| niemeyer | zyga: I see | 17:16 |
| sergiusens | nessita noise][ ok; fwiw this worked fine 2 days ago | 17:17 |
| niemeyer | zyga: on snapstate.Remove, if len(SnapSetup.Sequence) == 1, add discard-conns to the end of the pipe | 17:17 |
| * sergiusens blames python | 17:17 | |
| sergiusens | ;-) | 17:17 |
| ogra_ | just use cdimage :P | 17:18 |
| nessita | sergiusens, we can definitely help you more debugging this if you can print the URL you are hitting, the headers you are sending, and the response code you are getting | 17:18 |
| niemeyer | zyga: On discard-conns itself, double-check to ensure len is 1, just in case | 17:18 |
| niemeyer | zyga: Or rather, zero (or no state) | 17:18 |
| sergiusens | nessita yeah, I need to read the docs and figure out how to do that, one sec | 17:18 |
| niemeyer | zyga: Makes sense? | 17:19 |
| zyga | re (sorry, IRL interrupt) catching up | 17:20 |
| nessita | sergiusens, thanks! | 17:20 |
| zyga | niemeyer: so I disagree with what you said here: | 17:20 |
| sergiusens | nessita it is indeed a 401 | 17:20 |
| zyga | niemeyerzyga: on snapstate.Remove, if len(SnapSetup.Sequence) == 1, add discard-conns to the end of the pipe | 17:21 |
| sergiusens | nessita http://paste.ubuntu.com/15835131/ | 17:21 |
| zyga | niemeyer: if you have two versions of firefox and you run remove-snap-security task for a revision you are not using, it will break the one you are using | 17:21 |
| nessita | sergiusens, "GET /download-origin/local/canonical/ubuntu-core.canonic..." is not the store | 17:21 |
| zyga | niemeyer: you said that remove-profiles should just remove the profiles | 17:22 |
| nessita | sergiusens, that is something in snappy code, before the download server is hit (or after, but 401 may be a lie) | 17:22 |
| zyga | niemeyer: but those are global, they are not scoped to a snap revision | 17:22 |
| zyga | niemeyer: so I'm must be missing something or this is not going to do the right thing | 17:22 |
| zyga | s/remove-snap-security/remove-profiles/ | 17:22 |
| sergiusens | nessita there is no snappy in this code | 17:23 |
| niemeyer | zyga: What does it mean for it to be global? | 17:23 |
| niemeyer | zyga: and about the first quote, that's exactly what I mean! :) | 17:23 |
| zyga | niemeyer: not being scoped to a revision, remove-profiles is really simple, it just looks at the snap name and kills all the profiles of that snap *name* | 17:23 |
| niemeyer | zyga: THat's why we don't want to remove connections there | 17:23 |
| zyga | niemeyer: I think I understand connections now | 17:24 |
| niemeyer | zyga: I see, yes | 17:24 |
| zyga | niemeyer: can you give me a quick example that shows how two revisions of a single snap would interact? | 17:24 |
| zyga | niemeyer: wrt CLI commands and tasks? | 17:24 |
| niemeyer | zyga: But I don't see the disagreement.. remove-profiles just removes profiles for the given snap, okay | 17:24 |
| nessita | sergiusens, ok, let me rephrase: the store does not provide any /download-origin/local/canonical/ API, so that is not the store | 17:24 |
| niemeyer | zyga: We still want that | 17:24 |
| zyga | niemeyer: sure, that's okay :-) | 17:24 |
| nessita | sergiusens, is something else, and once identified, we could use knowing what URL is that hitting, which headers, and what actual return code is getting | 17:25 |
| niemeyer | zyga: Yes, remove-snap-security for firefox when removing firefox.1, drops all connections | 17:25 |
| zyga | niemeyer: if that's good in snapstate then there is no disagreement; I'm just confused as to how having multiple snaps with the sname name (and different revision) really works today | 17:25 |
| niemeyer | zyga: activate firefox.2 | 17:25 |
| noise][ | nessita: that's the redirect in CUD | 17:25 |
| niemeyer | zyga: Where are the connections I set up for it previously? GONE! | 17:25 |
| nessita | noise][, oh, now you make me look bad :-D | 17:25 |
| zyga | AHHH | 17:25 |
| zyga | niemeyer: I'm dumb :) | 17:25 |
| zyga | niemeyer: I get it | 17:26 |
| niemeyer | zyga: \o/ | 17:26 |
| niemeyer | ;) | 17:26 |
| noise][ | for CDNs - and currently we redirect to "local", which is /download-origin/… with a token for auth | 17:26 |
| zyga | niemeyer: sorry for taking so much of your time on this, I understand | 17:26 |
| nessita | noise][, is the signature validated before ther redirect? | 17:26 |
| zyga | niemeyer: I'll make that happen quickly | 17:26 |
| niemeyer | Cheers! | 17:26 |
| noise][ | nessita: yes, oauth is validated in download-snap, then redirect to download-origin w/that token to allow the actual download | 17:26 |
| noise][ | and is working fine for me in my tests | 17:26 |
| zyga | niemeyer: can you look at https://github.com/ubuntu-core/snappy/pull/950 | 17:26 |
| zyga | niemeyer: while the topic is still hot | 17:26 |
| zyga | niemeyer: this is reload in setup-snap-security | 17:27 |
| zyga | niemeyer: (see the TODO it removes) | 17:27 |
| noise][ | not sure what's different for sergiusens | 17:27 |
| sergiusens | nessita so don't lie to me please ;-) http://paste.ubuntu.com/15835258/ | 17:27 |
| nessita | sergiusens, yes, this was my bad, things are changing too fast | 17:27 |
| nessita | sorry | 17:27 |
| sergiusens | download_url I get back from the store points to https://public.apps.ubuntu.com/download-snap/canonical/ubuntu-core.canonical/ubuntu-core.canonical_16.04+20160409.16-42_amd64.snap | 17:27 |
| zyga | niemeyer: I think this is okay, no changes (apart from loooooooong test function names) are needed based on the conversation above | 17:27 |
| sergiusens | so I am either missing a header or something else | 17:28 |
| nessita | noise][, so, how can we debug why sergio is getting a 401? | 17:28 |
| sergiusens | zyga anon download url works fine for downloading the os snap ;-) | 17:28 |
| zyga | sergiusens: and the core snap? | 17:28 |
| zyga | sergiusens: what's a core snap? | 17:28 |
| sergiusens | zyga that's what I'm trying to get, `ubuntu-core` | 17:28 |
| zyga | sergiusens: ubuntu-core is currently an OS snap AFAIR | 17:29 |
| sergiusens | yes | 17:29 |
| ogra_ | sergiusens, 16.04+20160409.16-42 ? | 17:29 |
| ogra_ | thats ancient | 17:29 |
| nessita | noise][, can we assume that if download-snap was a 302, the Oauth was a success? | 17:29 |
| sergiusens | zyga don't get confused because people shorten names and use the name half complete and the type interchangeably | 17:29 |
| beuno | so | 17:29 |
| beuno | I know what it is! | 17:29 |
| sergiusens | ogra_ it is what the store gives back to me :shrug: | 17:30 |
| beuno | + | 17:30 |
| nessita | oh, a martin | 17:30 |
| * ogra_ wonders why sergiusens gets such an old version in return | 17:30 | |
| noise][ | nessita: correct, so no clue why the subsequent token would be bad | 17:30 |
| beuno | 16.04+20160409 | 17:30 |
| beuno | using + in URLs messes things up | 17:30 |
| ogra_ | 16.04+20160414.05-00 | 17:30 |
| beuno | it gets urlencoded in some layer, things to match | 17:30 |
| beuno | boom, etc | 17:30 |
| ogra_ | thast the current one | 17:30 |
| ogra_ | so the search is also returning the wrong thing | 17:31 |
| beuno | I'm looking forward to us switching to revisions for URLs :) | 17:31 |
| beuno | quick fix, re-upload with a less whacky version | 17:31 |
| beuno | proper fix, we switch to revisions for urls | 17:31 |
| sergiusens | beuno is there a reason the anon download works and the auth requiring one doesn't? | 17:32 |
| ogra_ | the version is generated by cdimage | 17:32 |
| beuno | maybe disallow +'s until we do | 17:32 |
| noise][ | aha | 17:32 |
| beuno | sergiusens, because oauth | 17:32 |
| beuno | and comparing URLs | 17:32 |
| beuno | and layers | 17:32 |
| sergiusens | oh | 17:32 |
| beuno | and software developers are terrible | 17:32 |
| sergiusens | ic | 17:32 |
| beuno | all of us | 17:32 |
| sergiusens | I know; I doubt myself every second! | 17:32 |
| noise][ | good catch beuno | 17:32 |
| ogra_ | beuno, so i need to re-do the cdimage code ? | 17:32 |
| sergiusens | so is upload automated? | 17:32 |
| ogra_ | not yet | 17:32 |
| sergiusens | for ubuntu-core | 17:32 |
| sergiusens | who does that, is it you ogra_ or mvo? | 17:33 |
| ogra_ | i was holding back because elopio said he could do it super easy with his jenkins instance | 17:33 |
| sergiusens | beuno since you are here, is anon download supposed to go away for ubuntu-core? | 17:33 |
| * noise][ has to go pickup food, bbiaf | 17:33 | |
| beuno | sergiusens, it'll go away when there's device auth | 17:33 |
| ogra_ | all i could do it to use the click-toolbelt ... since i cant run snapcraft on the 12.04 cdimage server | 17:33 |
| beuno | until then, it'll likely stay around just for the OS snap | 17:33 |
| noise][ | sergiusens: note we are going to be doing this same redirection thing to anon- as well | 17:34 |
| noise][ | likely by monday | 17:34 |
| ogra_ | beuno, could we keep it for the os snap even later ? | 17:34 |
| sergiusens | beuno the definition and resolution of the word "then" makes my path different for this | 17:34 |
| beuno | ogra_, why so? | 17:34 |
| sergiusens | as this download of the os snap is a hack until the kernel snap is redefined | 17:34 |
| ogra_ | beuno, makes porting easier ... a sa porter you need to have the os snap around | 17:34 |
| sergiusens | beuno enablement I guess | 17:34 |
| sergiusens | but then again ogra can run snapcraft login and forget about it | 17:35 |
| beuno | right | 17:35 |
| beuno | that's the idea | 17:35 |
| ogra_ | sergiusens, i cant | 17:35 |
| ogra_ | sergiusens, unless you port snapcraft to 12.04 | 17:35 |
| ogra_ | our cdimage server is ooold | 17:35 |
| beuno | ogra_, well | 17:35 |
| beuno | that's what needs fixing then | 17:35 |
| beuno | ;) | 17:35 |
| sergiusens | ogra_ to download the os snap, not upload! | 17:35 |
| ogra_ | you wont get IS to move | 17:35 |
| sergiusens | to upload you need auth no matter what! | 17:35 |
| ogra_ | sergiusens, oh | 17:35 |
| beuno | ogra_, we'll just go on a hunger strike | 17:36 |
| ogra_ | sergiusens, right, but that adds an extra hurdle for someone wanting to port | 17:36 |
| beuno | yes, I think it's an acceptable hurdle though | 17:36 |
| beuno | gets you in the right mindset | 17:36 |
| ogra_ | if i just want ot evaluate snappy for my new shiny board i probably dont even want to have or iuse an account at a canonical server | 17:36 |
| ogra_ | which will simply make me go to bitbake and yocto ... done | 17:37 |
| beuno | it sounds like a pretty small hurdle :) | 17:37 |
| ogra_ | for you and me perhaps :P | 17:37 |
| beuno | if that's what's going to tip the scales, the scales are probably already tipped | 17:37 |
| ogra_ | not for the enbedded people i talk to | 17:37 |
| beuno | the problem with exceptions is that they are essentially technical debt | 17:38 |
| ogra_ | (which is why i send them off to cdimage anyway, sionce there they can get the same thing without any authentication) | 17:38 |
| beuno | there are areas like authentication where technical debt is a bit worst than others | 17:38 |
| beuno | but | 17:38 |
| beuno | there's a sprint coming up, and you'll be there | 17:38 |
| ogra_ | right | 17:38 |
| beuno | so keep this in your back pocket :) | 17:38 |
| ogra_ | i definitely will ... especially sicne i expect gadget and kernel changes to be discussed there too | 17:39 |
| ogra_ | i really think all three of these snaps should go without any auth for the community images we provide | 17:39 |
| beuno | hold on | 17:40 |
| ogra_ | (totally fine to have the auth req. for oem products ) | 17:40 |
| beuno | device auth is automatic | 17:40 |
| beuno | you don't need an SSO account | 17:40 |
| ogra_ | once you have a working port, yes | 17:40 |
| beuno | well, that can be bridged by snapcraft | 17:40 |
| ogra_ | if i sideloaded all three snaps, then there will likely not be device auth | 17:40 |
| beuno | anyway, the requirement is auth one way or another | 17:41 |
| beuno | devices can be created in the fly | 17:41 |
| beuno | so it could be a transparent process | 17:41 |
| beuno | as long as you use snapcraf | 17:41 |
| ogra_ | so snapcraft will replace u-d-f ? | 17:41 |
| ogra_ | or how do i get a new board ported | 17:41 |
| ogra_ | (my focus is realyl on creating an initial image for not yet supported devices) | 17:42 |
| beuno | or u-d-f could create a device | 17:42 |
| beuno | whatever :) | 17:42 |
| sergiusens | ubuntu-image! | 17:43 |
| ogra_ | thats a merger of snapcraft and u-d-f ? | 17:43 |
| ogra_ | :) | 17:43 |
| zyga | ogra_: and it will be written in ruby, between python and go ;) | 17:44 |
| ogra_ | zyga, wrapped in .net i hope | 17:44 |
| ogra_ | so it runs on windows too | 17:44 |
| zyga | ogra_: with perl 6 installer | 17:45 |
| * zyga goes back to wrok | 17:45 | |
| ogra_ | as long as that has a TkTcl GUI i'm all fine | 17:45 |
| kyrofa | zyga, ogra_ ahhhh ruby | 17:54 |
| ogra_ | yep ... in ayear from now we'll all be hipsters ! | 17:55 |
| kyrofa | Haha, that's been one of my favorites for a long time now | 17:56 |
| kyrofa | I guess I'm a hipster :P | 17:57 |
| ogra_ | hah | 17:57 |
| ogra_ | and you didnt convince sergiusens yet to rewrite snapcraft ? | 17:58 |
| kyrofa | ogra_, it would probably involve bundling rvm somehow :P | 18:00 |
| ogra_ | just snap it ! | 18:01 |
| kyrofa | dpm, a docs update if you want to review: https://github.com/ubuntu-core/snapcraft/pull/454 | 18:07 |
| dpm | thanks kyrofa | 18:12 |
| kyrofa | dpm, ah, that was meant for davidcalle, sorry about that. But it got to the right place :) | 18:18 |
| dpm | :) | 18:18 |
| zyga | ssweeny: bluez merged, please open a new pull request if you need changes | 18:18 |
| ssweeny | zyga, thanks! will do | 18:22 |
| MichaelTunnell | are there any plans for other flavors to get Snappy? I assume 16.04 won't but do we know about 16.10 yet? | 18:29 |
| MichaelTunnell | Kubuntu, Ubuntu MATE, Xubuntu, etc | 18:29 |
| MichaelTunnell | is what I meant | 18:29 |
| MichaelTunnell | QUESTION: what if someone were to install a DEB for an app and then a SNAP becomes available? Will there be a process for SNAPs to overwrite the DEBs or would it be a case of "uninstall DEB and install the SNAP"? | 18:30 |
| beuno | MichaelTunnell, the snap will win over the deb when run | 18:31 |
| beuno | they can both be co-installed | 18:31 |
| beuno | but when you run the app, it'll run the snap | 18:32 |
| MichaelTunnell | beuno: ahh nice so it just uses a priority structure | 18:32 |
| beuno | right | 18:32 |
| beuno | MichaelTunnell, flavours can pull in snaps today, if they wanted | 18:32 |
| beuno | dpm might know more about what their plans are | 18:32 |
| beuno | you can also ask them directly :) | 18:33 |
| === JanC_ is now known as JanC | ||
| MichaelTunnell | I asked Kubuntu but so far their unsure too :) | 18:34 |
| MichaelTunnell | I figured that would be the case but worth asking :) | 18:34 |
| dpm | MichaelTunnell, essentially all flavours can already use the command line interface to install/remove/manage apps. The question is whether they decide to go the full integration route and add a plugin to their software installer to talk to the store | 18:34 |
| beuno | MichaelTunnell, so we're both in wait and see mode! | 18:35 |
| dpm | for those that already use gnome software, they'll get the full story already | 18:35 |
| MichaelTunnell | beuno: :) | 18:35 |
| MichaelTunnell | dpm: so Ubuntu GNOME could transition super easy in theory? | 18:35 |
| dpm | I know at least MATE already put the CLI tools in their seeds, and others are interested | 18:35 |
| dpm | MichaelTunnell, yeah, it'd be a matter of having the right packages put to their seeds to have it preinstalled (optimal situation) - or flavour users can also install the packages manually | 18:36 |
| davidcalle | kyrofa, thanks for the quick update! I'll have a look when I'm not on mobile | 18:36 |
| MichaelTunnell | was about to answer the user part . . . again you read my mind | 18:37 |
| MichaelTunnell | scary | 18:37 |
| MichaelTunnell | ask* the user part | 18:37 |
| MichaelTunnell | dpm: how well would Snappy work in a VM like if I were to install Snappy now could I demo everything in a VM? | 18:41 |
| MichaelTunnell | and by install Snappy I mean 16.04 Daily | 18:42 |
| dpm | MichaelTunnell, I've not tried it, but I guess it should work with no issues. In any case, if you're on 16.04 already, you can already try it today on your desktop. However, there is only a small subset of apps available and not all work atm, which is what we're right now trying to fix before we publish the documentation | 18:43 |
| crash_ | how do you know in the gnome-software which package is a snap or just a regular deb? | 18:45 |
| popey | MichaelTunnell: yes, you should be able to use snappy in a vm running 16.04 in that vm | 18:48 |
| popey | a good test actually as you'll be able to snapshot it, test it, revert and then do a demo live "on camera" | 18:48 |
| popey | better than screwing your man pc up ㋛ | 18:49 |
| MichaelTunnell | popey: thats a good idea. I wanted to have a stable recording of it so hence a VM but the rollback idea is great. :) | 18:55 |
| bhdouglass | hey guys, popey sent me here for some help with the click store api in relation to snappy packages. Currently uApp Explorer is only getting one architecture for most snaps even when they have more than one. I played around with the api and it looks like I need to explicitly specify the arch in the request in order to show anything different. I was hoping that uApp Explorer could get all the supported archs per package in one reque | 19:26 |
| dduffey | is the correct command to sideload a local snap in 16.04: | 19:28 |
| dduffey | sudo snappy install file:///home/ubuntu/blahlbah.snap? | 19:28 |
| MichaelTunnell | dduffey: snappy is gone basically, look at the man stuff for snap | 19:29 |
| MichaelTunnell | snappy the command is gone I mean :) | 19:30 |
| popey | yeah, sudo snap install ./foo.click | 19:32 |
| dduffey | popey, thanks "snappy package not found" | 19:35 |
| popey | did you do ./ in front? | 19:35 |
| dduffey | yep, but this is a .snap | 19:35 |
| dduffey | not a .click | 19:35 |
| popey | oh, duh | 19:35 |
| dduffey | brb | 19:35 |
| popey | yeah, sorry | 19:35 |
| dduffey | but still | 19:36 |
| dduffey | fails when I give it a local file | 19:36 |
| popey | odd | 19:36 |
| popey | dduffey: what does "snap list" show? | 19:36 |
| code1o6 | Hey has anyone since manik? | 19:41 |
| zyga | popey: list of installed snaps | 19:43 |
| popey | zyga: yeah, that was aimed at dduffey :) | 19:48 |
| dduffey | popey, sorry not in a position to cut and paste... but is says "unkown command list" and wanst ack, activate, cok... | 20:02 |
| dduffey | popey, ah, got some more info ... snappy install ./blah.snap says | 20:03 |
| popey | not snappy install... snap install | 20:03 |
| dduffey | "unkown header: "!<arch>\ndebian-binar" | 20:03 |
| popey | ah, known bug | 20:05 |
| dduffey | popey, work-around? | 20:06 |
| popey | I don't know, sorry. | 20:06 |
| popey | I'm a user, not a dev | 20:06 |
| dduffey | popey, okay, thanks | 20:07 |
| dduffey | apparently this snappy image / snap worked last week ... so not sure what changed or they knew a work-around (they are out this week) | 20:07 |
| zyga | FYI, snappy (the command) was replaced by snap | 20:10 |
| sergiusens | dduffey <arch>\ndebian-binar" means you are trying to install a 15.04 snap on 16.04 | 20:17 |
| mariogrip | can i build arm python2 apps with snapcraft on amd64? | 22:41 |
| mariogrip | if yes, how? | 22:42 |
| MichaelTunnell | cross architecture compiling? I doubt it. You could have the snappy build server do it | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!