| sergiusens | thanks ev, but you have static errors now :-) | 00:12 |
|---|---|---|
| ev | d'oh | 00:13 |
| ev | fixing | 00:13 |
| slangasek | ev: hey, so I mistakenly clicked the 'unpublish' button for pi2 (what I really wanted was to remove a particular revision from a channel), and I got a gateway timeout, and then when I hit reload I got an EPERM but it seems it actually did unpublish so that seems bad | 00:32 |
| mup | PR snapd#1818 opened: Fix documentation on price - it is a floating point number, not a string <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1818> | 00:33 |
| ev | slangasek: eep. Can I have a bug report? | 00:53 |
| slangasek | ev: where at? | 00:53 |
| ev | sergiusens: all good | 00:53 |
| ev | slangasek: https://bugs.launchpad.net/developer-portal/+filebug | 00:53 |
| slangasek | ev: https://bugs.launchpad.net/developer-portal/+bug/1619086 | 00:56 |
| mup | Bug #1619086: 'unpublish' throws errors, but actually worked <Developer registration portal:New> <https://launchpad.net/bugs/1619086> | 00:56 |
| ev | thank you | 00:56 |
| mup | PR snapd#1817 closed: Wrapper: create $SNAP_USER_COMMON (LP:#1611063) <Created by brunonova> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1817> | 01:01 |
| === petevg_ is now known as petevg | ||
| mup | PR snapd#1818 closed: Fix documentation on price - it is a floating point number, not a string <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1818> | 06:31 |
| === chihchun_afk is now known as chihchun | ||
| dholbach | hey hey | 06:56 |
| davidcalle | o/ | 07:22 |
| psivaa | dobey: re? | 07:39 |
| psivaa | dobey: sorry, re: tree, i did not have any issues installing. Let me try and dig more on that error | 07:40 |
| mup | PR snapd#1573 closed: asserts/tool,cmd/snap: introduce hidden "snap sign" <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1573> | 07:46 |
| dholbach | niemeyer, can you moderate the snapcraft list, I know of at least one good mail sitting in the queue :) | 07:48 |
| zyga | o/ | 08:00 |
| zyga | \o | 08:00 |
| zyga | \o/ :) | 08:00 |
| mwhudson | TIL: if you run /var/lib/classic/enable.sh before making your OS snap, snappy thinks you're on a classic system | 08:03 |
| mwhudson | is there an easy way to run kvm so you can see both serial and the vts? | 08:22 |
| mwhudson | oh -serial stdio | 08:23 |
| mvo | mwhudson: yeah | 08:24 |
| mvo | mwhudson: qemu is pretty fantasic, you can also run it as a nc/telnet capable service that you can connect to later, I pushed a branch for spread with that feature to allow easy inspection of boot failures | 08:25 |
| mwhudson | mvo: qemu's command line is one of those things i've been a bit afraid of for years, but i'm getting there :-) | 08:25 |
| mvo | mwhudson: ha! for totally good reasons, the functionality is awesome, the commandline … not so much | 08:29 |
| mwhudson | he's a strange systemd question | 08:37 |
| mwhudson | can a process find out if it is a main process for some systemd service? | 08:37 |
| kalikiana | best motivation to make a snap: qt update broke my irc | 08:41 |
| kalikiana | was done in 15min :-P | 08:42 |
| kalikiana | also, awesome to find that cleanbuild now can do remote parts | 08:42 |
| mup | PR snapd#1819 opened: snap: set user variables even if HOME is unset (like with systemd services) <Created by mvo5> <https://github.com/snapcore/snapd/pull/1819> | 08:43 |
| kalikiana | Hmm how do I launch a browser a la xdg-open from a confined snap? | 08:47 |
| morphis | mvo, ogra_: I've generated a new image for my pi3 yesterday with ubuntu-device-flash core 16 --channel edge -kernel pi2-kernel --gadget pi3 --os ubuntu-core -o test.img | 08:48 |
| morphis | mvo, ogra_: when I boot the resulting image now I get no snaps listed when calling snap list | 08:48 |
| morphis | where /snap/pi2-kernel/11/ is present | 08:48 |
| morphis | but no ubuntu-core snap inside /snap | 08:49 |
| mvo | morphis: what does snap changes tell you? | 08:49 |
| mvo | morphis: any error details there? also systemctl status snapd.firstboot | 08:49 |
| morphis | mvo: https://paste.ubuntu.com/23119389/ | 08:50 |
| morphis | https://paste.ubuntu.com/23119391/ | 08:50 |
| mup | PR snapd#1814 closed: client,cmd/snap: display os-release data only on classic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1814> | 08:56 |
| === Saviq_ is now known as Saviq | ||
| pitti | mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd → known? | 09:01 |
| ysionneau | hmm Snappy takes a very long time to boot when not connected to internet | 09:02 |
| zyga | kalikiana: you use xdg-open having snapd-xdg-open installed on your host | 09:02 |
| ysionneau | mostly because of [FAILED] Failed to start Wait for Network to be Configured. | 09:02 |
| ysionneau | is there a way to tell snappy to not wait for network to boot? | 09:02 |
| zyga | kalikiana: I believe there is an SRU for snapd-xdg-open into xenial, it is also slowly spreading into other distributions | 09:02 |
| ysionneau | ( https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html ) | 09:03 |
| zyga | mwhudson: hey, interesting, no idea really | 09:03 |
| zyga | kalikiana: the core snap should now have xdg-open executable that just talks to the service on the outside | 09:04 |
| kalikiana | zyga: Ah. So it should start working whenever that new package arrives? | 09:05 |
| mvo | pitti: yes, this is why I asked all those autopkgtest question :) | 09:05 |
| mvo | s | 09:05 |
| zyga | kalikiana: yes | 09:12 |
| zyga | kalikiana: I believe so, please have a look at https://github.com/snapcore/snapd-xdg-open/ | 09:12 |
| zyga | kalikiana: you can build and install that locally | 09:13 |
| zyga | kalikiana: and experiment with the special version of xdg-open available here: https://github.com/snapcore/snapd-xdg-open/blob/master/src/xdg-open.c | 09:13 |
| zyga | kalikiana: exectutable built from that file should be in the core snap, if not you can add it to your own snap for now) | 09:13 |
| zyga | jamiebennett: o/ | 09:14 |
| jamiebennett | zyga: o/ | 09:14 |
| mup | PR snapd#1820 opened: many: start services only after the snap is fully ready (link-snap was run) <Created by mvo5> <https://github.com/snapcore/snapd/pull/1820> | 09:15 |
| morphis | mvo: so really looks like something got broken with the firstboot scenario | 09:17 |
| morphis | mvo: want a bug for that? | 09:17 |
| mvo | morphis: its fine, I think this breaks our tests currently so I'm already on it | 09:19 |
| morphis | good :-) | 09:19 |
| mvo | morphis: very confusing that state.json is there, if you haven't done anything with the thing yet, could you paste that file? | 09:20 |
| mvo | morphis: but only if you haven't ran any command except snap changes | 09:20 |
| morphis | mvo: sure | 09:20 |
| morphis | mvo: https://paste.ubuntu.com/23119456/ | 09:20 |
| mvo | morphis: hm, interessting. looks like a race | 09:22 |
| morphis | :-) | 09:25 |
| mup | PR snapd#1821 opened: ensure snapd.refresh.service waits for snapd.firstboot.services <Created by mvo5> <https://github.com/snapcore/snapd/pull/1821> | 09:46 |
| mvo | morphis: -^ for you | 09:46 |
| === matteo` is now known as matteo | ||
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#1822 opened: snapd.refresh.service: require snap.socket and /snap/*/current <Created by stolowski> <https://github.com/snapcore/snapd/pull/1822> | 10:07 |
| ogra_ | ysionneau, this might be related to the new netplan network setup (before we covered for this case throughj /etc/network/interfaces.d options (iirc it was "allow-hotplug" and leave "auto" out so that link detection takes precedence)), probably pitti has an idea how the netplan setup now differs from this | 10:11 |
| pitti | ogra_: ah, so you want to mark some interfaces as "not relevant for booting" (allow-hotplug), so that network-online.target does not block on those? | 10:17 |
| pitti | ogra_: right, that's currently missing; bug report appreciated | 10:17 |
| mup | PR snapd#1823 opened: overlord/devicestate: try to fetch/refresh the signing key of serial (also in case is not there yett) <Created by pedronis> <https://github.com/snapcore/snapd/pull/1823> | 10:17 |
| ogra_ | pitti, well, we might have networkless drones that get occasionally connected to a cable for updates etc but are offiline most of the time ... or span up their own AP for a management app on a phone but for updates use ethernet ,... etc etc | 10:17 |
| ogra_ | pitti, i guess that also needs an option in console-conf ? | 10:19 |
| pitti | ogra_: enabling/disabling it globally is fairly easy; right now netplan always enables systemd-networkd-wait-online.service into wait-online.target, so that booting waits for all declared interfaces; if we want to globally disable that, this is simple | 10:20 |
| pitti | disabling it on a per-interface level is more involved, not sure if you need that | 10:20 |
| ogra_ | i guess thats a start ... long term per interface is likely needed | 10:20 |
| ogra_ | for such corner cases | 10:21 |
| pitti | ogra_: yeah, I think so; quite a lot of services start when network-online.target starts and assume that they can do network stuff; these would be broken wit that setup | 10:21 |
| pitti | but if you have done that until now with allow-hotplug, this won't change | 10:21 |
| ogra_ | mvo, do you remember why you created the pi2.moved dir in snappy-systems ? looks like thats a 15.04 setup, i guess i can wipe it ? | 10:27 |
| mvo | ogra_: yeah, kill it please | 10:27 |
| ogra_ | done | 10:28 |
| ppisati | so, this morning i created a fresh new amd64 img | 10:28 |
| ppisati | but when i try to install a kernel on it | 10:28 |
| ppisati | i got | 10:28 |
| ppisati | error: cannot find signatures with metadata for snap "foobar.snap" | 10:29 |
| ppisati | funny thing is that i installed a kernel yesterday on my rpi2 board | 10:29 |
| ppisati | so | 10:29 |
| ppisati | what am i doing wrong? | 10:29 |
| zyga | ppisati: I believe you are now seeing assertions in place | 10:35 |
| zyga | ppisati: is the foobar snap something you installed from the store? | 10:35 |
| ppisati | nope | 10:35 |
| ppisati | something i rolled | 10:35 |
| ppisati | is there a way to sideload a custom kernel/snap? | 10:35 |
| ppisati | or to turn off the assertions? | 10:35 |
| zyga | ppisati: yep, though I don't remember the option name, perhaps pedronis knows as he's working on that | 10:36 |
| ogra_ | would be bad if he wouldnt know it then ;) | 10:40 |
| mup | PR snapd#1824 opened: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1824> | 10:40 |
| === ant_ is now known as Guest4912 | ||
| ogra_ | mvo, do you happen to have commit access to ubuntu-image ? ( http://paste.ubuntu.com/23119768/ avoids the sudo calls if we are root already, should fix the snap issues) | 10:50 |
| pedronis | ppisati: you need to use --force-dangerous if that kernel is local | 10:52 |
| pedronis | and you don't have store assertions/signatures for it | 10:52 |
| ogra_ | uuuuh ! | 10:52 |
| ogra_ | "force dangerous" | 10:52 |
| ogra_ | that makes you feel like indiana jones ... :) ... adventures ;) | 10:52 |
| ppisati | use the force-dangeroues Luke! | 10:53 |
| pedronis | ogra_: it's quite new but that's what we discussed with Gustavo | 10:53 |
| ogra_ | :) | 10:53 |
| pedronis | ogra_: the issue is really that there are to cases, you are bing asked/tricked to install a random snap (the option should tell you maybe you need to know/trust what you are doing), you are installing a snap you just built | 10:54 |
| pedronis | and then it feels a bit silly | 10:54 |
| pedronis | s/to cases/two cases/ | 10:54 |
| ogra_ | yeah | 10:54 |
| ogra_ | i totally understand ... just found the option name funny :) | 10:54 |
| tvoss | sergiusens: o/ I'm trying to build a snapcraft package, latest and greatest from git, but package build fails with: http://pastebin.ubuntu.com/23119776/ | 10:55 |
| tvoss | sergiusens: is that known or "fails on your machine only"? :) | 10:55 |
| ogra_ | "root@" ?? | 10:56 |
| ogra_ | dont build snaps as root ... | 10:56 |
| mwhudson | uh oh i didn't realize switching to netplan implied waiting for network | 10:56 |
| mwhudson | pitti: is this a new-ish feature in netplan or something? | 10:56 |
| mwhudson | i'm sure i wasn't seeing this behaviour a few days ago but i am now | 10:57 |
| morphis | mvo: thanks! | 10:57 |
| pitti | mwhudson: not really that new: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1613548 | 10:57 |
| mup | Bug #1613548: enable systemd-networkd-wait-online.service <nplan (Ubuntu):Fix Released by pitti> <https://launchpad.net/bugs/1613548> | 10:57 |
| pitti | mwhudson: since 0.7 (two weeks ago) | 10:58 |
| mwhudson | pitti: huh | 10:58 |
| mwhudson | oh man i'm amazed anything ever boots | 10:58 |
| pitti | i. e. currently it behaves like ifupdown's "auto", before 0.7 it always behaved like "allow-hotplug" | 10:59 |
| mwhudson | what is it that's waiting for network-online though? | 11:00 |
| mwhudson | oh sorry never mind i need to sleep | 11:00 |
| pitti | mwhudson: not sure, a few services wait for it (or network mounts) | 11:01 |
| pitti | mwhudson: but most service indeed aren't blocking on this, so not sure what's actually blocking | 11:01 |
| === hikiko|ln is now known as hikiko | ||
| pitti | mwhudson: on my system: lxd.service, rc-local.service, kerneloops; none of those are critical | 11:02 |
| mwhudson | pitti: ah, it's ubuntu-fan.service here i think | 11:06 |
| mwhudson | here as in "on my snappy image" | 11:06 |
| mwhudson | oh yeah and rc.local.service | 11:07 |
| ogra_ | mwhudson, bug #1619245 for your enjoyment ... | 11:10 |
| mup | Bug #1619245: console-conf does not allow to create a user for offline devices <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1619245> | 11:10 |
| ogra_ | (since i noticed there was no bug for that yet) | 11:10 |
| mwhudson | ogra_: fair enough, can you get someone with some architectural-level view to say how that should work? | 11:11 |
| mup | Bug #1619245 opened: console-conf does not allow to create a user for offline devices <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1619245> | 11:11 |
| ogra_ | heh, i'll try to catch niemeyer today | 11:11 |
| jamiebennett | ogra_: That bug doesn't look good. | 11:23 |
| ogra_ | nope | 11:23 |
| ogra_ | pedronis, uuuh, i just noticed that in classic i get the same issue when tyring to install a local snap ... is that wanted ? | 11:24 |
| pedronis | ? | 11:24 |
| pedronis | it's for all snap install *.snap | 11:24 |
| ogra_ | ogra@styx:~/Devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5_amd64.snap --devmode | 11:24 |
| ogra_ | error: cannot find signatures with metadata for snap "ubuntu-image_0.5_amd64.snap" | 11:24 |
| ogra_ | ogra@styx:~/Devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5_amd64.snap --devmode --force-dangerous | 11:24 |
| ogra_ | ubuntu-image 0.5 installed | 11:24 |
| ogra_ | ah | 11:24 |
| ogra_ | i thought only for the ones the system marks un-upgradeable in the images | 11:25 |
| ogra_ | s/un-upgradeable/un-sideload-able/ | 11:25 |
| pedronis | ogra_: we are protecting from two things here | 11:25 |
| pedronis | a) the snap didn't go through the store validation (now containment should do its job but there are still potential issue with bugs that are more likely with a non validated snap) | 11:26 |
| pedronis | b) you will be mounting tha squashfs with the kernel | 11:27 |
| ogra_ | mvo, please try http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap ... should work even with the sudo issues | 11:27 |
| pedronis | so there are potential vulnerabilities that way | 11:27 |
| ogra_ | yeah ... but i already use --devmode in a local install anyway | 11:27 |
| pedronis | that means something else though | 11:28 |
| ogra_ | which means i know i'm installing something potentially insecure | 11:28 |
| pedronis | yea, maybe we should conflate devmode to mean that too | 11:28 |
| pedronis | but not sure | 11:28 |
| ogra_ | imho --devmode should just imply --force-dangerous when i do a local sideload | 11:28 |
| pedronis | it's a bit of Gustavo question that one | 11:28 |
| jamiebennett | ogra_: Seems others are having issues with this first boot experience, see the email from MikeB on the snapcraft list | 11:29 |
| jamiebennett | (this was with network though) | 11:29 |
| ogra_ | jamiebennett, that triggered my bug ... (i had discussed ityesterday with mwhudson and cyphermox already and they said they would discuss it internally, so i refrained from filing a bug ... seeing others have issues too got me to file it) | 11:30 |
| ogra_ | well, i guess he has network but no internet access in his case ... thats even more tricky | 11:30 |
| jamiebennett | ogra_: Yeah, I guess we will always come across people with no network or without a correctly configured UO account, in this case without a ssh key | 11:31 |
| ogra_ | right | 11:31 |
| jamiebennett | ogra_, mwhudson: Worth getting back to MikeB on the list | 11:31 |
| ogra_ | and we should have a fallback ... even if it is insecure and should probably print a warning | 11:31 |
| ogra_ | a typical case is an IoT device that brings up an AP so you can control it via a mobile app, but doesnt have any other connection to the internet | 11:32 |
| ogra_ | there you wouldnt set up any network, but would perhaps want a local user to snap install something | 11:33 |
| jamiebennett | ogra_: in that case only local sideloaded snaps should be allowed | 11:38 |
| ogra_ | well, that would be fine ... the issue is that you dont even get a login console | 11:38 |
| ogra_ | console-conf just hogs them all unless you can finish it once successfully | 11:39 |
| ogra_ | (though admittedly if there is no user at all you dont need a login console either) | 11:40 |
| jamiebennett | ogra_: so we need to teach console-conf to add local users it seems | 11:41 |
| ogra_ | yes | 11:41 |
| jamiebennett | It could use snap create-user but that expects a correctly configured UO account | 11:42 |
| ogra_ | pitti, bug 1619258 | 11:47 |
| mup | Bug #1619258: netplan should allow NICs to be disconnected and not stall the boot <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619258> | 11:47 |
| mup | Bug #1619258 opened: netplan should allow NICs to be disconnected and not stall the boot <Snappy:New> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1619258> | 11:47 |
| Son_Goku | morning | 11:53 |
| jamiebennett | Morning Son_Goku | 11:56 |
| jamiebennett | ogra_: Did you manage to test slangasek's pi2 image? | 11:56 |
| ogra_ | jamiebennett not yet ... in my TODO though ... | 11:58 |
| ogra_ | jamiebennett, i think he tested it locally on his pi2 though | 11:59 |
| junaidali | Hi everyone, I'm new to Snappy, can we install libvirt-bin in Snappy? | 12:00 |
| jamiebennett | ogra_: OK, let me know. I've just sent my Pi2 off to iahmad for testing | 12:00 |
| ogra_ | will do | 12:00 |
| jamiebennett | ogra_: and I believe slangasek said "It has not yet been tested on an actual RPi2" | 12:01 |
| * ogra_ waits for a free moment where he doesnt find bugs in 5min :P | 12:01 | |
| ogra_ | *5 bugs in | 12:01 |
| jamiebennett | ogra_: your a star :) | 12:02 |
| ogra_ | lol | 12:02 |
| la_juyis | jamiebennett: ogra_ are you talking about a new rpi2 image? | 12:03 |
| sergiusens | good morning | 12:03 |
| ogra_ | la_juyis, yes | 12:03 |
| jamiebennett | gm sergiusens | 12:03 |
| la_juyis | i was trying the classic offered in our site but aftr upgrading it didn't have network interfaces :D | 12:03 |
| la_juyis | well, not nicely named nework interfaces | 12:03 |
| ogra_ | la_juyis, well, not sure who maintains the classic pi images, try talking to foundations perhaps ? | 12:15 |
| ogra_ | (though most of them are on vacation this week apparently) | 12:15 |
| la_juyis | ogra_: thanks :) | 12:16 |
| ogra_ | pitti, did you see ysionneau's question on the ML ? | 12:18 |
| ogra_ | seems he sees the timing out network on boot when having two properly configured NICs (do they wrangle over the default route perhaps ? ) | 12:19 |
| pitti | I followed up on the bug | 12:27 |
| ogra_ | pitti, well, i think the thing he describes on the ML is another bug | 12:28 |
| pitti | ogra_: maybe bug 1618522? | 12:28 |
| mup | Bug #1618522: netplan does not generates .network files just for ethernet <nplan (Ubuntu):In Progress by pitti> <https://launchpad.net/bugs/1618522> | 12:28 |
| ogra_ | hmpf ... so building the pi2 image as slangasek describes explodes in snap prepare-image | 12:28 |
| pitti | ogra_: it seems we have a "match: *" with dhcp4 rule by default, which is rather demanding (we expect all existing interfaces to respond to DHCP4) | 12:29 |
| pitti | not a fan of this, this is a very strong assumption | 12:29 |
| ogra_ | yeah | 12:29 |
| pitti | anyway, I'm currently working on restricting this to ethernets, not wifis | 12:29 |
| ogra_ | i pointed him to your bug ... | 12:31 |
| ogra_ | lets see if he confirms | 12:31 |
| Son_Goku | zyga, hey | 12:36 |
| Son_Goku | have you tried the SELinux policy module with snapd on F24? | 12:37 |
| ogra_ | jamiebennett, so i'm not able to build the pi2 image at all :/ ... snap prepare-image seems to fail | 12:43 |
| ogra_ | mvo, any idea ? http://paste.ubuntu.com/23120037/ | 12:44 |
| ogra_ | subprocess.CalledProcessError: Command '['snap', 'prepare-image', '--channel=edge', 'amd64-generic-model.assertion', '/tmp/tmp77onoa5j/unpack']' returned non-zero exit status 1 | 12:44 |
| ogra_ | Crash in state machine | 12:44 |
| jamiebennett | ogra_: :( | 12:44 |
| === JanC is now known as Guest23252 | ||
| === JanC_ is now known as JanC | ||
| ogra_ | ogra@styx:~/Devel$ snap --version | 12:46 |
| ogra_ | snap 2.14.1+ppa214-1 | 12:46 |
| ogra_ | snapd 2.14.1+ppa214-1 | 12:46 |
| ogra_ | series 16 | 12:46 |
| ogra_ | ubuntu 16.04 | 12:46 |
| ogra_ | i should be on the latest snapd | 12:46 |
| ogra_ | mvo, did you manage to boot at least an amd64 image built by ubuntu-image yet ? | 12:47 |
| sborovkov | la_juyis: apt install network-manager and everything works fine... | 12:49 |
| mvo | ogra_: but cloud-init stuff is missing so its a bad experience | 12:53 |
| ogra_ | mvo, how did you build it at all ? | 12:53 |
| ogra_ | i cant mamange to even have snap prepare--image to create one | 12:53 |
| ogra_ | COMMAND FAILED: snap prepare-image --channel=edge pi2-model.assertion /tmp/tmpoyu83bsc/unpackerror: cannot decode model assertion "pi2-model.assertion": assertion: "sign-key-sha3-384" header is mandatory | 12:54 |
| ogra_ | same for amd64 | 12:54 |
| mvo | ogra_: try http://paste.ubuntu.com/23119360/ | 12:54 |
| ogra_ | hmm, more errros in slangasek's model assertion | 12:56 |
| ogra_ | wow, so after deleting like 10 extra lines it seems to do something now :) | 12:58 |
| ogra_ | (well, it sits there without any output) | 12:58 |
| mvo | ogra_: yes, I reported a bug about the long delay | 12:59 |
| mvo | ogra_: its snap prepare-image - which has a progress bar | 12:59 |
| mvo | ogra_: but u-i is eating it | 12:59 |
| ogra_ | well, some "what am i doing" output would be helpful :) | 12:59 |
| mvo | ogra_: I also pushed a branch with tweaks | 12:59 |
| ogra_ | ah | 12:59 |
| mvo | ogra_: yeah, reported a bug about htis | 12:59 |
| mvo | this | 12:59 |
| ogra_ | ok, i got an img | 12:59 |
| mvo | ogra_: https://github.com/snapcore/snapd/pull/1824 is something I want - u-i for our tests | 13:00 |
| mup | PR snapd#1824: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1824> | 13:00 |
| mvo | ogra_: but not quite working yet, but close | 13:00 |
| ogra_ | lets see ogra@styx:~/Devel$ kvm -m 512 -redir :8022::22 images/snappy/u-i-amd64.img | 13:00 |
| ogra_ | qemu-system-x86_64: -redir :8022::22: Could not open 'images/snappy/u-i-amd64.img': Permission denied | 13:00 |
| ogra_ | ogra@styx:~/Devel$ ls -l images/snappy/u-i-amd64.img | 13:00 |
| ogra_ | -rw-r--r-- 1 root root 4000000000 Sep 1 14:59 images/snappy/u-i-amd64.img | 13:00 |
| ogra_ | wow | 13:00 |
| ogra_ | ok, boots after chowning it to ogra | 13:01 |
| ogra_ | hmm, or not | 13:02 |
| ogra_ | hangs now | 13:02 |
| ogra_ | now cloud-init goes mad | 13:03 |
| ogra_ | (trying to connect to some http service even though console-conf didnt run/start yet to actually configure the network) | 13:04 |
| ogra_ | i also see a lot kernel complaints about /dev/fd0 ... i guess we should blacklist the floppy module | 13:05 |
| mvo | ogra_: yeah, cloud-init is going wild | 13:08 |
| mvo | ogra_: in a meeting right now, later | 13:08 |
| ogra_ | mvo, btw, did you see my ping about the ubuntu-image snap above | 13:08 |
| mvo | ogra_: not really, | 13:08 |
| ogra_ | seems to work fine here | 13:08 |
| mvo | ogra_: cool, I pushed some updates fwiw | 13:09 |
| mvo | ogra_: all based on my branch | 13:09 |
| ogra_ | yeah, i have a patch to work around the sudo bits | 13:09 |
| ogra_ | applied to your PR and then just snapcrafted :) | 13:09 |
| mvo | ogra_: nice | 13:10 |
| ogra_ | http://paste.ubuntu.com/23119768/ | 13:10 |
| ogra_ | something in ubuntu-image is actually bringing my machine onto its knees though ... during the last seconds the system goes completely unresponsive | 13:13 |
| sborovkov | Hello. What does this error even mean? [Errno 17] File exists: '../tmp/log' -> '/home/kami/build/snaps/full/parts/gstreamer/install/rootfs/dev/log' During snap build. All I do for this part is copying of 1 file with organize gstomx.conf: viewer/usr/share/gst-omx/ | 13:13 |
| ogra_ | (when building an image) | 13:13 |
| * ogra_ takes a break | 13:20 | |
| ogra_ | oooh ! | 13:34 |
| ogra_ | waiting til cloud-init dies helps ...just takes 10min | 13:34 |
| * ogra_ is logged in to his amd64 image built via ubuntu-image | 13:35 | |
| ogra_ | \o/ | 13:35 |
| jamiebennett | ogra_: ouch | 13:48 |
| jamiebennett | ogra_: 10min + boot sounds bad ;) | 13:48 |
| ogra_ | well, thats how we know and love cloud-init :P | 13:48 |
| ogra_ | (nah, i'm not bitter, i always taste like that :P = | 13:49 |
| ogra_ | ) | 13:49 |
| mvo | ogra_: misfeature in ubuntu-image, we really need a way to feed a inital configuraiton, i.e. a way to tell it to not look for remote cloud config | 13:55 |
| ogra_ | yeah | 13:55 |
| ogra_ | well,i'm happy it eventually boots | 13:56 |
| === drizztbsd is now known as timothy | ||
| ogra_ | hmpf | 13:59 |
| ogra_ | booting isnt enough though | 13:59 |
| ogra_ | i end up without resolver ... | 13:59 |
| ogra_ | ogra@localhost:~$ sudo snap install htop | 13:59 |
| ogra_ | error: cannot install "htop": Get https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=stable&confinement=strict: dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:56040->[::1]:53: read: connection refused | 13:59 |
| ogra_ | ogra@localhost: | 13:59 |
| ogra_ | ogra@localhost:~$ ping web.de | 14:00 |
| ogra_ | ping: unknown host web.de | 14:00 |
| ogra_ | didnt we have some cdmline option that prevented cloud-init from doing network stuff at all ? | 14:00 |
| ogra_ | or some u-d-f thing that put it in place in /var/lib/cloud | 14:01 |
| * ogra_ seems to remember something like that | 14:01 | |
| ogra_ | yeah, chacking /var/lib/cloud/data it definitely is different | 14:02 |
| ogra_ | err | 14:03 |
| ogra_ | s/data/seed/ | 14:03 |
| ogra_ | ogra@pi3:~$ cat /var/lib/cloud/seed/nocloud-net/meta-data | 14:03 |
| ogra_ | instance-id: nocloud-static | 14:03 |
| ogra_ | this is what we're missing | 14:04 |
| mvo | ogra_: yeah, there is some stuff stuff my branch | 14:05 |
| ogra_ | i think thats the only thing actually ... the other bit we put in place is uder-data which we wont need anymore | 14:06 |
| ogra_ | thanks to console-conf | 14:06 |
| ogra_ | wow ... and i thought after one successfull boot cloud--init wouldnt kick in anymore ... seems i was wrong | 14:08 |
| * ogra_ twiddles thumbs | 14:08 | |
| rharper | attempting to build a core image with ubuntu-device flash using an updated os-snap I built, I'm getting an error: mkdir /tmp/diskimage470593504/system/var/lib/cloud: read-only file system -- any pointers? | 14:11 |
| rharper | http://paste.ubuntu.com/23120293/ is my u-d-f command | 14:12 |
| ogra_ | rharper, --kernel pc-kernel | 14:14 |
| rharper | ok | 14:15 |
| ogra_ | (else you install the gadget as kernel :) ) | 14:15 |
| mvo | ogra_: trying to replace u-d-f with u-i in our tests, I'm in a world of pain currently | 14:15 |
| rharper | ogra_: thanks for that; I get the same error though; let me try in a clean Xenial vm | 14:17 |
| mup | PR snapd#1799 closed: asserts,cmd/snap: add "name" header to account-key(-request) <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1799> | 14:17 |
| ogra_ | no idea about the error though ... | 14:19 |
| ogra_ | mvo, i can imagine | 14:19 |
| ogra_ | damn ... i know i filed a bug once about the pre-creation of the cloud-init data | 14:20 |
| ogra_ | i cant find it | 14:20 |
| ogra_ | i was listing the exact files and their content | 14:20 |
| mvo | arges: hey, feedback for your branch :) | 14:22 |
| mvo | arges: I'm still keen to land it, delayed the sru for a bit | 14:23 |
| ogra_ | there we go | 14:23 |
| ogra_ | bug 1485306 | 14:23 |
| mup | Bug #1485306: ubuntu-device-flash should not create data in writable partition <Snappy:Invalid> <https://launchpad.net/bugs/1485306> | 14:23 |
| ogra_ | damn ... and it doesnt have the content either | 14:24 |
| ogra_ | hah | 14:25 |
| mvo | ogra_: what are you looking for? | 14:25 |
| ogra_ | but putting both files in place makes it boot in seconds again | 14:25 |
| ogra_ | mvo, getting rid of the cloud-init mess | 14:25 |
| ogra_ | i have a 20sec boot again now | 14:25 |
| ogra_ | http://paste.ubuntu.com/23120339/ | 14:26 |
| mvo | ogra_: https://github.com/snapcore/snapd/pull/1824/files#diff-556bb7431481e375713ea3e0883a771aR127 | 14:26 |
| mup | PR snapd#1824: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1824> | 14:26 |
| ogra_ | when i turn off the ubuntu user stuff it doesnt work though | 14:26 |
| ogra_ | i'd really like to get rid of this | 14:26 |
| mvo | ogra_: fwiw, slangasek mentioned that cyphermox will work on a option for ubuntu-image to copy these files in place | 14:26 |
| ogra_ | (oh how i wish we could just unseed cloud-init :/ ) | 14:26 |
| mvo | ogra_: oh, meh :( | 14:26 |
| ogra_ | mvo, well, cyphermox is off til next week too | 14:27 |
| mvo | ogra_: what happens if you turn off the ubuntu user? | 14:27 |
| mvo | ogra_: meh, ok | 14:27 |
| ogra_ | it does the 10min boot again | 14:27 |
| nessita | ogra_, hi! I read your response, when you have some time would you please let me know so we can find alternatives for you? | 14:27 |
| ogra_ | let me try to drop sigle lines from user-data | 14:27 |
| rharper | cloud-init is searching for user-data, including nocloud seed gives it a source and to moves on; | 14:28 |
| ogra_ | nessita, well, its not only me, i guess mvo would also like to be able to look up which revisions he released to stable :) | 14:28 |
| arges | mvo: ok no problem, yea looking at the comments now | 14:28 |
| ogra_ | rharper, so just the existence of the file shoould be enough ? | 14:28 |
| rharper | ogra_: you may only need the meta-data file | 14:28 |
| ogra_ | well, that definitely didnt work | 14:29 |
| mvo | ogra_: I use pen and paper for this | 14:29 |
| ogra_ | mvo, lol ! | 14:29 |
| mvo | (SCNR) | 14:29 |
| rharper | ogra_: it needs a meta-data file to declare the instances; it may need the user-data file as well (but empty) | 14:29 |
| ogra_ | mvo, living in the future, eh ? | 14:29 |
| cyphermox | ogra_: how am I off till next week? | 14:29 |
| ogra_ | cyphermox, oh, you arent ? i thought everyone working on u-image was | 14:29 |
| cyphermox | thanks for giving me some extra vacation, good day! :D | 14:29 |
| ogra_ | sorry, then i missed something :) | 14:29 |
| ogra_ | haha | 14:29 |
| mvo | cyphermox: he said so! off you go :) | 14:29 |
| cyphermox | hehe | 14:29 |
| cyphermox | nah, I'm indeed doing this today | 14:30 |
| cyphermox | I would write an empty user-data I guess, so no ubuntu user by default? | 14:30 |
| mhall119 | zyga: ping, have you had a chance to finish reviewing my blog? | 14:30 |
| * ogra_ hugs rharper | 14:30 | |
| rharper | so the presence of 'passwd' triggers the creation | 14:31 |
| ogra_ | you are right ! an empty user-data is ennough | 14:31 |
| rharper | no ubuntu user is created by default but if you set the passwd, then that triggers the creation of the default user | 14:31 |
| rharper | ogra_: nice! | 14:31 |
| nessita | ogra_, we'll definitely fix the issue, but right-right now, it may take a few days | 14:31 |
| cyphermox | well, actually we still want the ssh settings I think | 14:31 |
| rharper | cyphermox: right | 14:31 |
| ogra_ | though i'm not sure if it works with a virgin image ... this one was configured now | 14:31 |
| nessita | ogra_, so until then we wanted to give you an alternative, like curling the results from the package index | 14:31 |
| cyphermox | rharper: what is the syntax if I want to create a user other than ubuntu? | 14:31 |
| nessita | ogra_, so what do you need to know? what revision is in the stable channel for each arch? | 14:32 |
| rharper | https://git.launchpad.net/cloud-init/tree/doc/examples/cloud-config-user-groups.txt | 14:32 |
| rharper | cyphermox: | 14:32 |
| ogra_ | cyphermox, do you actually want to ? you should only need proper host keys | 14:32 |
| rharper | and we need my branch/patch to enable use of --extrausers when running under snappy | 14:32 |
| rharper | which is what I'm trying to test right now =) | 14:32 |
| ogra_ | nessita, yeah, i guess that would be a good first step | 14:32 |
| cyphermox | ogra_: then at least ssh_genkeytypes: ['rsa', 'dsa', 'ecdsa', 'ed25519'] seems good. | 14:32 |
| ogra_ | yeah | 14:32 |
| cyphermox | maybe pwauth we don't need for the default images, but you'll probably want it for the testing | 14:33 |
| rharper | if you drop the user-data keys 'password' and 'chpasswd'; no user should be created | 14:33 |
| ogra_ | user wise you already get the key from SSO ... so only the host keys shoudl be needed | 14:33 |
| mup | PR snapcraft#752 closed: Ant properties, build target, and destination directory options <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/752> | 14:33 |
| cyphermox | ogra_: well, for testing I would expect you don't run console-conf ? | 14:33 |
| ogra_ | cyphermox, well, yes and no ... | 14:34 |
| mvo | slangasek: I also added a bug about that we need to be able to create local users via console-conf otherwise people are stuck when there is no network | 14:34 |
| nessita | ogra_, what package name? ubuntu-core? | 14:34 |
| ogra_ | i'd like to see console-conf to work with offline devices too | 14:34 |
| mvo | slangasek: (this came out of the team meeting today) | 14:34 |
| ogra_ | which means we'd need a fallback to actually create a local user anyway | 14:34 |
| mvo | is it just my or is myapps.developer.ubuntu.com not responding? | 14:34 |
| cyphermox | mvo: I know about that too, we should be able to fix that today hopefully | 14:34 |
| ogra_ | hah | 14:34 |
| ogra_ | *snap* | 14:34 |
| ogra_ | mvo, is faster than me | 14:34 |
| mvo | cyphermox: excllent | 14:34 |
| ogra_ | (and i wasnt even in that meeting :P ) | 14:35 |
| cyphermox | ie. there already existed code to do that, we just need to dig for the corpse and hook it up to the lightning rods. | 14:35 |
| ogra_ | nessita, currently only ubuntu-core, yeah | 14:35 |
| mvo | cyphermox: I have a slightly messy branch up for review that contains one important trunacte() vs dd fix, testing that right now | 14:35 |
| cyphermox | ok | 14:35 |
| mvo | cyphermox: sorry for the messyness, its a very busy world right now | 14:35 |
| cyphermox | yeah, I know | 14:35 |
| cyphermox | ubuntu-image got in my hands today as a rush rush rush job :) | 14:35 |
| ogra_ | mvo, mind adding http://paste.ubuntu.com/23119768/ to your snapcraft.yaml PR too ? then i dont need to crete an extra one | 14:36 |
| mvo | but *hopefully* with that branch we can kill u-d-f for our own tests | 14:36 |
| mvo | ogra_: I'm a bit confused about this one tbh, sudo should already do this, i.e. if sudo is run with uid=0 it will just do nothing, so I'm not sure how what it fixes | 14:36 |
| ogra_ | that makes ubuntu-image fully working as a snap | 14:37 |
| ogra_ | mvo, the issue is that you cant exec sudo from inside a snap | 14:37 |
| ogra_ | so sudo has no chance to fall back | 14:37 |
| ogra_ | when the snap binary is execed with uid 0 it should just not attempt sudo | 14:38 |
| ogra_ | (i know that could be coded cleaner though) | 14:38 |
| mvo | ogra_: aha, you installed this without --devmode? | 14:38 |
| ogra_ | but with that change i can use ubuntu-image as snap just fine | 14:38 |
| ogra_ | nope | 14:38 |
| ogra_ | with --devmode | 14:38 |
| rharper | can anyone else get to search.apps.ubuntu.com ? u-d-f queries that and is failing now for me | 14:38 |
| ogra_ | ogra@styx:~/Devel/branches$ snap list ubuntu-image | 14:39 |
| ogra_ | Name Version Rev Developer Notes | 14:39 |
| ogra_ | ubuntu-image 0.5 x1 devmode | 14:39 |
| ogra_ | thats what i'm using here | 14:39 |
| ogra_ | http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap | 14:39 |
| mvo | ogra_: hm, http://paste.ubuntu.com/23120379/ works for me | 14:39 |
| ogra_ | weird | 14:39 |
| mvo | ogra_: maybe somethng else? | 14:39 |
| ogra_ | yeah, strange | 14:40 |
| * mvo scratches head | 14:40 | |
| ogra_ | perhaps my patch isnt actually needed ... | 14:40 |
| ogra_ | did you try without it ... can you run it ? | 14:40 |
| mvo | ogra_: yes, as long as I run it via sudo | 14:40 |
| ogra_ | and if you dont it doesnt do the sudo call ? | 14:41 |
| ogra_ | (the in-code one) | 14:41 |
| ogra_ | well, then ignore my patch | 14:41 |
| mvo | ogra_: it does and the sudo calls fails with "can not get pty" | 14:41 |
| ogra_ | ah | 14:41 |
| ogra_ | the old buddy pty :) | 14:41 |
| ogra_ | well, then ignore my patch ... should be fine then | 14:42 |
| ogra_ | mvo, do you also see your machine grind to a halt at the end of image creation ? | 14:43 |
| ogra_ | i think there is still something worng in the final steps of ubuntu-image | 14:43 |
| mvo | ogra_: haven't seen that yet | 14:45 |
| ogra_ | must be my laptop then | 14:45 |
| ogra_ | strange | 14:45 |
| ogra_ | reproducable though | 14:46 |
| mvo | ogra_: maybe I have it and just did not notice | 14:46 |
| morphis | niemeyer, jdstrand, mvo: any further comments for https://github.com/snapcore/snapd/pull/1688 or can we merge it? | 14:46 |
| mup | PR snapd#1688: interfaces: add fwupd interface <Critical> <Reviewed> <Created by timchen119> <https://github.com/snapcore/snapd/pull/1688> | 14:46 |
| tedg | kgunn: I keep getting this when doing your mir build image instructions: https://paste.ubuntu.com/23120407/ | 14:47 |
| tedg | kgunn: Have you seen that? Not sure what a partitioning error 1 is. | 14:47 |
| ogra_ | mvo, any objections in me blacklisting the floppy module inside ubuntu-core ? | 14:48 |
| ogra_ | (the floppy errors on boot are annoying in kvm) | 14:48 |
| niemeyer | morphis: I will look into it | 14:49 |
| mvo | ogra_: not at all | 14:49 |
| morphis | niemeyer: thanks | 14:49 |
| * ogra_ does so then | 14:49 | |
| niemeyer | morphis, joc: Do you have a moment to talk about snapd#1811 | 14:49 |
| mup | PR snapd#1811: interfaces: serial-port: udev slot definition <Blocked> <Created by jocave> <https://github.com/snapcore/snapd/pull/1811> | 14:49 |
| niemeyer | joc_: ^ | 14:50 |
| nessita | ogra_, roadmr my bash is poor but this will do https://pastebin.canonical.com/164527/ | 14:50 |
| mvo | morphis: its in | 14:50 |
| mup | PR snapd#1688 closed: interfaces: add fwupd interface <Critical> <Reviewed> <Created by timchen119> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1688> | 14:50 |
| ogra_ | nessita, whats json_pp ? | 14:50 |
| ogra_ | (you pipe to it) | 14:51 |
| mvo | pretty print | 14:51 |
| ogra_ | ah, perl | 14:51 |
| nessita | ogra_, something that pretty prints json | 14:51 |
| ogra_ | yep ... adds linewraps, i see | 14:52 |
| nessita | ogra_, can use any other json printing tools or just read the raw json | 14:52 |
| ogra_ | yup | 14:52 |
| joc_ | niemeyer: i have a moment yes | 14:52 |
| nessita | ogra_, does that work for a couple of days as workaround? | 14:52 |
| ogra_ | yeah, i guess | 14:52 |
| niemeyer | joc_: The point you raise there is a valid one, and I think we want a general fix so we don't hit this on other interfaces | 14:53 |
| nessita | ogra_, let me know if not, we have someone assigned to the bug but RTM and GA priorities are tough (well you would know :)) | 14:53 |
| ogra_ | :) | 14:54 |
| joc_ | niemeyer: ok, is it reasonble to attempt that fix now or do we need to do something to workaround it in the short term? | 14:55 |
| niemeyer | joc_: The special case there is len(slot.Apps) == 0.. | 14:56 |
| tedg | sergiusens: Do you have any idea what I could be doing wrong here? https://paste.ubuntu.com/23120407/ | 14:58 |
| kgunn | tedg: no that's news to me....might ask mvo | 14:58 |
| niemeyer | joc_: I'm looking at that code and wondering if it would be sensible to inject a security tag that matches the snap in that case, and whether that'd have the proper results | 14:58 |
| rharper | cyphermox: so I think the os-snap I'm trying to install during the build is the issue; if I specify --os ubuntu-core instead of my local snap; it builds fine. | 14:59 |
| rharper | how do we debug the install of the os-snap I built (which just added my ppa to pull in an updated cloud-init deb) | 14:59 |
| niemeyer | joc_: For udev, I think it'd clearly solve your problem.. I'm wondering if it'd have the intended consequence for other cases as well | 15:00 |
| joc_ | niemeyer: so that section is called as many times as there are slots | 15:00 |
| niemeyer | joc_: and whether we want that in the plug side too | 15:00 |
| joc_ | niemeyer: what key would you use so that multiple different rules files could be created with their possibly different requests for symlinks? currently appname prevents clashes there | 15:02 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ sudo snap install ubuntu-image_0.5_amd64.snap --devmode | 15:02 |
| ogra_ | error: cannot find signatures with metadata for snap "ubuntu-image_0.5_amd64.snap" | 15:02 |
| ogra_ | niemeyer, ^^^ | 15:02 |
| niemeyer | joc_: Each slot needs a unique name | 15:02 |
| ogra_ | could we prehaps make --force-dangerous implicit when i use --devmode ? | 15:03 |
| ogra_ | i already explicitly say i want to do something bad here, so i should not need to additionally say "i'm a bad guy" | 15:03 |
| niemeyer | ogra_: Sounds like different things | 15:03 |
| niemeyer | ogra_: What | 15:04 |
| niemeyer | ogra_: 's missing | 15:04 |
| ogra_ | well, i turn off all confinement | 15:04 |
| niemeyer | ogra_: on that picture is the generation of assertions for your devmode snap | 15:04 |
| sergiusens | tedg I am not involved in u-d-f anymore, but I am guessing it failed once and you have leftover mapped loops | 15:04 |
| ogra_ | so why not also make it implicit set --force-dangerous so i dont need to extra specify it on the commandline | 15:04 |
| ogra_ | feels like duplication and unnecessary annoyance for developers to me | 15:05 |
| niemeyer | joc_: Makes sense? | 15:05 |
| joc_ | niemeyer: so something like securityTag := snap.AppSecurityTag(snapName, slot.Name) ? | 15:06 |
| niemeyer | ogra_: --force-dangerous ignores checksum errors, ignores the lack of signatures on that snap, etc | 15:06 |
| ogra_ | right ... which is what i want when installing a local snap | 15:06 |
| niemeyer | ogra_: It's turning off confinement for something that is completely unknown vs. turning off confinement for something known | 15:06 |
| niemeyer | ogra_: But will discuss that to see what others think | 15:07 |
| ogra_ | probably it shouldnt be bound to --devmode but to "this snap is local anyway" | 15:07 |
| niemeyer | ogra_: No, local snaps is yet another axis on that picture | 15:07 |
| niemeyer | ogra_: A snap can be local and be properly signed | 15:07 |
| ogra_ | oh ? | 15:07 |
| ogra_ | hwo is that ? | 15:07 |
| ogra_ | *how | 15:07 |
| mhall119 | signed by the store, or by the developer? | 15:08 |
| ogra_ | if i have a local snap it should be considered insecure by default imho | 15:08 |
| tedg | sergiusens: I don't see any, but let me reboot to be sure :-) | 15:08 |
| niemeyer | mhall119: Either.. more likely both | 15:08 |
| niemeyer | ogra_: "local" is not indicative of it being insecure | 15:09 |
| ogra_ | the only snaps i trust shoudl come from the store ... all others are developer meterial ... IMHO | 15:09 |
| ogra_ | *materiel | 15:09 |
| ogra_ | bah | 15:09 |
| niemeyer | ogra_: Downloading a snap and installing it with the proper assertinos, or downloading from the store, has the exact same result | 15:09 |
| * ogra_ signs up for the anonymous dyslectics | 15:09 | |
| niemeyer | ogra_: In fact, when you install a local snap, snapd will eventually attempt to get assertions for it | 15:10 |
| ogra_ | hmm | 15:10 |
| niemeyer | It's not about where the data is obtained from, but about whether the data is trusted or not.. assertions give an async way to convey that | 15:11 |
| ogra_ | well, i'd just like to have something more convenient than an additionall cmdline switch for that usecase | 15:11 |
| ogra_ | which is a typical thing ... i develop a snap and first install it locally before it has ever seen the store | 15:12 |
| niemeyer | ogra_: Yeah, I get it.. I think we'll have something slightly more subtle than simply have --force-dangerous behavior by default | 15:13 |
| ogra_ | well, fine with me too :) | 15:14 |
| ogra_ | i just feel that once we have more bits you need to turn off to test a dev snap you will have a very long commandline with lots of options :) | 15:14 |
| jdstrand | morphis: regarding fwupd. I gave my +1 yesterday | 15:15 |
| niemeyer | Yep.. we want to solve that without opening the door for eaiser social exploits | 15:15 |
| ogra_ | right | 15:15 |
| niemeyer | ogra_: There's also some subtlety here that indeed we need to account for.. maybe --force-dangerous indeed doesn't protect much compared to --devmode, which means we could make one imply the other as you suggest | 15:17 |
| niemeyer | ogra_: Will discuss this with pedronis | 15:17 |
| ogra_ | thx :) | 15:17 |
| niemeyer | joc_: Ok, here is a strawman proposal to get us unblocked: | 15:19 |
| jdstrand | ogra_: regarding building kernel snap> thanks. I have two bbbs that I'd like to have run series 16 and will have to figure out something. was hoping for the generic armhf kernel... is that still going to be a thing? | 15:20 |
| jdstrand | ogra_: btw, I saw you say you might need me to approve something? | 15:20 |
| ogra_ | jdstrand, i learned that gadgets go magically through now ! | 15:21 |
| ogra_ | so no, you're not needed ... go on vacation :) | 15:21 |
| niemeyer | - If there are interfaces (slots or plugs) and no apps on a given snap, we pretend there's a single app with the snap name, which means a security tag of snap.AppSecurityTag(snap.Name(), snap.Name()) | 15:21 |
| jdstrand | ogra_: heh, not on vacation today. tomorrow, yes :) | 15:21 |
| niemeyer | jdstrand: Just tomorrow? | 15:22 |
| niemeyer | jdstrand: Not next week? | 15:22 |
| jdstrand | monday is a us holiday so then too | 15:22 |
| niemeyer | Ah, ok | 15:22 |
| ogra_ | jdstrand, the generic armhf kernel wont be an official thing ... but i think mvo will go on maintaining the BBB gadget as "community maintained" so then we'll need a matching kernel that i can set up an auto-build for | 15:22 |
| jdstrand | but working tue-fri next week | 15:22 |
| niemeyer | jdstrand: Ack, thanks | 15:22 |
| jdstrand | mon-thu this week, tue-fri next week | 15:22 |
| niemeyer | jdstrand, joc, morphis: we need to sort all of these interfaces today then | 15:22 |
| niemeyer | As we'd like to cook a pre-image on Monday | 15:23 |
| jdstrand | that was what I was thinking | 15:23 |
| niemeyer | joc_, morphis: I think this will sort out the issue | 15:24 |
| niemeyer | I mean, this: | 15:24 |
| niemeyer | - If there are interfaces (slots or plugs) and no apps on a given snap, we pretend there's a single app with the snap name, which means a security tag of snap.AppSecurityTag(snap.Name(), snap.Name()) | 15:24 |
| niemeyer | on len(slot.Apps()) == 0 on the slot side, and len(plug.Apps()) on the plug side | 15:25 |
| niemeyer | We can do that both for permanent and connected slots, I believe | 15:26 |
| joc_ | niemeyer: so 4 changes to securitySnippetsForSnap one for each snippet function? | 15:26 |
| niemeyer | Yeah, I think so | 15:26 |
| === chihchun is now known as chihchun_afk | ||
| morphis | niemeyer: we still need to sort the remaining issue with the udisks interface | 15:27 |
| niemeyer | morphis: Indeed.. can we have that ready today? | 15:28 |
| niemeyer | morphis: So that jdstrand can review | 15:29 |
| morphis | niemeyer: the interface is fine, we the thing we have to solve is the mount propagation in snap-confine | 15:29 |
| morphis | s/we the/the/ | 15:29 |
| jdstrand | niemeyer: so, on my list is serial-port/hidraw (in progres), fwupd (+1 from me, seems ready to merge), udisks2/removable-storage (close). systemd-control was another, but I thought we were going to go for a much simpler 'reboot-control' interface (or whatever it would be named-- I asked in the PR) | 15:30 |
| niemeyer | morphis: Okay, let's talk about this in a bit, with mvo | 15:30 |
| niemeyer | morphis, mvo: Can we have a call in ~45 mins on this? | 15:30 |
| jdstrand | niemeyer: fyi, zyga was the one advising ssweeny on the mount bits for snap-confine for udisks2 | 15:31 |
| jdstrand | he seemed to know the issue | 15:31 |
| niemeyer | zyga is off due to some family needs and I'm not quite sure he'll be back soonish | 15:32 |
| niemeyer | So we cannot count on him before we hear more details | 15:32 |
| morphis | niemeyer: ok, meeting for that? | 15:32 |
| niemeyer | morphis: Yeah | 15:32 |
| niemeyer | I'll step out for lunch.. back in a bit | 15:33 |
| morphis | niemeyer: ok, need to finish a meeting here | 15:33 |
| morphis | ssweeny, jdstrand: ok with a meeting in 30-45 min? | 15:34 |
| ssweeny | sure | 15:35 |
| jdstrand | sure | 15:37 |
| ogra_ | mvo, on pi2 http://paste.ubuntu.com/23120588/ | 15:49 |
| ogra_ | image creation worked though ... cloud-init timeout took a little longer than in kvm (more like a 20min boot) ... but no snaps found is worrying | 15:49 |
| ogra_ | jamiebennett, ^^^ FYI | 15:50 |
| mvo | ogra_: woah, nice | 15:51 |
| ogra_ | otoh cyphermox will be happy to hear that console-conf worked just fine :) | 15:51 |
| mvo | ogra_: oh, no snaps found | 15:51 |
| mvo | ogra_: sucks | 15:51 |
| ogra_ | yeah | 15:51 |
| mvo | ogra_: could you do snap changes please? | 15:51 |
| mvo | ogra_: and systemctl status snapd.firstboot? | 15:51 |
| ogra_ | ogra@localhost:~$ snap changes | 15:51 |
| ogra_ | error: no changes found | 15:51 |
| ogra_ | ogra@localhost:~$ | 15:51 |
| mvo | oh | 15:52 |
| ogra_ | ogra@localhost:~$ systemctl status snapd.firstboot | 15:52 |
| ogra_ | ● snapd.firstboot.service - Run snappy firstboot setup | 15:52 |
| ogra_ | Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled) | 15:52 |
| ogra_ | Active: failed (Result: exit-code) since Thu 2016-09-01 15:43:20 UTC; 8min ago | 15:52 |
| * mvo scratches head harder | 15:52 | |
| ogra_ | Process: 2584 ExecStart=/usr/bin/snap firstboot (code=exited, status=1/FAILURE) | 15:52 |
| ogra_ | Main PID: 2584 (code=exited, status=1/FAILURE) | 15:52 |
| ogra_ | ogra@localhost:~$ | 15:52 |
| mvo | ogra_: :( no ouput why it failed | 15:52 |
| ogra_ | well, it resulted in an exit code :P | 15:53 |
| ogra_ | (the most silly error message of all) | 15:53 |
| mup | PR snapd#1825 opened: interfaces: snippet creation for snaps without apps <Created by jocave> <https://github.com/snapcore/snapd/pull/1825> | 15:53 |
| mvo | ogra_: do you have "error need a model assertion"? | 15:54 |
| ogra_ | ogra@localhost:~$ ls /var/lib/snapd/snaps/ | 15:54 |
| ogra_ | pi2-kernel_11.snap ubuntu-core_414.snap | 15:54 |
| ogra_ | i dont have a gadget snap ! | 15:54 |
| mvo | ogra_: you have, just under seed/snaps | 15:54 |
| ogra_ | mvo, where would i find that ? | 15:54 |
| ogra_ | (tghe model assertion error) | 15:54 |
| joc_ | niemeyer: let me know if PR snapd#1825 matches expectation | 15:55 |
| mup | PR snapd#1825: interfaces: snippet creation for snaps without apps <Created by jocave> <https://github.com/snapcore/snapd/pull/1825> | 15:55 |
| cyphermox | mvo: I have some issues with the assertions for ubuntu-image? | 15:55 |
| ogra_ | ogra@localhost:~$ sudo journalctl |grep model | 15:55 |
| ogra_ | Sep 01 15:43:09 localhost.localdomain kernel: Machine model: Raspberry Pi 2 Model B Rev 1.1 | 15:55 |
| ogra_ | Sep 01 15:43:20 localhost.localdomain snap[2584]: error: need a model assertion | 15:55 |
| ogra_ | mvo, ^^^ | 15:55 |
| ogra_ | cyphermox, http://people.canonical.com/~ogra/snappy/amd64-generic-model.assertion use that one | 15:55 |
| mvo | ogra_: yeah, I think this is it | 15:55 |
| cyphermox | first it complained about a sign-key, and now about the gadget.yaml | 15:55 |
| ogra_ | cyphermox, tseves is porked | 15:56 |
| ogra_ | *steves | 15:56 |
| ogra_ | *borked | 15:56 |
| ogra_ | mvo, asny hit how to fix it ? | 15:56 |
| ogra_ | *any | 15:56 |
| ogra_ | (my god ... typing is hard today) | 15:56 |
| ogra_ | mvo, http://people.canonical.com/~ogra/snappy/pi2-model.assertion is what i used | 15:57 |
| cyphermox | ogra_: Steve's isn't missing 'core', 'class' and 'store' ;) | 15:57 |
| ogra_ | cyphermox, yes, these are the keys that break everything :) | 15:57 |
| cyphermox | COMMAND FAILED: snap prepare-image /home/mtrudel/Téléchargements/amd64-generic-model.assertion.1 /tmp/tmpol1xbe71/unpackerror: cannot decode model assertion "/home/mtrudel/Téléchargements/amd64-generic-model.assertion.1": assertion model: "class" header is mandatory | 15:58 |
| ogra_ | uuuh | 15:58 |
| ogra_ | works for me | 15:58 |
| cyphermox | I'm using the code from master | 15:58 |
| ogra_ | using the latest ubuntu-image rolled as snap | 15:58 |
| ogra_ | http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap | 15:58 |
| jdstrand | morphis: so, I really think zyga should be in that meeting if it is about how to fix snap-confine. otherise, I'm not prepared to speak to the fix (I would have to come up to spead on the problem, etc) | 15:58 |
| ogra_ | cyphermox, ah, i built it from mvo's PR | 15:58 |
| cyphermox | nah, I'm trying to work on the git code; to modify ubuntu-image ;) | 15:59 |
| ogra_ | there might be more fixes than just the snapcraft.yaml | 15:59 |
| morphis | jdstrand: zyga is out | 15:59 |
| mvo | cyphermox: that PR keeps growing fixes | 15:59 |
| mvo | just saying | 15:59 |
| morphis | jdstrand: that is why I invited you, or is there anyone else who can speak to mount namespace issues? | 15:59 |
| ogra_ | cyphermox, well, i thought it was master with snapcraft.yaml added ... seems there are more fixes | 15:59 |
| mvo | ogra_: yes, almost ready to use it for our image tests | 16:00 |
| cyphermox | mvo: oh, is that already ready to be merged? | 16:00 |
| ogra_ | cyphermox, https://github.com/mvo5/ubuntu-image | 16:00 |
| ogra_ | there os a PR | 16:00 |
| ogra_ | *is | 16:00 |
| mup | PR snapd#1808 closed: many: add snap set and snap get commands <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1808> | 16:00 |
| jdstrand | morphis: well, there is no one that knows *this* issue. zyga knew the specific problem. tyhicks or I can look into it, but aiui this was a code ordering thing | 16:00 |
| mvo | cyphermox: definitely for a review, I plan to make more noise once I get a successful image test in our infrastructure | 16:00 |
| ogra_ | cyphermox, https://github.com/CanonicalLtd/ubuntu-image/pull/46 | 16:01 |
| mup | PR CanonicalLtd/ubuntu-image#46: add snapcraft.yaml & --extra-snaps <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/46> | 16:01 |
| mvo | cyphermox: but some of the bugs I reported are fixed there | 16:01 |
| morphis | jdstrand: yeah, then lets take this as briefing session for you guys, is that ok? | 16:01 |
| jdstrand | morphis: but the point is, neither one of us is ready to comment on the fix cause we haven't studied the issue | 16:01 |
| cyphermox | mvo: none of that looks like it would help in finding a gadget.yaml though :/ | 16:01 |
| jdstrand | tyhicks: are you able to meet in 10 minutes? | 16:01 |
| ogra_ | mvo, so for the pi, is there anything i can fix in my model assertion ? | 16:01 |
| ogra_ | or do i need to wait for your side | 16:02 |
| jdstrand | tyhicks: I can give you some context before (what little I have) | 16:02 |
| morphis | jdstrand: yeah I see, I am sorry for that but from somewhere we need to get help for ssweeny on this | 16:02 |
| ogra_ | cyphermox, well, i just built a kvm image 5 min ago here and it worked fine | 16:02 |
| mvo | cyphermox: finding a gadget yaml? you mean ogras bug? or something else. sorry, a bit confused | 16:02 |
| ogra_ | (apart from the known cloud-init issue) | 16:02 |
| cyphermox | let's back up for a second | 16:03 |
| cyphermox | what version of ubuntu-image is currently snapped up? | 16:03 |
| jdstrand | morphis: no I get that. I just want you to know we are as far along on diagnosing/suggesting a fix as yourself :) I think one of us could look at it, but we need time. a briefing meeting is fine | 16:03 |
| mvo | cyphermox: my branch | 16:03 |
| ogra_ | cyphermox, https://github.com/mvo5/ubuntu-image | 16:03 |
| morphis | jdstrand: thanks!! | 16:03 |
| ogra_ | snap is at http://people.canonical.com/~ogra/snappy/ubuntu-image_0.5_amd64.snap | 16:03 |
| ogra_ | using the model assertion from http://people.canonical.com/~ogra/snappy/amd64-generic-model.assertion gets me a working kvm image | 16:04 |
| cyphermox | huh, it works there | 16:05 |
| cyphermox | oh well, I won't pretend I know how all this works yet ;) | 16:05 |
| ogra_ | just merge mvo's PR and we're all good :) | 16:05 |
| mvo | cyphermox: heh, do not merge just yet, lets wait for slangasek or barry first | 16:06 |
| ogra_ | mvo, so next week ? | 16:06 |
| ogra_ | they are off | 16:06 |
| cyphermox | mvo: yeah, I know | 16:06 |
| mvo | ogra_: is steve off today | 16:06 |
| ogra_ | i thought til monday ? | 16:06 |
| cyphermox | I wasn't going to merge, but I'm forking my own branch to merge in yours + my changes | 16:07 |
| cyphermox | barry should be around tomorrow to do the mergings | 16:07 |
| ogra_ | mvo, "I'm on vacation Thursday through Monday, returning Tuesday. " | 16:07 |
| jdstrand | niemeyer: how important is docker interface for monday? I ask but I suspect there is no way that will be ready due to another snap-confine issue that needs zyga (the pivot_root lxd bug) | 16:07 |
| tyhicks | jdstrand, morphis: I can meet in a few minutes but have a hard stop for another meeting at the half hour | 16:07 |
| lazyPower | jdstrand - thanks for driving that conversation forward. i've been tracking it | 16:07 |
| ogra_ | mvo, well, anything i can do for the pi2 ? while we wait for merges ... | 16:08 |
| jdstrand | tyhicks: it is briefing meeting only. let's join this second so you and I can coordinate | 16:08 |
| mvo | ogra_: not sure, I think not, sucks a bit | 16:08 |
| ogra_ | quite, yeah | 16:08 |
| mvo | ogra_: we will have real signed assertions for themodel | 16:08 |
| jdstrand | tyhicks: if you can | 16:08 |
| ogra_ | but why ddoes it work with the fake amd64 one | 16:09 |
| tyhicks | jdstrand: ack | 16:09 |
| ogra_ | i dont get that | 16:09 |
| cyphermox | ogra_: what do you need merges for? just mvo's PR? | 16:10 |
| ogra_ | cyphermox, well, that is what is working currently | 16:10 |
| ogra_ | so yeah, i havent used more than that | 16:10 |
| mvo | ogra_: not sure, need to look | 16:11 |
| ogra_ | k | 16:11 |
| cyphermox | anything else needs fixed in ubuntu-image? | 16:11 |
| ogra_ | only the bugs :) | 16:11 |
| * ogra_ just filed bug 1619362 | 16:12 | |
| mup | Bug #1619362: images should not be largely bigger than the actual content <Ubuntu Image:New> <https://launchpad.net/bugs/1619362> | 16:12 |
| ogra_ | i'm really tired of 20min dd runs ;) | 16:12 |
| morphis | niemeyer: joining us? | 16:13 |
| mvo | ogra_: fixed in my branch | 16:13 |
| ogra_ | mvo, the size thing ? | 16:13 |
| mvo | ogra_: yes, I create a sparse file, so it looks big but is not | 16:14 |
| ogra_ | nooo | 16:14 |
| ogra_ | dd will still write zeros | 16:14 |
| ogra_ | cxant we just check the size of the snaps, add a certain wiggle room and be fine ? | 16:14 |
| mvo | ogra_: it will be exactly the same as with u-d-f, or was u-d-f not fine? | 16:14 |
| ogra_ | no | 16:14 |
| ogra_ | udf was a pain too | 16:14 |
| ogra_ | the pi2 image can be 200MB | 16:15 |
| mvo | ogra_: fair enough | 16:15 |
| ogra_ | that takes 30sec with dd | 16:15 |
| ogra_ | since we resize on first boot anyway the img doesnt need to be bigger than the actual content | 16:15 |
| ogra_ | also releasing images is a pain if you have so many zeros to xz :) | 16:16 |
| ogra_ | you know that | 16:16 |
| morphis | tyhicks: thanks!! | 16:30 |
| tyhicks | np! | 16:32 |
| cyphermox | mvo: ogra_: even with that PR (things look a little bit better) it still fails to find gadget.yaml | 16:35 |
| cyphermox | http://paste.ubuntu.com/23120867/ | 16:35 |
| mvo | cyphermox: what is the full output? do you use --channel edge? | 16:35 |
| cyphermox | I did not set --channel | 16:35 |
| mvo | cyphermox: that should help | 16:35 |
| cyphermox | right, it's just not very discoverable ;) | 16:36 |
| cyphermox | yup, that works, finally | 16:38 |
| cyphermox | thanks! | 16:38 |
| ogra_ | well, once the gadget is in stable you wont need it anymore :) | 16:41 |
| cyphermox | right | 16:42 |
| cyphermox | well, now to test the crack I just added :) | 16:42 |
| ogra_ | :D | 16:42 |
| cyphermox | Q'apla! | 16:48 |
| mup | PR snapd#1804 closed: tests: use the spread tests with the adhoc interface inside autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1804> | 16:51 |
| mup | PR snapd#1812 closed: image,overlord/boot,snap: metadata from asserts for image snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1812> | 16:57 |
| joc_ | jdstrand: note that i just push a couple of commits that change the allowed symlink path on serial-port | 17:06 |
| jdstrand | ack | 17:06 |
| cyphermox | ogra_: mvo: https://github.com/CanonicalLtd/ubuntu-image/pull/47 | 17:08 |
| mup | PR CanonicalLtd/ubuntu-image#47: Preseed cloud-init and allow further preseeding when building the image <Created by cyphermox> <https://github.com/CanonicalLtd/ubuntu-image/pull/47> | 17:08 |
| ogra_ | cyphermox, hmm, but that requires the user to have a local cloud-init config, no ? | 17:10 |
| ogra_ | ahm no, i see you write defaults | 17:11 |
| ogra_ | ignore that :) | 17:11 |
| mvo | ogra_: could you trigger a ubuntu-core build once snapd 2.14.2 is published in the PPA? that would be super nice, the resulting core-snap will become the new candidate snap | 17:11 |
| mvo | cyphermox: I think we want something like --cloud-init-file some-file too so that we can create images that are actually useful in the cloud, but that is for later | 17:12 |
| ogra_ | mvo, no prob | 17:12 |
| cyphermox | ogra_: are there any fixes needed to console-conf? | 17:13 |
| ogra_ | mvo, oh ... i3386 FTBFS | 17:13 |
| cyphermox | (asking if anything transpired last night while I was away) | 17:13 |
| ogra_ | cyphermox, not sure yet ... sabdfl_ said in my bug that a special assertion should create local users for offline devices (no idea how that will work and it sounds really complex for someone doing a port and initial device bringup etc) ... in that light it seems console-conf is fine for the moment | 17:14 |
| niemeyer | ogra_: next week devmode will get over dangerous as you suggested | 17:14 |
| cyphermox | ok | 17:14 |
| sabdfl_ | yeah yeah | 17:15 |
| * ogra_ hugs niemeyer | 17:15 | |
| cyphermox | well, --cloud-init will let you create an offline user | 17:15 |
| ogra_ | oh, right ... | 17:15 |
| cyphermox | then I will also add back the local-user magic in console-conf | 17:15 |
| ogra_ | now that we can just inject config ... | 17:15 |
| sabdfl_ | the basic guidance is that "all snap users are associated with the private or public store that the device is getting updates and apps from" | 17:15 |
| cyphermox | well, injecting config is nice, but it's not proper experience for a random appliance someone would buy | 17:15 |
| sabdfl_ | if you are offline, then the way to do that is to have an assertion from that store saying "user joe has these ssh keys" | 17:16 |
| mvo | ogra_: yeah, super confusing | 17:16 |
| cyphermox | hrm | 17:16 |
| ogra_ | FAIL | 17:16 |
| ogra_ | FAILgithub.com/snapcore/snapd/overlord/state0.385s | 17:16 |
| ogra_ | === RUN Test | 17:16 |
| ogra_ | seems it faisl this test | 17:16 |
| sabdfl_ | cyphermox here's the experience as I would like it | 17:16 |
| ogra_ | *fails | 17:16 |
| sabdfl_ | - you go to your web-based management system ("my.ubuntu.com" or a corporate equivalent) | 17:17 |
| sabdfl_ | - you get a text file on a USB key | 17:17 |
| sabdfl_ | - you stick that USB key into your appliance | 17:17 |
| sabdfl_ | - it is now securely registered to your account | 17:17 |
| sabdfl_ | that's pretty friendly | 17:17 |
| cyphermox | that covers what I was going to ask: "sabdfl_: I'm just not clear on how an offline system would get the information for user joe?" | 17:17 |
| sabdfl_ | it's in that text file | 17:17 |
| cyphermox | yup | 17:17 |
| sabdfl_ | it's signed (an "assertion" is a signed piece of text) | 17:18 |
| sabdfl_ | et voila | 17:18 |
| sabdfl_ | ogra is just being difficult :p | 17:18 |
| cyphermox | I suppose all these should be parsed by snapd, not by console-conf; and rather get console-conf to be skipped, perhaps | 17:18 |
| ogra_ | sabdfl_, nah, i'm lazy :) | 17:18 |
| sabdfl_ | old-fashioned :p | 17:18 |
| ogra_ | heh | 17:19 |
| sabdfl_ | in a good way! | 17:19 |
| sabdfl_ | we are building on fine traditions ;) | 17:19 |
| cyphermox | sabdfl_: so should we have a method to create a user manually in console-conf; aside from the 'enter your email' form? | 17:19 |
| ogra_ | sabdfl_, though a way to inject that assertion during ubuntu-image run would be nice so i dont need additional HW when i roll my own offline rpi image | 17:19 |
| sabdfl_ | console-conf is a console front-end to this experience | 17:19 |
| sabdfl_ | cloud-init is a metadata front-end | 17:19 |
| sabdfl_ | both of them can essentially steer the process | 17:20 |
| sabdfl_ | one is for humans on a console | 17:20 |
| sabdfl_ | the other is for orchestrators spinning stuff up remotely in clouds | 17:20 |
| sabdfl_ | but yes, snapd is the steward of device state, so ultimately both of those pathways drive things through snapd | 17:20 |
| ogra_ | hmm, but cloud-init can currently completely circumvent the assertion process ... if i tell it to add a local user it will do so ... sounds like we should block that | 17:21 |
| sabdfl_ | the base *primitive* for users is "dear snapd please create a user on this device associated with such-and-such a user in such-and-such a store" | 17:21 |
| sabdfl_ | ogra_, possibly, yes | 17:21 |
| sabdfl_ | we have to understand the gray area of classic, too, where you have both snap-friendly users and legacy UNIX-only users | 17:21 |
| cyphermox | ogra_: sound like we should make sure you can specify the store credentials for a user cloud-init would create. | 17:23 |
| ogra_ | cyphermox, right ... and find out how to block the standard adduser cloud-init does | 17:23 |
| ogra_ | else you could just randomly abuse that | 17:24 |
| ogra_ | the prob now is ... we dont have that magic assertion creator yet ... even console-conf just downloads the ssh key from LP without further stuff | 17:25 |
| cyphermox | sabdfl_: I guess what I'm asking is if we should have the UI to create UNIX-only users in console-conf at all, or if the current behavior of using the email address is all we want. | 17:25 |
| ogra_ | cyphermox, no | 17:26 |
| ogra_ | it is either "you are online" -> console-conf ... or "you are offline" -> provide an assertion via cloud-init | 17:26 |
| cyphermox | ok, so only "preseeding" via store assertions or | 17:26 |
| cyphermox | skip the 'or' there. | 17:27 |
| ogra_ | right ... | 17:27 |
| ogra_ | but we dont have that store side bit yet ... so only online devices for now i guess | 17:27 |
| cyphermox | ok, in that case we'll want these assertions to be able to tell snapd that console-conf has run. | 17:27 |
| ogra_ | we should probably have an "ubuntu" user assertion for now and make that publically available until the sotre can generate real ones :) | 17:28 |
| ogra_ | *store | 17:28 |
| ogra_ | i.e. some fake placeholder so people with offline devices dont get blocked in their development | 17:29 |
| cyphermox | who will be doing that? | 17:29 |
| ogra_ | no idea | 17:29 |
| ogra_ | i yet have to understamd assertions properly :) | 17:29 |
| ogra_ | (only slowly understanding the machine part of it since today) | 17:30 |
| ogra_ | cyphermox, i guess the core team together with the stroe team should be able to provide us something | 17:30 |
| ogra_ | mvo, should i just retry the i386 build ? | 17:33 |
| ogra_ | seems amd64 passed the test | 17:33 |
| * ogra_ just tries | 17:33 | |
| ogra_ | mvo, i386 retry worked | 17:40 |
| ogra_ | weird ... | 17:40 |
| jdstrand | zyga: please ignore my irc highlights from earlier today | 17:42 |
| joc_ | jdstrand: thanks for reviews, i think i have addressed all comments (including ones just made), i'm going to start copying this over to a hidraw interface | 17:51 |
| mup | PR snapd#1819 closed: snap: set user variables even if HOME is unset (like with systemd services) <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1819> | 17:52 |
| slangasek | mvo: "create local users via console-conf" - that's contrary to the design we've been given; can we please discuss that on the list? If you are mastering an image and want a local user created, that should be via cloud-init preseeding and not via console-conf | 17:55 |
| cyphermox | slangasek: we've already reached that conclusion, I think. | 17:56 |
| slangasek | mvo: so, please explain where you're seeing non-sparse images | 17:56 |
| slangasek | cyphermox: ok ;) | 17:56 |
| cyphermox | also, what are you doing here? | 17:57 |
| cyphermox | ;) | 17:57 |
| jdstrand | joc_: I made a comment on your most recent commit | 17:57 |
| joc_ | jdstrand: i think what you are asking for is there, just not in an else block | 18:00 |
| jdstrand | mvo (cc ogra_): is it known that on all snaps images the ip address keeps incrementing? I think netplan isn't sending the dhclient hostname or something so the dhcp server isn't reusing the ip for the mac. I didn't investigate, just a hunch | 18:01 |
| jdstrand | joc_: oh, maybe I read to fast | 18:02 |
| * jdstrand rereads | 18:02 | |
| jdstrand | joc_: yeah, sorry, you're right. thanks! | 18:03 |
| * jdstrand deleted the comment | 18:03 | |
| joc_ | np | 18:03 |
| ogra_ | jdstrand, doesnt happen for me on pi2, pi3 or dragonboard ... where do you see that ? | 18:06 |
| jdstrand | ogra_: amd64 vm | 18:06 |
| jdstrand | ogra_: that I generated yesterday | 18:06 |
| ogra_ | ah, something i rarely use | 18:06 |
| jdstrand | note, this is with libvirt's dnsmasq. that is a configuration that worked in earlier series 16, which is why I thought of netplan | 18:08 |
| jdstrand | anyway, I can't focus on that right now, but thought I'd mention it | 18:08 |
| ogra_ | yeah, could be ... talk to pitti or mwhudson then ... | 18:08 |
| ogra_ | i assume you went through the console-conf stuff to actually have the setup ready ? | 18:09 |
| mvo | jdstrand: aha, thank you - I think the righ people for a question like why netplan keeps increating the ips is pitti or mwhudson, your idea about the missing hostname makes sense | 18:12 |
| ogra_ | ooooh ! | 18:14 |
| ogra_ | the arm builders finally made their mind up | 18:14 |
| jdstrand | ogra_: I did go through console-conf. fyi, static ip address didn't seem to work at all (always got incrementing dhcp) | 18:17 |
| ogra_ | yeah, that sounds like either console-conf or netplan | 18:18 |
| ogra_ | ststic should surely work too | 18:18 |
| jdstrand | pitti, mwhudson: ^ fyi (also, I can't debug this right now. easy to see with this image: sudo /snap/bin/ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160831-amd64.img --gadget pc --kernel pc-kernel --os ubuntu-core 16 | 18:19 |
| jdstrand | pitti, mwhudson: I saw it after importing that image into libvirt, but bet it would happen with any dnsmasq dhcp server (or possibly isc) | 18:20 |
| cyphermox | jdstrand: do you mean you configured static and don't get a static IP? | 18:20 |
| elopio | you are not funny ogra_ | 18:20 |
| * ogra_ hugs elopio | 18:20 | |
| elopio | :) | 18:20 |
| ogra_ | :) | 18:20 |
| cyphermox | because otherwise I wouldn't be surprised if the leases for DHCP were all wrong | 18:20 |
| jdstrand | cyphermox:yes. after I saw the incrementing dhcp ip I tried to workaround by setting static ip | 18:20 |
| jdstrand | cyphermox: and that didn't work | 18:21 |
| cyphermox | interesting | 18:21 |
| cyphermox | I'll give it a shot here | 18:21 |
| ogra_ | --size 8 .... how excessive | 18:21 |
| jdstrand | ogra_: not really-- I'm helping with docker interface :) | 18:21 |
| ogra_ | heh, k ... thats explains a lot :) | 18:21 |
| jdstrand | though not this second. now I'm working on udisks/snap-confine | 18:22 |
| jdstrand | ssweeny: fyi, I left a note in your snap-confine fork but that isn't for you to do anything at this time. just now starting to look and will sync when I have more info | 18:22 |
| ssweeny | jdstrand, sounds good. I'll have to step out around 3-4PM EDT but I'll be back later in the afternoon | 18:23 |
| ogra_ | mvo, sigh, who is that overlord guy ... arm64 FTBFS in the same test ... retrying | 18:36 |
| jdstrand | ssweeny: can you make the udisks2 snap available? | 18:40 |
| cyphermox | jdstrand: ok, the IP issue is a bug that is fixed, just need a newer nplan / console-conf I think | 18:51 |
| cyphermox | I'm double-checking | 18:51 |
| jdstrand | that's great! :) | 18:51 |
| ogra_ | mvo, and arm64 built too ... this overlord is an evil overlord for sure :P | 18:55 |
| cyphermox | jdstrand: ah, not fixed, but we did run into the same issue once before, it needs to be changed again :/ | 18:55 |
| * ogra_ waits for the publisher now | 18:55 | |
| mup | Bug #1619420 opened: snappy removal of dpkg-query breaks lsb_release --all <Snappy:New> <https://launchpad.net/bugs/1619420> | 18:56 |
| mup | Bug #1619423 opened: snappy does not include ssh-import-id preventing cloud-init user-data from importing ssh-keys <Snappy:New> <https://launchpad.net/bugs/1619423> | 18:59 |
| === sabdfl_ is now known as sabdfl | ||
| sabdfl | ogra_, cyphermox, assertions are coming along, latest snapd added a few, user ones will be there in good time, i would not worry too much | 19:03 |
| sabdfl | for the current image test and dev just.... be online ;) | 19:03 |
| ahoneybun | this : http://snapcraft.io/docs/reference/snapcraft links to this : https://linuxcontainers.org/lxd/getting-started-cli/ | 19:04 |
| ahoneybun | when talking about cleanbuild but there is no “Ubuntu Desktop and Ubuntu Server” section on that page | 19:05 |
| cyphermox | sabdfl: great, I'm glad people are happy so far with console-conf and all :) | 19:07 |
| mup | PR snapd#1825 closed: interfaces: snippet creation for snaps without apps <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1825> | 19:08 |
| SamYaple | sergiusens: hey. question for you. what is the reason of _get_python2_include and why does python3 not also need that? | 19:08 |
| SamYaple | im unifying the two plugins and just coming across some inconsistencies | 19:09 |
| sergiusens | SamYaple hey | 19:09 |
| sergiusens | SamYaple non, but look https://github.com/snapcore/snapcraft/pull/771 | 19:09 |
| mup | PR snapcraft#771: Python plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/771> | 19:09 |
| SamYaple | oh.. | 19:10 |
| cyphermox | mvo: where is ubuntu-device-flash source? could it be writing a netplan config? | 19:11 |
| ogra_ | ARGH | 19:14 |
| SamYaple | sergiusens: cool. looks good. i just switched jobs so ive been a bit busy :) | 19:14 |
| ogra_ | so console-conf breaks the classic mode | 19:14 |
| mup | PR snapd#1826 opened: interfaces: add interface for hidraw devices <Created by jocave> <https://github.com/snapcore/snapd/pull/1826> | 19:15 |
| SamYaple | sergiusens: ill let you handle that then and ill work on some other python improvements that ive had in mind then | 19:15 |
| joc_ | jdstrand: hidraw PR opened ^ should be fairly familiar | 19:15 |
| ogra_ | hmm ... | 19:16 |
| ogra_ | ogra@dragonboard:~$ sudo classic | 19:16 |
| ogra_ | sudo: unknown user: ogra | 19:16 |
| ogra_ | sudo: unable to initialize policy plugin | 19:16 |
| ogra_ | ogra@dragonboard:~$ sudo -u ubuntu -i | 19:16 |
| ogra_ | ubuntu@dragonboard:~$ sudo classic | 19:16 |
| ogra_ | (classic)ubuntu@dragonboard:~$ | 19:16 |
| ogra_ | fun | 19:16 |
| sergiusens | SamYaple yeah, I took a completely different approach and a lot happier with it; a much needed improvement over the older python plugins | 19:16 |
| sergiusens | SamYaple I would like to know if you can run it through any test subjects you might have or point me to them | 19:16 |
| ogra_ | cyphermox, for some reason the sudo user that console-conf created is different | 19:17 |
| SamYaple | sergiusens: agree. much nicer. like the unified approach too. wasnt looking forward to duping work to add python features | 19:17 |
| SamYaple | sergiusens: i will start using it locally, but i don't have any projects or test suites around snappy yet. still working on a POC for openstack | 19:18 |
| sergiusens | SamYaple sounds good! | 19:22 |
| mup | PR snapd#1827 opened: #1802 + #1823 <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1827> | 19:26 |
| sergiusens | josepht seems the parser tests are leaving the /tmp dirs behind. Mind adding a cleanup task for that? | 19:31 |
| sergiusens | I guess elopio could help | 19:31 |
| josepht | sergiusens: sure, file a bug :) | 19:32 |
| elopio | oh, just use the tmp dir fixture. | 19:32 |
| sergiusens | josepht trololol | 19:32 |
| cyphermox | ogra_: groups, I bet | 19:33 |
| cyphermox | there's nothing I can really do about that, we just use snap create-user to create the user (but I'll double-check) | 19:34 |
| cyphermox | result = run_command(["snap", "create-user", "--sudoer", "--json", self.email.value]) | 19:34 |
| cyphermox | let's see, self.email.value contains... | 19:35 |
| cyphermox | doh, reading it the wrong way around | 19:35 |
| cyphermox | self.email.value is obviously just an email address, and we expect a result in json format from snap | 19:35 |
| ogra_ | cyphermox, yeah, that wont work ... the user needs to be in adm and sudoers | 19:36 |
| ogra_ | ogra@dragonboard:~$ groups | 19:37 |
| ogra_ | ogra | 19:37 |
| ogra_ | else he cant even open logfiles | 19:37 |
| cyphermox | so somethign to fix in snap create-user I guess | 19:37 |
| ogra_ | oh CRAP ! | 19:37 |
| ogra_ | no, that wont work at all | 19:37 |
| ogra_ | the sudo group lives in the readonly /etc/groups | 19:38 |
| ogra_ | and i doubt sudo gets along with moving that to extrausers | 19:38 |
| cyphermox | why is that an issue? | 19:38 |
| cyphermox | sudo works fine on the system | 19:38 |
| josepht | sergiusens: where can the name and version variables be used? in the wiki and in the part? Or just one or the other? | 19:38 |
| ogra_ | because you cant write to it ? | 19:38 |
| ogra_ | well, not when i try to spawn a classic chroot | 19:39 |
| ogra_ | as you can see above | 19:39 |
| cyphermox | I don't disagree that something is wrong, I'm just saying it's not the fact that the user is in sudo group or not | 19:40 |
| cyphermox | classic might not know about extrausers? | 19:40 |
| josepht | sergiusens: I guess either way I can just do the substitution on the parsed part to cover both bases. | 19:40 |
| ogra_ | i thought it gets bindmounted | 19:40 |
| cyphermox | will outside the chroot maybe | 19:40 |
| ogra_ | yeah,, it doesnt ... | 19:41 |
| sergiusens | josepht in the snapcraft.yaml | 19:41 |
| ogra_ | i guess i should bind mount it then | 19:41 |
| ogra_ | sigh | 19:42 |
| sergiusens | josepht only | 19:42 |
| josepht | sergiusens: ack | 19:42 |
| ogra_ | (classic)ubuntu@dragonboard:~$ cat /var/lib/extrausers/passwd | 19:43 |
| ogra_ | ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash | 19:43 |
| ogra_ | (classic)ubuntu@dragonboard:~$ | 19:43 |
| sergiusens | stokachu hey, would you mind looking at this https://github.com/snapcore/snapcraft/pull/771/files I built conjure-up successfuly after changing a tinsy thing in the `snap` entry s|/usr/bin/conjure-up|bin/conjure-up| | 19:43 |
| mup | PR snapcraft#771: Python plugin improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/771> | 19:43 |
| ogra_ | cyphermox, ^^ | 19:43 |
| ogra_ | so extrausers is there | 19:43 |
| ogra_ | but does not contain added users | 19:43 |
| sergiusens | stokachu I really hope that is ok and not have to support the backwards compatible dist-packages anymore. | 19:43 |
| cyphermox | I have no idea what to tell you; my understanding of classic is that it extracts a tarball, that must furthermore include any users created outside that tarball | 19:44 |
| stokachu | sergiusens, so does this not use requirements.txt any longer? | 19:44 |
| cyphermox | it's really as simple as extrausers, we don't do anything special to create the user in console-conf | 19:44 |
| stokachu | sergiusens, looks ok to me | 19:45 |
| ogra_ | ogra@dragonboard:~$ sudo cp /var/lib/extrausers/* /var/snap/classic/common/classic/var/lib/extrausers/ | 19:46 |
| ogra_ | ogra@dragonboard:~$ sudo classic | 19:46 |
| ogra_ | (classic)ogra@dragonboard:~$ | 19:46 |
| ogra_ | cyphermox, theer we go | 19:46 |
| ogra_ | i'll fix the classic wrapper to copy it every time you invoke the classic shell | 19:47 |
| cyphermox | ok | 19:49 |
| SamYaple | sergiusens: when do you think that python plugin will be done? i dont want to make you rebase but i need to change teh constraints part around a bit | 19:51 |
| SamYaple | sergiusens: also, it builds everything i need it to so far :) good job | 19:51 |
| sergiusens | SamYaple good to hear | 19:52 |
| sergiusens | SamYaple somewhere around today/tomorrow most likely | 19:52 |
| SamYaple | oh yea. perfect. | 19:53 |
| sergiusens | cprov did grade make it to the store review? | 19:53 |
| ogra_ | mvo, ok, finally all snapd package built ... ubuntu-core build running ... | 19:53 |
| ogra_ | *packages | 19:53 |
| cprov | sergiusens: yes, in production. | 19:53 |
| SamYaple | the constraints should also accept a url, so i just need to adjust how it processes the option | 19:53 |
| mvo | ogra_: cool! thats will be the new candidate snaps for core :) | 19:54 |
| ogra_ | yay | 19:54 |
| ogra_ | mvo, note that the store UI is borked regarding channels (you cant open the list of uploads) | 19:54 |
| ogra_ | so it might be a bit tricky to get that moving through the channels | 19:55 |
| ssweeny | jdstrand, hey sorry for the delay. Do you need an armhf or amd64 snap? | 19:56 |
| ogra_ | mvo, ad classic will need a fix ... i'll prepare a Pr for tomorrow | 19:57 |
| ogra_ | *and | 19:57 |
| Birchy | Can you do unionfs with Snappy? | 19:57 |
| Birchy | I'm thinking of a fancy system for Wine | 19:57 |
| ogra_ | Birchy, well, there is a fuse interface ... so a fuse-unionfs might be possible | 19:58 |
| ogra_ | but that will crawl indeed | 19:58 |
| mvo | ogra_: uh, ok | 19:58 |
| Birchy | ogra_, just how slow? | 19:59 |
| ogra_ | you have to try ... i know it wasnt really usable when we tried it for livecds several years ago | 19:59 |
| SamYaple | sergiusens: youll be happy to know your python plugin also fixes an issue with some python package installs (try installing uwsgi python package with the python2 plugin) | 20:10 |
| SamYaple | sergiusens: so you are fixing bugs you didnt know about with just overall better code | 20:10 |
| mup | Bug #1619455 opened: classic does not work with connsole-conf created user <Snappy:New> <https://launchpad.net/bugs/1619455> | 20:21 |
| sergiusens | SamYaple good to know, I knew I'd be fixing bugs along the way and just switched to use pip for everything | 20:21 |
| sergiusens | SamYaple stage-packages from python are also taken into account when calculating deps (that was a peeve of mine) | 20:21 |
| SamYaple | sergiusens: yea i saw that. awesome! very happy youve had the time for this. i have not | 20:25 |
| mup | PR snapd#1828 opened: cmd/snap,client: add snap set and snap get commands <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1828> | 20:25 |
| sergiusens | SamYaple it is my job and this was long overdue so I gave it priority ;-) | 20:26 |
| SamYaple | sergiusens: yea this is my free time stuff, so slightly different. still glad for your help here | 20:26 |
| sergiusens | SamYaple the pleasure is mine | 20:32 |
| mup | PR snapd#1829 opened: interfaces: fix interface handling on no-app snaps <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1829> | 21:03 |
| mup | PR snapcraft#773 opened: parser - Handle project name and version variables <Created by josepht> <https://github.com/snapcore/snapcraft/pull/773> | 21:03 |
| niemeyer | jdstrand: snapd#1829 contains that idea we discussed | 21:07 |
| mup | PR snapd#1829: interfaces: fix interface handling on no-app snaps <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1829> | 21:07 |
| niemeyer | jdstrand: Evolved a bit since then | 21:08 |
| niemeyer | jdstrand: Less hackish now | 21:08 |
| awe | can anyone help me with a signatures error when trying to sideload a snap on my rpi2 running latest core? | 21:18 |
| awe | I get the same error with and without --devmode ( which I didn't think would help ) | 21:18 |
| awe | error: cannot find signatures with metadata for snap | 21:19 |
| awe | snap was built by lp earlier today | 21:19 |
| pedronis | awe: yea, that's not released/announced but snap install -h mentiones --force-dangerous (it's going to change again and devmode will imply it but as master stands it's like that) | 21:20 |
| awe | thanks pedronis; I see that now when running 'snap install --help' on my rpi. I initially checked on my desktop, and I guess I need to update there | 21:22 |
| awe | ;)- | 21:22 |
| awe | and that works | 21:22 |
| awe | cool | 21:22 |
| pedronis | awe: it's a follow up for locally installing snaps for the fact that since 2.13 we are verifying assertions/signatures when we install from the store | 21:24 |
| awe | got it | 21:24 |
| pedronis | flags will change a bit again (likely already tomorrow --devmode will sort of imply it , and will be just --dangerous) | 21:25 |
| awe | it'd be nice if there was a shortened paramater ( eg. -f ), as --force-dangerous is a mouthful, and bash completion doesn't work on the rpi | 21:26 |
| awe | ah, cool | 21:26 |
| * awe likes --dangerous | 21:26 | |
| mup | PR snapd#1830 opened: firstboot: only configure en* interfaces by default <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1830> | 21:35 |
| jdstrand | niemeyer, ssweeny: status update: the snap-confine changes for udisks2 are not done. tyhicks and I are investigating. there will not be a patch for snap-confine today. that should not block udisk2 merge and Monday's image (but this is a bug we need to fix and are looking at it with priority) | 21:35 |
| niemeyer | jdstrand: Okay, let's please aim at having this fixed on Tuesday the latest, as it's a bug worth fixing for RTM | 21:36 |
| jdstrand | niemeyer: that is the goal | 21:37 |
| niemeyer | jdstrand: Thanks for looking into this on short notice | 21:38 |
| niemeyer | cc tyhicks | 21:38 |
| jdstrand | it's unfortunately a bit thornier than we expected | 21:39 |
| ssweeny | jdstrand, thanks for the update | 21:39 |
| mup | PR snapd#1829 closed: interfaces: fix interface handling on no-app snaps <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1829> | 22:07 |
| antipsychiatry | A | 23:17 |
| antipsychiatry | N | 23:17 |
| antipsychiatry | T | 23:17 |
| antipsychiatry | I | 23:17 |
| antipsychiatry | P | 23:17 |
| antipsychiatry | S | 23:17 |
| antipsychiatry | Y | 23:17 |
| antipsychiatry | C | 23:17 |
| antipsychiatry | H | 23:17 |
| antipsychiatry | I | 23:17 |
| antipsychiatry | A | 23:17 |
| antipsychiatry | T | 23:17 |
| antipsychiatry | R | 23:17 |
| antipsychiatry | Y | 23:17 |
| antipsychiatry | . | 23:17 |
| antipsychiatry | O | 23:17 |
| antipsychiatry | R | 23:17 |
| antipsychiatry | G | 23:17 |
| mwhudson | hey so https://launchpad.net/ubuntu/+source/golang-github-coreos-pkg needs to be MIRed as it's now a dep of golang-github-coreos-go-systemd | 23:26 |
| mwhudson | so can the snappy-dev team subscribe to bugs? | 23:26 |
| mwhudson | hm that needs mvo asac or slangasek, all not here | 23:27 |
| wililupy | HA! I finally figured out why my custom images were not coming up showing the three basic snaps installed.... | 23:39 |
| wililupy | My kernel snaps were being built with confinement: devmode. I switch it to strict and now I get the kernel snap, the gadget snap and the os snap. | 23:40 |
| mwhudson | hm is there a good document on assertions? | 23:53 |
| mwhudson | i've read a spec ages ago, but i wonder if details have changed | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!