| === balloons is now known as Guest45465 | ||
| === Guest45465 is now known as balloons_ | ||
| === asac` is now known as asac | ||
| fgimenez | good morning | 08:07 |
|---|---|---|
| mvo | hey fgimenez, good morning | 08:08 |
| fgimenez | hi mvo :) | 08:08 |
| dholbach | good morning | 08:09 |
| mvo | hey dholbach, good morning | 08:16 |
| dholbach | hey mvo | 08:21 |
| davidcalle | Good morning | 09:04 |
| JamesTait | Good morning all; happy Monday, and happy Button Day! 😃 | 10:03 |
| dholbach | mvo, from which ppa would I get the most up-to-date ubuntu-snappy-cli for devel and 15.04 respectively? | 11:23 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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 | 11:43 | |
| ogra_ | hmpf | 13:35 |
| 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:36 |
| 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:37 |
| Chipaca | ogra_: file a bug, see how many people me-too it? | 13:38 |
| ogra_ | yeah, will do | 13:38 |
| 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:39 |
| 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:40 |
| sergiusens | ogra_, build it from source! | 13:44 |
| ogra_ | heh | 13:45 |
| ogra_ | crazy talk ! | 13:45 |
| Chipaca | ogra_: https://gist.github.com/chipaca/58552b58a1a75cd1607b | 13:54 |
| * Chipaca hugs rsalveti | 13:55 | |
| ogra_ | Chipaca, dude ! why is that not snapped ! | 13:56 |
| 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 | 13:57 |
| * rsalveti hugs Chipaca | 14:03 | |
| === lool- is now known as lool | ||
| 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:27 |
| 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:28 |
| ogra_ | you should really take the livecd-rootfs snippet for that :) | 14:29 |
| ogra_ | rootstock adds a massive overhead | 14:29 |
| 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:30 |
| ogra_ | well, you need the nested qemu chroot if you are actually buildin for another arch | 14:31 |
| ogra_ | but only then | 14:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| === tyhicks` is now known as tyhicks | ||
| sergiusens | rtg, how about building the kernel instead of using the deb? | 14:35 |
| sergiusens | for people building alternate trees | 14:35 |
| 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:36 |
| lool | rtg: you need to make install to DESTDIR | 14:41 |
| 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:42 |
| 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:49 |
| elopio_ | fgimenez: yes. | 14:50 |
| === elopio_ is now known as elopio | ||
| 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:50 |
| 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:51 |
| fgimenez | elopio, in that case -src native-security-policygen-regen -repo https://github.com/mvo5/snappy | 14:52 |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:57 |
| fgimenez | mvo, it is in the "Settings -> Webhooks & services" section of the repo | 14:58 |
| mvo | fgimenez: aha, nice. let me try that | 14:58 |
| fgimenez | mvo, the jenkins instance is at http://162.213.34.171:8080, only accessible from the vpn | 14:59 |
| 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:01 |
| fgimenez | elopio, :) iirc i've seen it not being changed, anyway now the code is a lot cleaner | 15: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 overhead | 15:03 |
| ogra_ | (there are some live-build specifics in there you need to replace but thats minor) | 15:04 |
| rtg | ogra_, I thought the goal was to build a snap, not a device tarball | 15:05 |
| 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:06 |
| rtg | ogra_, 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 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:08 |
| === balloons_ is now known as balloons | ||
| === JanC_ is now known as JanC | ||
| asac | would personally be awesome if we could make the kernel plugin capable of cross compiling | 15:21 |
| 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:22 |
| ogra_ | asac, trivial ... | 15:23 |
| ogra_ | (but needs qemu-user-static for the initrd chroot ... that will limit us) | 15:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| rtg | sergiusens, how do you inspect a snap ? seems like there was a dpkg option that I read about somewhere | 15:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| ogra_ | (no update-grub in grub setups, no flash-kernel for uboot) | 15:44 |
| ogra_ | in fact you would break stuff using them | 15:44 |
| 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:45 |
| ogra_ | right | 15:46 |
| ogra_ | neither grub binaries nor config | 15:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| rtg | ogra_, I think the kernel depends on linux-firmware | 15:50 |
| ogra_ | ok | 15:50 |
| ogra_ | on -extra too ? | 15:50 |
| rtg | ogra_, yup | 15:51 |
| 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:52 |
| rtg | ogra_, this PPA ? ppa:snappy-dev/image | 15:57 |
| ogra_ | rtg, yeah | 15:57 |
| === chiluk_ is now known as chiluk | ||
| === j12t_ is now known as j12t | ||
| 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: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 case | 18:09 |
| ogra_ | mvo_ is your man here | 18:09 |
| rtg | ogra_, is there a way to specify which a|b ? | 18:10 |
| ogra_ | the one thats not in use usually | 18:10 |
| 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:11 |
| sergiusens | rtg, the only person who really knows the details here is mvo_ | 18:21 |
| rtg | sergiusens, any idea how you force an a|b switch ? | 18:22 |
| 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:23 |
| rtg | hmm, hacking grubenv was fatal | 18:26 |
| mkarliner | newbie question. I've made a snap on AMD64 , how do I create a version for RPi? | 18:36 |
| tedg | mkarliner: Probably easiest way is to just build it on the RPi itself. | 18:51 |
| mkarliner | But all the instructions are for using snapcraft | 18:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| tedg | There's one in progress, but I don't think it is completed yet. | 18:57 |
| mkarliner | Can you give me any clues? | 18:58 |
| dwaite | is it possible to grab (or self-build) a newer release of docker on snappy? | 19:08 |
| 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:14 |
| 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:23 |
| serg_ | Hi | 19:35 |
| serg_ | how can i try my snappy app before deploying into ubuntu store? | 19:36 |
| 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:38 |
| serg_ | virtualbox | 19:39 |
| kyrofa | serg_, just sideload it there | 19:40 |
| serg_ | sorry, can you explain it step-by-step? | 19:40 |
| 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:41 |
| kyrofa | serg_, assuming you have SSH access to the VM, just use scp to get the .snap on there | 19:42 |
| dwaite | the autopilot updates are really nice, but not if it limits what I can actually run | 19:43 |
| 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:45 |
| serg_ | how can i bypass this verification? | 19:47 |
| rtg | serg_, sudo snappy install --allow-unauthenticated | 19:48 |
| serg_ | too much thanks | 19:48 |
| === dpm is now known as dpm-afk | ||
| 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:06 |
| rtg | sergiusens, hmm, that image isn't exactly network capable AFAICT | 21:11 |
| sergiusens | rtg, I am not sure, haven't tested it | 21:20 |
| 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 | 21:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!