dyfi | Hello; is there anybody here who is familiar with loading a Snappy image on to the Beaglebone Black? | 01:39 |
---|---|---|
aatchison | Hey guys. Energies severely depleted over here. I just had a crazy idea. Tensor flow on snappy? | 06:19 |
aatchison | Also, random question. Does Snappy deploy well with JuJu? | 06:20 |
dholbach | good morning | 07:51 |
=== davidcalle_afk is now known as davidcalle | ||
ysionneau | morning | 08:42 |
zyga | good morning | 08:43 |
noizer | good morning | 08:57 |
zyga | hey ysionneau, noizer :) | 08:58 |
zyga | have you read about the skills rename? | 08:58 |
ysionneau | skills rename ? | 08:59 |
noizer | no | 08:59 |
noizer | was it send in the mailing? | 08:59 |
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:00 |
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:04 |
ysionneau | ah found it, it's in snappy-system.txt | 09:05 |
zyga | ysionneau: no but I guess you just found out :) | 09:08 |
ysionneau | yep! | 09:09 |
ysionneau | I'm trying to boot your rpi2 image using qemu | 09:09 |
ysionneau | so far I'm KO | 09:09 |
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:10 |
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:11 | |
zyga | help wanted ^^ | 09:12 |
=== chihchun_afk is now known as chihchun | ||
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:29 |
noizer | do you have images for soft float? | 09:30 |
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:33 |
noizer | zyga ok | 09:34 |
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:43 |
=== chihchun is now known as chihchun_afk | ||
=== vrruiz_ is now known as rvr | ||
ysionneau | it seems that the initramfs does not mount the squashfs (the snaps) since the systemd init is not found... | 09:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
zyga | ysionneau: emulating various beagle board-like hardware | 09:59 |
zyga | ysionneau: though I don't know how much work that would be today | 09:59 |
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:00 |
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:02 |
=== Chipaca` is now known as Chipaca | ||
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:07 |
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:08 |
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:09 |
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:11 |
zyga | maybe just aarch64 with the same bits as before | 10:12 |
zyga | then with different kerenl | 10:12 |
zyga | kernel* | 10:12 |
ysionneau | not sure I understand ? | 10:13 |
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:14 |
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:16 |
ysionneau | right, I need to reconstruct the kernel snap squashfs to include the arm64 modules | 10:20 |
ysionneau | jeez | 10:20 |
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:04 |
zyga | ysionneau: \o/ | 11:06 |
zyga | ysionneau: great | 11:06 |
uralbash | Hello all | 11:46 |
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:47 |
ysionneau | snappy search does not exist any moer ? | 11:51 |
ysionneau | anymore* | 11:51 |
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:56 |
ysionneau | same here, snappy search does not seem to exist anymore on 16.04 | 11:58 |
svij | it's "snappy find" afaik | 11:58 |
ysionneau | nop, does not work | 11:59 |
uralbash | `find` not work too http://paste.ubuntu.com/15196599/ | 12:04 |
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:23 |
ysionneau | is it still snapcraft? or snappy build? snap.yaml? syntax? | 12:24 |
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:37 | |
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:38 |
svij | ah, so I wasn't completely wrong with "snappy find" | 12:40 |
ysionneau | :) | 12:41 |
ysionneau | where's the source code of "snap" mvo ? | 12:44 |
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:45 |
=== gp is now known as Guest81475 | ||
uralbash | `sudo snap add mir.mvp-demo` is an error http://paste.ubuntu.com/15196831/ | 12:49 |
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. | 12:51 |
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:02 |
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:03 |
uralbash | ysionneau: Ah, got it, I need to try build it with snapcraft | 13:05 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:32 |
Guest81475 | I do not like APT but I love the idea of packages as in snappy. AFAIK, MacOS has a similar system. | 13:33 |
ysionneau | zyga: ok :) | 13:36 |
zyga | Guest81475: http://developer.ubuntu.com/en/snappy/start/ | 13:37 |
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:38 |
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:39 |
ysionneau | the magic of live :) | 13:40 |
zyga | the magic of open | 13:40 |
* ysionneau generates a new docker image -> xenial | 13:45 | |
ysionneau | there's no "snappy-tools" package in the PPA for Xenial ? | 13:55 |
ysionneau | that's just a meta package ... but that can be handy | 13:58 |
beuno | ysionneau, I think it's part of the Xenial archive now instead of the PPA | 13:59 |
sergiusens | elopio, joining? | 14:33 |
sergiusens | ysionneau, beuno just apt install snapcraft | 14:58 |
ysionneau | yep that's what I've done | 14:59 |
sergiusens | beuno, are we going to have the store treat each release as different pockets? | 15:02 |
beuno | sergiusens, maybe! what do you mean by that? | 15:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
beuno | which I'll find a volunteer to go and play with you soon | 15:09 |
kyrofa | Good morning! | 15:09 |
kyrofa | jdstrand, nooo https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1467595/comments/28 | 15:10 |
ubottu | Launchpad bug 1467595 in xorg (Ubuntu) "cursor sometimes disappears on XPS 13 9343 and external monitor" [High,Confirmed] | 15:10 |
sergiusens | kyrofa, joining? | 15:18 |
kyrofa | Haha, just saw that you guys were meeting | 15:19 |
kyrofa | Grabbing headphones | 15:19 |
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:26 |
stgraber | elopio: what lxc version, what lxd version, what kernel version and what Ubuntu version in the container? | 15:33 |
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:38 |
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:39 |
jdstrand | kyrofa: I know, right? there is still hope for 4.4 | 15:58 |
jdstrand | kyrofa: and 4.3 is *way* better | 15:59 |
kyrofa | jdstrand, alright, good deal | 16:01 |
noizer | Hi guys is it even possible to communicate with usb devices on snappyN? | 16:46 |
kyrofa | noizer, yes, but you need to give snaps permission to use them | 16:50 |
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:52 |
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 | 16:59 |
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:15 |
zyga | kyrofa: eleven years ;) | 17:16 |
zyga | not in this channel though | 17:16 |
kyrofa | zyga, haha, yeah exactly | 17:16 |
zyga | I'm tired with all the rename I did today | 17:17 |
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 | 17:18 |
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:03 |
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:04 |
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:05 |
plars | back to ebcdic until further notice | 19:06 |
ev | LOL | 19:06 |
ev | nearly lost my tea there | 19:06 |
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:07 |
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:26 |
sergiusens | kyrofa, yes it will | 19:34 |
kyrofa | sergiusens, alright thanks :) | 19:35 |
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 | 19:39 |
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:13 |
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 | 20:14 |
pindonga | jdstrand, hey, crt @ 596 on prod now | 21:03 |
sergiusens | elopio, can we apt update the jenkins instances before test run? | 21:07 |
jdstrand | pindonga: thanks! | 21:32 |
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:33 |
ubottu | 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:33 |
jdstrand | mvo: however, that bug is in hand so next week that'll just work itself out | 21:34 |
mvo | jdstrand: nice, thanks for the update | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!