[01:39] <dyfi> Hello; is there anybody here who is familiar with loading a Snappy image on to the Beaglebone Black?
[06:19] <aatchison> Hey guys. Energies severely depleted over here. I just had a crazy idea. Tensor flow on snappy?
[06:20] <aatchison> Also, random question. Does Snappy deploy well with JuJu?
[07:51] <dholbach> good morning
[08:42] <ysionneau> morning
[08:43] <zyga> good morning
[08:57] <noizer> good morning
[08:58] <zyga> hey ysionneau, noizer :)
[08:58] <zyga> have you read about the skills rename?
[08:59] <ysionneau> skills rename ?
[08:59] <noizer> no
[08:59] <noizer> was it send in the mailing?
[09:00] <zyga> https://lists.ubuntu.com/archives/snappy-devel/2016-February/001501.html
[09:00] <zyga> yep
[09:00] <zyga> it's just a new name, nothing has changed
[09:00] <ysionneau> ah yes I had this email
[09:04] <ysionneau> zyga: would you know what is supposed to be the init= cmdline for the rpi2 snappy 16.04 ?
[09:04] <ysionneau> (image generated with your tool)
[09:05] <ysionneau> ah found it, it's in snappy-system.txt
[09:08] <zyga> ysionneau: no but I guess you just found out :)
[09:09] <ysionneau> yep!
[09:09] <ysionneau> I'm trying to boot your rpi2 image using qemu
[09:09] <ysionneau> so far I'm KO
[09:10] <ysionneau> it boots the kernel, initrd "works", and then "No init found. Try passing init= bootarg."
[09:10] <ysionneau> (I do pass the init=)
[09:10] <zyga> ysionneau: I don't think qemu will boot it
[09:10] <zyga> ysionneau: initrd is the OS snap btw
[09:11] <noizer> zyga are the interface then for sharing libs
[09:11] <noizer> ?
[09:11] <zyga> noizer: nope
[09:11] <noizer> ok
[09:11]  * zyga needs to update https://wiki.ubuntu.com/SnappyHackerUsefulLinkCollection
[09:12] <zyga> help wanted ^^
[09:29] <noizer> zyga is snappy an 64bit system?
[09:29] <zyga> noizer: snappy works on 32 and 64 bit systems
[09:29] <zyga> noizer: we have official images for x86, amd64, arm v7 hard float and aarch64 (or arm64)
[09:30] <noizer> do you have images for soft float?
[09:33] <noizer> the image on the rpi is that an 64 bit systme?
[09:33] <noizer> zyga
[09:33] <zyga> noizer: raspberry pi 2 is 32 bit, hard float
[09:33] <noizer> zyga ok thx
[09:33] <zyga> noizer: we don't support ARMv6 (soft float)
[09:34] <noizer> zyga ok
[09:43] <ysionneau> zyga: I was able to boot the rpi2  15.04 image on qemu
[09:43] <ysionneau> but not as a rpi2 board but as a generic arm64 board with my own arm64 kernel
[09:43] <ysionneau> but except the kernel+modules it was the vanilla 15.04 rpi2 image running in my qemu
[09:43] <ysionneau> that's where I do all my tests so far
[09:43] <ysionneau> I'm trying to replicate this setup with your 16.04 image
[09:53] <ysionneau> it seems that the initramfs does not mount the squashfs (the snaps) since the systemd init is not found...
[09:54] <ysionneau> oh, seems I need to put snappy_os= and snappy_kernel= on the cmdline
[09:54] <zyga> ysionneau: I'd suggest, if you want to continue down this path, is to build a new kernel snap
[09:54] <zyga> ysionneau: that's specifically intended to work with qemu
[09:54] <zyga> ysionneau: you can reuse the os snap as-is
[09:54] <zyga> ysionneau: you can fine-tune the kernel snap
[09:54] <zyga> ysionneau: and you will absolutely need a gadget snap that's not pi2
[09:55] <zyga> ysionneau: I think that would be a fanstastic thing to have
[09:55] <zyga> ysionneau: just one question, why aarch64 kerenl rather than armhf?
[09:55] <ysionneau> 10:54 < zyga> ysionneau: I'd suggest, if you want to continue down this path, is to build a new kernel snap < yes I have my own arm64 kernel (which worked fine with 15.04)
[09:56] <ysionneau> not sure if I need a snap since there is no bootloader involved, qemu boots the kernel directly as I pass it to -kernel cmdline arg
[09:56] <ysionneau> (a snap for the kernel I mean)
[09:56] <zyga> ysionneau: 10:43 < ysionneau> but not as a rpi2 board but as a generic arm64 board with my own arm64 kernel
[09:56] <zyga> ysionneau: you used a different kernel
[09:56] <zyga> ysionneau: you really need a different kernel snap
[09:57] <ysionneau> allright, maybe I should start by asking: what's a kernel snap?
[09:57] <zyga> ysionneau: a snap that has the kenrel, modules and bootloader
[09:57] <zyga> ysionneau: that snappy mounts from the bootloader
[09:57] <ysionneau> here I don't use any bootloader
[09:57] <zyga> ysionneau: and loads the kernel from the mounted snap
[09:57] <ysionneau> since I boot the kernel directly from qemu
[09:57] <zyga> ysionneau: right but that will break varius snappy interaction
[09:57] <zyga> ysionneau: it'd better to boot a disk image
[09:57] <zyga> ysionneau: with a bootloader
[09:58] <zyga> ysionneau: it's extra work but what you did won't survive a snappy update and reboot
[09:58] <ysionneau> not sure if I can boot a disk image with no -kernel
[09:58] <zyga> ysionneau: depending on what you want, it may not be good or it may be exactly what you need
[09:58] <zyga> ysionneau: no, but you can boot a whole disk image
[09:58] <zyga> ysionneau: er. sorry, yes you can
[09:58] <ysionneau> but yes I agree that booting directly on a kernel will break some snappy stuff
[09:58] <ysionneau> like the system updates and such
[09:58] <zyga> ysionneau: I've done things like that in linaro a while ago
[09:59] <zyga> ysionneau: emulating various beagle board-like hardware
[09:59] <zyga> ysionneau: though I don't know how much work that would be today
[10:00] <ysionneau> for now I only need a qemu environment with basic snappy fonctionality, not 100%, to do some tests of .snap packaging of apps
[10:00] <ysionneau> to package a service, an app etc
[10:00] <ysionneau> and to test my ability to generate cross-compiled apps correctly
[10:00] <zyga> ysionneau: I see, good luck
[10:02] <ysionneau> thanks :)
[10:02] <ysionneau> 10:55 < zyga> ysionneau: just one question, why aarch64 kerenl rather than armhf? < when I'm done playing with qemu, I will prototype on a real board, which is a Tegra X1 board
[10:07] <zyga> ysionneau: I see, cool
[10:07] <zyga> ysionneau: did you use aarch userspace?
[10:07] <zyga> ubuntu-core (os snap) has an aarch64 build as well
[10:08] <ysionneau> for user space on my last prototype (15.04 :p) I used the rpi2 image (armhf)
[10:08] <ysionneau> ok, I have the 16.04 user space booting :)
[10:09] <ysionneau> bottom line is I had to add this to kernel cmdline : snappy_os=ubuntu-core.canonical_16.04.0-10.armhf.snap snappy_kernel=canonical-pi2-linux.canonical_4.3.0-1006-3.snap
[10:11] <ysionneau> ok I'm logged in
[10:11] <zyga> woot, great
[10:11] <ysionneau> now let's try with an arm64 kernel and a qemu-aarch64
[10:12] <zyga> maybe just aarch64 with the same bits as before
[10:12] <zyga> then with different kerenl
[10:12] <zyga> kernel*
[10:13] <ysionneau> not sure I understand ?
[10:14] <zyga> ysionneau: try 64 bit qemu
[10:14] <zyga> ysionneau: with the same set of blobs
[10:14] <zyga> ysionneau: so same old kernel and everything else
[10:14] <zyga> ysionneau: (just suggesting to switch one thing at a time)
[10:16] <ysionneau> yes that's what I'll do
[10:16] <ysionneau> just switch the kernel and qemu and keep all the remaining
[10:16] <ysionneau> that should work
[10:20] <ysionneau> right, I need to reconstruct the kernel snap squashfs to include the arm64 modules
[10:20] <ysionneau> jeez
[11:04] <ysionneau> zyga: ok it boots with arm64 kernel (I had to add the squashfs support in the kernel :p)
[11:04] <ysionneau> I also have network o/
[11:04] <ysionneau> *afk eating*
[11:06] <zyga> ysionneau: \o/
[11:06] <zyga> ysionneau: great
[11:46] <uralbash> Hello all
[11:47] <uralbash> Explain to me please, I want to create a kiosk on ubuntu + mir + qt4 app. Is this ok? Which version of ubuntu (core, snappy-15.04, ..) to use? Where to get mir server (form source or ppa or snap demo)?
[11:51] <ysionneau> snappy search does not exist any moer ?
[11:51] <ysionneau> anymore*
[11:56] <uralbash> on xenial (from there https://people.canonical.com/~mvo/all-snaps/) "snappy search mir"  command out "Unknown command `search'. Please specify one command of: activate, booted, ..."
[11:58] <ysionneau> same here, snappy search does not seem to exist anymore on 16.04
[11:58] <svij> it's "snappy find" afaik
[11:59] <ysionneau> nop, does not work
[12:04] <uralbash> `find` not work too http://paste.ubuntu.com/15196599/
[12:23] <ysionneau> zyga: so now, I have my 16.04 environment ready, I want to make some 16.04 packages, where can I find the documentation on how to do that?
[12:24] <ysionneau> is it still snapcraft? or snappy build? snap.yaml? syntax?
[12:37] <mvo> uralbash: ysionneau: please try "snap find" (not that the command is "snap" not snappy for this). its a bit confusing, sorry for that. this is transitioning currently ,there will be a new snap command for everything
[12:37] <mvo> but its not fully done so you are in this in-between state, again, this is just for a couple of days until the conversion is fully done
[12:37]  * mvo wonder if we should simply make snappy search an alias until the rest has landed and until the docs are updated
[12:38] <ysionneau> oh ... snappy ... now snap
[12:38] <ysionneau> now I understand why I wanted to stay on 15.04 :'
[12:38] <ysionneau> things are documented, now everything changes
[12:38] <uralbash> it's work :)
[12:38] <uralbash> thanks
[12:38] <ysionneau> works great mvo thanks for the intel :)
[12:40] <svij> ah, so I wasn't completely wrong with "snappy find"
[12:41] <ysionneau> :)
[12:44] <ysionneau> where's the source code of "snap" mvo ?
[12:45] <mvo> ysionneau: https://github.com/ubuntu-core/snappy/tree/master/cmd/snap
[12:45] <ysionneau> thx
[12:45] <ysionneau> ah it's just another frontend
[12:49] <uralbash> `sudo snap add mir.mvp-demo` is an error http://paste.ubuntu.com/15196831/
[12:51] <Guest81475> Hi, I want to try snappy but there is only an img file available. When I rename it into an iso file and burn it, then I can still not obtain a bootable system. I would like to have snappy as easy  as the regular ubuntu release.
[13:02] <ysionneau> uralbash: !<arch> means it's an AR archive
[13:02] <ysionneau> but AFAIK the new snap format is squashfs
[13:02] <ysionneau> so you are trying to install old snaps on a new system
[13:03] <ysionneau> and btw, I have the same issue as you =)
[13:03] <ysionneau> error: nethack-armhf.ogra failed to install: can not open /tmp/nethack-armhf061356496: cannot open snap: unknown header: "!<arch>\ndebian-binar"
[13:05] <uralbash> ysionneau:  Ah, got it, I need to try build it with snapcraft
[13:23] <zyga> ysionneau: hey
[13:23] <zyga> ysionneau: sorry for the lag, busy time :)
[13:23] <zyga> ysionneau: so apart from small syntax changes, it's the same, you can also use snapcraft
[13:23] <zyga> ysionneau: you just have to use a xenial host with snapcraft 2.x series
[13:24] <zyga> ysionneau: the syntax is again, in examples, in snapcraft
[13:24] <zyga> ysionneau: changes are minor, it's just easier to express stuff IMHO
[13:24] <zyga> ysionneau: snapcraft CLI is tweaked too but it's again simple to adapt, snapcraft snap makes a snap and there's --help and all that typical stuff
[13:25] <zyga> ysionneau: you can look at an example snap I'm working on https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml
[13:25] <zyga> ysionneau: give it a try
[13:26] <zyga> ysionneau: at runtime there are now "snap" and "snappy" commands, you want to use the snap one, unless it has missing functionality
[13:26] <zyga> ysionneau: as mvo said, we're transitioning, snap is using our public APIs while snappy had everything linked in
[13:27] <zyga> ysionneau: you really want 16.04
[13:27] <zyga> ysionneau: it's trivial to adapt and things work much better than on 15.04
[13:27] <zyga> Guest81475: hey, give this script a try: https://github.com/zyga/devtools/blob/master/ubuntu-image
[13:28] <zyga> Guest81475: the images are not iso images, they are hard drive images (or SD card images), typically a CD image has different structure
[13:28] <zyga> Guest81475: but they are all bootable
[13:32] <Guest81475> zyga: Thank you for your replies. Do you know why ubuntu does not offer a bootable iso image for snappy ? That is what all people expect and are used to. I am using Windows 10 and have a working Arch linux installation.
[13:33] <Guest81475> I do not like APT but I love the idea of packages as in snappy. AFAIK, MacOS has a similar system.
[13:36] <ysionneau> zyga: ok :)
[13:37] <zyga> Guest81475: http://developer.ubuntu.com/en/snappy/start/
[13:38] <zyga> Guest81475: http://www.ubuntu.com/internet-of-things/developers
[13:38] <zyga> Guest81475: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
[13:38] <ysionneau> zyga: isn't it weird that the snap tool seems to be downloading old snap packages?
[13:38] <zyga> Guest81475: https://developer.ubuntu.com/en/snappy/start/intel-nuc/
[13:38] <zyga> everything is there :)
[13:38] <Guest81475> zyga: ok. Thanks again.
[13:38] <ysionneau> it downloads .snap which are AR (old format) instead of squashfs, and then fails to install them
[13:39] <zyga> ysionneau: it's a one-off issue, when we made the transition the store didn't have enough information to filter this out
[13:39] <zyga> ysionneau: we're well aware of the problem
[13:39] <ysionneau> oh right
[13:39] <zyga> ysionneau: and I suspect there's going to be a fix that mass-removes click-based snaps from the 16.04 distribution channel
[13:39] <ysionneau> because at the beginning of 16.04 it was still using AR files?
[13:39] <zyga> ysionneau: yep
[13:39] <ysionneau> arggg
[13:39] <zyga> ysionneau: tons of moving pieces to make this work on time :)
[13:39] <zyga> ysionneau: you just see it live
[13:40] <ysionneau> the magic of live :)
[13:40] <zyga> the magic of open
[13:45]  * ysionneau generates a new docker image -> xenial
[13:55] <ysionneau> there's no "snappy-tools" package in the PPA for Xenial ?
[13:58] <ysionneau> that's just a meta package ... but that can be handy
[13:59] <beuno> ysionneau, I think it's part of the Xenial archive now instead of the PPA
[14:33] <sergiusens> elopio, joining?
[14:58] <sergiusens> ysionneau, beuno just apt install snapcraft
[14:59] <ysionneau> yep that's what I've done
[15:02] <sergiusens> beuno, are we going to have the store treat each release as different pockets?
[15:03] <beuno> sergiusens, maybe!  what do you mean by that?
[15:04] <sergiusens> beuno, that I can upload one snap for 16.04 and another for 18.04 during the overlapping support period
[15:04] <beuno> sergiusens, yes, it works like that right now
[15:05] <sergiusens> beuno, o really? so no more checkboxes?
[15:05] <sergiusens> or is it checkbox driven per revision?
[15:05] <sergiusens> that explains why I have to check those boxes on every upload
[15:06] <beuno> sergiusens, yeah, it should really be radio buttons at this point
[15:06] <beuno> it is per revision
[15:06] <beuno> so you can upload one for 15.04 and one for 16.04
[15:06] <beuno> and target them differently
[15:06] <beuno> so yes, that's why you pick each time
[15:07] <beuno> we'll get better at that UI
[15:07] <beuno> sergiusens, you even have history in the store now  :)
[15:07] <beuno> we've essentially created 3 dimensions: release, architecture and channel
[15:07] <beuno> you can targe different binaries to each of those
[15:08] <sergiusens> beuno, nice; we should have snapcraft semantics for upload (among others, the 'release' key in the yaml)
[15:08] <beuno> sergiusens, indeed
[15:08] <beuno> I think that's part of our UX story overall
[15:09] <beuno> which I'll find a volunteer to go and play with you soon
[15:09] <kyrofa> Good morning!
[15:10] <kyrofa> jdstrand, nooo https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1467595/comments/28
[15:18] <sergiusens> kyrofa, joining?
[15:19] <kyrofa> Haha, just saw that you guys were meeting
[15:19] <kyrofa> Grabbing headphones
[15:26] <elopio> stgraber: ping. Our lxc in travis is timing out waiting for eth0. This used to work great for the past weeks.
[15:26] <elopio> any change on your side?
[15:33] <stgraber> elopio: what lxc version, what lxd version, what kernel version and what Ubuntu version in the container?
[15:38] <sergiusens> stgraber, host is trusty; here's the full of it, it's a small log https://travis-ci.org/ubuntu-core/snapcraft/jobs/111744184
[15:38] <kyrofa> stgraber, 2.0.0~beta4-0ubuntu4~ubuntu14.04.1~ppa1
[15:38] <stgraber> sergiusens: oh, the output of lxc info changed slightly, you'll need to change that grep, sorry
[15:39] <kyrofa> stgraber, whew, easy fix though
[15:39] <sergiusens> stgraber, we are using a beta, all good :-)
[15:39] <stgraber> "IPV4" now shows up as "inet" (the actual name of the network family)
[15:39] <sergiusens> stgraber, thanks for spotting it quickly
[15:39] <stgraber> yeah, had a similar problem here with one of my scripts
[15:58] <jdstrand> kyrofa: I know, right? there is still hope for 4.4
[15:59] <jdstrand> kyrofa: and 4.3 is *way* better
[16:01] <kyrofa> jdstrand, alright, good deal
[16:46] <noizer> Hi guys is it even possible to communicate with usb devices on snappyN?
[16:50] <kyrofa> noizer, yes, but you need to give snaps permission to use them
[16:52] <noizer> ok what skill is it?
[16:52] <kyrofa> noizer, in 15.04 you had to hw-assign it. jdstrand has that gone away in 16.04?
[16:59] <jdstrand> kyrofa: hw-assign currently exists. it won't once zyga and niemeyer have their way :)
[16:59] <jdstrand> but it is still there
[16:59] <noizer> ok
[17:15] <zyga> noizer, kyrofa: interfaces (renamed skills)
[17:15] <zyga> kyrofa: hw-assign is still in 16.04 daily but I'll remove it when interfaces go live
[17:15] <zyga> and I should read backlogs backwards ;)
[17:15] <kyrofa> zyga, yeah that's kinda tough-- you never know how far back they go :P
[17:16] <zyga> kyrofa: eleven years ;)
[17:16] <zyga> not in this channel though
[17:16] <kyrofa> zyga, haha, yeah exactly
[17:17] <zyga> I'm tired with all the rename I did today
[17:18] <zyga> I'd love to land this but there are Ks of diffs and everyone is busy
[17:18] <zyga> if someone can have a look at https://github.com/ubuntu-core/snappy/pull/524/files
[17:18] <zyga> that would help me out
[17:18] <zyga> or https://github.com/ubuntu-core/snappy/pull/523/files for a shorter pull request
[19:03] <plars> ev:  I got this when trying to create a spec, which I think might be interesting to you.... it doesn't let me re-run it because it says the spec already exists: "message": "Oops! Something bad happened server side (id=Vs9PuwoZwIwAAGe9IgMAAAAl)"
[19:04] <beuno> plars, the cloud is being messed with
[19:04] <beuno> good to know, though
[19:04] <beuno> just not surprising  :)
[19:04] <ev> 😢 🎺
[19:04] <plars> ev: a sad trumpet? as a trombone player, I'm deeply offended by that
[19:05] <ev> hahaha, there’s no trombone in unicode
[19:05] <plars> a major flaw imho, let's dump unicode
[19:05] <ev> we probably should
[19:06] <plars> back to ebcdic until further notice
[19:06] <ev> LOL
[19:06] <ev> nearly lost my tea there
[19:07] <plars> ev in all seriousness though, I guess I should hold off on messing with this while it's in this state? any idea how long?
[19:07] <ev> depends on IS
[19:07] <ev> I’d give it another go next week
[19:07] <plars> ack
[19:07] <plars> hah, ok
[19:26] <kyrofa> sergiusens, say I have a 15.04 snap that depends on the docker framework. If I upload a version of the snap that doesn't depend upon docker, will the previously-installed docker snap still get automatically updated?
[19:26] <kyrofa> sergiusens, I'm not quite sure how the frameworks thing plays into that
[19:34] <sergiusens> kyrofa, yes it will
[19:35] <kyrofa> sergiusens, alright thanks :)
[19:39] <kyrofa> sergiusens, you okay waiting a bit on that pkg-config PR? I'm giving it some good testing, but might take a while
[19:39] <sergiusens> kyrofa, no rush
[19:39] <kyrofa> sergiusens, good deal
[20:13] <kyrofa> sergiusens, in 16.04 snappy, the .service files still have restart on failure, but it seems the snap installation itself fails if the service fails to start. Do you know anything about that?
[20:14] <sergiusens> kyrofa, I have no idea; the right person to ask this is Chipaca
[20:14] <kyrofa> sergiusens, alright thanks :)
[20:14] <kyrofa> Chipaca, I suppose you're eating
[20:14] <sergiusens> kyrofa, I am really outdated these days :-)
[20:14] <sergiusens> lol
[20:14] <sergiusens> risotto?
[20:14] <kyrofa> Hahaha
[21:03] <pindonga> jdstrand, hey, crt @ 596 on prod now
[21:07] <sergiusens> elopio, can we apt update the jenkins instances before test run?
[21:32] <jdstrand> pindonga: thanks!
[21:33] <jdstrand> mvo: note, with that ^ on prod, we are going to start getting a warning that the store can't verify resquashing until bug #1548988 is srud to trusty
[21:34] <jdstrand> mvo: however, that bug is in hand so next week that'll just work itself out
[21:35] <mvo> jdstrand: nice, thanks for the update