[08:07] <fgimenez> good morning
[08:08] <mvo> hey fgimenez, good morning
[08:08] <fgimenez> hi mvo :)
[08:09] <dholbach> good morning
[08:16] <mvo> hey dholbach, good morning
[08:21] <dholbach> hey mvo
[09:04] <davidcalle> Good morning
[10:03] <JamesTait> Good morning all; happy Monday, and happy Button Day! 😃
[11:23] <dholbach> mvo, from which ppa would I get the most up-to-date ubuntu-snappy-cli for devel and 15.04 respectively?
[11:32] <mvo> dholbach: generally ppa:snappy-dev/tools is a good one, what do you need it for? we also have daily build ppas
[11:32] <sergiusens> ogra_, dholbach how do I update https://developer.ubuntu.com/en/snappy/guides/porting/ ?
[11:32] <ogra_> sergiusens, didnt someone give you write access to that ?
[11:32] <davidcalle> sergiusens, login with http://developer.ubuntu.com/openid/login
[11:33] <sergiusens> ogra_, yes, but not sure if there is a markdown source synced from it
[11:33] <davidcalle> sergiusens, ah, no md source
[11:33] <sergiusens> davidcalle, grat, I'll take the bullet tonight, wasn't easy to edit from the web for me :-P
[11:34] <dholbach> mvo, the question came up if we could automatically import a snappy manpage (I found out that 'snappy man' creates one)
[11:34] <davidcalle> sergiusens, if you struggle with the editor, ping me or dholbach anytime :)
[11:34] <sergiusens> I'll ping mhall as you guys might be sleeping when I decide to edit this ;-)
[11:35] <dholbach> mvo, maybe during the build one could be generated? :)
[11:35] <sergiusens> dholbach, if you can, Chipaca and myself failed to hook it up correclty in debian/rules
[11:36] <dholbach> sergiusens, ok, I'll take a look
[11:36] <davidcalle> sergiusens, naah, I'll just give you dholbach phone number, he is awake all night! :p
[11:36] <Chipaca> um
[11:36] <Chipaca> sergiusens: I have "man snappy"
[11:36] <Chipaca> sergiusens: from debian/rules
[11:36] <sergiusens> davidcalle, oh, I have him on telegram, I can wake him up :-P
[11:36] <sergiusens> Chipaca, oh, then it was already done and I forgot
[11:36] <Chipaca> sergiusens: don't you?
[11:37] <Chipaca> $ dpkg -S snappy.1
[11:37] <Chipaca> ubuntu-snappy-cli: /usr/share/man/man1/snappy.1.gz
[11:37] <sergiusens> Chipaca, yes
[11:37] <dholbach> Chipaca, you're right, thanks O:-)
[11:38] <Chipaca> sergiusens: i did this when i added 'snappy man' :)
[11:38] <sergiusens> let me rephrase, **I had a hard time** and then you created a working branch ;-)
[11:39] <sergiusens> dholbach, there is no man in ubuntu core though
[11:39] <dholbach> sergiusens, no worries - this would be for importing into the dev site
[11:39] <Chipaca> dholbach: note the manpage also lists internal commands, as it's a zero-effort automatic thing generated from the thing that does commandline parsing
[11:40] <dholbach> Chipaca, that's good to know
[11:40] <Chipaca> dholbach: ideally those internal ones would be pruned (but upstream isn't amenable to patches)
[11:41] <dholbach> mvo, the last ubuntu-snappy-cli uploads to that ppa are from july
[11:41] <mvo> Chipaca: for some unexplained reason that has changed recently and the patch to hide stuff is in. at the same time the drop-priv stuff will soon vanish
[11:41] <Chipaca> mvo: seriously? woo! we should merge that in
[11:41] <mvo> dholbach: hm, then you will need the daily one from ppa:snappy-dev/image
[11:42] <mvo> Chipaca: yeah, no explanation just the github message "merged #XY"
[11:42] <dholbach> mvo, great - thanks
[11:42] <Chipaca> mvo: there's 5 internal commands, not just drop-priv. And some more that could probably do with being reclassified as internal.
[11:43] <Chipaca> mvo: e.g. booted is internal, but firstboot isn't?
[11:43] <Chipaca> ah, wait, first_boot is
[11:43]  * Chipaca learns to read
[13:35] <ogra_> hmpf
[13:36] <ogra_> sergiusens, Chipaca, do we have some kind of "inetd plugin"  in snapcraft ? i wonder how to snap up a service that relies on it
[13:36] <Chipaca> ogra_: we do not
[13:36] <ogra_> ah sad
[13:36] <Chipaca> ogra_: we'd have to expose one more service flag for that
[13:36] <Chipaca> which is totally doable, but needs doing :-)
[13:36] <ogra_> well, not sure if thats very common
[13:37] <ogra_> (people packaging inetd depending services)
[13:37] <Chipaca> ogra_: OTOH, all you need to turn an inetd plugin into a regular service is netcat
[13:37] <ogra_> yeash
[13:37] <ogra_> thats my fallback idea
[13:37]  * Chipaca oversimplifying complex engineering problems since 1976
[13:37] <ogra_> i'm just wondering if it is a common task ... in which case a snapcraft option would make sense
[13:38] <Chipaca> ogra_: file a bug, see how many people me-too it?
[13:38] <ogra_> yeah, will do
[13:39] <Chipaca> ogra_: don't forget to say «don't comment with “me too”», so people comment with “me too”
[13:39] <ogra_> +1
[13:39] <ogra_> :D
[13:40] <ogra_> geez
[13:40] <ogra_> so i tried to snap up approx (which caused the above question) ... and just noticed the resulting snap is 74MB !!
[13:40] <ogra_> thats half an OS !
[13:40] <ogra_> (or even a full one)
[13:44] <sergiusens> ogra_, build it from source!
[13:45] <ogra_> heh
[13:45] <ogra_> crazy talk !
[13:54] <Chipaca> ogra_: https://gist.github.com/chipaca/58552b58a1a75cd1607b
[13:55]  * Chipaca hugs rsalveti 
[13:56] <ogra_> Chipaca, dude ! why is that not snapped !
[13:57] <Chipaca> ogra_: because i'd need to change it for small memory systems
[13:57] <Chipaca> ogra_: or clean it up
[13:57] <Chipaca> ogra_: maybe even merge in whatever's gone on with TinyHTTPProxy in the 3+ years since I did this to it
[14:03]  * rsalveti hugs Chipaca
[14:27] <rtg> lool, hey, can you have a look at git://kernel.ubuntu.com/rtg/kernel-snap.git and tell me why my snapcraft.yaml doesn't copy files into the snap from staging ?
[14:28] <ogra_> rtg, did you find a way to generate the initrd yet ?
[14:28] <rtg> ogra: I ruthlessly butchered rootstock to do so
[14:28] <ogra_> lol
[14:29] <ogra_> you should really take the livecd-rootfs snippet for that :)
[14:29] <ogra_> rootstock adds a massive overhead
[14:30] <rtg> ogra_, the first thing I did was to only go one level deep. I didn't need to do nested qemu. hence the major surgery, but I did extract the concepts I needed.
[14:31] <ogra_> well, you need the nested qemu chroot if you are actually buildin for another arch
[14:31] <ogra_> but only then
[14:32] <ogra_> beyond that a simple "debootstrap --variant=minbase" should be fine
[14:32] <rtg> for now I'm just trying to get amd64 working
[14:33] <ogra_> debootstrap --variant=minbase + PPA setups for the different special kernels + the snappy specific packages needed in the initrd
[14:33] <ogra_> that should be all you need
[14:33] <ogra_> then just install your meta and pull out the files from the tree you need
[14:33] <rtg> ogra_, what snappy specific packages do I need in the initrd ?
[14:34] <ogra_> initramfs-tools-ubuntu-core at least ... i have to chekc livecd-rootfs
[14:34] <rtg> ogra_, that sounds familiar
[14:34] <ogra_> (there are a few more)
[14:35] <sergiusens> rtg, how about building the kernel instead of using the deb?
[14:35] <sergiusens> for people building alternate trees
[14:36] <rtg> sergiusens, that is the next example I'm gonna work on
[14:36] <sergiusens> great
[14:36] <sergiusens> rtg, after we have this I guess I'll start using your stuff to create a proper plugin that wraps all this in
[14:36] <rtg> sergiusens, I thought I'd do a snap for each reference kernel, plus one as an example for building from source
[14:41] <lool> rtg: you need to make install to DESTDIR
[14:42] <rtg> lool, in the Makefile plugin ?
[14:42] <lool> rtg: in the Makefile itself, yup
[14:42] <lool> rtg: snapcraft sets DESTDIR to the right di
[14:42] <lool> dir
[14:42] <rtg> lool, cool, now I see that in the examoples
[14:49] <fgimenez> elopio_, the jenkins instance is ready to go, you have access to the canonistack dashboard as the ues-snappy-integration-tests user, right?
[14:50] <elopio_> fgimenez: yes.
[14:50] <mvo> fgimenez: is it possible to run the new integration test machinery against the branch https://github.com/mvo5/snappy/tree/feature/native-security-policygen-regen ? or is that not possilbe (yet?)
[14:51] <fgimenez> elopio, ok, it's created for that user, there's also a floating ip assigned to it, the webhook should point to it
[14:51] <fgimenez> elopio, sure, the -src flag is the branch and the new repo flag the repo location, like https://github.com/user/snappy
[14:52] <fgimenez> elopio, in that case -src native-security-policygen-regen -repo https://github.com/mvo5/snappy
[14:53] <fgimenez> mvo, ^ :)
[14:53] <elopio> mvo: ^
[14:53] <elopio> mvo, fgimenez, but we can't yet generate an image with taking the snappy deb from the branch, right? We can just overwrite the snappy binary for now.
[14:54] <fgimenez> elopio, yes, snappy and snapd binaries
[14:54] <mvo> elopio: that should be ok, I'm curious if the integration test shows any regressions. if its a lot of work for you I can just merge and see the results from the normal integration test run. this needs to go in, but of course the less disruption the better :)
[14:54] <fgimenez> mvo, whenever you make a PR or add commits to an existing one the job is triggered anyway, once the webhook is in place
[14:56] <mvo> fgimenez: ok, is it worth waiting for the webhook, i.e. is this happening really soon? no problem if not, I'm ponering if I merge now or wait a little bit, but I'm more on the merge-now side currently
[14:57] <fgimenez> mvo you can set it up right now :) this is the url http://162.213.34.171:8081/ghprbhook/, the events ticked should be "Pull request" and "Issue comment"
[14:58] <fgimenez> mvo, it is in the "Settings -> Webhooks & services" section of the repo
[14:58] <mvo> fgimenez: aha, nice. let me try that
[14:59] <fgimenez> mvo, the jenkins instance is at http://162.213.34.171:8080, only accessible from the vpn
[15:01] <elopio> fgimenez: I'm not sure where I got the idea that uboot was not changing snappy_ab on update. Maybe it was a bug, or maybe it came from the voices in my head.
[15:02] <fgimenez> elopio, :) iirc i've seen it not being changed, anyway now the code is a lot cleaner
[15:03] <ogra_> rtg, http://paste.ubuntu.com/13299329/ try turning that snippet into a script and you should get something that is identical to the device tarballs that livecd-rootfs creates today ... without all the rootstock overhead
[15:04] <ogra_> (there are some live-build specifics in there you need to replace but thats minor)
[15:05] <rtg> ogra_, I thought the goal was to build a snap, not a device tarball
[15:06] <ogra_> rtg, you want the same contents in both
[15:06] <ogra_> they should be absolutely identical except that one is a squashfs img and the other is a tarball
[15:07] <rtg> ogra_, even the YAML file ?
[15:07] <ogra_> thats something mvo needs to answer ... :)
[15:08] <ogra_> you definitely want the same initrd and you want the right PPA used for the right suabarch
[15:08] <ogra_> and afaik mvo used the existing device tarballs during the all snaps development as input
[15:08] <rtg> ok. I am close to being able to build the snap. I have some permissions issues. then I'll look at this.
[15:21] <asac> would personally be awesome if we could make the kernel plugin capable of cross compiling
[15:22] <asac> rtg: ogra_ sergiusens: ^
[15:22] <asac> just as input
[15:22] <rtg> asac, when built from source it certainly will be.
[15:22] <sergiusens> asac, I'm fine with per plugin x-compile
[15:23] <ogra_> asac, trivial ...
[15:23] <ogra_> (but needs qemu-user-static for the initrd chroot ... that will limit us)
[15:24] <asac> rtg: are we doing the "built from debs in archive" variant first?
[15:24] <asac> guess yeah, then its later
[15:24] <rtg> asac, yup, that is what I'm working on
[15:24] <asac> sergiusens: isnt x- something we used for something else?
[15:24] <ogra_> asac, rtg, the initrd generation will always have to be deb based FWIW
[15:25] <ogra_> we dont have a way to "just generate" one without that
[15:25] <rtg> ogra_, fortunately the kernel makefile has a deb target
[15:25] <asac> i thoguht we do generic initrd that is in the OS
[15:26] <asac> so we dont need that in kernel
[15:26] <ogra_> we *could* do the same we do for touch and actually geneare the initrd inside a package build ... but then you need to be sure to never need modules for booting
[15:26] <asac> mvo: ?
[15:26] <sergiusens> asac, x as in cross
[15:26] <sergiusens> not sure what else you speak of ;-)
[15:26] <mvo> asac: sorry in a meeting
[15:26] <asac> sergiusens: yeah, thought we used x- for another implicit meaning... like local plugins, but think we moved away from that
[15:26] <asac> all fine
[15:26] <ogra_> asac, we cant ... specifically with the new requirement for squashfs
[15:26] <ogra_> you need the modules
[15:26] <asac> ogra_: i think its the spec to have initd in OS snap
[15:26] <sergiusens> asac, we have that still (x for extension)
[15:26] <asac> and just say kernel folks have to built in what they need
[15:26] <ogra_> thats not possible
[15:26] <ogra_> you need to find the rootfs from the initrd
[15:27] <asac> well, it technically would get copied
[15:27] <ogra_> which means you need to support the disk type, controller, filesystem
[15:27] <asac> to the boot paertition from the OS
[15:27] <asac> but the one and only initrd is in the OS snap ... so we dont need to build it turning kernel buil;d
[15:27] <ogra_> asac, that still wont have the right contents
[15:27] <asac> thats how i understand at least one of the proopsals
[15:27] <ogra_> you need the kernel modules inside the initrd
[15:27] <asac> ogra_: we can say you cant put them there\
[15:27] <asac> like what you suggested for long time :)
[15:27] <ogra_> then you cant boot
[15:27] <mvo> asac: generic initrd is on the roadmap *but* right now we need the squashfs and nls modules (iso8859) so we can't have a module-less iniitrd
[15:28] <sergiusens> ogra_, asac rtg can't we make initrd mount the modules from the kernel?
[15:28] <ogra_> asac,  if we can have it module less, we can do the same as for touch
[15:28] <ogra_> sergiusens, you still need to find them
[15:28] <asac> so you need modules only in the initd if you need them to mount the rootfs afaik
[15:28] <asac> so thats disk drivers, filesystem types etc.
[15:28] <ogra_> sergiusens, so all needed modules for that need to be there
[15:28] <ogra_> asac, right
[15:28] <rtg> sergiusens, yeah, what ogra_ said
[15:29] <asac> once you have rootfs (or a partition that hosts the modules) you can go and load modules
[15:29] <sergiusens> ogra_, then it is a no brainer to just include it in the kernel
[15:29] <ogra_> asac, network cards for things like remote keys for encrypted rootfs
[15:29] <asac> hmm
[15:29] <sergiusens> it is not really a generic kernel, is it?
[15:29] <asac> well, so there is still stuff that is rather a configuration etc.
[15:29] <ogra_> sergiusens, if we actually want saushfs inside all kernels, sure ;)
[15:29] <ogra_> sergiusens, it is -generic
[15:29] <ogra_> thats the prob :)
[15:29] <asac> dont think the factory keys would go into the initrd ... at least i never anticipated that
[15:29] <sergiusens> ogra_, it always going to be loaded for core
[15:29] <ogra_> asac, no, the keys live on a remote server
[15:30] <ogra_> asac, but you need to obtain them via network
[15:30] <ogra_> at least in one specific arch we support today
[15:30] <ogra_> sergiusens, from where ?
[15:31] <sergiusens> ogra_, from the kernel itself
[15:31] <ogra_> note that i would love nothing more than to use the same setup we have for the touch initrd in core
[15:31] <ogra_> but as long as we hard depend on modules we cant
[15:37] <rtg> sergiusens, how do you inspect a snap ? seems like there was a dpkg option that I read about somewhere
[15:38] <ogra_> rtg, dpkg-deb -x /part/to.snap
[15:38] <ogra_> that will unpack it
[15:38] <sergiusens> rtg, -c should work to just list
[15:38] <ogra_> or that :P
[15:39] <rtg> alrighty, looks like my snap has stuff in it. would y'all care to clone git://kernel.ubuntu.com/rtg/kernel-snap.git and tell me if I'm on crack ?
[15:41] <ogra_> rtg, you definitely want the snappy-image ppa in your chroot ...
[15:41] <ogra_> that often contains a newer initramfs-tools-ubuntu-core
[15:42] <ogra_> beyond that the rootstock bit looks good
[15:42] <ogra_> err
[15:42] <rtg> ogra_, do you intend to use the PPA for production as well ?
[15:42] <ogra_> rtg, why $BOOTLOADER ?
[15:42] <ogra_> the bootloader has to go into the oem (or in the future "gadget") snap
[15:43] <ogra_> rtg, yes
[15:43] <rtg> ograthe bootloader only has an impact when installing the kernel in the chroot. it is otherwise unsued
[15:43] <ogra_> the PPA is used during distro freezes etc
[15:43] <ogra_> rtg, we dont use any of the distro setup for bootloaders anyway
[15:43] <rtg> ogra_, ok, I'll get that PPA logic added.
[15:44] <ogra_> (no update-grub in grub setups, no flash-kernel for uboot)
[15:44] <ogra_> in fact you would break stuff using them
[15:45] <ogra_> the rootfs should have all you need bootloader wise (binaries) ... the oem/gadget snap should have all confguration for bootloader setups
[15:45] <rtg> ogra_, but there is no grub logic in the kernel snap, right ?
[15:46] <ogra_> right
[15:46] <ogra_> neither grub binaries nor config
[15:47] <rtg> ogra_, so run snapcraft on this project and inspect the snap. I think it is right
[15:47] <rtg> aside from needing the PPA
[15:48] <ogra_> rtg, oh, and you want linux-image-signed on all amd64 installs
[15:48] <rtg> ogra_, easy enough
[15:48] <ogra_> and preferably even a higher meta
[15:48] <ogra_> like linux-signed
[15:49] <rtg> what do you need the headers for in the chroot ?
[15:49] <ogra_> so you get linux-firmware ... and where wanted linux-image-extra installed
[15:49] <ogra_> you dont need the headers ... but then you simply dont copy them before the squashing
[15:49] <rtg> ogra_, I'll check, but I think those meta package pull in the right bits
[15:49] <ogra_> but you need firmware
[15:50] <rtg> ogra_, I think the kernel depends on linux-firmware
[15:50] <ogra_> ok
[15:50] <ogra_> on -extra too ?
[15:51] <rtg> ogra_, yup
[15:52] <rtg> ogra_, I think what we want installed is linux-signed-image-generic.
[15:52] <ogra_> then it should indeed be fine
[15:52] <ogra_> yeah
[15:57] <rtg> ogra_, this PPA ? ppa:snappy-dev/image
[15:57] <ogra_> rtg, yeah
[18:08] <rtg> sergiusens, ogra_: I've got a kernel snap which appears to install OK in a KVM, but I can't figure out where all the /lib or /boot bits have gone, nor does the new kernel get booted. Any thoughts ?
[18:09] <ogra_> rtg, well, it needs to land in /boot/grub/a|b somehow currently ... not sure if it still needs to in the all snaps case
[18:09] <ogra_> mvo_ is your man here
[18:10] <rtg> ogra_, is there a way to specify which a|b ?
[18:10] <ogra_> the one thats not in use usually
[18:11] <rtg> that is what I thought. perhaps I'll dump my troubles on the snappy mailing list
[18:11] <ogra_> but all that stuff has completely changed in all-snaps so i cant tell if it is still the case for such a setup
[18:21] <sergiusens> rtg, the only person who really knows the details here is mvo_
[18:22] <rtg> sergiusens,  any idea how you force an a|b switch ?
[18:23] <sergiusens> rtg, an install should make the switch, it is all managed by grub, so grubenv away (look at grub.cfg for the exact vars) or just edit grub.cfg
[18:26] <rtg> hmm, hacking grubenv was fatal
[18:36] <mkarliner> newbie question. I've made a snap on AMD64 , how do I create a version for  RPi?
[18:51] <tedg> mkarliner: Probably easiest way is to just build it on the RPi itself.
[18:52] <mkarliner> But all the instructions are for using snapcraft
[18:53] <mkarliner> That is, all the 'create a snap' tutorials start with apt-get install etc, etc.
[18:53] <tedg> mkarliner: Yes, you probably want to setup snapcraft in an LXD or Docker container and then run it.
[18:53] <tedg> mkarliner: We do realize this is non-ideal right now, working on better solutions.
[18:54] <mkarliner> I've done that, what I'm trying to understand is how to make the cross platform target, or is there a native way
[18:55] <tedg> No, we don't really have a way to cross-compile
[18:55] <mkarliner> OK, so is there a tutorial on how to create a snap on a RpI?
[18:57] <tedg> There's one in progress, but I don't think it is completed yet.
[18:58] <mkarliner> Can you give me any clues?
[19:08] <dwaite> is it possible to grab (or self-build) a newer release of docker on snappy?
[19:14] <dwaite> unlike apt, it doesn't seem I can just add an external source to get this, and I don't see anything in the tools to enable me to build a framework, just apps
[19:14] <dwaite> is this a limitation of snappy?
[19:23] <tedg> mkarliner: You need to install lxd or docker on your RPi and then you can build with snapcraft. That's the tutorial in a nutshell.
[19:23] <mkarliner> Thanks, I'll give it a go
[19:23] <tedg> dwaite: I think they're all built by hand right now. Generally, most things don't need to be frameworks though.
[19:35] <serg_> Hi
[19:36] <serg_> how can i try my snappy app before deploying into ubuntu store?
[19:38] <kyrofa> serg_, you've created the .snap?
[19:38] <serg_> yes
[19:38] <kyrofa> serg_, do you actually have Ubuntu Core installed anywhere? On a device or a VM?
[19:39] <serg_> virtualbox
[19:40] <kyrofa> serg_, just sideload it there
[19:40] <serg_> sorry, can you explain it step-by-step?
[19:41] <kyrofa> serg_, sure! First, get your .snap into the VM
[19:41] <kyrofa> serg_, then you can install it with `snappy install <my_snap>.snap`
[19:41] <dwaite> Snappy looks interesting, but limiting the infrastructure I can actually use to older "supported" versions just won't work for my environment. I need the new networking features in recent docker releases.
[19:42] <kyrofa> serg_, assuming you have SSH access to the VM, just use scp to get the .snap on there
[19:43] <dwaite> the autopilot updates are really nice, but not if it limits what I can actually run
[19:45] <serg_> thank you, but now i have other problem
[19:45] <serg_> No signature, or no origin signature
[19:45] <serg_> which is this?
[19:47] <serg_> how can i bypass this verification?
[19:48] <rtg> serg_, sudo snappy install --allow-unauthenticated
[19:48] <serg_> too much thanks
[21:06] <rtg> sergiusens, so where do I find a 16.04 KVM image ?
[21:06] <sergiusens> rtg, mvo has one in his people.c.c, let me see.
[21:06] <sergiusens> rtg, http://people.canonical.com/~mvo/all-snaps/
[21:06] <sergiusens> rtg, there's a u-d-f there that should work too
[21:11] <rtg> sergiusens, hmm, that image isn't exactly network capable AFAICT
[21:20] <sergiusens> rtg, I am not sure, haven't tested it
[21:21] <sergiusens> rtg, you can try and u-d-f with what is there and using your snap
[21:21] <rtg> sergiusens, well, I'll have to get back to it tomorrow. I'm EOD