[00:22] Who can tell what kind of error? http://paste.ubuntu.com/15822298/ [00:24] General-Beck, looks like that error is specific to the service you're trying to install [00:24] General-Beck, and it's restarted several times fast enough that systemd just stopped trying [00:26] the fact that the restart is clear, but the error indicated `ubuntu-core-launcher ERROR: Error upgrading parity data: CannotLockVersionFile` [00:50] code https://github.com/ethcore/parity-snappy/tree/master/snap [00:58] I think I know the reason [02:38] ping elopio === test is now known as Guest70089 [02:42] ping elopio [02:49] ping elopio === chihchun_afk is now known as chihchun [04:21] hi, guys! [04:52] 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] What do I miss? [04:55] ypwong: some snap which started with ubuntu, which name I don't remember, something about core or base [05:11] Mikaela, you're right, install ubuntu-core snap and now it can be run [05:12] but now got "QXcbConnection: Could not connect to display :0" === devil is now known as Guest28671 === Guest28671 is now known as devil__ === not_phunyguy is now known as phunyguy [06:08] good morning === sgclark_sleeping is now known as sgclark === attente_ is now known as attente [07:16] mvo: telegram seems to be down [07:16] mvo: I've posted a trivial branch https://github.com/ubuntu-core/snappy/pull/936 [07:17] 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] mvo: so iface manager doesn't ever see ubuntu-core [07:17] mvo: so we don't add implicit slots and get all the auto-connection magic to happen [07:17] zyga: interessting, the code should do exactly the same as for the first download, hmmm [07:18] mvo: try it, wipe your state, then install hello-world [07:18] mvo: and list interfaces [07:18] mvo: (on master) [07:18] mvo: (maybe merge the branch above so that it's not painful if snapd doesn't start [07:18] mvo: then restart snapd and it will see ubuntu-core interfaces (I do a scan on startup) [07:18] zyga: I'm not disputing that you see this :) I'm just puzzled why it happens [07:19] * zyga would love _some_ logging to be there for tasks [07:21] 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] 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] 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:25] mvo: fyi, telegram sends every other message I wrote; I'll switch to irc for now [07:25] (the remaining messages are marked as queued) [07:27] Morning o/ [07:29] zyga: Telegram has finally realized this group was using half of its bandwith ;) [07:29] davidcalle: and 90% of the cat photo traffic ;) [07:31] 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:32] davidcalle: snappy auto-connects certain interfaces that are deemed safe or important, e.g. network, network-bind, x11 and unity7 [07:32] davidcalle: for other interfaces we will add auto-connection when assertions are in place [07:32] davidcalle: because those interfaces give a lot of power [07:32] davidcalle: and lastly users still can disconnect anything they want [07:33] I see [07:33] davidcalle: later on with hardware interfaces you will need to pick stuff, e.g. which GPIO pin goes to "mr blinky" snap [07:33] davidcalle: this is why plugs and slots have interface type -- there will be multiple interoperable ways to connect snaps to hardware [07:34] Yeah, makes sense then [07:34] 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:46] good morning [07:46] fgimenez: morning :) [07:47] hey zyga :) [07:47] 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] mvo, ^ [07:49] 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] 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:51] 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] mvo, ok thx, on it [07:52] ogra_`: do we alreay support the raspberry pi 3 with snappy today? [07:53] fgimenez: hmm, I should update ubuntu-image then [07:53] yay, tests are green again [07:54] once https://github.com/ubuntu-core/snappy/pull/938 gets merged [07:56] mvo: merged [07:57] mvo: can you run "go test" in daemon/ for me it seems to hang... [07:59] ah, no it's just slow [07:59] sorry :) [08:08] mvo: latest u-d-f fails to find OS snap [08:09] ah, ignore me [08:09] Good morning [08:11] If a snapcraft.yaml contains multiple 'parts', is it possible to refer from 'part2' to the build or install directories of 'part1'? [08:13] 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:15] didrocks: thanks I will try that === EkePoetry is now known as ToyKeeper [08:16] yw! keep us posted :) [08:19] 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:23] Gunther_: yeah, that should be doable this way then. [08:29] * zyga has connect + security working, fights through mock layers to let daemon tests go [09:22] mvo: I have a simple daemon branch for review, do you have a moment? [09:23] Chipaca: ^ ditto [09:24] https://github.com/ubuntu-core/snappy/pull/942 [09:29] mvo: https://github.com/ubuntu-core/snappy/pull/943/files [09:39] ogra_: ping [09:41] morphis__: once you know about pi3 support please ping me, I'd like to support it in ubuntu-image [09:51] zyga: will do :-) [09:55] mvo: around? [09:55] mvo: (I don't know if you see my pings on telegram) [09:56] 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] ogra_: sounds great! [09:57] long term plan is to have the 32bit image work on both ... and eventually have a 64bit img additionally [09:57] ogra_: one other thing, is http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ supposed to be the new place for daily snappy images? [09:58] morphis, well, the store is ... but yes, these snaps go to the store [09:59] ogra_: for snaps, yes, the store is the place, but talking about .img files I can flash [09:59] ah [09:59] no, thats a 15-04 dir ... [09:59] sorry missed that you had the wrong path in there [10:00] http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ [10:00] thats the path for the roilling dailies [10:00] we will release underneath http://cdimage.ubuntu.com/ubuntu-snappy/ though ... in a 16.04 subdir [10:01] (with img files) [10:01] ogra_: ok, so what do I take from daily-preinstalled to flash? xenial-preinstalled-core-amd64.tar.gz for example? [10:03] 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:04] that creates test.img which you can flash [10:04] you need the u-d-f from http://people.canonical.com/~mvo/all-snaps/ for that [10:04] ogra_: so u-d-f with support for that wasn't yet released? [10:04] oh, there is a "rolling" missing in the command [10:05] 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] sadly not ... mvo is planning an SRU i think [10:05] hm [10:06] (effectively there is a new tool in the works but that wont make the release most likely) [10:06] ogra_: tool to replace u-d-f-? [10:06] 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] yes, a tool to replace u-d-f [10:08] interesting [10:08] ogra_: however, will we end up with actual .img files for the release? [10:09] perhaps :) [10:10] ok [10:10] (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] I see [10:11] ogra_: hi, anyidea how can i compile an armhf snap ? [10:11] daker, do you have an armhf board ? [10:11] yes rpi2 & bbb [10:11] with a snappy install ? [10:12] not yet [10:12] does snappy/snapcraft comes with the ubuntu-core img ? [10:13] snapcraft 1.x i mean :D otherwise i have to rewrite the snapcraf yaml again [10:13] oh [10:13] 1.x [10:14] * ogra_ hasnt used that in ages :P [10:14] 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] (you can then just apt-get what you need and build your stuff) [10:15] 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] from http://cdimage.ubuntu.com/ubuntu-core/daily/current/ [10:17] hmm is someone interested in reviewing a kmodule.py plugin for snapcraft? http://paste.ubuntu.com/15826883/ [10:18] Gunther_: send it to sergiusens_ on github [10:18] ok [10:22] zyga: as pull request? [10:31] niemeyer: telegram is not quite working for european people atm, they said it was fixed but seems back to not working again [10:36] pedronis: Ah, I thought everybody was taking a good rest :-) [10:36] zyga: Some feedback on #943 [10:39] zyga: 942 is in [10:40] zyga: 943 has a few comments [10:44] mvo: 941 is missing update-pot it seems [10:49] niemeyer: let me fix that [10:50] niemeyer: thank you [10:59] is there an easy way to look into a .snap package? [11:00] Gunther_, mount it ... it is a squashfs file ;) [11:00] too much work :) [11:00] haha [11:01] you can also use unsquashfs indeed [11:02] i think "unsquashfs -l" lists the content without unsquashing [11:04] mounting worked great :) [11:14] re [11:14] niemeyer: hey! [11:14] niemeyer: looking, thanks [11:21] niemeyer: refreshed https://github.com/ubuntu-core/snappy/pull/943 [11:21] niemeyer: have a look please, we can get connect/disconnect security working after that :) [11:22] 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:24] zyga: Yeah, most people are in I think [11:25] niemeyer: I pinged mvo, pedronis and Chipaca without effect [11:25] maybe just not looking at irc notificaction (desktop integration) [11:25] zyga: I see their messages, but not your pings [11:25] niemeyer: I also tried in snappy-internal [11:26] niemeyer: as long as I can talk to you we're good :) [11:26] zyga: I don't see your pings in snappy-internal either [11:26] hmmm [11:26] * zyga restarts irc [11:26] * zyga loves technology [11:27] zyga: I think it'd be trivial to have SetupCallback recording the calls instead of the fake public value [11:27] zyga: But it's okay to do that later [11:27] irc should have a "no emergency calls" disclaimer [11:27] niemeyer: yes, I agree, I'll try to do that today after all the feature work is in place [11:27] zyga: It's okay, let's focus on the release.. this is an easy TODO for next week after things have calmed down [11:28] zyga: It's in [11:29] perfect, now for the meat [11:35] niemeyer: https://github.com/ubuntu-core/snappy/pull/948 [11:35] niemeyer: that's getting us 90% there [11:35] niemeyer: I'll work on setup-snap-security to be fully operational [11:35] niemeyer: and on remove-snap-security [11:35] niemeyer: along with some tests for both [11:36] niemeyer: _after_ that I'd like to get developer mode working [11:36] niemeyer: and switch connect/disconnect to async REST [11:36] 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] zyga: I can do the async rest thing immediately [11:36] niemeyer: please do, thanks! [11:36] zyga: Will look at the branch first [11:36] niemeyer: does the plan above look good, anything to shuffle or change? [11:37] zyga: What's still pending about setup-snap-security? [11:37] niemeyer: we still disconnect and don't reconnect [11:37] zyga: In which sense? [11:38] 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] niemeyer: and perhaps auto-connect should not reconenct something that was disconnected by the user [11:38] niemeyer: that's all for setup (plus tests) [11:39] niemeyer: for remove AFAIR we don't remove the connection from the state (+ tests) [11:39] niemeyer: I feel I can do those very quickly with the testing helpers I now have [11:40] zyga: Sounds good.. quite a few items there.. best to do those piecemeal [11:40] yep, that's my plan! [11:40] zyga: For autoconnect, [11:41] 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] zyga: Then, use that as a blacklist when reconnecting [11:41] niemeyer: mmm, yep, that sounds doable [11:42] zyga: Also an easy fix after it's all working [11:42] yep === devil is now known as Guest8551 === Guest8551 is now known as devil_ [12:15] niemeyer: I have setup-snap-security, how about we land https://github.com/ubuntu-core/snappy/pull/948 [12:36] Good morning [12:37] kyrofa: hey [12:38] Hey zyga :) . How are things going? [12:38] kyrofa: irc/telegram is flaky today [12:38] kyrofa: almost all interface features are implemented, just last few bits and I'm happy [12:38] zyga, excellent! [12:39] zyga, we're releasing snapcraft with that interface change pretty quick (if not already done) [12:39] kyrofa: sounds like a good day :) [12:43] zyga, indeed! [12:43] kyrofa, zyga it just passed adt, so it is making its way out of proposed [12:44] sergiusens_, morning! Thanks for the update :) [12:44] sergiusens: great news [12:44] niemeyer, mvo: what is the release plan for today? [12:44] kyrofa yeah, and I just built shout irc and running it in the snappy dimmension :-) [12:45] chatting from a browser now :-) [12:45] sergiusens, nice-- so the network interfaces are working now? [12:46] zyga: definitely [12:46] zyga: a release [12:46] zyga: later today, evening most likely. anything I should wait for? [12:47] mvo: I should be done with essentials in < 1 hour (all implemented, pending review) [12:47] mvo: I'll do more apparmor work and I'll try to get developer mode in [12:47] sergiusens, hah, now install my ircproxy snap and chain them :P (wont work, fully relies on snappy config :/ ) [12:48] niemeyer: all done on https://github.com/ubuntu-core/snappy/pull/948 [12:48] zyga: sounds great [12:48] kyrofa seems so [12:49] ogra_ I want to install shout on some server somewhere eventually (but I need to solve https without snappy config) [12:49] 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] sergiusens, yeah, it is rather awful to lose snappy config :/ ... only one of my packages doesnt use it [12:50] ogra_, yeah when I saw that email I immediately thought of you [12:50] * ogra_ hopes it will be back soon [12:50] zyga: yes [12:53] kyrofa so now more cleanups ahead [12:53] sergiusens, the example tests still fail-- have you tried shout on snappy instead of snappy dimension recently? [13:02] kyrofa we need a new `ubuntu-core` for that [13:02] Ah, okay gotcha [13:02] niemeyer: https://github.com/ubuntu-core/snappy/pull/948/commits/bf0ce588cace658bd20a09850a453e2ef973911e [13:06] niemeyer: https://github.com/ubuntu-core/snappy/pull/948/commits/ec305bef724e84519150160265ecdcbe3e3240ab [13:06] niemeyer: both done (perhaps stale browser diff?) === mariogrip_ is now known as mariogrip [13:41] niemeyer: ^^ I don't know if you saw those two commits above [13:41] niemeyer: is that what you meant earlier or is something missing still? [13:42] zyga: Did you get my comments in Telegram? [13:42] zyga: Or are you still having connectivity issues/ [13:42] ? [13:42] niemeyer: no [13:42] niemeyer: apparently so [13:42] Gustavo Niemeyer, [14.04.16 09:56] [13:43] @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] Gustavo Niemeyer, [14.04.16 09:56] [13:43] @zyga_pl The boilerplate being added everywhere as a side effect is unnecessary [13:43] Gustavo Niemeyer, [14.04.16 09:57] [13:43] niemeyer: No such command! [13:43] niemeyer: No such command! [13:43] @zyga_pl So securityBackends can actually be simply []interfaces.SecurityBackend, no function calls [13:43] niemeyer: No such command! [13:43] nothal: shh! [13:43] poor bot :) [13:43] niemeyer: ahh === beuno_ is now known as beuno [13:43] niemeyer: you are right, this will be killed with old-security [13:43] zyga: The comments described that [13:43] zyga: Even with code :) [13:44] niemeyer: if you want I can do it right now [13:44] zyga: Yeah, I think it'd be useful [13:44] zyga: As I see it growing legs elsewhere [13:44] niemeyer: it is one of the places that still had connection to old-security having special needs [13:44] one moment [13:45] ogra_: thanks i will test that [13:48] niemeyer: pushed [13:55] zyga jdstrand hey, would it be sensible to allow something like $EDITOR? [13:55] sergiusens: what do you mean? [13:55] sergiusens: for a snap to run $EDITOR? [13:56] zyga shout has this facility where it you can do `shout config` which just runs `$EDITOR ` which is sort of nice given snap directories [13:57] hmmm [13:57] that isn't going to work great [13:57] sergiusens: we cannot expand $EDITOR that the user has [13:57] sergiusens: we'd have to whitellist a range of editors but that would never work reliably [13:57] cause EDITORs write all over the place [13:57] * jdstrand agress with zyga [13:58] jdstrand right, so my solution is to provide a minimal editor in my snap and set $EDITOR up to use that, right? [13:58] that is why we don't allow it now [13:58] sergiusens: it could be done with an editor interface [13:58] sergiusens: sure, you could do that [13:58] sergiusens: not sure if the UX for that would be good though [13:58] sergiusens: you then can configure the editor to point at whatever files are in your snap/writable by your snap [13:59] zyga and editor interface (or a vim.tiny or nano one) which only allows read/write to SNAP_ if possible would be great [13:59] I did something like that for a personal snap of mine [13:59] I shipped vim and setup all the various .vimrc, etc to look in the right places [13:59] 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] well [14:00] that interface would require support from the os snap [14:00] jdstrand ok, sounds good, I'm going to see if I can find something more light weight and less dep heavy [14:00] yeah, longer term, it would be nice to think of something for this, I don't mind today [14:00] 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:01] I guess the snap could ship its own nano or vim.tiny [14:01] but then what good is the interface. just set your editor to work in your writable areas === sergiusens74 is now known as sergiusens [14:22] mvo: around? [14:22] I need a 2nd +1 on https://github.com/ubuntu-core/snappy/pull/948 [14:26] 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:34] dholbach: I'm making some updates to https://docs.google.com/spreadsheets/d/1xBHxFwBNk3HjomnxzOjrohy-E3eyjAGX8ZLvXPqOG84/edit#gid=0 [14:37] thanks a lot jdstrand! [14:37] dholbach: I see a lot of old-security in the snap-playpen, so fixing that as I come across it [14:38] jdstrand: I have 90% of security side of interfaces implemented; should be released today [14:38] jdstrand, thanks... most of the contents of the branch is old... it's from last week! [14:38] jdstrand: I'll try to get developer mode as well [14:38] dpm, ^ [14:39] jdstrand: can you quickly review https://github.com/ubuntu-core/snappy/pull/933 [14:39] jdstrand: (trivial) [14:39] awesome, thanks jdstrand! [14:39] jdstrand: without old-security I'd like to simplify that futher still but this needs to land first [14:39] 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? === stgraber_ is now known as stgraber [14:39] 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:40] halfline: 2) same thing 1) not exactly (we don't use most namespaces AFAIR) [14:43] zyga: and how does it relate to docker? similar technology but different implementation ? [14:43] halfline: it has the same perception; we don't put apps in a container [14:43] halfline: we use apparmor and seccomp to sandbox them [14:43] zyga: ah okay thanks [14:44] halfline: we use some namespaces but just for confinement [14:44] but not a chroot [14:45] 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] we do not use a file namespace-- apparmor handles that [14:46] jdstrand: gotcha ! thanks much [14:46] * zyga will start collecting FAQs [14:55] jdstrand: can I also remove (harcode) /snap as INSTALL_DIR or is that used by any of the include files? [14:57] 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] jdstrand: right, I remember something like that being mentioned, fine with me [14:57] jdstrand: can I at least drop /gadget from it? [14:58] zyga: if /gadget no longer exists [14:58] 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] I don't know the status of what gadgets are doing [14:59] jdstrand: https://github.com/ubuntu-core/snappy/pull/955 [14:59] jdstrand: (without any changes to INSTALL_DIR) [14:59] zyga: btw, autoconnect is working nice in 1.9.2 [14:59] kyrofa https://github.com/ubuntu-core/snapcraft/pull/451 [14:59] jdstrand: cool! [14:59] zyga: Huh [14:59] zyga: What's /gadget? [15:00] niemeyer: it's a directory where snaps can be installed to according to the apparmor template [15:00] niemeyer: it feels like some really old leftover [15:01] in days past, gadget snaps were installed in /gadget [15:01] aiui [15:01] if all snaps are in /snap, then fine to remove /gadget [15:01] * jdstrand just didn't know the status of gadget snaps [15:04] * zyga has huge lag on internal IRC [15:06] 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:08] Hi, is there any news over the new stable version? [15:10] Or will it be next week the release? [15:10] zyga, jdstrand: Yeah, let's kill it [15:11] niemeyer: ack, will do === chihchun is now known as chihchun_afk [15:11] noizer, snappy images will happen later [15:11] fgimenez, elopio: Any news about the int tests? [15:12] 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] 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] niemeyer, yep, they are currently broken because of scalingstack failures, IS is already looking into it [15:13] fgimenez: Super, thank you [15:13] ogra_: Ok [15:14] niemeyer, yw, i'll ping you when ready [15:14] fgimenez: Appreciated, thanks! [15:15] ogra_: Wil the image be ready this month for the raspberry pi 3? [15:15] niemeyer: while we wait for unit tests to pass on the other branch: https://github.com/ubuntu-core/snappy/pull/955/files [15:15] 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] niemeyer: this is just removal of old security and changes to internal-only apparmor variables to make more sense [15:15] noizer, no promises ... but yeah, pi3 is on my prio list [15:16] it will definitely be ready by snappy release [15:16] Ok [15:16] niemeyer: and (more importantl actually) we can now look at this :-) https://github.com/ubuntu-core/snappy/pull/950/files [15:18] ogra_: Will libsnaps be available in the stable release? [15:19] libsnaps ? [15:21] ogra_to compress ;-) [15:23] niemeyer: https://github.com/ubuntu-core/snappy/pull/958 [15:25] 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] Chipaca do you have your branch handy where you worked on the store api changes? I need to do the same [15:26] noizer, you mean snapcraft ? [15:28] 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:29] noizer: that will be done wtih interfaces [15:29] noizer: but it's not supported yet [15:29] noizer, oh, that ... i think thats already possible ... but only for your own snaps [15:29] ah ... zyga is surely more up to date here :) [15:30] noizer: we will probably prototype that with the SDK runtime [15:30] noizer: I don't know now [15:30] hi, where are the Snappy images for the Dragonboard 410c ? [15:30] edsiper: you can use https://github.com/zyga/devtools but I don't think we guarantee that they work this week [15:30] zyga: ogra_ Will there be later on in the development of snappy. be possible to share it with other users that develops snaps? [15:31] fgimenez: I'm following the discussion in #ubuntu-on-air. It's interesting. [15:31] noizer: perhaps not, use snapcraft for that, we don't want to get into deb dependency [15:31] yeah, very unlikely [15:32] zyga ogra_ ok thx for the information. [15:33] ogra_: zyga I needed this information because i have tomorrow a meeting with Maarten Ectors. Do you know him? [15:34] not personally ... but yeah [15:34] noizer: sorry, I'm busy now I cannot help you; we're working on the release still [15:35] ogra_: zyga Ok keep up the good work! [15:46] 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:48] zyga, ok, thanks [15:48] almejo: this was just answered by beuno in ubuntu-on-air [15:49] yes.. I was writing here just when he was talking and lost half of the answer :(... [15:49] thanks guys for your time [15:51] 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] I guess I'm doing something wrong, I ran 'sudo lxd init' and lxd is working for autopkgtest stuff for me [15:53] or kyrofa ^ :) [15:53] * kyrofa jolts awake [15:54] dholbach I need to see what broke since the latest lxd release and why this stopped working [15:55] dholbach I think I am creating instance names that are too long [15:56] dholbach about the 404; check your sources lists or run with `--enable-geoip` [15:56] dholbach, yeah can you use apt okay? [15:56] sergiusens, I think it's because of PPAs and stuff like that [15:57] 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:58] dholbach, davidcalle, popey, mhall119: and I updated the notes and pastebins when things were different [15:58] jdstrand, wow wow wow! [15:58] thanks a lot [15:58] sergiusens, with enable-geoip it now works [16:00] jdstrand: https://github.com/ubuntu-core/snappy/pull/962 [16:00]