=== balloons is now known as Guest45465
=== Guest45465 is now known as balloons_
=== asac` is now known as asac
fgimenezgood morning08:07
mvohey fgimenez, good morning08:08
fgimenezhi mvo :)08:08
dholbachgood morning08:09
mvohey dholbach, good morning08:16
dholbachhey mvo08:21
davidcalleGood morning09:04
JamesTaitGood morning all; happy Monday, and happy Button Day! 😃10:03
dholbachmvo, from which ppa would I get the most up-to-date ubuntu-snappy-cli for devel and 15.04 respectively?11:23
mvodholbach: generally ppa:snappy-dev/tools is a good one, what do you need it for? we also have daily build ppas11:32
sergiusensogra_, 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
davidcallesergiusens, login with http://developer.ubuntu.com/openid/login11:32
sergiusensogra_, yes, but not sure if there is a markdown source synced from it11:33
davidcallesergiusens, ah, no md source11:33
sergiusensdavidcalle, grat, I'll take the bullet tonight, wasn't easy to edit from the web for me :-P11:33
dholbachmvo, the question came up if we could automatically import a snappy manpage (I found out that 'snappy man' creates one)11:34
davidcallesergiusens, if you struggle with the editor, ping me or dholbach anytime :)11:34
sergiusensI'll ping mhall as you guys might be sleeping when I decide to edit this ;-)11:34
dholbachmvo, maybe during the build one could be generated? :)11:35
sergiusensdholbach, if you can, Chipaca and myself failed to hook it up correclty in debian/rules11:35
dholbachsergiusens, ok, I'll take a look11:36
davidcallesergiusens, naah, I'll just give you dholbach phone number, he is awake all night! :p11:36
Chipacasergiusens: I have "man snappy"11:36
Chipacasergiusens: from debian/rules11:36
sergiusensdavidcalle, oh, I have him on telegram, I can wake him up :-P11:36
sergiusensChipaca, oh, then it was already done and I forgot11:36
Chipacasergiusens: don't you?11:36
Chipaca$ dpkg -S snappy.111:37
Chipacaubuntu-snappy-cli: /usr/share/man/man1/snappy.1.gz11:37
sergiusensChipaca, yes11:37
dholbachChipaca, you're right, thanks O:-)11:37
Chipacasergiusens: i did this when i added 'snappy man' :)11:38
sergiusenslet me rephrase, **I had a hard time** and then you created a working branch ;-)11:38
sergiusensdholbach, there is no man in ubuntu core though11:39
dholbachsergiusens, no worries - this would be for importing into the dev site11:39
Chipacadholbach: note the manpage also lists internal commands, as it's a zero-effort automatic thing generated from the thing that does commandline parsing11:39
dholbachChipaca, that's good to know11:40
Chipacadholbach: ideally those internal ones would be pruned (but upstream isn't amenable to patches)11:40
dholbachmvo, the last ubuntu-snappy-cli uploads to that ppa are from july11:41
mvoChipaca: 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 vanish11:41
Chipacamvo: seriously? woo! we should merge that in11:41
mvodholbach: hm, then you will need the daily one from ppa:snappy-dev/image11:41
mvoChipaca: yeah, no explanation just the github message "merged #XY"11:42
dholbachmvo, great - thanks11:42
Chipacamvo: there's 5 internal commands, not just drop-priv. And some more that could probably do with being reclassified as internal.11:42
Chipacamvo: e.g. booted is internal, but firstboot isn't?11:43
Chipacaah, wait, first_boot is11:43
* Chipaca learns to read11:43
ogra_sergiusens, Chipaca, do we have some kind of "inetd plugin"  in snapcraft ? i wonder how to snap up a service that relies on it13:36
Chipacaogra_: we do not13:36
ogra_ah sad13:36
Chipacaogra_: we'd have to expose one more service flag for that13:36
Chipacawhich is totally doable, but needs doing :-)13:36
ogra_well, not sure if thats very common13:36
ogra_(people packaging inetd depending services)13:37
Chipacaogra_: OTOH, all you need to turn an inetd plugin into a regular service is netcat13:37
ogra_thats my fallback idea13:37
* Chipaca oversimplifying complex engineering problems since 197613:37
ogra_i'm just wondering if it is a common task ... in which case a snapcraft option would make sense13:37
Chipacaogra_: file a bug, see how many people me-too it?13:38
ogra_yeah, will do13:38
Chipacaogra_: don't forget to say «don't comment with “me too”», so people comment with “me too”13:39
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:40
sergiusensogra_, build it from source!13:44
ogra_crazy talk !13:45
Chipacaogra_: https://gist.github.com/chipaca/58552b58a1a75cd1607b13:54
* Chipaca hugs rsalveti 13:55
ogra_Chipaca, dude ! why is that not snapped !13:56
Chipacaogra_: because i'd need to change it for small memory systems13:57
Chipacaogra_: or clean it up13:57
Chipacaogra_: maybe even merge in whatever's gone on with TinyHTTPProxy in the 3+ years since I did this to it13:57
* rsalveti hugs Chipaca14:03
=== lool- is now known as lool
rtglool, 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:27
ogra_rtg, did you find a way to generate the initrd yet ?14:28
rtgogra: I ruthlessly butchered rootstock to do so14:28
ogra_you should really take the livecd-rootfs snippet for that :)14:29
ogra_rootstock adds a massive overhead14:29
rtgogra_, 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:30
ogra_well, you need the nested qemu chroot if you are actually buildin for another arch14:31
ogra_but only then14:31
ogra_beyond that a simple "debootstrap --variant=minbase" should be fine14:32
rtgfor now I'm just trying to get amd64 working14:32
ogra_debootstrap --variant=minbase + PPA setups for the different special kernels + the snappy specific packages needed in the initrd14:33
ogra_that should be all you need14:33
ogra_then just install your meta and pull out the files from the tree you need14:33
rtgogra_, what snappy specific packages do I need in the initrd ?14:33
ogra_initramfs-tools-ubuntu-core at least ... i have to chekc livecd-rootfs14:34
rtgogra_, that sounds familiar14:34
ogra_(there are a few more)14:34
=== tyhicks` is now known as tyhicks
sergiusensrtg, how about building the kernel instead of using the deb?14:35
sergiusensfor people building alternate trees14:35
rtgsergiusens, that is the next example I'm gonna work on14:36
sergiusensrtg, after we have this I guess I'll start using your stuff to create a proper plugin that wraps all this in14:36
rtgsergiusens, I thought I'd do a snap for each reference kernel, plus one as an example for building from source14:36
loolrtg: you need to make install to DESTDIR14:41
rtglool, in the Makefile plugin ?14:42
loolrtg: in the Makefile itself, yup14:42
loolrtg: snapcraft sets DESTDIR to the right di14:42
rtglool, cool, now I see that in the examoples14:42
fgimenezelopio_, the jenkins instance is ready to go, you have access to the canonistack dashboard as the ues-snappy-integration-tests user, right?14:49
elopio_fgimenez: yes.14:50
=== elopio_ is now known as elopio
mvofgimenez: 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:50
fgimenezelopio, ok, it's created for that user, there's also a floating ip assigned to it, the webhook should point to it14:51
fgimenezelopio, sure, the -src flag is the branch and the new repo flag the repo location, like https://github.com/user/snappy14:51
fgimenezelopio, in that case -src native-security-policygen-regen -repo https://github.com/mvo5/snappy14:52
fgimenezmvo, ^ :)14:53
elopiomvo: ^14:53
elopiomvo, 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:53
fgimenezelopio, yes, snappy and snapd binaries14:54
mvoelopio: 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
fgimenezmvo, whenever you make a PR or add commits to an existing one the job is triggered anyway, once the webhook is in place14:54
mvofgimenez: 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 currently14:56
fgimenezmvo you can set it up right now :) this is the url, the events ticked should be "Pull request" and "Issue comment"14:57
fgimenezmvo, it is in the "Settings -> Webhooks & services" section of the repo14:58
mvofgimenez: aha, nice. let me try that14:58
fgimenezmvo, the jenkins instance is at, only accessible from the vpn14:59
elopiofgimenez: 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:01
fgimenezelopio, :) iirc i've seen it not being changed, anyway now the code is a lot cleaner15:02
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 overhead15:03
ogra_(there are some live-build specifics in there you need to replace but thats minor)15:04
rtgogra_, I thought the goal was to build a snap, not a device tarball15:05
ogra_rtg, you want the same contents in both15:06
ogra_they should be absolutely identical except that one is a squashfs img and the other is a tarball15:06
rtgogra_, even the YAML file ?15:07
ogra_thats something mvo needs to answer ... :)15:07
ogra_you definitely want the same initrd and you want the right PPA used for the right suabarch15:08
ogra_and afaik mvo used the existing device tarballs during the all snaps development as input15:08
rtgok. I am close to being able to build the snap. I have some permissions issues. then I'll look at this.15:08
=== balloons_ is now known as balloons
=== JanC_ is now known as JanC
asacwould personally be awesome if we could make the kernel plugin capable of cross compiling15:21
asacrtg: ogra_ sergiusens: ^15:22
asacjust as input15:22
rtgasac, when built from source it certainly will be.15:22
sergiusensasac, I'm fine with per plugin x-compile15:22
ogra_asac, trivial ...15:23
ogra_(but needs qemu-user-static for the initrd chroot ... that will limit us)15:23
asacrtg: are we doing the "built from debs in archive" variant first?15:24
asacguess yeah, then its later15:24
rtgasac, yup, that is what I'm working on15:24
asacsergiusens: isnt x- something we used for something else?15:24
ogra_asac, rtg, the initrd generation will always have to be deb based FWIW15:24
ogra_we dont have a way to "just generate" one without that15:25
rtgogra_, fortunately the kernel makefile has a deb target15:25
asaci thoguht we do generic initrd that is in the OS15:25
asacso we dont need that in kernel15: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 booting15:26
asacmvo: ?15:26
sergiusensasac, x as in cross15:26
sergiusensnot sure what else you speak of ;-)15:26
mvoasac: sorry in a meeting15:26
asacsergiusens: yeah, thought we used x- for another implicit meaning... like local plugins, but think we moved away from that15:26
asacall fine15:26
ogra_asac, we cant ... specifically with the new requirement for squashfs15:26
ogra_you need the modules15:26
asacogra_: i think its the spec to have initd in OS snap15:26
sergiusensasac, we have that still (x for extension)15:26
asacand just say kernel folks have to built in what they need15:26
ogra_thats not possible15:26
ogra_you need to find the rootfs from the initrd15:26
asacwell, it technically would get copied15:27
ogra_which means you need to support the disk type, controller, filesystem15:27
asacto the boot paertition from the OS15:27
asacbut the one and only initrd is in the OS snap ... so we dont need to build it turning kernel buil;d15:27
ogra_asac, that still wont have the right contents15:27
asacthats how i understand at least one of the proopsals15:27
ogra_you need the kernel modules inside the initrd15:27
asacogra_: we can say you cant put them there\15:27
asaclike what you suggested for long time :)15:27
ogra_then you cant boot15:27
mvoasac: 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 iniitrd15:27
sergiusensogra_, 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 touch15:28
ogra_sergiusens, you still need to find them15:28
asacso you need modules only in the initd if you need them to mount the rootfs afaik15:28
asacso thats disk drivers, filesystem types etc.15:28
ogra_sergiusens, so all needed modules for that need to be there15:28
ogra_asac, right15:28
rtgsergiusens, yeah, what ogra_ said15:28
asaconce you have rootfs (or a partition that hosts the modules) you can go and load modules15:29
sergiusensogra_, then it is a no brainer to just include it in the kernel15:29
ogra_asac, network cards for things like remote keys for encrypted rootfs15:29
sergiusensit is not really a generic kernel, is it?15:29
asacwell, 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 -generic15:29
ogra_thats the prob :)15:29
asacdont think the factory keys would go into the initrd ... at least i never anticipated that15:29
sergiusensogra_, it always going to be loaded for core15:29
ogra_asac, no, the keys live on a remote server15:29
ogra_asac, but you need to obtain them via network15:30
ogra_at least in one specific arch we support today15:30
ogra_sergiusens, from where ?15:30
sergiusensogra_, from the kernel itself15:31
ogra_note that i would love nothing more than to use the same setup we have for the touch initrd in core15:31
ogra_but as long as we hard depend on modules we cant15:31
rtgsergiusens, how do you inspect a snap ? seems like there was a dpkg option that I read about somewhere15:37
ogra_rtg, dpkg-deb -x /part/to.snap15:38
ogra_that will unpack it15:38
sergiusensrtg, -c should work to just list15:38
ogra_or that :P15:38
rtgalrighty, 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:39
ogra_rtg, you definitely want the snappy-image ppa in your chroot ...15:41
ogra_that often contains a newer initramfs-tools-ubuntu-core15:41
ogra_beyond that the rootstock bit looks good15:42
rtgogra_, 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") snap15:42
ogra_rtg, yes15:43
rtgograthe bootloader only has an impact when installing the kernel in the chroot. it is otherwise unsued15:43
ogra_the PPA is used during distro freezes etc15:43
ogra_rtg, we dont use any of the distro setup for bootloaders anyway15:43
rtgogra_, ok, I'll get that PPA logic added.15:43
ogra_(no update-grub in grub setups, no flash-kernel for uboot)15:44
ogra_in fact you would break stuff using them15:44
ogra_the rootfs should have all you need bootloader wise (binaries) ... the oem/gadget snap should have all confguration for bootloader setups15:45
rtgogra_, but there is no grub logic in the kernel snap, right ?15:45
ogra_neither grub binaries nor config15:46
rtgogra_, so run snapcraft on this project and inspect the snap. I think it is right15:47
rtgaside from needing the PPA15:47
ogra_rtg, oh, and you want linux-image-signed on all amd64 installs15:48
rtgogra_, easy enough15:48
ogra_and preferably even a higher meta15:48
ogra_like linux-signed15:48
rtgwhat do you need the headers for in the chroot ?15:49
ogra_so you get linux-firmware ... and where wanted linux-image-extra installed15:49
ogra_you dont need the headers ... but then you simply dont copy them before the squashing15:49
rtgogra_, I'll check, but I think those meta package pull in the right bits15:49
ogra_but you need firmware15:49
rtgogra_, I think the kernel depends on linux-firmware15:50
ogra_on -extra too ?15:50
rtgogra_, yup15:51
rtgogra_, I think what we want installed is linux-signed-image-generic.15:52
ogra_then it should indeed be fine15:52
rtgogra_, this PPA ? ppa:snappy-dev/image15:57
ogra_rtg, yeah15:57
=== chiluk_ is now known as chiluk
=== j12t_ is now known as j12t
rtgsergiusens, 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:08
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 case18:09
ogra_mvo_ is your man here18:09
rtgogra_, is there a way to specify which a|b ?18:10
ogra_the one thats not in use usually18:10
rtgthat is what I thought. perhaps I'll dump my troubles on the snappy mailing list18: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 setup18:11
sergiusensrtg, the only person who really knows the details here is mvo_18:21
rtgsergiusens,  any idea how you force an a|b switch ?18:22
sergiusensrtg, 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.cfg18:23
rtghmm, hacking grubenv was fatal18:26
mkarlinernewbie question. I've made a snap on AMD64 , how do I create a version for  RPi?18:36
tedgmkarliner: Probably easiest way is to just build it on the RPi itself.18:51
mkarlinerBut all the instructions are for using snapcraft18:52
mkarlinerThat is, all the 'create a snap' tutorials start with apt-get install etc, etc.18:53
tedgmkarliner: Yes, you probably want to setup snapcraft in an LXD or Docker container and then run it.18:53
tedgmkarliner: We do realize this is non-ideal right now, working on better solutions.18:53
mkarlinerI've done that, what I'm trying to understand is how to make the cross platform target, or is there a native way18:54
tedgNo, we don't really have a way to cross-compile18:55
mkarlinerOK, so is there a tutorial on how to create a snap on a RpI?18:55
tedgThere's one in progress, but I don't think it is completed yet.18:57
mkarlinerCan you give me any clues?18:58
dwaiteis it possible to grab (or self-build) a newer release of docker on snappy?19:08
dwaiteunlike 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 apps19:14
dwaiteis this a limitation of snappy?19:14
tedgmkarliner: 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
mkarlinerThanks, I'll give it a go19:23
tedgdwaite: I think they're all built by hand right now. Generally, most things don't need to be frameworks though.19:23
serg_how can i try my snappy app before deploying into ubuntu store?19:36
kyrofaserg_, you've created the .snap?19:38
kyrofaserg_, do you actually have Ubuntu Core installed anywhere? On a device or a VM?19:38
kyrofaserg_, just sideload it there19:40
serg_sorry, can you explain it step-by-step?19:40
kyrofaserg_, sure! First, get your .snap into the VM19:41
kyrofaserg_, then you can install it with `snappy install <my_snap>.snap`19:41
dwaiteSnappy 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:41
kyrofaserg_, assuming you have SSH access to the VM, just use scp to get the .snap on there19:42
dwaitethe autopilot updates are really nice, but not if it limits what I can actually run19:43
serg_thank you, but now i have other problem19:45
serg_No signature, or no origin signature19:45
serg_which is this?19:45
serg_how can i bypass this verification?19:47
rtgserg_, sudo snappy install --allow-unauthenticated19:48
serg_too much thanks19:48
=== dpm is now known as dpm-afk
rtgsergiusens, so where do I find a 16.04 KVM image ?21:06
sergiusensrtg, mvo has one in his people.c.c, let me see.21:06
sergiusensrtg, http://people.canonical.com/~mvo/all-snaps/21:06
sergiusensrtg, there's a u-d-f there that should work too21:06
rtgsergiusens, hmm, that image isn't exactly network capable AFAICT21:11
sergiusensrtg, I am not sure, haven't tested it21:20
sergiusensrtg, you can try and u-d-f with what is there and using your snap21:21
rtgsergiusens, well, I'll have to get back to it tomorrow. I'm EOD21:21

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!