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