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