[03:59] <stgraber> jdstrand: sent lxd 2.0 rc4 to the store, no packaging change
[07:34] <dholbach> good morning
[07:35] <didrocks> hey dholbach!
[07:35] <dholbach> salut didrocks
[09:52] <sabdfl> sync
[09:52] <sabdfl> hah
[09:52] <sabdfl> nervous twitch, that
[09:52] <ogra_> heh
[11:16] <renat> Hi all! It's Renat from Screenly!
[11:17] <renat> I have a question. Does this page contain up-to-date documentation? https://developer.ubuntu.com/en/snappy/guides/gadget/
[11:17] <kyrofa> Good morning
[11:18] <renat> Because when I moved assign part to the boot-assets branch it stopped to produce udev rules with hw-assing information
[11:18] <renat> Hi, kyrofa!
[11:18] <renat> There is a code block after the "Structure and layout" heading.
[11:20] <renat> PS. We moved to 16.04 and now I can't build a gadget snap properly.
[11:22] <renat> I used canonical-pi2 snap as a base.
[11:22] <renat> Just added config and assign part.
[11:22] <renat> Then tried to flash it using the ubuntu-device-flash tool from here: https://people.canonical.com/~mvo/all-snaps/
[11:27] <ogra_> renat, that should work fine
[11:27] <renat> If I place assign part as usual - I get other error: http://pastebin.com/RCmFFguP
[11:27] <renat> orga_, hello!
[11:27] <renat> ogra_, hello!
[11:27] <renat> Sorry=(
[11:29] <renat> ps. My os version it 16.04
[11:29] <ogra_> hmm ... mvo ^^^ ?
[11:30] <ogra_> (i didnt even know that files out of /boot were ever supported, did that work before ? )
[11:30] <ogra_> (supported from gadget snaps i mean)
[11:31] <renat> Here is my snap.yaml: http://pastebin.com/UANSHjkN
[11:32] <renat> ogra_, that worked fine on the  15.04
[11:32] <renat> With regular ubuntu-device-flash
[11:33] <ogra_> i guess the new "interfaces" security system gets in your way here
[11:33] <ogra_> zyga-phone, or mvo should eb able to tell something about it
[11:33] <zyga-phone> hmm?
[11:33] <zyga-phone> what's that?
[11:34] <ogra_> zyga-phone, hw-assign stuff from gadget snap as i understand it
[11:34] <renat> zyga-phone, hi!
[11:34] <zyga-phone> did it break?
[11:34] <zyga-phone> renat: hey!
[11:34] <zyga-phone> renat: AFAIK gustavo will publish spec on how gadget snaps can do this but it's not the same way as it was in 15.04
[11:34] <ogra_> renat, btw, did you try without the "assign:" bit ? does it work then ?
[11:35] <zyga-phone> renat: you will have to express connection between plugs in snaps and slots in the system
[11:35] <renat> Yes. It works. But I need to assign=)
[11:35] <ogra_> indeed
[11:35] <ogra_> i just want to be sure it is only that bit that breaks :)
[11:37] <ogra_> zyga-phone, it might be technically very complicated though ... looking at the u-d-f error it seems like it tries to add files to the os snap (which is obviously readonly) http://pastebin.com/RCmFFguP
[11:37] <ogra_> tghe new implementation needs to take that into account
[11:38] <zyga-phone> ogra_: yeah that sounds plausible
[11:38] <zyga-phone> ogra_: looks like it's just broken now
[11:38] <ogra_> yeah
[11:39] <zyga-phone> on the up side, I can now install a snap and see the interfaces instantly :)
[11:39] <zyga-phone> and connect them
[11:39] <zyga-phone> (I don't write security files yet, still waiting for a few branches to land)
[11:39] <zyga-phone> but integration is progressing nicely
[11:40] <kyrofa> Hey ogra_ you mentioned a few days ago that u-d-f --install seemed broken. It seems broken for me as well (not in snappy list, no systemd units for the services, etc.). Did you ever find a way around that?
[11:40] <ogra_> zyga-phone, well, this is for an appliance image so nobody will interact with the system, the assignment needs to be there by default
[11:40] <zyga-phone> yes
[11:40] <zyga-phone> that's supported but the syntax cannot be the same as hw-assign is gone
[11:41] <kyrofa> ogra_, failing that, do you know where we keep the rpi2 gadget sources so I can customize it a bit?
[11:41] <ogra_> kyrofa, nope, and i forgot to file a bug even ... what i saw was that the snap actually got installed under /snaps but the "current" link and all generated files (systemd services etc) were missing
[11:41] <zyga-phone> there's going to be a connection, in the model or gadget, not sure, that says "snap S1, plug P is connected to snap S2, slot S"
[11:41] <zyga-phone> and snappy will honor that
[11:41] <kyrofa> ogra_, yup, same
[11:41] <ogra_> kyrofa, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
[11:42] <renat> Hmm... I was able to do hw-assign on the 16.04 snappy.
[11:42] <renat> Is it the other way of setting up access rights to devices on 16.04?
[11:43] <ogra_> yes, it all changed
[11:43] <ogra_> (and i think hw-assign itself is actually gone in the latest images)
[11:44] <renat> Where can I read how it's done now? Or is there any example gadget snap where I can find hardware assigning stuff?
[11:46] <kyrofa> ogra_, where would you log that bug, anyway? https://bugs.launchpad.net/ubuntu/+source/phablet-tools ?
[11:48] <ogra_> kyrofa, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+filebug
[11:48] <kyrofa> ogra_, ahh
[11:49] <ogra_> if you give me the bug number i can confirm it :)
[11:58] <kyrofa> ogra_, bug #1558517
[11:59] <ogra_> confirmed
[12:02] <kyrofa> Thank you :) . So is trunk of that tool the version that actually works?
[12:02] <ogra_> i dont think so ... afaik the all-snaps stuff has not been merged yet
[12:04] <kyrofa> Ugh
[12:04] <kyrofa> So I can't even try to fix this
[12:05] <kyrofa> Maybe lp:~snappy-dev/goget-ubuntu-touch/all-snaps ...
[12:08] <kyrofa> I was hoping maybe the gadget would be as simple as "here's the stuff to preload" but it has all sorts of stuff in it that I don't want to duplicate. I'm not even sure I'd call that a workaround for this problem
[12:19] <kyrofa> ogra_, I'm willing to bet it's simply using an old version of snappy
[12:21] <renat> Ok. I found a little bit more information about new mechanism of slots and plugs. As far as I can understand - I need to create a plug to the file on the gadget snap. (I need access to the /dev/vchiq). But I still can't find how it's done on the gadget snap side=(
[12:22] <renat> Seems I'm digging to chaotically without knowing right direction=(
[12:22] <renat> Guys, can you help me with this, please?
[12:32] <kyrofa> renat, sorry, I'm afraid you have more gadget snap experience than I do :(
[12:32] <kyrofa> I'd love to help
[12:32] <kyrofa> renat, have you tried looking at the sources for the gadget snaps that already exist?
[12:34] <renat> kyrofa, I investigated these packages: ~snappy-dev/snappy-hub/snappy-systems but nothing useful there=(
[12:35] <kyrofa> renat, bah, sorry
[12:36] <renat> Interesting that there is two commands, snappy and snap. I can install snapcraft 2.4 generated snaps using "snappy" command, but not using "snap" command.
[12:43] <kyrofa> renat, yeah, we're in the midst of transitioning to snap
[12:43] <kyrofa> didrocks, I'm not sure what you're saying in your comment here: https://askubuntu.com/questions/746791/snappy-ubuntu-core-on-beaglebone-black/746814#746814
[12:43] <renat> I will continue using snappy for now.
[12:43] <didrocks> kyrofa: can you se my edit on your answer?
[12:43] <didrocks> kyrofa: it needs peer reviewing
[12:43] <kyrofa> didrocks, no, I'm not that cool on askubuntu apparently
[12:44] <kyrofa> didrocks, how might I get that ability?
[12:44] <didrocks> kyrofa: more credits/points
[12:44] <kyrofa> Boo
[12:44] <didrocks> hum, it seems that my edit was rejected :/
[12:44] <didrocks> let me retry
[12:44] <didrocks> and see if you can see it
[12:45] <didrocks> "This edit was intended to address the author of the post and makes no sense as an edit. It should have been written as a comment or an answer.
[12:45] <didrocks> "
[12:45] <didrocks> no, it was another option
[12:46] <didrocks> kyrofa: ok, let me write it as another answer then, and you can plus it :)
[12:46] <kyrofa> didrocks, ooo, rejected!
[12:46] <niemeyer> jdstrand: Heya
[12:46] <kyrofa> didrocks, alright, I'll plus it ;)
[12:46] <niemeyer> jdstrand: When you are around, would you mind to have another look at https://github.com/ubuntu-core/snappy/pull/658?
[12:47] <didrocks> kyrofa: https://askubuntu.com/questions/746791/snappy-ubuntu-core-on-beaglebone-black/747087#747087
[12:47] <didrocks> kyrofa: I'm plussing your answers so that you get credits as well :)
[12:47] <kyrofa> didrocks, I know, it gives me fuzzy feelings every time
[12:48] <didrocks> heh
[12:49] <kyrofa> Thank you :)
[12:49] <didrocks> thanks to you! :)
[13:01] <jdstrand> niemeyer: sure
[13:01] <jdstrand> niemeyer: and hi :)
[13:11] <niemeyer> jdstrand: Thanks!
[13:17] <ogra_> renat, i fear only zyga-phone and niemeyer can help with your prob (i havent used hw-assign from gadget before and they are the ones implementing the new featureset in 16.04 for such bits)
[13:19] <ogra_> there will at least be new syntax that i dont know where it is documented ...
[13:21] <renat> ogra_, thanks. Let me disturb them again, then=)
[13:21] <niemeyer> renat, ogra_: This is likely the best docs we have on it ATM: https://docs.google.com/document/d/1Q5_T00yTq0wobm_nHzCV-KV8R4jdk-PXcrtm80ETTLU/edit
[13:22] <niemeyer> Please note this is work in progress.. fast progress as we speak
[13:22] <niemeyer> renat: hw-assign will soon not be there
[13:22] <renat> niemeyer, already read them=( Decided to leave my question here: https://askubuntu.com/questions/747090/allow-access-to-the-device-file-on-the-snappy-16-04
[13:24] <renat> But the guy with nick "techraf" sends me back here=)
[13:25] <techraf> renat: I was suggesting, not sending you back
[13:25] <renat> techraf, hi!=)
[13:25] <ogra_> niemeyer, sadly that doesnt cover gadget vs oem snap defaults
[13:26] <ogra_> niemeyer, renat used to use the "assign:" bits in his oem snap in 15.04 and wants to convert that part to his 16.04 gadget snap now
[13:28] <niemeyer> ogra_: I don't recall us touching the gadget snap in that sense yet, although that's definitely going to be broken soon indeed if it's already not
[13:29] <ogra_> right, it used to call hw-assign during image creation in u-d-f .... but with all-snaps it cant actually create the udev rules inside the os snap (since it is readonly now)
[13:30] <niemeyer> ogra_, renat: Aha, indeed.. that's not going to work
[13:30] <renat> niemeyer, we need to wait for an update?
[13:30] <ogra_> yeah, we need to have some equivalent by release though
[13:31] <niemeyer> renat: So the answer is that this isn't working yet, sorry.. it will once interfaces land entirely and we get the gadget to express the default connections to be made
[13:31] <niemeyer> renat: What is in that document explains how that's going to work, but it doesn't document how the gadget snap will express those default connections
[13:31] <niemeyer> renat: That's on me to specify over the next few days
[13:31] <renat> niemeyer, understood, thanks.
[13:33] <ogra_> i'd suggest to use your app snap unconfined for now so you are not blocked by this
[13:33] <ogra_> (temporary indeed)
[13:34] <renat> ogra_, yes. I can do hw-assign for now. At least - it worked today=)
[13:34] <ogra_> heh, or that :)
[13:34] <ogra_> (as long as it still works)
[13:35] <jdstrand> niemeyer: should I concern myself with the 'Handling errors' email to snappy-devel?
[13:35] <niemeyer> renat, ogra_ : Sweet.. hw-assign will probably be broken very soon.. but we'll introduce the development mode before or while we do that so snaps can continue to evolve while we finish the proper logic
[13:36] <niemeyer> So you'll be able to do something along the lines of "snap install --devel <snap>" and get something that is "unconfined" (it'll have more logic to aid in development, besides unconfinement)
[13:37] <ogra_> neat !
[13:37] <renat> niemeyer, ogra_, thanks!
[13:37] <ogra_> (it would even be cooler if it could convert from squashfs to ext2 at install time so you can edit in place ;) )
[13:38] <jdstrand> niemeyer: it seems resolved in the comments of the PR, so I guess I'll just ignore the email thread
[13:39] <niemeyer> jdstrand: It's sorted.. let me answer Zygmunt's email
[13:40] <niemeyer> ogra_: You'll be able to do the equivalent of that, in a much nicer way
[13:40] <ogra_> wow
[13:40] <niemeyer> ogra_: we will get a "snap try" or "snapcraft try" subcommand, which you can call inside the snap development tree
[13:41] <ogra_> cool
[13:49] <qengho> Hi hi. So, when a process calls "snappy config $p yamlfile", it's the responsibility of the config program in the package to verify and then write a new configuration file for the program, right? Is it supposed to signal the running process to reload right then?
[13:51] <ogra_> qengho, thats the job of what you defined as "config:" in the snap..yaml of $p
[13:52] <qengho> ogra_: Okay, so the config program in-package should both write the native config file AND reload the process right away.
[13:52] <ogra_> qengho, http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml uses http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/config.sh in my ircproxy package to generate a bip.conf file for the bip binary it ships for example
[13:52] <ogra_> (though shell for parsing yaml is perhaps not what you want :) )
[13:52] <qengho> Python3 forever
[13:53] <ogra_> yeah, i dont really like to ship megabytes of python in my snap for just that
[13:54] <ogra_> (the python interpreter in the os snap isnt guaranteed to be there ... we might drop it now that we got rid of system-image)
[13:55] <qengho> ogra_: gasp! Sounds like some better yaml tool should be a to-do item.
[13:55] <ogra_> you can use a go or C binary ::)
[13:57] <qengho> If I delighted in doing things the hard way, I would not be using snappy at all.
[13:58] <ogra_> well, in any case relying on anything from the os will make your snap not os independent ... which it should be since nothing (except snappy itself) is guaranteed in there
[13:59] <ogra_> we might even drop the shell at some point (for some snappy shell implementation)
[14:00] <ogra_> sorry ... s/the shell/bash/ .... /bin/sh will have to be there for boot scripts and the like
[14:03] <qengho> ogra_: can I have some kind of built-in programming language that isn't 1975 Bourne shell? Tcl? Awk?
[14:08] <ogra_> qengho, whatever you ship :)
[14:08] <qengho> ogra_: And? Can I rely on coreutils?
[14:09] <ogra_> you can guess for them :)
[14:09] <ogra_> one of the core feastures of snappy is that apps and the os can be updated completely independently ... that only works if you dont make such assumptions
[14:10] <ogra_> the question for coreutils is if confinement allows you to use them at all
[14:12] <ogra_> (you can indeed make an assumption that python is there or that you always have a certain libc version. but you will risk that the independence breaks when one of them gets in incpmpatible update ... we do not have any actual dependency support)
[14:12] <ogra_> s/in/an/
[14:56] <noise][> Chipaca or mvo: do you know if it's on anyone's plate to tweak the autoupdate frequency (https://bugs.launchpad.net/snappy/+bug/1537793) ?
[15:04] <kyrofa> ogra_, looking at the pi2 gadget, autopilot is false. But when I create an all-snaps image it's true. Does that mean another gadget is being used?
[15:05] <ogra_> kyrofa, no, it means the option isnt called autopilot anymore :)
[15:05] <kyrofa> ogra_, hahaha
[15:05] <ogra_> legacy code is legacy :)
[15:06] <kyrofa> ogra_, so I can safely remove that, then. Auto-updates seem to work in all-snaps anyway
[15:06] <kyrofa> Yeah?
[15:06] <ogra_> yeah
[15:07] <kyrofa> ogra_, is gadget->software->preinstalled still valid?
[15:07] <ogra_> not sure
[15:07] <ogra_> (i always used --install to get preinstalled snaps)
[15:07] <kyrofa> ogra_, I'm not sure how I'd find out. Dive into the snappy source I guess
[15:08] <ogra_> or just add something and see if it gets installed :)
[15:08] <kyrofa> ogra_, I just learned that --install will never work for 16.04, by the way
[15:08] <ogra_> oh
[15:08] <kyrofa> ogra_, it's not a bug in u-d-f, it's a snappy thing
[15:08] <kyrofa> ogra_, where the snaps used to be activated upon boot, but no longer are
[15:08] <kyrofa> ogra_, u-d-f installs them without activating them
[15:09] <ogra_> well, we surely want webdm preinstalled as we had it before ... in the official imgs
[15:09] <kyrofa> ogra_, we'll have to do it with model assertions then
[15:09] <ogra_> whatever works :)
[15:09] <kyrofa> ogra_, yeah, they're be a way to do it anyway
[15:09] <kyrofa> there'll
[15:10] <ogra_> as long as we know early enough to implement it for the release all is fine i guess
[15:10] <kyrofa> Agreed
[15:25] <kyrofa> jdstrand, I'm trying to upload a gadget that is essentially the rpi2 gadget with a preinstalled snap
[15:25] <kyrofa> jdstrand, it failed review, obviously because it's a gadget, but also with "found binaries for architecture 'all': boot-assets/bcm2709-rpi-2-b.dtb, boot-assets/start_x.elf, boot-assets/bcm2708-rpi-b.dtb, boot-assets/fixup.dat, boot-assets/fixup_x.dat, boot-assets/bootcode.bin, boot-assets/uboot.bin, boot-assets/start_cd.elf, boot-assets/uboot.env, boot-assets/bcm2708-rpi-b-plus.dtb, boot-assets/start.elf, boot-assets/fixup_
[15:25] <kyrofa> cd.dat lint-snap-v2_valid_contents_for_architecture"
[15:25] <ogra_> thats normal
[15:25] <kyrofa> Ah, okay
[15:26] <kyrofa> jdstrand, I requested manual review. Do you mind checking it out?
[15:26] <ogra_> gadget is a special case :)
[15:28] <kyrofa> ogra_, the error message didn't tell me why any of that was actually an error, either
[15:28] <ogra_> because your snap is arch: all ... cant contain arch specific binaries
[15:29] <kyrofa> ogra_, I thought you could do that, as long as you had a shell script to dispatch
[15:29] <ogra_> (i.e. you ship armhf binary files ... technically your snap should be arch: armhf then ... but thats not true for gadgets)
[15:30] <ogra_> if you would do that in an app snap with a dispatcher script you had to define all arches you ship binaries for (but not use "all")
[15:30] <ogra_> not sure if it still exists ... we used to have arch: multi as well
[15:30] <kyrofa> Oh right, I forgot about that!
[15:30] <ogra_> which indicated multiple binary arches
[15:31] <kyrofa> Okay, that makes sense then
[15:31] <ogra_> (i forgot why exactly gadgets have to be arch: all though ... but there was a reason :) )
[15:32] <kyrofa> ogra_, yeah I'm sure there's some technicality there somewhere
[15:34] <jdstrand> kyrofa: yeah. I may use it as a guinea pig for a change
[15:35] <ogra_> do we actually allow snaps inside snaps ?
[15:35] <kyrofa> jdstrand, sure! I'm on a bit of a timeline though, can I still get that through this morning?
[15:35] <jdstrand> yes
[15:35] <jdstrand> just be a few minutes
[15:36] <kyrofa> jdstrand, not a problem at all then, thank you :)
[15:45] <sergiusens> ogra_, I left a cliffhanger for you in that initrd.img thread; hope you don't mind
[15:46] <kyrofa> sergiusens, hahaha, you piqued my curiosity
[15:46] <kyrofa> "Wait... what?"
[15:46] <sergiusens> kyrofa, lol
[15:47] <sergiusens> well we have to wait :-)
[15:47] <sergiusens> jdstrand, ogra_, given the thing about models and the architecture will be defined there it seems perfectly reasonable to make the gadgets arch specific now
[15:49] <jdstrand> kyrofa: fyi, I pressed the button.
[15:49] <kyrofa> jdstrand, I appreciate it! Did it work for your test?
[15:50] <jdstrand> kyrofa: my change worked locally, yes. I suspect the store will need a pull, but wanted to run through the tests again to make sure
[15:50] <kyrofa> jdstrand, wait, it says failed review
[15:50] <kyrofa> jdstrand, should I request manual again?
[15:50] <jdstrand> kyrofa: yes, I pushed the run the tests again button
[15:50] <jdstrand> please do
[15:50] <kyrofa> Oh, THAT button
[15:50] <ogra_> sergiusens, not a cliffhanger at all :P
[15:50] <jdstrand> :)
[15:50] <kyrofa> jdstrand, done
[15:51] <sergiusens> ogra_, oh, the why we don't mount part
[15:52] <kyrofa> Still a cliffhanger! Even more intense now as ogra_ totally ignored it
[15:52] <jdstrand> oh hrmm, I thought this was like yesterday's owncloud
[15:52] <jdstrand> this is a gadget snap
[15:52] <ogra_> lol
[15:52] <kyrofa> jdstrand, right, it's just reloading yesterday's owncloud
[15:52] <kyrofa> preloading, rather
[15:52]  * ogra_ wonders if he has all mails in that thread already ... my old mailserver often delays delivery 
[15:52] <jdstrand> sorry, got a wire crossed cause I was asked to do another one that needed a different review tools fix
[15:52] <kyrofa> jdstrand, oh oops, I'm sorry!
[15:53] <jdstrand> kyrofa: ok, let me look at this more closely
[15:54] <jdstrand> kyrofa: I guess this is following all the new gadget yaml?
[15:54] <kyrofa> jdstrand, honestly I don't know. I just copied the rpi2 one and added the preinstalled key
[15:55] <jdstrand> kyrofa: what command did you use to generate the snap?
[15:55] <kyrofa> jdstrand, snappy build
[15:56] <jdstrand> ok, you hit bug #1546821
[15:56] <jdstrand> kyrofa: can you do: mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs
[15:56] <kyrofa> jdstrand, oh darn, I forgot about that
[15:56] <jdstrand> kyrofa: and reupload?
[15:56] <ogra_> or snapcraft snap ;)
[15:57] <kyrofa> jdstrand, will do. I'm comparing that YAML to https://github.com/ubuntu-core/snappy/blob/master/docs/gadget.md though, and it doesn't match up. Should it?
[15:57] <kyrofa> ogra_, I tried snapcraft snap and it gave me a wonderfully cryptic error
[15:57] <kyrofa> ogra_, I'll look into that later ;)
[15:57] <ogra_> oh
[15:57] <jdstrand> kyrofa: honestly? idk
[15:57] <kyrofa> jdstrand, I'm going to assume the pi2 one is valid... and I'll test it out as soon as it's in the store
[15:58] <jdstrand> sure
[15:58] <jdstrand> when the docs are all up to date, I'll update the tools for gadget snaps
[15:58] <jdstrand> they'll always trigger a manual review and I can see who uploaded, so I can just waive it through atm
[15:59] <ogra_> should gadgets probably stay manual forever ?
[16:00] <jdstrand> that is my current thinking. that doesn't mean the tools can't do lint checks though
[16:00] <ogra_> sound like the place i'd  actually do the malicious stuff since it is the most powerful snap in the chain
[16:00] <ogra_> yeah
[16:00] <jdstrand> kyrofa: so, this should specify the architecture, no?
[16:00] <jdstrand> that is what sergiusens suggested
[16:01] <kyrofa> jdstrand, there we go, no more hash mismatch error
[16:01] <kyrofa> (uploaded again and in the manual review queue)
[16:02] <kyrofa> jdstrand, this has gadget->hardware->architecture, but it seems the gadget snaps are arch all
[16:02] <jdstrand> ok, thanks
[16:02] <jdstrand> I'll approve and add a todo to fix that
[16:03] <jdstrand> kyrofa: this one has a .git directory
[16:03] <kyrofa> Argh
[16:03]  * jdstrand rejects
[16:04] <sergiusens> jdstrand, today they are arch all
[16:04] <sergiusens> jdstrand, or u-d-f won't find them
[16:04]  * kyrofa alters the layout of the repo
[16:04] <jdstrand> I see
[16:04] <sergiusens> jdstrand, as it doesn't know before hand what arch a gadget targets
[16:04] <jdstrand> is gadget->hardware->architecture something to look at?
[16:04] <sergiusens> jdstrand, the functionality of the gadget has been split out and some of it moved to the model
[16:04] <jdstrand> is https://github.com/ubuntu-core/snappy/blob/master/docs/gadget.md accurate?
[16:05] <sergiusens> jdstrand, but that is not there yet, when it happens, gadgets can be arch specific
[16:05] <jdstrand> I see
[16:05] <jdstrand> I'll just wait then
[16:05] <ogra_> this btw makes all gadget snaps show up in snap find/webdm on all arches
[16:05] <ogra_> which is rather ugly
[16:05] <sergiusens> ogra_, that is probably a bug; we used to filter out gadget snaps completely
[16:05] <sergiusens> as they are only selectable during build time
[16:05] <ogra_> yeah,m we should do again
[16:06] <sergiusens> stevebiscuit, ^
[16:06] <ogra_> well, there were discussions about bootloader updates
[16:06] <ogra_> for that you would at least want to see the installed gadget
[16:06] <sergiusens> ogra_, yeah, but you should only see your own gadget
[16:06] <kyrofa> jdstrand, uploaded again, sorry about that
[16:06] <ogra_> right
[16:06] <sergiusens> I guess for browsing you can say "show me uninstallables"
[16:07] <sergiusens> and it will show you other arches and gadgets
[16:09] <jdstrand> kyrofa: approved. thank you for being patient
[16:10] <kyrofa> jdstrand, ha! Barely any time at all, thank you for taking the time to check it out :)
[16:44] <stevebiscuit> sergiusens, ogra_: noted
[17:11] <kyrofa> jdstrand, I needed to switch the preinstalled key to built-in on that gadget snap. Mind checking it out again?
[17:15] <kyrofa> ogra_, FYI, preinstalled isn't supported in 16.04, only built-in
[17:16] <ogra_> someone should clean up the docs ;)
[17:16] <kyrofa> ogra_, yeah didrocks is working on revamping it quite a bit actually
[17:17] <kyrofa> ogra_, though it sounds like the content of the kernel and gadget snaps will still be changing here soon
[17:18] <ogra_> well, nothing that touches the user actually
[17:18] <kyrofa> ogra_, well, developers though
[17:18] <ogra_> that will all be internal stuff (if you refer to the initrd discussion)
[17:19] <kyrofa> Oh, no. I mean all the extra stuff currently included in the gadget might get thinned out/put into other snaps (e.g. the kernel)
[17:19] <ogra_> ah
[17:22] <kyrofa> beuno, I pinged jdstrand about this but I just noticed that he's away. Can I get someone to take a look at the owncloud-pi2.kyrofa gadget snap's update?
[17:25] <beuno> kyrofa, sure
[17:26] <beuno> kyrofa, approved
[17:26] <kyrofa> beuno, thank you!
[17:28] <qengho> Ugh. Slots and plugs are bewildering.
[17:30] <kyrofa> qengho, how so? Can we help?
[17:41] <qengho> kyrofa: Is https://github.com/ubuntu-core/snappy/blob/master/docs/meta.md supposed to be up to date?
[17:42] <kyrofa> qengho, doesn't look like plugs are mentioned in there, eh?
[17:42] <kyrofa> qengho, so no, I'd say not
[17:42] <kyrofa> Want some examples to look at instead?
[17:43] <qengho> kyrofa: I think that page is wrong in at least a dozen ways.
[17:43] <kyrofa> qengho, I think I agree with you
[17:44] <kyrofa> qengho, looks like sections of it have been updated while others have languished
[17:44] <ogra_> like our code :P
[17:44] <kyrofa> ogra_, hahahahahaha
[17:45] <kyrofa> qengho, but in all seriousness, there are several examples here that can show you how to use plugs/slots: https://github.com/ubuntu-core/snapcraft/tree/master/examples
[17:46] <kyrofa> qengho, sorry about the docs, things are still in flux leading up to 16.04
[17:48] <qengho> kyrofa: I understand. Thanks.
[17:48] <qengho> ls
[18:08] <jdstrand> kyrofa, beuno: I'm back now
[18:08] <kyrofa> jdstrand, all good now, thanks! Tested and works
[18:08] <jdstrand> kyrofa: was this another upload? did I not approve it?
[18:08] <kyrofa> jdstrand, it was another upload
[18:08] <jdstrand> ok
[18:08] <jdstrand> I really thought I was losing it
[18:30] <ryanleesipes> Hey folks, how's it going?
[18:38] <ogra_> ryanleesipes, busy ... heading towards a stable 16.04  :)
[18:39] <ryanleesipes> ogra_, haha, makes sense
[18:39] <ryanleesipes> how far out is it you think?
[18:41] <ogra_> stabilizing every day :)
[18:42] <ogra_> it should be in beta state when the deb based ubuntu release comes out ... and finished a few weeks after that
[18:42] <ogra_> (deb release date is april 21st or so)
[18:54] <kyrofa> jdstrand, just uploaded another owncloud.canonical using network-listener. Mind pressing the button on that one?
[18:55] <kyrofa> jdstrand, sorry for this today
[18:57] <kyrofa> jdstrand, I'll have one more in a minute as well, same package but for armhf
[18:57] <kyrofa> jdstrand, then I should be done
[18:58] <jdstrand> done
[19:00] <kyrofa> jdstrand, alright, armhf is in queue now
[19:01] <kyrofa> jdstrand, now I think I'm done ;)
[19:01] <jdstrand> done
[19:01] <jdstrand> kyrofa: np :)
[19:01] <kyrofa> jdstrand, awesome, thanks so much!
[19:01] <jdstrand> :)
[19:41] <qengho> I thought Launchpad's snap-building feature would be too good to be true. I guess the builders don't download "parts".
[19:46] <noise][> is this the proper way to get outbound network access for a snap:
[19:46] <noise][> plugs:
[19:46] <noise][>   old-security:
[19:46] <noise][>     caps: [network-client]
[19:47] <kyrofa> qengho, yeah internet access is disabled right now, but that will be fixed soon
[19:47] <kyrofa> qengho, kinda useless right now unless your snap is archive-only
[19:47] <kyrofa> qengho, I was told "a week or two"
[20:16] <kyrofa> jospoortvliet, images FINALLY done, email sent. So sorry for the delay
[20:30] <qengho> f
[21:52] <plars> elopio: *hopefully* I managed to fix the merge breaks from recent updates with my two PRs, have a look if you get a sec
[21:52] <plars> elopio: I'm off tomorrow
[21:56] <qengho> Yay, uploaded first package. Boo, fails automatic review because of network listener.
[21:57] <kyrofa> qengho, that's to be expected!
[21:57] <kyrofa> qengho, request a manual review
[21:58] <kyrofa> qengho, network-listener will be changing names shortly, and the review tools are a little ahead of the times. jdstrand knows about this
[21:59] <jdstrand> I know about this and added it back in trunk and requested a fix
[21:59] <jdstrand> a pull*
[21:59] <qengho> kyrofa: how does one request a manual review?
[21:59] <qengho> kyrofa: state is still "pending review".
[21:59] <kyrofa> qengho, oh... how do you know it failed then?
[22:00] <kyrofa> jdstrand, heh, got tired of all my reviews eh?
[22:01] <kyrofa> qengho, in my experience there's a big red bar say that it failed the review, and it's a link. If you click that link and scroll to the bottom of the review log you'll see "Request manual review"
[22:01] <qengho> kyrofa: At what web site? myapps.develeloper.u.c?
[22:02] <kyrofa> qengho, right
[22:02] <kyrofa> qengho, so you must have just gotten an email, eh?
[22:03] <qengho> kyrofa: I did.
[22:04] <qengho> kyrofa: and I found the button. Submitted.