| mup | PR snapcraft#863 opened: history/status alignment fixes <Created by cprov> <https://github.com/snapcore/snapcraft/pull/863> | 00:10 |
|---|---|---|
| Ryan___ | help | 01:39 |
| rl-ubuntu | Anyone has a guide in running .net core in snappy ubuntu core? i'm following the guide in microsoft website, i can't install because it was using apt-get install. | 01:45 |
| Son_Goku | it's not snapped yet | 01:51 |
| rl-ubuntu | @Son_Goku so it's possible to run a .net core in snappy ubuntu core i just need to snap it first, correct? | 01:54 |
| nothal | rl-ubuntu: No such command! | 01:54 |
| Son_Goku | yep | 01:54 |
| rl-ubuntu | awesome, will try that. thanks | 01:56 |
| mup | Bug #1612260 changed: My package is published but not showing up in the store <Snappy:Expired> <https://launchpad.net/bugs/1612260> | 04:17 |
| mup | PR snapd#2125 opened: tests: fixed code blocks on external backend readme <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2125> | 07:05 |
| dholbach | good morning | 07:13 |
| oSoMoN | didrocks, hey, I’ve rebuilt my webbrowser-app snap and I was expecting that because of https://github.com/ubuntu/snapcraft-desktop-helpers/commit/46bea1d261e005eecfe532a5a23d9dd080898432 locales-all would be pulled in as a stage package, but it appears it’s not. any idea why? | 07:32 |
| mup | PR snapd#2126 opened: tests: add spread test for `snap auto-import` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2126> | 07:37 |
| didrocks | oSoMoN: hey! oh, interesting, let me check if I can find the online definition of the importer | 07:42 |
| didrocks | oSoMoN: you did snapcraft update, correct? | 07:42 |
| didrocks | I do see locales-all here | 07:42 |
| oSoMoN | didrocks, I didn’t run snapcraft update, but when checking the source of the desktop-qt5 part, it has my commit | 07:52 |
| oSoMoN | re-running now, after running snapcraft update | 07:53 |
| === mbriza|gone is now known as mbriza | ||
| didrocks | oSoMoN: you did snapcraft clean as well? | 07:56 |
| didrocks | because I'm unsure it dirty check properly | 07:56 |
| oSoMoN | I ran bzr clean-tree --unknown --ignored in my branch, so there should be no leftover | 07:57 |
| didrocks | yep! | 07:57 |
| mup | PR snapd#2127 opened: tests: add test for auto-mount assertion import <Created by mvo5> <https://github.com/snapcore/snapd/pull/2127> | 08:05 |
| mup | PR snapd#2125 closed: tests: fixed code blocks on external backend readme <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2125> | 08:11 |
| oSoMoN | didrocks, now it worked, locales-all got included in my snap | 08:14 |
| oSoMoN | looks like running snapcraft update made the differenc | 08:14 |
| didrocks | nice! :) | 08:14 |
| oSoMoN | difference | 08:14 |
| didrocks | yep | 08:14 |
| didrocks | you need to refresh the definition | 08:14 |
| didrocks | it's like apt update if you prefer | 08:14 |
| oSoMoN | thanks for the tip! | 08:14 |
| seb128 | it's a bit error prone that it needs to be done manually this way :-/ | 08:16 |
| didrocks | agreed, (I'm pretty sure that was already raised) | 08:18 |
| didrocks | at least, it should tell "we have new definitions for you, please run…" | 08:18 |
| didrocks | IIRC, the concern was "too many connections to the server" | 08:18 |
| seb128 | I can see that connecting every time you use snapcraft wouldn't work either | 08:19 |
| seb128 | but maybe refreshing once a day | 08:19 |
| seb128 | then those who need to trigger an update can manually do it | 08:19 |
| === jamespag` is now known as jamespage | ||
| === StoneTable is now known as aisrael | ||
| mup | PR snapcraft#864 opened: Update documentation links to developer.ubuntu.com that now redirect … <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/864> | 08:47 |
| === King_InuYasha is now known as Son_Goku | ||
| mup | PR snapd#2128 opened: debian: remove usage of dh-systemd <Created by vosst> <https://github.com/snapcore/snapd/pull/2128> | 09:06 |
| mup | PR snapd#2129 opened: interface attributes: prepare plug slot hooks (phase 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2129> | 09:23 |
| Chipaca | ogra_, once again talking about doing fancy stuff in core in #systemd and the "run systemd in initrd" comes up | 09:45 |
| ogra_ | Chipaca, well, have fun implementing it and making it work with the existing bits :P | 09:51 |
| ogra_ | Chipaca, effectively that will just make the initrd explode in size | 09:51 |
| Chipaca | ogra_, my response was *very* polite | 09:51 |
| ogra_ | with not much benefit | 09:51 |
| ogra_ | :) | 09:52 |
| Chipaca | ogra_, on the other hand, did we ever have a serious conversation around making initrd be the actual root? | 09:52 |
| ogra_ | Chipaca, we did in the phonedations team a few times. but not in context to snappy ... if we'd actually use initamfs-tools to create that rootfs (to only contain *exactly* what is necessary) that would surely result in an awesome but maintenance intense system | 09:56 |
| dr1337 | ogra_ what was it like working on the ninja sphere? | 09:59 |
| ogra_ | dr1337, like working with a beaglebone on streoids ;) | 10:00 |
| ogra_ | *steroids | 10:01 |
| dr1337 | How did canonical get involved in it? | 10:01 |
| mup | PR snapd#2130 opened: store: retry store ops (phase 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2130> | 10:01 |
| ogra_ | dr1337, no idea ... probably a conference or some such. i only got the board and was asked to do an initial test image after the involvement was there already | 10:09 |
| === hikiko is now known as hikiko|ln | ||
| om26er | re: launchpad snap builders, which version of Ubuntu do they use ? | 10:17 |
| ogra_ | xenial i think | 10:17 |
| om26er | I am building a snap, it works fine in a lxc container running xenial but fails to build in lp | 10:17 |
| ogra_ | how does it fail (got a build log link ?) | 10:17 |
| om26er | ogra_: https://launchpadlibrarian.net/289187171/buildlog_snap_ubuntu_xenial_amd64_crossbar_BUILDING.txt.gz | 10:17 |
| ogra_ | om26er, i'd guess for a firewall issue | 10:18 |
| om26er | ogra_: seems other things are downloading file from pypi | 10:19 |
| om26er | atleast from what I can see | 10:19 |
| daker | om26er: it says : Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known | 10:19 |
| ogra_ | i see a lot "Ignoring indexes:" above the error | 10:19 |
| ogra_ | so this is probably the first point where it actually tries to download any indexes | 10:20 |
| om26er | hmm | 10:20 |
| om26er | ogra_: lp bug? | 10:20 |
| ogra_ | dunno, but surely something to ask cjwatson about :) | 10:21 |
| ogra_ | he has the deeper insight here :) | 10:21 |
| om26er | cjwatson: ^ my snap build fails in lp, it works fine in a clean lxd container I am running locally. | 10:23 |
| cjwatson | om26er: you have to do your network access in the pull phase, not build | 10:23 |
| om26er | the snapcraft.yaml looks like this: https://github.com/om26er/crossbar/blob/master/snapcraft.yaml | 10:24 |
| cjwatson | om26er: I know you're trying to, but it's clearly not complete | 10:24 |
| cjwatson | om26er: possibly due to setup_requires or similar that pip download isn't managing to follow | 10:24 |
| cjwatson | om26er: you can probably just manually add cffi to the download step | 10:24 |
| om26er | ogra_: ^ can you decrypt that on to how that may reflect in my snapcraft.yaml (still trying to get used to snapcraft :) | 10:25 |
| ogra_ | no, sorry, i'm not a big python guy beyond what comes from the archive (i have no biggger knowledge of pip) | 10:27 |
| cjwatson | om26er: "python-packages: cffi" probably | 10:28 |
| cjwatson | at least worth a go as a starting point | 10:28 |
| cjwatson | om26er: well strictly "python-packages: cffi>=1.1.0" | 10:28 |
| cjwatson | om26er: though you might possibly be better with "requirements: requirements.txt" instead | 10:30 |
| cjwatson | that would get the pinned requirements recommended by upstream in this case | 10:30 |
| om26er | ok let me try that. | 10:32 |
| om26er | cjwatson: seems that didn't help :/ same results https://launchpadlibrarian.net/289191346/buildlog_snap_ubuntu_xenial_amd64_crossbar_BUILDING.txt.gz | 10:55 |
| om26er | .yaml looks like this now https://github.com/om26er/crossbar/blob/master/snapcraft.yaml | 10:56 |
| om26er | note: I used requirements-in.txt file in the tree as requirements.txt has some hash verification so its fails like http://paste.ubuntu.com/23307635/ | 10:57 |
| om26er | a successful build (local lxd) looks like this http://paste.ubuntu.com/23307708/ | 11:00 |
| === hikiko|ln is now known as hikiko | ||
| cjwatson | om26er: Yuck. Possibly wheel should be in the download phase due to this. | 11:01 |
| cjwatson | om26er: Adding "python-packages: cffi>=1.1.0" should work around it, then. | 11:02 |
| om26er | cjwatson: with removal of the requirements like ? or can that co-exist ? | 11:02 |
| cjwatson | om26er: It can coexist. | 11:02 |
| cjwatson | om26er: But I think there's a reasonable argument that this is a snapcraft bug: given that wheel may need to hit the network, it should be done in the pull phase. | 11:03 |
| cjwatson | om26er: i.e. something like http://paste.ubuntu.com/23307726/ (totally untested) | 11:06 |
| om26er | cjwatson: hmm wonder if there is a way to test that in lp :) | 11:07 |
| ogra_ | cjwatson, hmm, all my kernel snap rebuilds failed with a 403 error | 11:09 |
| ogra_ | that is: https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/6639 https://code.launchpad.net/~snappy-dev/+snap/dragonboard-kernel/+build/6641 https://code.launchpad.net/~snappy-dev/+snap/pc-kernel/+build/6638 and https://code.launchpad.net/~snappy-dev/+snap/pc-kernel/+build/6637 | 11:10 |
| om26er | cjwatson: btw that did work :) | 11:18 |
| om26er | So we need to fix that so that others don't hit that. | 11:19 |
| om26er | *in snapcraft | 11:19 |
| liuxg | ogra_, if I have a ubuntu core device and it is bound to my launchpad account, may I know how I can make it work with another colleauge's launchpad on his computer? | 11:26 |
| liuxg | ogra_, the idea is that he can login into the device witth his account instead of my account, which uses the ssh key in my computer. | 11:27 |
| ogra_ | i think the command that console-conf uses in teh backend is "snap create-user" | 11:29 |
| ogra_ | (not 100% sure though) | 11:29 |
| === sjn__ is now known as sjn | ||
| liuxg | ogra_, what is the correct syntax for using the command "snap create-user"? do I just need to supply the launchpad id? | 11:30 |
| cjwatson | ogra_: I don't have enough logging at the moment to be able to tell you exactly why that was. The possible causes are that the uploader hasn't signed the latest developer agreement in the store, that the uploader hasn't set a developer namespace in the store, or that the authorisation token isn't authorised for the correct package name. (You can rule out the last of those by going through ... | 11:30 |
| cjwatson | ... e.g. https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+authorize) | 11:30 |
| ogra_ | liuxg, i dont actually know ... doesnt snap help tell something about it ? (but i guess jst your mail address should suffice) | 11:30 |
| cjwatson | "snap create-user --help" says you give it an email address. | 11:31 |
| cjwatson | [create-user command arguments] | 11:31 |
| cjwatson | <email>: An email of a user on login.ubuntu.com | 11:31 |
| ogra_ | cjwatson, well, thats weird, the uploader is indeed me :) | 11:31 |
| ogra_ | uh, oh | 11:31 |
| ogra_ | and i just notice that all the core builds failed to upload too ... | 11:32 |
| cjwatson | ogra_: I'm just telling you the possible causes. It will be one of those. I don't know which. | 11:32 |
| ogra_ | cjwatson, can we have mail notification for that ? i havent gotten a single mail | 11:32 |
| cjwatson | ogra_: bug please | 11:32 |
| ogra_ | will do | 11:32 |
| cjwatson | ogra_: there's supposed to be a mail notification, so must have missed a case | 11:33 |
| ogra_ | yeah, i get mails for other failures | 11:33 |
| cjwatson | right, BadUploadResponse doesn't have an associated notification | 11:34 |
| liuxg | ogra_, thanks. I have not tried it yet. Maybe I will try it when I am with my colleague. I do not have his account info now. | 11:35 |
| cjwatson | ogra_: anyway apparently the 403s are a known SCA bug in production, being looked at now | 11:37 |
| ogra_ | sigh, this is insane ... i'll be clicking authorize stuff for the next hour or so, *all* aumoated snaps failed | 11:37 |
| cjwatson | ogra_: +authorize won't help | 11:37 |
| cjwatson | in this case | 11:37 |
| ogra_ | ouch | 11:37 |
| cjwatson | ogra_: once the SCA bug is fixed you should be able to retry the store upload from LP though | 11:38 |
| ogra_ | ok | 11:38 |
| ogra_ | yeah, even after authorize/re-upload i get 403's everywhere, confirmd | 11:39 |
| ogra_ | cjwatson, bug 1632299 | 11:44 |
| mup | Bug #1632299: BadUploadResponse store reply in snap uploads should trigger email notification <Launchpad itself:New> <https://launchpad.net/bugs/1632299> | 11:44 |
| popey | what is "Initialize device" and why is it spamming my "snap changes" every 9 mins or so... http://termbin.com/rzoi ? | 11:44 |
| cjwatson | thanks | 11:45 |
| ogra_ | popey, by reading that paste i would say it is an Error :P | 11:46 |
| popey | heh | 11:49 |
| popey | ogra_: worthy of a bug report somewhere do you think? | 11:50 |
| ogra_ | yeah | 11:50 |
| popey | ok, thanks for looking | 11:50 |
| ogra_ | i guess mvo or pedronis could help you further with that one | 11:50 |
| popey | ok, bug filed. | 11:52 |
| mup | Bug #1632305 opened: console-conf cannot be used twice <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1632305> | 11:53 |
| mup | Bug #1632306 opened: 'snap changes' spammed with "Initialize device" <Snappy:New> <https://launchpad.net/bugs/1632306> | 11:53 |
| ogra_ | liuxg, hah ... looks like Bug #1632305 above has a trick you can use to create your second user ;) | 11:55 |
| mup | Bug #1632305: console-conf cannot be used twice <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1632305> | 11:55 |
| liuxg | ogra_, where is the trick? sorry, I missed it. | 11:55 |
| ogra_ | re-run "sudo console-conf" ;) | 11:56 |
| ogra_ | seems to work if you use a new user and just dont change the network settings | 11:56 |
| ogra_ | (according to that bug) | 11:56 |
| liuxg | ogra_, do you mean run it after ssh into the device? | 11:57 |
| ogra_ | yes, as the bug says | 11:57 |
| pedronis | popey: it means it's failing to register itself? is this with a canonical image? does it have network? | 11:57 |
| liuxg | ogra_, OK. thanks. I will have a try. | 11:57 |
| liuxg | ogra_, so, "sudo console-conf" is now working or not. according to the bug report, it does not work yet | 11:59 |
| ogra_ | it faisl if you re-use the same user | 11:59 |
| ogra_ | (thats the bug) | 11:59 |
| ogra_ | but thats not what you want | 11:59 |
| liuxg | ogra_, oh, so, I can set it to another user. after that, I can switch back to my own, right? if this works, it should be fine for me. | 12:00 |
| ogra_ | right | 12:00 |
| liuxg | ogra_, thanks. it is cool. by the way, does "snap create-user" do the same thing? it seems to be the correct command | 12:01 |
| ogra_ | console-conf calls it, ye | 12:02 |
| ogra_ | s | 12:02 |
| ogra_ | (as i said in the beginning) | 12:02 |
| mvo | popey: thanks for your bug on the init device issue, could you please attach the output of "change change 833" (or similra, one of the failing ones) | 12:02 |
| liuxg | ogra_, ok. so, both ways work. thanks a lot | 12:02 |
| ogra_ | re-using console-conf is just cheap way | 12:02 |
| ogra_ | popey, btw, is that the device that switched back to stable unconditionally ? | 12:02 |
| liuxg | ogra_, right. :) | 12:03 |
| ogra_ | popey, if so, that could indeed be related | 12:03 |
| ogra_ | (teh fw_setenv command i gave you is just a hack) | 12:03 |
| popey | mvo: done | 12:10 |
| popey | ogra_: uhm, not sure if it's that one, I have 3 | 12:11 |
| pedronis | popey: did you reset you state at some point or something ? | 12:12 |
| popey | not intentionally | 12:12 |
| popey | see also bug 1631791 | 12:13 |
| mup | Bug #1631791: Pi 2 on ubuntu-core 424 no longer able to do anything <Snappy:Confirmed> <https://launchpad.net/bugs/1631791> | 12:13 |
| popey | ooh, i have another one doing the initialize device thing | 12:13 |
| pedronis | that error mode is weird | 12:14 |
| popey | also, bug 1632124 is on a pi 3 which is also doing the initialize device thing | 12:16 |
| mup | Bug #1632124: snapd pegging cpu at 100% <Snappy:New> <https://launchpad.net/bugs/1632124> | 12:16 |
| === cmars` is now known as cmars | ||
| pedronis | popey: asked a couple more questions in the bug itself | 12:38 |
| popey | pedronis: on it, painfully slow to get snap changes as the cpu is pegged by snapd | 12:39 |
| popey | pedronis: ok, commented | 12:40 |
| pedronis | popey: it's creating key after key and not finding them | 12:42 |
| pedronis | apparently | 12:42 |
| * ogra_ notes that popey's image is still using ubuntu-core ... | 12:44 | |
| ogra_ | (newer images use the "core" package instead) | 12:44 |
| popey | interesting | 12:45 |
| balloons | Good morning all. Quick question -- should there be any delay from publish to availibilty in the store? I don't remember ever seeing a delay, but I'm hearing publication can take 12 hours or more sometimes | 12:45 |
| ogra_ | well, not that much, you would have to flash a newer image to get there ... but perhaps there is a bug in the code that handles both names ... | 12:45 |
| ogra_ | thats relatively new code | 12:46 |
| ara | mmm, on a clean rpi2 clasic image as of today, doing snap install hello-world shouldn't install core instead of ubuntu-core? | 12:46 |
| ara | I just did this and ubuntu-core was downloaded | 12:46 |
| popey | oh, it doesn't migrate from ubuntu-core to core? I need to re-flash again? | 12:46 |
| ogra_ | popey, yes ... | 12:46 |
| zyga | ara: hey | 12:47 |
| popey | :( | 12:47 |
| ogra_ | ara, i think thats only happening with the next snapd revision ... | 12:47 |
| ogra_ | (defaulting to install core) | 12:47 |
| ara | mmm, classic on rpi2 fails to install ubuntu-core as well: https://pastebin.canonical.com/167549/ | 12:48 |
| ara | hey zyga, how's korea? | 12:49 |
| pedronis | popey: I'm quite baffled by what is going on on your pi2, seems like we write something and a second after we are not reading it | 12:49 |
| ogra_ | ara, wow, gross | 12:49 |
| ogra_ | it shouldnt try to handle any boot stuff on classic ever | 12:49 |
| ara | ogra_, this is a clean server classic image, no dist-upgrade yet | 12:50 |
| ogra_ | probably that code isnt pi-safe :) | 12:50 |
| ara | ogra_, do you want me to file a bug for this? if so, where? what logs? | 12:51 |
| ogra_ | ara, hmm, you should definitely dist-upgrade first to get the latest snapd | 12:51 |
| ara | let me update snapd and see if that solves it | 12:51 |
| ogra_ | snapd, snap-confine and ubuntu-core-launcher | 12:52 |
| ogra_ | (orr just dist-upgrade) | 12:52 |
| * ara wonders if we should produce 16.04.1.1 images with the latest packages, as so much changed | 12:52 | |
| ara | snap-confine was not even installed yet on those images | 12:52 |
| ogra_ | well, 16.04.2 will have everything | 12:53 |
| ogra_ | right, but snapd will pull it in on dist-upgrade | 12:53 |
| ogra_ | iirc it was added as dependency | 12:53 |
| ara | yes, it does | 12:53 |
| zyga | ara: hey, pretty and exotic | 12:56 |
| mup | Bug #1631801 changed: snapd removes Exec lines from .desktop file on installation <Snappy:Invalid> <https://launchpad.net/bugs/1631801> | 13:15 |
| om26er | So I need to write values to /sys/class/gpio/ is there a way to keep my snap confined and be able to do so ? | 13:16 |
| om26er | zyga: ^ | 13:18 |
| zyga | om26er: using the GPIO interface on a correctly set up core image (only gadget can expose those) | 13:21 |
| om26er | zyga: apart from those to be exposed, my main question is can I write to lets say /sys/class/gpio21/direction or /sys/class/gpio21/value ? Since that's what would make it be able to do it anything. Now I assume it will always require sudo ? | 13:22 |
| om26er | on another question what would it take to ensure they are exposed on a RaspberryPi ? Does the RPi gadget snap need to do that ? | 13:24 |
| om26er | or even is there a "gadget" snap for the Pi ? | 13:25 |
| zyga | om26er: yes, regular permissions will still be in the way | 13:25 |
| zyga | om26er: you'd have to write a service that can run as root to use them | 13:25 |
| om26er | zyga: curious where does this PR stand in all this https://github.com/snapcore/snapd/pull/2065 ? | 13:28 |
| mup | PR snapd#2065: interfaces/builtin: use udev to export GPIOs to userspace <Blocked> <Reviewed> <Created by zyga> <https://github.com/snapcore/snapd/pull/2065> | 13:28 |
| zyga | om26er: on hold | 13:29 |
| zyga | I was busy with roscon lately | 13:29 |
| === josepht` is now known as josepht | ||
| rvr | Is there any problem with the store? | 13:34 |
| om26er | Currently it seems I can expose the GPIO by adding udev rule, not sure though If I can read/write values to from a confined snap, will test soon. | 13:34 |
| rvr | snap install classic doesn't work | 13:34 |
| rvr | vrruiz@localhost:~$ snap install hello-world | 13:34 |
| rvr | error: cannot install "hello-world": snap not found | 13:34 |
| om26er | WFM | 13:35 |
| qengho | rvr: Weird. What architecture? | 13:35 |
| rvr | qengho: arm64 | 13:35 |
| qengho | Ah hah. | 13:35 |
| qengho | I bet no one made an arm64 package for hello-world. | 13:35 |
| qengho | But that can be fixed in no time. ... | 13:36 |
| rvr | qengho: Ok, but I could run spread tests just one hour ago | 13:36 |
| rvr | and now it's giving me error with snap install classic | 13:36 |
| qengho | rvr: I don't know what that means. | 13:36 |
| sergiusens | qengho hello world is arch all I think | 13:36 |
| sergiusens | hello however isn't | 13:37 |
| sergiusens | too many hellos | 13:37 |
| ogra_ | ogra@localhost:~$ sudo snap install hello-world | 13:37 |
| ogra_ | hello-world (stable) 6.3 from 'canonical' installed | 13:37 |
| ogra_ | ogra@localhost:~$ | 13:37 |
| * ogra_ is just testing dragonboard arm64 here | 13:37 | |
| ogra_ | not classic though | 13:37 |
| ogra_ | (do we actually have classic images yet ?) | 13:37 |
| om26er | speaking of classic, I don't see a yakkety classic RPi image anywhere. | 13:38 |
| rvr | ogra_: I guess so, because it was working this morning | 13:39 |
| ogra_ | om26er, ask foundations :) | 13:39 |
| ogra_ | or the server team | 13:39 |
| ogra_ | or whoever cares for classic these days | 13:39 |
| om26er | its boring, still uses linux 4.4 :p as linux-raspi2 was never updated in yakkety | 13:39 |
| sergiusens | ogra_ maybe there needs to be clarification on what classic, the enable-classic or a classic install on the rootfs | 13:39 |
| ogra_ | oh, crap, i mis-read rvr's line above | 13:40 |
| om26er | oh wait, 4.8 for RPi is now uploaded. | 13:40 |
| ogra_ | ogra@localhost:~$ sudo snap install classic --devmode --edge | 13:40 |
| ogra_ | classic (edge) 16.04 from 'canonical' installed | 13:40 |
| ogra_ | ogra@localhost:~$ | 13:40 |
| ogra_ | works fine here | 13:40 |
| ogra_ | rvr, ^^^ | 13:40 |
| rvr | + snap install --devmode --edge classic | 13:41 |
| rvr | error: cannot install "classic": snap not found | 13:41 |
| rvr | Hmm | 13:41 |
| ogra_ | your order is different | 13:42 |
| om26er | try turning it off and on again | 13:42 |
| om26er | ;) | 13:42 |
| rvr | lol | 13:42 |
| rvr | This is weird | 13:43 |
| rvr | vrruiz@localhost:~$ sudo snap install classic --devmode --edge | 13:43 |
| rvr | error: cannot install "classic": snap not found | 13:43 |
| mup | Bug #1632336 opened: after first boot /var/lib/snapd/seed/snaps is empty <Snappy:New> <https://launchpad.net/bugs/1632336> | 13:53 |
| mup | Bug #1632337 opened: dragonboard beta3 image reboots during snap create-user <Snappy:New> <https://launchpad.net/bugs/1632337> | 13:53 |
| Chipaca | popey, on the pi2/3 that get that weird device thing loop, what does "snap --version" say? | 14:00 |
| Chipaca | popey, i mean in bug 1632306 | 14:00 |
| mup | Bug #1632306: 'snap changes' spammed with "Initialize device" <Snappy:New> <https://launchpad.net/bugs/1632306> | 14:00 |
| mvo | popey: what revision is your core snap on currently? we are looking at the device registraiton bug reight now | 14:00 |
| popey | popey@localhost:~$ snap --version | 14:00 |
| popey | snap 2.16+ppa37-1 | 14:00 |
| popey | snapd 2.16+ppa37-1 | 14:00 |
| popey | series 16 | 14:00 |
| popey | on pi 2 | 14:00 |
| popey | Chipaca: ^ | 14:01 |
| mvo | popey: revision from snap list please, that will also help us | 14:01 |
| Chipaca | popey, ta | 14:01 |
| === jgrimm-out is now known as jgrimm | ||
| mvo | Chipaca: ppa37 sounds like beta3 | 14:01 |
| Chipaca | mvo, that's already in the bug :-) | 14:01 |
| mvo | popey: *cough* sorry! | 14:01 |
| mvo | Chipaca: autsch | 14:01 |
| popey | yeah, i would, but running "snap list" takes aaaaaages | 14:01 |
| popey | np | 14:01 |
| Chipaca | mvo, ubuntu-core 16.04.1 845 canonical - | 14:02 |
| popey | ubuntu-core 16.04.1 845 canonical - | 14:02 |
| mvo | popey: aha, takes ages because snapd is so busy churning :/ | 14:02 |
| popey | confirmed | 14:02 |
| popey | it's variable, sometimes it is, sometimes not | 14:02 |
| popey | my pi3 is churning, for sure. still not responsed to --version | 14:03 |
| popey | popey@localhost:~$ snap --version | 14:03 |
| popey | snap 2.16+ppa39-1 | 14:03 |
| popey | snapd 2.16+ppa39-1 | 14:03 |
| popey | series 16 | 14:03 |
| popey | ^ from pi 3 | 14:04 |
| shuduo | hello, where is right place to define snapweb should be included or not in a customized image? | 14:26 |
| gerry_ | hi I am just playing with snaps for the first time I have used the first example yaml to style what I want to do with my .jar. Unsuprisingly it does not work I was just looking if there is an easy reason? the yaml is at http://pastebin.com/69B0spML | 14:29 |
| mup | PR snapd#2131 opened: tests add spread test for prepare-device customizing device init/registration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2131> | 14:43 |
| mup | PR snapd#2132 opened: interfaces/builtin: enable out of process providers for locationd <Created by vosst> <https://github.com/snapcore/snapd/pull/2132> | 14:48 |
| Chipaca | ogra_, you around? | 14:58 |
| Chipaca | or maybe it's barry | 14:58 |
| Chipaca | ogra_, about resizing the image to its smallest, what filesystem is it? | 14:58 |
| ogra_ | ext4 | 14:58 |
| mup | PR snapd#2133 opened: osutil: add missing unit tests for IsMounted <Created by mvo5> <https://github.com/snapcore/snapd/pull/2133> | 15:00 |
| Chipaca | ogra_, any reason not to make it 4G and then resize2fs -M (and then truncate)? | 15:01 |
| ogra_ | Chipaca, yes, 4G takes 10.15min to dd, uses your diskspace pointlessly etc etc | 15:02 |
| ogra_ | *10-15 | 15:02 |
| Chipaca | ogra_, dd to where? | 15:02 |
| ogra_ | Chipaca, we already have a bug about this and agreement to implement it properly to only have the images as big as their content requires | 15:02 |
| ogra_ | Chipaca, to a device | 15:02 |
| ogra_ | Chipaca, that bug is why i'm so surprised that barry implemented "+50%" | 15:03 |
| shuduo | hello ogra_, where is right place to define snapweb should be included or not in a customized image? | 15:03 |
| ogra_ | which is just nonsense | 15:03 |
| Chipaca | ogra_, but I mean resize2fs -M before dd'ing | 15:03 |
| ogra_ | Chipaca, you need the right partition size ... so you still have an image size that is to big and having the user run resize2fs as a step of a standard install is awful | 15:04 |
| ogra_ | we have this properly automated on first boot | 15:04 |
| ogra_ | there is really no need to add other fancy hackery here | 15:04 |
| ogra_ | we just need ubuntu-image to do the thing that was agreed | 15:04 |
| jdstrand | thomi: use 'architectures: [all]' | 15:05 |
| * jdstrand notes he is off today and just passing through | 15:05 | |
| ogra_ | shuduo, in your ubuntu-image call when you build the image | 15:05 |
| ogra_ | shuduo, there might be some way in the gadget but i dont know how that exactly works | 15:06 |
| ogra_ | s/might/should/ | 15:06 |
| ogra_ | (never used it) | 15:06 |
| zyga | tyhicks: hey | 15:07 |
| zyga | tyhicks: can you review snap-confine change for me please | 15:07 |
| tyhicks | zyga: hey - I can only handle something small/quick right now | 15:08 |
| zyga | tyhicks: hmm, this is neither but it is very important | 15:09 |
| zyga | tyhicks: alternatively just pick it up tomorrow and review/finish it (if it requires any changes) | 15:09 |
| zyga | tyhicks: this is about /media sharing for GA | 15:09 |
| zyga | ogra_: hey | 15:10 |
| zyga | ogra_: I'm booting beta3 amd64 on vmware and ... I get "cannot find 'writable' partition", being dropped to initrd shell, can you help me debug this? | 15:11 |
| tyhicks | zyga: is there an open PR? | 15:11 |
| zyga | tyhicks: yes, two, let me give you the links | 15:11 |
| zyga | https://github.com/snapcore/snap-confine/pull/169 | 15:12 |
| mup | PR snap-confine#169: Add spread tests for mount namespace layout <Created by zyga> <https://github.com/snapcore/snap-confine/pull/169> | 15:12 |
| zyga | this is easy and just serves as a before/after | 15:12 |
| ogra_ | zyga, i have not even a clue how to run such an image in vmware, iirc you need to run the image though a bunch of tools to convert it etc | 15:12 |
| zyga | while it works fine the json dump is somewhat flaky, in my tests sometimes some entries are ordered in another way and the test fails (nothing is broken but the output is different). I will look at fixing that in the next branch | 15:12 |
| shuduo | ogra_: hmm, i can't find clues in the doc https://github.com/CanonicalLtd/ubuntu-image/blob/master/docs/gadget-yaml.rst | 15:12 |
| zyga | ogra_: qemu-img and you've got a vmdk | 15:13 |
| zyga | ogra_: I wonder if there's something special that qemu does for us that is missing? | 15:13 |
| ogra_ | nope, nothing special | 15:13 |
| zyga | tyhicks: the "meat" is in https://github.com/snapcore/snap-confine/pull/168 | 15:13 |
| mup | PR snap-confine#168: Rework mount namespace support <Created by zyga> <https://github.com/snapcore/snap-confine/pull/168> | 15:13 |
| zyga | ogra_: what can I do in initrd to debug this? | 15:14 |
| zyga | tyhicks: I'll sort the output, that should fix it | 15:14 |
| ogra_ | zyga, you could boot with break=premount ... but i'D just inspect the image and the partitioning ... i guess whetever that tool does did somehow trash the partitioning | 15:15 |
| tyhicks | zyga: oof... when do you need this reviewed by? | 15:15 |
| zyga | tyhicks: ASAP, this is the big late feature | 15:16 |
| tyhicks | :( | 15:16 |
| zyga | ogra_: thanks, I'll check | 15:16 |
| ogra_ | not sure if kpartx can handle vmdk | 15:16 |
| zyga | ogra_: I can explore from within easily | 15:17 |
| zyga | (attach it to another VM) | 15:17 |
| ogra_ | k | 15:17 |
| zyga | ogra_: but I strongly doubt it is corrupted, vmdk is just another wrapper for the same set of bytes | 15:17 |
| * ogra_ hasnt used vmware in like 5 years ... so i cant really tell ... | 15:18 | |
| ogra_ | perhaps the conversion tool removes FS labels ... who knows :) | 15:19 |
| * ogra_ curses the beta3 images ... | 15:19 | |
| zyga | ogra_: it's a block level convertion | 15:19 |
| ogra_ | 12min dd ... still going ... | 15:20 |
| zyga | ogra_: it doesn't understand fs or partitioning | 15:20 |
| ogra_ | (30-40sec with the dailies that have a proper size) | 15:20 |
| zyga | ogra_: did you have any luck with that wireless SD card | 15:20 |
| ogra_ | zyga, did you see my mail ? | 15:20 |
| ogra_ | i sent a summary yesterday | 15:20 |
| zyga | ogra_: no, I'm totally behind email | 15:20 |
| zyga | I'll read it, thanks | 15:20 |
| ogra_ | i'm in love !!! | 15:20 |
| ogra_ | these wireless SD cards are the best since sliced bread | 15:21 |
| zyga | ogra_: really? :D | 15:21 |
| ogra_ | 400MHz v5 CPU, 30MB ram ... linux driven ... | 15:21 |
| zyga | ogra_: brig it next week, I'll buy some back home (or maybe in seoul) | 15:21 |
| ogra_ | just adding a bettery and you have the püerfect IoT device | 15:21 |
| zyga | v5 heh, maybe we can build core for v5 :) | 15:21 |
| ogra_ | nah | 15:22 |
| zyga | how much flash? | 15:22 |
| ogra_ | only 1MB disk size on the mtd device | 15:22 |
| zyga | oooh | 15:22 |
| zyga | omg :) | 15:22 |
| zyga | how big is the kernel? | 15:22 |
| zyga | and are there sources? | 15:22 |
| ogra_ | the OS is all busybox + wpa_supplicant | 15:22 |
| ogra_ | partitally i heard | 15:22 |
| ogra_ | havent found them yet | 15:23 |
| ogra_ | there used to be sources but tanscend seems to have taken them down | 15:23 |
| ogra_ | doesnt matter though ... for our usecase i need to replace the busybox with one that has different applets enabled and add a dropbear binary with proper keyx setup ... the rest of the OS can stay as is | 15:24 |
| zyga | ogra_: no matter, I'm happy that it works | 15:24 |
| ogra_ | it is super insecude ... | 15:24 |
| zyga | ogra_: I bet :) | 15:24 |
| zyga | plars: ^^ do you know about this? | 15:24 |
| ogra_ | dsont ever store your nekkid photos on such a card ;) | 15:24 |
| zyga | ogra_: I almost wish someone made a wired version of the card :) | 15:25 |
| ogra_ | (though admittedly you are not jennifer lawrence ... the interest would probably be lower) | 15:25 |
| zyga | hehee | 15:25 |
| zyga | "omg how do I remover this ugly guy from my computer" | 15:25 |
| ogra_ | the card has soldering points for serial too btw | 15:25 |
| ogra_ | so you could drive serial sensors etc | 15:26 |
| ogra_ | so an Sd card+coin battery ... + whatever serial device you want to use for measuring | 15:26 |
| plars | zyga: in a meeting, give me a bit | 15:26 |
| zyga | plars: nothing urgent, I bet you will like what orga found for pi testing :) | 15:27 |
| ogra_ | zyga, indeed, if you dont use the SD side for image testing like we do, the SD can become your rootfs ... so the 1MB mtd size is moot | 15:27 |
| ogra_ | you'd only use it for jump-start | 15:29 |
| ogra_ | mvo, so pi3 dies with bug 1630586 now if you dont have a serial cable attached (there is a workaround in the bug i can add to the notes) | 15:30 |
| mup | Bug #1630586: Pi3 kernel crash and is unreliable <patch> <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1630586> | 15:30 |
| tyhicks | zyga: I'm starting to review those PRs now | 15:31 |
| zyga | tyhicks: thanks | 15:31 |
| zyga | ogra_: does pi2/3 have hw watchdog? | 15:34 |
| mvo | ogra_: hm, what does that mean? image unsuitbable for publication? | 15:34 |
| zyga | ogra_: smells like something we should enable early to let snappy recover | 15:34 |
| zyga | (on upgrade) | 15:34 |
| ogra_ | mvo, i added a line to the notes ... see yourself if the workaround is to hard | 15:35 |
| ogra_ | zyga, i think ppisati tried to enable it on u-boot level but i think it isnt reliable | 15:35 |
| mvo | ogra_: hm, hm, feels not ideal, how hard would it be to incoperate this - do we need a new kernel? | 15:38 |
| ogra_ | mvo, we can either kill serial completely (by removing that line) ... or wait for a new kernel | 15:39 |
| ogra_ | if you want serial you need the line ... booting without serial requires the line removed currently | 15:40 |
| ogra_ | mvo, we could default to not support serial at all on the pi3 for beta3 and upload a changed gadget .... but that makes debugging any boot probs really hard | 15:42 |
| ogra_ | ogra@localhost:~$ snap lust | 15:43 |
| ogra_ | error: Unknown command `lust', did you mean `list'? | 15:43 |
| ogra_ | ogra@localhost:~$ snap list | 15:43 |
| ogra_ | Name Version Rev Developer Notes | 15:43 |
| ogra_ | core 16.04.1 75 canonical - | 15:43 |
| ogra_ | pi2-kernel 4.4.0-1021-3 14 canonical - | 15:43 |
| ogra_ | pi3 16.04-0.4 5 canonical - | 15:43 |
| ogra_ | snapweb 0.21 16 canonical - | 15:43 |
| ogra_ | looks fine after removing the line | 15:43 |
| mvo | ppisati_: what do you think? how long will a new kernel with the fix for the serial issue for pi3 take? | 15:43 |
| ogra_ | mvo, given that we only had new kernels yesterday (general SRU) i guess a bit | 15:44 |
| * ogra_ runs another pi3 test with wlan only | 15:50 | |
| ogra_ | if dd ever finishes :( | 15:51 |
| ogra_ | hmm ... console-conf startup time on pi is still not stellar :( | 15:55 |
| plars | zyga: Yeah, I saw some emails about ogra_ doing some cools stuff with that. I look forward to hearing how it comes out, but it's all moot if we can't get network and user automatically provisioned | 15:58 |
| plars | I've heard that there's some way of getting the user part done by putting a file on a usb stick and leaving it in the device, but I've not seen a functioning example of that yet, nor how the automatically getting the network set up without console interaction would work | 15:59 |
| plars | mvo: I heard that you might have answers to at least part of that ^? | 15:59 |
| ogra_ | plars, why qould yu need that ? | 15:59 |
| plars | ogra_: for provisioning the image on the device for automated testing | 16:00 |
| ogra_ | plars, the card starts in AP mode, you would only have a PC with extra WLAN card that attaches to that AP | 16:00 |
| ogra_ | there is nothing you need to do on the SD side for this | 16:00 |
| plars | ogra_: no, I'm talking about the snappy image that we flash onto it | 16:00 |
| ogra_ | plars, ah, so you would dd the img and then push additional files to it ? | 16:01 |
| ogra_ | or mangle files | 16:01 |
| plars | ogra_: what you're describing would let us flash the image onto the sd, which we could then boot. But if we want to run tests on it, we would need a way to provision the user and network without having to connect it to video/keyboard and have someone press buttons | 16:01 |
| ogra_ | plars, and how do you do this today ? | 16:01 |
| plars | ogra_: I don't know... I've heard there's supposed to be something we can do with assertions | 16:01 |
| plars | ogra_: today? We don't ever since that was changed | 16:01 |
| ogra_ | mvo, no WIFI only love on pi3 either :( | 16:01 |
| plars | ogra_: we didn't have problems before when there was a default user, but it's not possible right now. The latest I've heard is that it should be possible soon with assertions, but no functioning example of how to do it yet | 16:02 |
| ogra_ | plars, well, you can definitely do some cloud-init stuff today ... so affectively you would push cloud-init user config to it | 16:02 |
| plars | ogra_: where does it read that from? can you give me an example or link to documentation on how it looks and how it uses it? | 16:03 |
| plars | that's the piece I'm missing at the moment | 16:03 |
| zyga | tyhicks: FI, I found the missing sort in process.py, the results are now stable | 16:03 |
| zyga | plars: we already can get user provisioned | 16:04 |
| zyga | not sure about network | 16:04 |
| ogra_ | plars, you would need to delete a file in /etc/cloud that by default disables cloud init today ... and tzhen just use the "normal" cloud-init configuration ... whatever that is | 16:04 |
| tyhicks | zyga: I've left my review of 169 | 16:04 |
| ogra_ | plars, in any xcase that will be possible via wifi SD | 16:05 |
| * zyga looks | 16:05 | |
| === chihchun is now known as chihchun_afk | ||
| plars | ogra_: where does it get that cloud init config from if I remove the disable file? | 16:06 |
| r2geo | hi all, can someone tell me where I can find the a stable image for RPi3? Is there an estimate when the RPi3 image may appear on http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ ? | 16:06 |
| zyga | tyhicks: I'll fix 169 and merge this into the other one so that the essential change is visible and accurate (the mountinfo contents) | 16:07 |
| ogra_ | plars, you dd ... then remount the SD so you have the new filesystem there ... then remove /etc/cloud/disable-cloud-init.foo (or however it is called) then put your cloud-init user config into /writable/system-files/var/cloud/foobar/whatever ... call sync ... re-power the board ... done | 16:08 |
| === rmescandon_ is now known as rmescandon | ||
| plars | ogra_: I'll give it a try, thanks | 16:08 |
| ogra_ | plars, everything from dd to sync in that line above would be in a simple shell script the SD card execs when you tell it to | 16:08 |
| plars | sure | 16:09 |
| ogra_ | so regarding the wifiSD it shouldnt matter how you provision, it wont care ... all it will be is a "wlan -> nc -> dd" bridge | 16:10 |
| ppisati_ | ogra_: mvo: a kernel with the fixed serial is being prepared this week | 16:10 |
| ppisati_ | it'll go out... | 16:11 |
| ppisati_ | last week of Oct | 16:11 |
| ogra_ | phew, thats late | 16:12 |
| mvo | ogra_, ppisati_: could we create our own kernel snap for pi3 with just this patch ? or is the amount of work too crazy? | 16:14 |
| mup | Bug #1632387 opened: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632387> | 16:15 |
| mup | Bug #1632388 opened: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632388> | 16:15 |
| ogra_ | mvo, filed ^^^ and added to the notes too | 16:15 |
| ogra_ | mvo, we surely could but thats likely a day of work or so | 16:15 |
| ogra_ | since i need to use proper debs here | 16:16 |
| ogra_ | mvo, so with these two drawbacks the pi3 is good as well | 16:16 |
| ppisati_ | ogra_: if you can build from ckt PPA, you can get it next week | 16:17 |
| ogra_ | i could set up a special build | 16:17 |
| ogra_ | mvo, ^^^ | 16:17 |
| ogra_ | so next week | 16:18 |
| mup | Bug #1632390 opened: "snap find" return unrelative snap <Snappy:New> <https://launchpad.net/bugs/1632390> | 16:18 |
| rvr | ogra_: http://paste.ubuntu.com/23308944/ | 16:27 |
| rvr | ogasawara: I reinstalled the image, the device has access to the internet, but snap install still doesn't work | 16:27 |
| rvr | Oops | 16:27 |
| rvr | ogra_: ^ | 16:27 |
| ogra_ | rvr, weird, it definitely worked here | 16:28 |
| rvr | ogra_: Also, there are suspicious messages in the syslog about dragonboard-kernel | 16:28 |
| ogra_ | (i have trashed the Sd now for pi3 testing) | 16:28 |
| rvr | ogra_: Yeah, fgimenez could also install it | 16:28 |
| ogra_ | smells like something went wrong with your initial setup | 16:29 |
| plars | hmm, I haven't tried it yet without removing that cloud-init.disabled, but after I removed it from my image and rebooted, it just gets stuck in a boot loop | 16:29 |
| plars | shows the 4 raspberries, black screen, repeat | 16:29 |
| ogra_ | plars, because you have no conbfig in place | 16:29 |
| plars | no other output... | 16:29 |
| ogra_ | cloud-init goes mad if you run it without any config | 16:30 |
| rvr | ogra_: Wifi and account setup went fine | 16:30 |
| plars | ogra_: I tried it with one, but perhaps I need it to have a different filename/path? I put a very basic one to just create the user in /writable/system-data/var/lib/cloud/cloud-init.conf | 16:30 |
| ogra_ | plars, yeah, there are special dirs underneath var/lib/cloud/ you need to use | 16:31 |
| * ogra_ forgot the exact bits | 16:31 | |
| ogra_ | plars, if you have access to some 15.04 image, that should have everything ... we used to use this for sertting up the ubuntu user | 16:31 |
| plars | ogra_: I'll see if I can find one somewhere | 16:32 |
| ogra_ | for series 16 there will be some additional changes to make it actuall yuse snap create-user ... but for a first smoke test the old 15.04 stuff should suffice | 16:32 |
| ogra_ | rvr, did your board not reboot after creating the user ? i think fgimenez and me both had that issue ... perhaps that fixes something you dont have gotten fixed then | 16:33 |
| rvr | ogra_: Right, no reboot | 16:34 |
| zyga | tyhicks: how are you doing on that other branch? | 16:34 |
| rvr | ogra_: I'll try that | 16:34 |
| ogra_ | rvr, and that is mvo's beta3 test image ? | 16:34 |
| ogra_ | or are you on one of my dailies | 16:35 |
| rvr | ogra_: untested | 16:35 |
| ogra_ | ok. same here | 16:35 |
| fgimenez | ogra_, rvr all the beta3 images are affected, there's a fix for it that hasn't landed yet | 16:35 |
| ogra_ | then i dont really know whats different | 16:36 |
| ogra_ | fgimenez, i dont see any reboots on the pi's | 16:36 |
| tyhicks | zyga: haven't made much progress just yet and I am about to have to step away for a short appointment | 16:36 |
| tyhicks | zyga: it'll be my top priority after I return | 16:36 |
| zyga | tyhicks: do you mind if I rebase it to clean up the spread test? | 16:37 |
| zyga | tyhicks: no changes to any of the c code | 16:37 |
| fgimenez | ogra_, i found the issue on the pi3, all the images are affected afaik, maybe you didn't wait enough | 16:37 |
| tyhicks | zyga: now would be a great time for that | 16:37 |
| zyga | tyhicks: thanks, I'll do that then | 16:37 |
| zyga | tyhicks: when will you get back? | 16:37 |
| tyhicks | zyga: about an hour from now | 16:38 |
| ogra_ | fgimenez, well, i just finished a pi3 (wired network, hdmi/usb kbd with the uart fix in config.txt) ... no reboot at all and works just fine | 16:38 |
| zyga | ah, ok, I _might_ be around still | 16:38 |
| zyga | though 1:38 AM now ;-) | 16:38 |
| plars | ogra_: no luck - I copied over the user-data file from an old image to the same path on my sd, and I still get the reboot loop. Maybe fgimenez has tried this? | 16:38 |
| ogra_ | plars, well, there might be bugs :) | 16:39 |
| ogra_ | i just know how it is supposed to work | 16:39 |
| ogra_ | and my wifiSd setup will still take a while til it is ready, so we have time | 16:39 |
| ogra_ | (to fix the bugs) | 16:39 |
| ogra_ | plars, iirc there were two dirs and two files in 15.40 | 16:40 |
| ogra_ | *04 | 16:40 |
| ogra_ | did you copy both ? | 16:40 |
| plars | ogra_: yes, the meta-data one was the same as I already have thre | 16:40 |
| plars | *there | 16:40 |
| ogra_ | one for user and one for system stuff | 16:40 |
| ogra_ | ah, k | 16:40 |
| fgimenez | ogra_, mmm i see it happening on the untested image, sometimes during console-conf, sometimes after, but the issue is there, after the first reboot all goes fine | 16:41 |
| plars | ogra_: This was the path and contents of the user-data one: https://www.irccloud.com/pastebin/3AZ5Etxv/ | 16:41 |
| ogra_ | plars, could you try a daily image instead ? that you see nothing but berries is definitely also wrong ... we fixed that a while ago in the dailies and about 2h ado in the beta candidates | 16:41 |
| rvr | Argh | 16:41 |
| rvr | Same after reboot | 16:41 |
| rvr | error: cannot install "classic": snap not found | 16:41 |
| fgimenez | ogra_, this PR fixes the problem https://github.com/snapcore/snapd/pull/2117 | 16:42 |
| mup | PR snapd#2117: snapstate: avoid reboots if nothing in the boot setup has changed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2117> | 16:42 |
| === Mikaela is now known as Mikaela_ | ||
| plars | ogra_: ah, that could be then... let me re-download. I grabbed it from here, but it looks like the pi3 image is gone (and no db410c yet too): http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ | 16:42 |
| plars | ogra_: so there's no new daily yet? | 16:43 |
| ogra_ | plars, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 16:43 |
| ogra_ | every day :) | 16:43 |
| plars | oh nice! | 16:43 |
| === Mikaela_ is now known as Mikaela | ||
| ogra_ | fgimenez, right ... but that only causes a normal reboot with the "system will reboot in 10 min" warning on the console ... the reboot in console-conf when creation the user looks more like a crash | 16:45 |
| ogra_ | *creating | 16:45 |
| fgimenez | ogra_, yes, it's the same issue | 16:45 |
| ogra_ | fgimenez, why did i get the notification after the dragonbaord was set up then ? | 16:47 |
| ogra_ | (i.e. after the reboot that happened in the middle of console-conf) | 16:48 |
| ogra_ | i dont think they are the same ... | 16:49 |
| fgimenez | ogra_, not sure, i'm having a lot of unrelated reboots in dragonboard, something different is happening there | 16:49 |
| ogra_ | (but it is moot anyway, teh fix will land andd we'll see if console-conf will work then) | 16:49 |
| ogra_ | i did two installs and only had one reboot in each of them when console-conf ran snap create-user ... reliable and reproducable in both tests i did | 16:50 |
| ogra_ | i didnt use the first one long enough to know if i also had the 10min waring then ... i definitely had it on the second install though | 16:51 |
| ogra_ | fgimenez, do you run your board with the mezzanine board attached ? | 16:51 |
| ogra_ | (i do) | 16:51 |
| ogra_ | prehaps that has some influence | 16:51 |
| fgimenez | ogra_, on dragonboard i have the firstboot reboot as in the rest of images and then a lot more of them | 16:52 |
| ogra_ | weird | 16:52 |
| fgimenez | while executing the suite | 16:52 |
| rvr | ogra_: fgimenez: Could my U1 account be misconfigured? | 16:52 |
| ogra_ | rvr, how would that be misconfigured ? if you have an ssh key it will download it | 16:53 |
| lucacome | hello | 16:53 |
| fgimenez | ogra_, no mezzanine here, looks nice :) | 16:53 |
| rvr | ogra_: Well, I'm trying to guess why snap install works for you and not for me | 16:53 |
| lucacome | do you know if there are any statistics about the adoption of snap? | 16:53 |
| ogra_ | fgimenez, aha ... we default to serial console only on the dragonboard currently ... i bet you have more instability because it tries to write console stuff to serial | 16:54 |
| fgimenez | ogra_, well only the uart to usb adapter card | 16:54 |
| ogra_ | that *is* the mezzanine board ;) | 16:54 |
| fgimenez | ogra_, aha! then yes :) | 16:54 |
| ogra_ | http://www.96boards.org/products/mezzanine/ | 16:55 |
| fgimenez | i thought you were talking about this http://www.96boards.org/products/mezzanine/linksprite-7-display-kit/ | 16:55 |
| ogra_ | http://www.96boards.org/products/mezzanine/uarts/ | 16:55 |
| fgimenez | yep that's it | 16:56 |
| ogra_ | right | 16:56 |
| ogra_ | ok, so it isnt that | 16:56 |
| ogra_ | sad, i had some hope :P | 16:56 |
| rvr | I have an UART to USB adapter, for programming atmel chips | 16:57 |
| rvr | I guess it can be used with the Dragonboard connecting the correct pins | 16:58 |
| plars | ogra_: I can't seem to open the writable partition from your image directly, not even after I write it to the sd. Maybe that's something to do with the resize? | 16:59 |
| ogra_ | plars, nope ... there is still some wiggle room | 16:59 |
| plars | ogra_: [1951890.585324] EXT4-fs (dm-1): bad geometry: block count 118499 exceeds size of device (118272 blocks) | 16:59 |
| ogra_ | you should be able to write a few mb | 16:59 |
| ogra_ | "exceeds size of device" ?!? | 17:00 |
| ogra_ | what size is that SD = | 17:00 |
| ogra_ | ? | 17:00 |
| plars | similarly, when I try to do it with the sd: [1951839.136126] EXT4-fs (mmcblk0p2): bad geometry: block count 118499 exceeds size of device (118272 blocks) | 17:00 |
| plars | ogra_: the first one was just trying to open the raw image file after running it through kpartx | 17:00 |
| plars | ogra_: the second was after writing it to an 8GB sd | 17:01 |
| fgimenez | rvr, at last i'm getting the same error installing classic on dragonboard, it seems that the error comes from the store http://paste.ubuntu.com/23309074/ | 17:03 |
| rvr | fgimenez: !!!! | 17:04 |
| rvr | So at the end, I am not mad ;) | 17:05 |
| rvr | Although I was getting mad! | 17:05 |
| ogra_ | plars, works fine here ... i can plug the SD in and nautilus auto-mounts the partitions | 17:05 |
| plars | ogra_: strange - is that with the pi3 image? | 17:05 |
| ogra_ | plars, with all images ... | 17:05 |
| ogra_ | the geometry is indeed wrong, but it should still be mountable | 17:06 |
| plars | mine doesn't mount... extraction went ok but I didn't check the checksum. Let me retry downloading. I'll grab another one too as a sanity check | 17:07 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/ | 17:08 |
| ogra_ | system-boot writable | 17:08 |
| ogra_ | this i get when re-plugging the SD after dd'ing it | 17:08 |
| rvr | fgimenez: Who do manage the store? | 17:09 |
| ogra_ | why does it work for me then ... very weird | 17:09 |
| rvr | fgimenez: Ok, snap install works with ubuntu-snappy/16.04/current/ | 17:11 |
| ogra_ | are both of you using --devmode --edge ? | 17:11 |
| rvr | ogra_: I just installed hello world in Dragonboard with that image | 17:11 |
| rvr | No devmode nor edge | 17:11 |
| rvr | But I couldn't do that with the untested image | 17:12 |
| ogra_ | you need it for classic | 17:12 |
| ogra_ | there is no stable classic package | 17:12 |
| ogra_ | (never has been) | 17:12 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ df -h /dev/sdc* | 17:12 |
| ogra_ | Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf | 17:12 |
| ogra_ | udev 7,8G 0 7,8G 0% /dev | 17:12 |
| ogra_ | /dev/sdc1 127M 22M 105M 17% /media/ogra/system-boot | 17:13 |
| ogra_ | /dev/sdc2 3,3G 313M 2,9G 10% /media/ogra/writabl | 17:13 |
| ogra_ | plars, ^^^ i just freshly dd'ed | 17:13 |
| ogra_ | re-plug .... and i get the above | 17:13 |
| fgimenez | ogra_, yes, that comes from the suite https://github.com/snapcore/snapd/blob/master/spread.yaml#L117 | 17:13 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ touch /media/ogra/writable/foo.txt | 17:14 |
| ogra_ | touch: '/media/ogra/writable/foo.txt' kann nicht berührt werden: Keine Berechtigung | 17:14 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ sudo touch /media/ogra/writable/foo.txt | 17:14 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ | 17:14 |
| ogra_ | plars, ^^^ | 17:14 |
| ogra_ | that works too | 17:14 |
| plars | ogra_: just re-downloaded, checking again now | 17:14 |
| ogra_ | fgimenez, are you sure prefixing the options is supposed to work ? | 17:14 |
| ogra_ | sudo snap install classic --devmode --edge | 17:15 |
| ogra_ | that is what i use all the time | 17:15 |
| pmcgowan | ogra_, hey do you know about the network bridges snapd sets up | 17:16 |
| rvr | classic (edge) 16.04 from 'canonical' installed | 17:16 |
| ogra_ | nope | 17:16 |
| rvr | So there is something wrong with the untested image and the store | 17:17 |
| ogra_ | pmcgowan, you mean netplan ? thats pitti-land | 17:17 |
| pmcgowan | ogra_, I see lxdbr0 | 17:17 |
| fgimenez | ogra_, yes, according to snap install --help the install options should go between "install" and the snap name | 17:17 |
| pmcgowan | its grabbing an address that is screwing me up I suspect | 17:17 |
| ogra_ | fgimenez, well, i always use it the other way around ... | 17:17 |
| ogra_ | and it works here | 17:17 |
| fgimenez | ogra_, good to know that works too :) | 17:18 |
| * ogra_ dd's another dragon image to verify ... cant be that everything works for me but doesnt for you guys | 17:18 | |
| ogra_ | are we actually using the same image ? | 17:18 |
| ogra_ | :P | 17:18 |
| ogra_ | pmcgowan, well, i'm pretty sure snapd doesnt set up any lxc network devices | 17:19 |
| rvr | The untested one, Oct 7th | 17:19 |
| ogra_ | pmcgowan, unless you install an lxc snap or use snapcraft cleanbuild there is nothiong that involves lxc/d in snappy | 17:20 |
| ogra_ | rvr, yes | 17:20 |
| pmcgowan | ogra_, ok somethig else then | 17:20 |
| plars | ogra_: ok, it seems I'm able to mount the dragonboard one, but not the pi3 one | 17:23 |
| ogra_ | plars, well, all the above was pi3 | 17:23 |
| plars | ogra_: weird | 17:23 |
| ogra_ | plars, else it would have been sdc8 and 9 | 17:24 |
| plars | Yeah | 17:24 |
| ogra_ | ogra@localhost:~$ sudo snap install classic --devmode --edge | 17:26 |
| ogra_ | classic (edge) 16.04 from 'canonical' installed | 17:26 |
| ogra_ | ogra@localhost:~$ | 17:26 |
| ogra_ | fginther, rvr ^^^ i'm looged in for the first time ... | 17:26 |
| ogra_ | ogra@localhost:~$ uname -a | 17:26 |
| ogra_ | Linux localhost.localdomain 4.4.0-1024-snapdragon #27-Ubuntu SMP Fri Aug 12 11:45:29 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux | 17:26 |
| ogra_ | ogra@localhost:~$ | 17:26 |
| ogra_ | no issues at all with classic | 17:26 |
| ogra_ | i dont get it ... | 17:27 |
| rvr | :-/ | 17:27 |
| ogra_ | ogra@localhost:~$ snap list | 17:28 |
| ogra_ | Name Version Rev Developer Notes | 17:28 |
| ogra_ | classic 16.04 17 canonical devmode | 17:28 |
| ogra_ | core 16.04.1 74 canonical - | 17:28 |
| ogra_ | dragonboard 16.04-0.17 23 canonical - | 17:28 |
| ogra_ | dragonboard-kernel 4.4.0-1024-3 9 canonical - | 17:28 |
| ogra_ | snapweb 0.21 17 canonical - | 17:28 |
| ogra_ | ogra@localhost:~$ | 17:28 |
| ogra_ | do your versions match ? | 17:28 |
| rvr | I don't get any list | 17:28 |
| ogra_ | ( core 74 specifically ) | 17:28 |
| ogra_ | so weird | 17:28 |
| ogra_ | as if we had different boards | 17:28 |
| ogra_ | (or different images) | 17:29 |
| zyga | ha | 17:33 |
| zyga | found it | 17:33 |
| zyga | damn, that was silly | 17:33 |
| zyga | I should sleep | 17:34 |
| ogra_ | silly is the new clever i heard | 17:34 |
| ogra_ | ;) | 17:34 |
| zyga | hehehe | 17:34 |
| zyga | well, clever is the "has regular sleeping patterns" thing | 17:35 |
| ogra_ | sleeping is for the week^Wweak | 17:38 |
| ogra_ | (or so) | 17:39 |
| mup | Bug #1632085 changed: Support "fudge factor" for file system sizing <Ubuntu Image:In Progress by barry> <https://launchpad.net/bugs/1632085> | 17:51 |
| plars | ogra_: tried the cloud-init bits on dragonboard, it boots at least, but no network, no user - still wants manual config :( | 18:07 |
| plars | nothing in cloud-init.log too | 18:09 |
| tyhicks | zyga: I'm back and can start looking at 168 again - are you close to pushing the rebased version? | 18:09 |
| zyga | tyhicks: yes, but don't worry, just keep on reading and commenting | 18:11 |
| zyga | tyhicks: I'll merge | 18:11 |
| zyga | tyhicks: I was just not sorting the stuff correctly and I cannot imagine it even worked at all | 18:11 |
| kyrofa | zyga, why are you here? | 18:16 |
| zyga | kyrofa: well, you know me | 18:18 |
| zyga | kyrofa: but I had a great day | 18:18 |
| kyrofa | zyga, tsk tsk | 18:18 |
| kyrofa | zyga, manage to avoid more meetings? | 18:18 |
| zyga | kyrofa: and I just love the feeling when something works well | 18:18 |
| zyga | kyrofa: I will just smile and say I was far away from other people ;) | 18:18 |
| kyrofa | zyga, good ;) | 18:18 |
| zyga | kyrofa: this place is amazing | 18:18 |
| zyga | kyrofa: I found so many cool things today | 18:19 |
| kyrofa | zyga, does your new hotel have that soup? | 18:19 |
| zyga | kyrofa: soup? | 18:19 |
| zyga | kyrofa: which one? | 18:19 |
| kyrofa | That one you like for breakfast | 18:19 |
| zyga | kyrofa: this place has no food, I moved to the old town, there are restaurants like *everywhere* here | 18:20 |
| kyrofa | Ah, that sounds _great_ | 18:20 |
| zyga | kyrofa: I did't try the breakfast here yet, I had onigiri for breakfast | 18:20 |
| * zyga googles to check if he rememebers the name right | 18:20 | |
| zyga | yep | 18:20 |
| zyga | I don't remember the korean name though | 18:20 |
| kyrofa | Ah, nice | 18:21 |
| zyga | this hotel is so not enterprise level though :) the room is the size of the bed in the other one :) | 18:21 |
| zyga | but it's fun, the owner even learned some polish today to surprise me | 18:22 |
| zyga | tyhicks: I just pushed to https://github.com/snapcore/snap-confine/pull/169/files | 18:45 |
| mup | PR snap-confine#169: Add spread tests for mount namespace layout <Created by zyga> <https://github.com/snapcore/snap-confine/pull/169> | 18:45 |
| zyga | tyhicks: I'll merge this into the other branch and resolve conflicts | 18:45 |
| zyga | tyhicks: how do you feel about the 2nd branch? | 18:45 |
| tyhicks | zyga: still processing it - this is a lot of change to the most complex part of the project :) | 18:47 |
| tyhicks | zyga: no deal breakers yet | 18:47 |
| zyga | tyhicks: fingers crossed then, thank you for working on this! | 18:49 |
| tyhicks | zyga: np - nice job on getting something working | 18:49 |
| tyhicks | zyga: do you have a link to that doc that you wrote up before starting to implement this? | 18:51 |
| zyga | yeah, give me a second | 18:52 |
| zyga | there's one thing I didn't comment on that's somewhat bad | 18:53 |
| zyga | bootstrap pollutes the main NS if it dies mid-way | 18:53 |
| zyga | I was looking for ways to avoid that but I don't think this is possible | 18:53 |
| zyga | there might be a way to detect abnormal termination and use a child to help clean up but this is imperfect | 18:54 |
| zyga | tyhicks: I think there was no doc this time, it was for the ns sharing but not for this | 18:56 |
| zyga | tyhicks: we had a pastebin and a shell prototype | 18:56 |
| tyhicks | zyga: the main NS is only polluted due to /tmp/snap.rootfs_XXXXXX having mounts set up inside of it, correct? | 18:57 |
| tyhicks | zyga: ah, I must have gotten those two confused - thanks for looking | 18:57 |
| zyga | tyhicks: yes, that directory will still have some stale bits if we terminate abnormally | 18:58 |
| * tyhicks nods | 18:58 | |
| thomi | Thanks jdstrand, I'll try that. I must have missed it in the docs on snapcraft.io? | 19:12 |
| zyga | damn | 19:25 |
| zyga | well, just anoying | 19:25 |
| zyga | tyhicks: AFAIK I removed cgroups because they get mounted in unexpected order, so I was thinki that I should sort stuff so that I can do deterministic remapping but parts of the sorted strings are random | 19:26 |
| tyhicks | zyga: ok, skip cgroups for now | 19:26 |
| tyhicks | zyga: that is frustrating | 19:26 |
| zyga | I'll sort twice,first after partial derandomization (just paths) and then after everything else is derandomized | 19:27 |
| zyga | I'll just test this a few more times before I push it again, you really have to reboot the test machine to see this fail | 19:27 |
| kgunn | noise][ you about? | 19:33 |
| tyhicks | zyga: I've just submitted my review | 19:35 |
| kgunn | nessita_: or you about? | 19:35 |
| zyga | tyhicks: thank you, checking | 19:36 |
| pmcgowan | snapd wont run for me today, http://pastebin.ubuntu.com/23309681/ | 19:37 |
| * kyrofa needs a nap, back in a bit | 19:39 | |
| kgunn | nessita_: noise][ so i'll just leave my query here...long time ago :) i made "mir-server" namespace in the store... i suppose at the time i said amd64 for supported arch's | 19:39 |
| kgunn | i now have armhf and arm64 snaps available, is there any way to change the namespace to reflect this? so that i can upload these for folks? | 19:40 |
| pmcgowan | also seeing Oct 11 19:39:39 localhost snapd[3538]: error: cannot downgrade: snapd is too old for the current system state (patch level 4) | 19:40 |
| kgunn | ...at least, it's not obvious to me how i might do it looking at my options in myapps.developer.com | 19:40 |
| josepht | kgunn: have you tried to upload one of the new architecture's snaps? | 19:45 |
| kgunn | josepht: ironically...did just now....and i see it's saying arm64...so it's smart that way | 19:46 |
| kgunn | ? | 19:46 |
| josepht | kgunn: yes, that's been my experience. | 19:46 |
| kgunn | cool thanks josepht i was having nightmares thinking i was going to have to create a new store namespace just for arch support | 19:47 |
| josepht | kgunn: no problem | 19:48 |
| mup | Bug #1632452 opened: snappy store still indicates Martin Albisetti for publishing <Snappy:New> <https://launchpad.net/bugs/1632452> | 19:52 |
| mup | PR snapd#2133 closed: osutil: add missing unit tests for IsMounted <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2133> | 19:58 |
| mup | PR snapd#2127 closed: tests: add test for auto-mount assertion import <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2127> | 20:05 |
| mup | PR snapd#2126 closed: tests: add spread test for `snap auto-import` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2126> | 20:07 |
| === nacc_ is now known as nacc | ||
| mup | PR snapd#2121 closed: cmd/snap: do not auto-import from loop or non-dev devices <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2121> | 20:50 |
| mup | PR snapd#2117 closed: snapstate: avoid reboots if nothing in the boot setup has changed <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2117> | 20:52 |
| mup | PR snapd#2119 closed: tests: abort tests if an update process is scheduled <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2119> | 20:53 |
| mup | PR snapd#2124 closed: daemon: add postCreateUserSuite test suite <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2124> | 20:55 |
| mup | PR snapd#2118 closed: overlord: merge overlord/boot pkg into overlord/devicestate <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2118> | 20:59 |
| mup | Bug #1632452 changed: snappy store still indicates Martin Albisetti for publishing <Software Center Agent:New> <https://launchpad.net/bugs/1632452> | 21:05 |
| mup | PR snapd#2134 opened: overlord/devicestate: recover/mark as seeded devices that were first booted with the old external approach <Created by pedronis> <https://github.com/snapcore/snapd/pull/2134> | 21:33 |
| benbro | any update on this? | 21:34 |
| benbro | https://bugs.launchpad.net/snappy/+bug/1584779 | 21:35 |
| mup | Bug #1584779: Upgrade a running snap without restarting it <Snappy:Confirmed> <https://launchpad.net/bugs/1584779> | 21:35 |
| mup | PR snapd#2135 opened: cmd/snap: simplify auto-import mountinfo parsing <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2135> | 21:49 |
| mup | PR snapd#2136 opened: tests/lib: prepare ubuntu-core with core from beta <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2136> | 22:09 |
| mup | PR snapd#2134 closed: overlord/devicestate: recover/mark as seeded devices that were first booted with the old external approach <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2134> | 22:21 |
| mup | Bug #1632508 opened: Get a way to differentiate uninstall/shutdown from snap update in stop script <lxd> <Snappy:New> <https://launchpad.net/bugs/1632508> | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!