| mup | PR snapd#2092 opened: store: do not set store auth for local users <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2092> | 00:44 |
|---|---|---|
| === wililupy is now known as wililupy|away | ||
| === wililupy|away is now known as wililupy | ||
| mup | PR snapd#2082 closed: overlord,daemon,snap: support gadget config defaults <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2082> | 01:06 |
| mup | PR snapd#2071 closed: interfaces,overlord/ifacestate: switch to use declaration-based checking for auto-connect <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2071> | 01:07 |
| mup | PR snapd#2089 closed: store: do not set store auth for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2089> | 01:17 |
| mup | PR snapd#2092 closed: store: do not set store auth for local users <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2092> | 01:17 |
| mup | PR snapd#2093 opened: cmd/snap,ctlcmd: fix behavior of snap(ctl) get <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2093> | 03:20 |
| mup | PR snapd#2094 opened: docs: fix missing "=" in the systemd-active docs <Created by mvo5> <https://github.com/snapcore/snapd/pull/2094> | 06:06 |
| mvo | ogra_: thanks for setting up "core". could we make it so that core is auto-triggered to build daily just like ubuntu-core? that would be great! | 06:18 |
| dholbach | good morning | 06:25 |
| mup | PR snapd#2094 closed: docs: fix missing "=" in the systemd-active docs <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2094> | 06:40 |
| morphis_ | zyga: ping | 07:22 |
| mvo | pitti: quick question - what is the best way to conditionall enable a systemd service (cloud-init in my case). during boot I want to evaulate via "snap get core cloud-init.enabled" if it should run or not and based on target start cloud-init.target. should I just do that in a new snapd.cloud-init.service ? "ExecStart=/bin/sh -c "if snap get core cloud-init.enabled; do systemctl start cloud-init.target; fi"? or is there a better way to do that? | 07:43 |
| pitti | mvo: not sure that this works as cloud-init wants to run *very* early; you can't alter the early boot transaction while you are already in that | 07:45 |
| pitti | mvo: I can think of two ways: | 07:45 |
| pitti | 1) write a generator which does the get and enables cloud-init.service in the generator run dir | 07:46 |
| pitti | (that's the "official" way) | 07:46 |
| pitti | 2) run snapd.cloud-init.service Before=cloud-init-local.service, if enabled create a /run/somewhere/run_cloud_init, and add ConditionPathExists=/run/somewhere/run_cloud_init to cloud-init*.service | 07:46 |
| pitti | but the latter is the same effort with a non-standard way to enable it and requires modifying cloud-init.service (you can do that with drop-ins); so I'd actually just use a generator | 07:47 |
| pitti | mvo: I thought cloud-init already had like five different ways to enable/disable it -- none of them are suitable? | 07:48 |
| pitti | (kernel command line, flag files, etc.) | 07:48 |
| mvo | pitti: well, maybe I have not found the right one yet :) I want it to be totally disabled, i.e. no python running by default to not slow down boot on arm | 07:48 |
| mvo | pitti: the /etc/cloud/cloud-init.disabled does not do that, there is still python code run afaict (mind you, I'm not a cloud-init expert) | 07:49 |
| pitti | ah, too bad -- otherwise that could just be the flag file | 07:49 |
| pitti | although having it in /run would be better | 07:49 |
| mvo | pitti: yeah | 07:49 |
| pitti | mvo: so, I'd say just write a generator | 07:49 |
| mvo | pitti: this will run very early, right? | 07:50 |
| pitti | mvo: yes, before any unit starts; so you can make essentially zero assumptions about r/w mounts, remote mounts, networking etc. | 07:50 |
| pitti | but for checking a config option it should work fine | 07:50 |
| mvo | pitti: hm, that is also going to be tricky because of the way the snapd config works. hm hm | 07:50 |
| mvo | pitti: essentially a config get goes through snapd | 07:51 |
| pitti | oh | 07:51 |
| mvo | pitti: but thanks, I won't bother you more with this, let me think about this some more, this is really helpful so far | 07:51 |
| pitti | mvo: when does snapd start? | 07:51 |
| pitti | mvo: there is no way to get that config option without the daemon? | 07:51 |
| mvo | pitti: in multi-user somewhere | 07:51 |
| mvo | pitti: maybe, I need to check that out | 07:52 |
| pitti | mvo: ok, way too late; cloud-init (the earliest is cloud-init-local) runs basically as the second thing after boot | 07:52 |
| pitti | s/after/at/ | 07:52 |
| mvo | pitti: uhhh | 07:53 |
| pitti | mvo: it wants to be able to change fstab entries, reformat partitions etc. | 07:53 |
| clobrano | Hi everybody, I was looking at some bugs to fix, and saw Bug #1470661. Is it still a valid one? The code has changed a lot, this problem is still reproducible,but snapcraft schema allows tilde in version | 07:53 |
| mup | Bug #1470661: Tilde allowed in version but systemd hates it <Snappy:Triaged> <Snappy 15.04:Won't Fix> <Snappy trunk:Triaged> <https://launchpad.net/bugs/1470661> | 07:53 |
| mvo | pitti: thanks, tricky | 07:54 |
| pitti | mvo: hm, I thought it had some ConditionSomething= on a file, seems not | 07:55 |
| pitti | mvo: then again, how many features of cloud-init would actually work on snappy? most certainly not the fstab, formatting, package installation, etc. parts | 07:55 |
| pitti | mvo: so on snappy you might actually get away with starting it later | 07:56 |
| * pitti suggests discussing that in a hangout with smoser | 07:56 | |
| pitti | mvo: but still -- I'd say, find a way to get that flag without the daemon | 07:56 |
| mvo | pitti: yeah, that is a good point, again, thanks for your input | 07:59 |
| zyga | ara: hey | 08:56 |
| ackk | hey, I think you query'd the wrong nick :) | 08:57 |
| ackk | n/m, my client tricked me | 08:57 |
| zyga | ara: we found this bug https://bugs.launchpad.net/snap-confine/+bug/1630479 | 08:58 |
| mup | Bug #1630479: permission denied while opening mount namespace file <Snappy Launcher:In Progress by zyga> <snap-confine (Ubuntu):In Progress by zyga> <https://launchpad.net/bugs/1630479> | 08:58 |
| zyga | ara: this will probably fail verification (well, it's a regression compared to .38) but we already fixed it and I'll probably upload .43 | 08:58 |
| ara | zyga, thanks for the heads up | 09:04 |
| ara | zyga, (even if it is bad news!) :) | 09:04 |
| morphis_ | zyga: ping | 09:06 |
| mup | PR snapd#2095 opened: snapstate: fix hanging `snap remove` if a try mount dir is no longer mounted <Created by mvo5> <https://github.com/snapcore/snapd/pull/2095> | 09:11 |
| zyga | morphis_: hey | 09:14 |
| morphis_ | zyga: hey! | 09:19 |
| morphis_ | zyga: you came forward yesterday with the /media share work? | 09:19 |
| zyga | morphis_: some, I'm working on that now | 09:19 |
| morphis_ | zyga: I read yesterday here that you're out tomorrow and on friday, so you want to complete it today? | 09:20 |
| zyga | morphis_: yes | 09:20 |
| mup | PR snapcraft#716 closed: Add Waf plugin (LP: #1611335) <Created by cpaelzer> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/716> | 09:20 |
| morphis_ | zyga: ok, then please lets discuss later today where you stop with this and what the status is | 09:22 |
| zyga | ok | 09:22 |
| zyga | sounds good | 09:22 |
| morphis_ | zyga: I guess for the feature-freeze this needs to be done today anyway, right? | 09:32 |
| zyga | morphis_: I don't know | 09:33 |
| zyga | morphis_: gustavo said we might do this after ff and just treat it as a bug | 09:33 |
| zyga | morphis_: but my plan is to do it today | 09:33 |
| mup | PR snapd#2096 opened: tests: check for failure creating user on managed ubuntu-core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2096> | 09:33 |
| ogra_ | mvo, i was waiting for the store to support auto landing (it was still failing yesterday on "type: os") | 09:39 |
| ogra_ | but yeah, as i said yesterday, i'm plainning to set that up today | 09:40 |
| ara | hello! can I set up any env variable so that "snap login" uses the staging SSO site? | 09:41 |
| ogra_ | zyga, a line or two in bug #1630492 would have avoided the heart attack i just had :P | 09:49 |
| mup | Bug #1630492: /var/lib/extrausers is wrong in all-snap <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1630492> | 09:49 |
| ogra_ | (though whats wrong about it ?) | 09:50 |
| mup | PR snapd#2085 closed: many: check installation of slots and plugs against declarations <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2085> | 10:07 |
| sborovkov | hmm, when I do snap revert for snap installed in devmode does it keep devmode? | 10:18 |
| zyga | ogra_: whaaat? | 10:18 |
| zyga | ara: pedronis would probably know this | 10:18 |
| zyga | ogra_: it's empty :) fixing it now | 10:18 |
| sborovkov | yeah, it does not... Does that even make any sense? | 10:19 |
| mup | PR snapd#2097 opened: snap: add `snap is-managed` for console-conf <Created by mvo5> <https://github.com/snapcore/snapd/pull/2097> | 10:20 |
| ara | zyga, thanks | 10:21 |
| ara | pedronis, question was whether there was an env variable (or other method) so that snap login points to the staging SSO site | 10:21 |
| pedronis | ara: yes, but it needs to be set of snapd, so you need some kind of /etc/systemd/system/snapd.service.d/local.conf and setting USE_STAGING_STORE=1 there, but also you need a specially built with snapd | 10:24 |
| pedronis | s/of snapd/for snapd/ | 10:24 |
| ara | pedronis, but does USE_STAGING_STORE set, also sets staging SSO? | 10:25 |
| pedronis | ara: yes | 10:25 |
| pedronis | it points everything to staging | 10:25 |
| ara | pedronis, OK, I will try that | 10:25 |
| ara | " but also you need a specially built with snapd" | 10:25 |
| ara | ? | 10:26 |
| ara | what does that mean | 10:26 |
| pedronis | ara: if you do anything that involves getting assertions you need a snapd with the staging root key | 10:26 |
| pedronis | otherwise it will try to verify with only the prod one and that won't work | 10:26 |
| ara | pedronis, how do you do that? a snapd with the staging root key | 10:27 |
| pedronis | ara: are you on classic? or using an all-snaps image? | 10:27 |
| ara | pedronis, classic | 10:28 |
| pedronis | ara: you need a deb of snapd built with something like DEB_BUILD_OPTIONS='nocheck testkeys' dpkg-buildpackage -tc -b -Zgzip or building snapd with go and replacing your system one | 10:30 |
| ara | pedronis, OK, will try that | 10:30 |
| ara | pedronis, | 10:30 |
| ara | pedronis, thanks | 10:30 |
| pedronis | ara: if you just build with go : go build -tags withstagingkeys ./cmd/snap and go build -tag withstagingkeys ./cmd/snapd should do the trick | 10:32 |
| * pedronis lunch | 10:32 | |
| sborovkov | Hello. How do I revert snap revert? snap refresh does not work it seems | 10:33 |
| ara | pedronis, cool, will try that | 10:33 |
| zyga | sborovkov: "snap revert" | 10:37 |
| mup | Bug #1630520 opened: snap login error message incorrect <Snappy:Triaged by chipaca> <https://launchpad.net/bugs/1630520> | 10:39 |
| sborovkov | zyga: wait won't it revert to even more previous version? | 10:39 |
| sborovkov | zyga: also how does that make any sense that snap revert removes devmode... | 10:40 |
| popey | hm. I have a pi2 which auto updated overnight and now won't boot | 10:42 |
| popey | http://paste.ubuntu.com/23279200/ hangs at Starting kernel... | 10:42 |
| ogra_ | popey, anything on screen or serial ? | 10:43 |
| popey | yes ^ | 10:43 |
| ogra_ | hmm, weird | 10:43 |
| popey | i have two pi's (a pi 2 and a pi 3) on daily images and the pi3 came back okay, but pi2 didn't | 10:44 |
| ogra_ | well, nothing changed in the kernel | 10:45 |
| popey | sorry, I have them the wrong way round, pi2 came back, pi3 didn't it seems | 10:45 |
| popey | i need to put stickers on my pis to idenify them :) | 10:47 |
| ogra_ | the pi3 has a white plastic bar on the top | 10:49 |
| ogra_ | at least mine does | 10:49 |
| zyga | sborovkov: look at --help | 10:50 |
| ogra_ | mvo, so the auto-builds are set up, but since the store still doesnt accept them i wont set up a cron entry until i heard back from roadmr that the fixes landed (like i said yesterday as well) | 10:51 |
| zyga | sborovkov: 12:47 < popey> i need to put stickers on my pis to idenify them :) | 10:51 |
| zyga | ogra_: plastic bar? | 10:51 |
| zyga | ogra_: photo? | 10:51 |
| popey | mine are in cases | 10:52 |
| popey | i need to put a sticker on the case | 10:52 |
| popey | I saw some nice transparent cases recently, which will help | 10:52 |
| ogra_ | mvo, also note that the store now blocks *all* subsequent uploads if there was one failure in one revision upload | 10:52 |
| sborovkov | ogra_: oh wow. Now I know how to differentiate my RPIs. Never noticed that bar before | 10:54 |
| ogra_ | zyga, similar to the pi1 in that pic mine has that white plastic thingy (vs the same part in black on the left one) https://www.pretzellogix.net/wp-content/uploads/2015/08/flirc-rpi-3.jpg | 10:54 |
| ogra_ | next to the headphone jack ... | 10:54 |
| sborovkov | ogra_: to be fair though it also says the model in text if you don't have it without case | 10:54 |
| ogra_ | but very fine print :) | 10:55 |
| popey | old man eyes | 10:57 |
| popey | http://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/ is useful if you "grep Revision /proc/cpuinfo" :) | 10:57 |
| zyga | ahh | 10:57 |
| zyga | ogra_: you mean the flat-flex connector latch | 10:58 |
| popey | anyway, what can I do with this pi3 that won't boot? | 10:58 |
| ogra_ | zyga, yeah, the bar :P | 10:58 |
| zyga | :D | 10:58 |
| nhaines | popey: well, if you leave it running it's probably nice for a small space heater. | 10:58 |
| popey | should I get something off the sd card? logs or somesuch? | 10:58 |
| zyga | the thing ;-) | 10:58 |
| ogra_ | popey, hard reset | 10:58 |
| popey | ogra_: que? | 10:58 |
| ogra_ | youo wouldnt get anything off the card anyway before anything is mounted | 10:58 |
| ogra_ | so just reset it | 10:59 |
| popey | as in, dd a new image on it? | 10:59 |
| ogra_ | you can indeed check via HDMI | 10:59 |
| ogra_ | if there is an oops or so | 10:59 |
| ogra_ | but beyond that, just do a reset | 10:59 |
| ogra_ | popey, that power plug thing ... pull it and plug it in again :P | 10:59 |
| popey | hah, okay | 11:00 |
| ogra_ | (i would have said re-flash otherwise ;) ) | 11:00 |
| popey | I was hoping for some leet reset tool :) | 11:00 |
| popey | indeed, "reset" has other connotations for me, "reboot" might work ;) | 11:00 |
| popey | also as we call it in our house "Do a Daddy Pig" | 11:01 |
| * ogra_ notes that down for next time :) | 11:01 | |
| === hikiko is now known as hikiko|ln | ||
| popey | https://www.youtube.com/watch?v=fxqw0am27Fk is the episode in question | 11:02 |
| mup | Bug #1572175 changed: change finished in status "Hold" with no error message <amd64> <apport-bug> <sdoc> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572175> | 11:03 |
| mvo | ogra_: ok, thanks | 11:06 |
| popey | ogra_: magically came back after a reboot :S | 11:08 |
| mup | PR snapcraft#852 opened: Simplify the parser tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/852> | 11:11 |
| ogra_ | popey, yeah, i thought so, there is a mystical OOPS that we are still trying to debug ... ppisati didnt get further on that one either and i didnt manage to capture it yet | 11:16 |
| popey | ogra_: ok, thanks | 11:16 |
| ogra_ | mvo, once enabled core info for the auto-builds will be at http://people.canonical.com/~ogra/core-builds/ (much like http://people.canonical.com/~ogra/ubuntu-core-builds/ was for ubuntu-core before) | 11:19 |
| sborovkov | zyga: btw "look at help" does not have anything about devmode or whatever. Idk I might be on old version though. Not going to update until that issue that makes snaps not working becase of cross architecture stuff is fixed... | 11:19 |
| mvo | ogra_: neato | 11:23 |
| zyga | sborovkov: oh, yes, perhaps it is not released yet, I'm running master | 11:25 |
| zyga | sborovkov: I think behavior changed and it should not behave as you expect | 11:25 |
| ogra_ | cjwatson, is there any specific reason why s3390x and ppc64el do not publish their manifest files (i see in the log that they built) | 11:37 |
| ogra_ | -3 | 11:37 |
| mup | PR snapd#2098 opened: store: retry store operations (WIP) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2098> | 11:39 |
| cjwatson | ogra_: s390x hasn't been upgraded to the new launchpad-buildd because I'm lazy; ppc64el hasn't been upgraded for some mysterious reason we've yet to properly investigate | 11:41 |
| cjwatson | (its image upgrader script is probably broken somewhere ...) | 11:41 |
| ogra_ | ah, ok ... it isnt that important anyway, just curiosity ... i doubt anyone but me cares :) | 11:42 |
| cjwatson | ogra_: I'll take care of s390x at least, ppc64el will be a bit of a when-we-get-round-to-it | 11:45 |
| === hikiko|ln is now known as hikiko | ||
| ogra_ | yeah, dont put it on to high prio, i doubt there are even many users on these arches atm | 11:46 |
| ogra_ | (i wish i could look up the numbers, but the store times out when i click on "stats" for ubuntu-core :) ) | 11:46 |
| ogra_ | hah, and saying tht, this time it didnt | 11:47 |
| ogra_ | but no downloads by arch :( | 11:47 |
| cjwatson | Mainly I just like having production revisions of things in sync where possible. | 11:52 |
| * ogra_ notes mvo is a busy bee manually approving stuff in the store :) | 11:53 | |
| * ogra_ thinks this new store behaviour of blocking the world is insane ... approving a set now takes ages since you have to wait for the next fail first | 11:56 | |
| mup | PR snapd#2099 opened: docs/hooks.md: fix typos <Created by pedronis> <https://github.com/snapcore/snapd/pull/2099> | 12:02 |
| === dholbach_ is now known as dholbach | ||
| daker | hi snapcraft question, how can i tell the make plugin to run two make commands (make something then make) ? | 12:06 |
| zyga | daker: write the make rules so that you don't have to | 12:06 |
| daker | zyga: what do you mean ? write another Makefile that will run thoses make commands ? | 12:07 |
| zyga | daker: if you can control the original makefile just change that | 12:08 |
| daker | zyga: no i don't have control that's an upstream project, and the first make commands is from a submodules | 12:09 |
| ogra_ | well, a toplevel makefile would likely work ... just put your upstream project in a subdir and have the toplevel makefile drive everything | 12:10 |
| hikiko | just for the record I found a solution for my problem with the libcuda1-361 package but it was a hack: I edited the /var/lib/dpkg/info/libcuda1-361.prerm and put an "exit 0;" at the beginning so that the script doesn't run, then I purged nvidia* and libcuda1* and then I had no issues | 12:13 |
| morphis_ | zyga: how are things going? | 12:24 |
| === ycheng-afk is now known as ycheng | ||
| zyga | morphis_: I'm having issues using all-snap systems | 12:31 |
| zyga | morphis_: fighting console-conf | 12:32 |
| morphis_ | zyga: what kind of issues? | 12:32 |
| zyga | i cannot log in | 12:32 |
| morphis_ | zyga: do you have a ssh key registered with your sso account? | 12:34 |
| zyga | ah, I think I know what the problem is | 12:34 |
| zyga | trying again | 12:34 |
| zyga | yes, certainly, I was just using the wrong key to log in | 12:34 |
| zyga | morphis_: I'm in :) | 12:43 |
| mup | PR snapd#2100 opened: store: local users download from the anonymous url <Created by matiasb> <https://github.com/snapcore/snapd/pull/2100> | 12:44 |
| morphis_ | zyga: ah | 12:44 |
| * ogra_ hands zyga a lockpick for the next time | 12:44 | |
| mup | PR snapd#2099 closed: docs/hooks.md: fix typos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2099> | 12:45 |
| ogra_ | mvo, if someone sends me an updated set of official assertions i can also set up the dailies to use core by default btw | 12:46 |
| ogra_ | (if snapd is ready for that already indeed) | 12:46 |
| popey | anyone seen this before:- popey@localhost:~$ sudo snap refresh | 12:54 |
| popey | error: cannot refresh []: cannot refresh snap-declaration for "pi2": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/ZbHoNCV2YMyGLhAf1U9SLaOvuVD02Sqs: dial tcp: lookup assertions.ubuntu.com: no such host | 12:54 |
| popey | hmm, dns issue on that box... odd. | 12:55 |
| morphis_ | ogra_: is it known that the pi3 kernel crashes quite often on edge? | 12:59 |
| ogra_ | morphis_, there is a known oops on boot, if you can capture something please give it to ppisati | 13:02 |
| ogra_ | beyond that my pi is rock solid | 13:02 |
| morphis_ | ogra_: yeah happens always at boot, something with the uart | 13:03 |
| ogra_ | rather withthe wifi | 13:03 |
| morphis_ | will take a picture next time | 13:03 |
| ogra_ | thx | 13:04 |
| morphis_ | ogra_: but it corrupts the whole firstboot so I have to reflash my sdcard | 13:04 |
| ogra_ | yep | 13:05 |
| ogra_ | annoying.... | 13:05 |
| zyga | jdstrand: hey, can you look at https://github.com/snapcore/snap-confine/pull/162/files | 13:06 |
| mup | PR snap-confine#162: Set PATH unconditionally even if mount namespace is set up <Created by zyga> <https://github.com/snapcore/snap-confine/pull/162> | 13:06 |
| ogra_ | it works with wired networkfor me though | 13:06 |
| zyga | jdstrand: I'm making a tiny tweak to the test but it's just polish, the semantics is okay as is | 13:06 |
| jdstrand | zyga: yeah, I am looking at it now | 13:11 |
| zyga | jdstrand: I need to cook a new release | 13:11 |
| zyga | jdstrand: so those two are going in for sure | 13:11 |
| zyga | jdstrand: I also merged this just a moment ago: https://github.com/snapcore/snap-confine/pull/163 | 13:12 |
| mup | PR snap-confine#163: Disable quirks on all-snap systems <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/163> | 13:12 |
| jdstrand | zyga: does the lxd snap continue to work on all snaps? | 13:17 |
| zyga | jdstrand: that is irrelevant as the quirk was only meaningful in classic, /var/lib/lxd doesn't exist in the core snap | 13:20 |
| zyga | jdstrand: AFAIK it never worked there | 13:20 |
| zyga | but again, this is irrelevant for this reason | 13:20 |
| jdstrand | zyga: I was thinking perhaps this did work before because this created the /var/lib/lxd directory | 13:21 |
| zyga | jdstrand: it cannot create that directory | 13:21 |
| jdstrand | but maybe lxd does that already. idk. seems at least worth testing if it worked before and now doesn't so you could let the lxd guys know the snap will break on all snaps | 13:22 |
| zyga | jdstrand: on all-snap /var/lib is on the core snap, there's no mount point for /var/lib/lxd | 13:22 |
| zyga | root@localhost:~# mkdir /var/lib/lxd | 13:22 |
| zyga | mkdir: cannot create directory ‘/var/lib/lxd’: Read-only file system | 13:22 |
| jdstrand | well, right, which is partly what the quirk dealt with, no? | 13:22 |
| zyga | no, the qurik only made the host's version of /var/lib/lxd show up | 13:23 |
| zyga | if there was one | 13:23 |
| zyga | but there's no /var/lib/lxd here and the idea of "hostfs" is meaningless | 13:23 |
| jdstrand | hmm, I guess that's true | 13:23 |
| ogra_ | om26er, while i appreciate https://code.launchpad.net/~om26er/core-snap/improve_build_script/+merge/307640 (a lot actually, my python is usually awful) ... there is sadly no python3 on any of the servers these scripts run on | 13:24 |
| diddledan | could someone enlighten me as to why my corebird experiment isn't showing up in the unity menu when I've installed it? I'm thinking it might be related to my use of an svg icon(?) otherwise I feel I must have seriously misunderstood the setup of the desktop file | 13:24 |
| diddledan | https://github.com/diddledan/corebird-snap | 13:24 |
| om26er | ogra_, oh, fun ;) | 13:24 |
| ogra_ | the datacenter runs mostly on 12.04 | 13:24 |
| om26er | ogra_, no problem, its only a matter of a few months when 12.04 goes EOL and I can resurrect my branch ;) :p | 13:25 |
| ogra_ | heh, well, i can merge it into a lp-build-core-py3 or so | 13:26 |
| ogra_ | so we are future proof | 13:26 |
| ogra_ | morphis_, bug 1627643 btw | 13:27 |
| mup | Bug #1627643: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1627643> | 13:27 |
| morphis_ | ogra_: different one here: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1630586/ | 13:38 |
| mup | Bug #1630586: Pi3 kernel crash and is unreliable <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586> | 13:38 |
| ogra_ | how do you know it is different ? | 13:38 |
| morphis_ | ogra_: it crashes reliable at the same point here | 13:39 |
| ogra_ | same here | 13:39 |
| morphis_ | and there is nothing which relates to wifi | 13:39 |
| ogra_ | and after the crash there is no wlan device setup possible | 13:39 |
| morphis_ | ogra_: actually you can't even get into the device with this crash | 13:40 |
| ogra_ | oh, it hangs hard ? | 13:40 |
| morphis_ | yes | 13:40 |
| ogra_ | then it actually is different | 13:40 |
| mup | Bug #1630586 opened: Pi3 kernel crash and is unreliable <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586> | 13:40 |
| morphis_ | ppisati: https://bugs.launchpad.net/snappy/+bug/1630586 | 13:41 |
| mup | Bug #1630586: Pi3 kernel crash and is unreliable <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586> | 13:41 |
| ogra_ | for me i see the oops pass by but after a while (1-2 min) i get the "please press enter" prompt and can set up the device | 13:41 |
| ogra_ | only with wired though | 13:41 |
| zyga | jdstrand: 1.0.43 released | 13:57 |
| zyga | jdstrand, ara: we should get it into yakkety and override the SRU to use it | 13:57 |
| zyga | it contains two fixes, one is very important and affects xenial | 13:57 |
| mup | PR snapcraft#852 closed: Simplify the parser tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/852> | 14:12 |
| cjwatson | ogra_: You should get s390x manifests now. | 14:17 |
| ogra_ | cjwatson, yay, thanks ! | 14:17 |
| morphis_ | kyrofa: is this expected that snapd takes authority over the current configuration settings I can set via the config hook? | 14:17 |
| mup | PR snapd#2100 closed: store: local users download from the anonymous url <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2100> | 14:23 |
| ogra_ | niemeyer, dbarth, so just in time for the meeting i had two WiFi SD cards and an adapter arrive :) | 14:27 |
| * ogra_ is just unpacking them here | 14:27 | |
| didrocks | sergiusens: hey! I think I found a regression (or case that wasn't tested) in the go plugin with go-importpath | 14:28 |
| dbarth | ogra_: ah nice | 14:28 |
| didrocks | sergiusens: source: ., go-importpath: <matching-my-project-import-url>. I see that parts/go/src/<myproject-url> is still the git branch and not the local source | 14:29 |
| niemeyer | ogra_: Oh, nice | 14:29 |
| niemeyer | ogra_: Looking forward to the news there! | 14:29 |
| didrocks | sergiusens: so, local modification aren't reflected, I guess that's a bug and that was the purpose of importpath, correct? | 14:29 |
| ogra_ | i'll report back what works and what doesnt once i had some time to play with them | 14:29 |
| * ogra_ shakes fist at google | 14:31 | |
| ara | pedronis, I have built the debs with the parameters you mentioned and installed the new .debs, yet snap login cannot find the account that was created in staging | 14:34 |
| ara | pedronis, (and I have USE_STAGING_STORE=1) | 14:35 |
| pedronis | ara: you can turn on debugging with SNAPD_DEBUG_HTTP=1 (only requests) or SNAPD_DEBUG_HTTP=7 (everything) | 14:37 |
| pedronis | and look at syslog | 14:37 |
| morphis_ | zyga: you got it working already? | 14:37 |
| ara | pedronis, trying | 14:37 |
| zyga | morphis_: I fixed two issues in snap-confine, iterating on the problem | 14:38 |
| zyga | morphis_: (the problem==/media) | 14:38 |
| zyga | morphis_: I need to rebase it on top and try again, fingers crossed but outlook is positive | 14:39 |
| morphis_ | zyga: ok, you think we need a plan to accommondate you being away starting tomorrow? | 14:39 |
| morphis_ | zyga: if yes, lets bring that up in the team meeting | 14:40 |
| kyrofa | morphis_, I'm not sure what you're asking about the configuration settings | 14:40 |
| ara | pedronis, mmm, syslog doesn't give me a lot of info: Oct 5 16:39:01 sushirider /usr/lib/snapd/snapd[7573]: daemon.go:174: DEBUG: uid=0;@ POST /v2/login 1.734880238s 401 | 14:42 |
| ara | pedronis, (for example, whether it is correctly pointing to staging) | 14:42 |
| pedronis | ara: seems the wway you are turning on those env var is wrong | 14:42 |
| pedronis | you should get a lot of spam | 14:42 |
| pedronis | with SNAPD_DEBUG_HTTP | 14:42 |
| om26er | How do I get pip on all-snaps ? | 14:43 |
| ogra_ | you ue it in snapcraft ;) | 14:43 |
| ogra_ | *use | 14:43 |
| morphis_ | kyrofa: I started to play with it now that my hook is called and saw that the actual configuration state is stored in the snap which seems to be applied again when a new snap revision is installed | 14:44 |
| morphis_ | kyrofa: which conflicts a bit if the snap has other mechanisms to change the same configuration items | 14:44 |
| morphis_ | s/stored in the snap/stored in snapd/ | 14:45 |
| kyrofa | morphis_, how is it applied again when a new revision is installed? | 14:46 |
| kyrofa | Are you saying the hook is called again? | 14:46 |
| morphis_ | yes | 14:46 |
| ara | pedronis, I have them set up at /etc/systemd/system/snapd.service.d/local.conf | 14:46 |
| ara | pedronis, what's the right way? | 14:46 |
| pedronis | that's one of the ways | 14:46 |
| pedronis | one sec | 14:47 |
| morphis_ | kyrofa: so "snap install my.snap" gives me a call on the configure hook where I then look into the existing config items via snapctl | 14:47 |
| morphis_ | kyrofa: however those might be already overriden by something inside the snap | 14:47 |
| pedronis | ara: this what our tests do (just making sure we are on the same page): http://pastebin.ubuntu.com/23280119/ | 14:48 |
| ara | pedronis, definitely different, thanks for the pointer! | 14:48 |
| pedronis | replace SNAP_REEXEC=0 with USE_STAGING_STORE=1 | 14:48 |
| kyrofa | morphis_, huh... I only added a hook call when `snap set` is called, I'm not sure why it would be called upon install | 14:48 |
| pedronis | ara: those conf are overrides, they follow systemd unit syntax | 14:49 |
| morphis_ | kyrofa: so I am wondering who has authoritive over the current state of the configuration, the snap itself or snapd? | 14:49 |
| pedronis | ara: sorry I wasn't super clear when I mentioned that | 14:49 |
| om26er | ogra_, won't I be able to just pip install something ? | 14:49 |
| ara | pedronis, no worries, thanks a lot for the help | 14:49 |
| kyrofa | morphis_, we wanted it to be held within snapd, otherwise every snap would need some way to store it and respond to queries about it | 14:49 |
| ogra_ | om26er, nope ... and python is not even guaranteed to be on the core snap | 14:50 |
| morphis_ | kyrofa: so how can something inside the snap change the configuration? calling snap set? | 14:50 |
| ogra_ | the only things we guarantee are snapd, systemd and /bin/sh | 14:50 |
| ogra_ | everything else can change at any time | 14:50 |
| kyrofa | morphis_, admittedly we need a way to ask the snap for its configuration so we can initialize it within snapd | 14:50 |
| om26er | ogra_, a snap for pip, maybe ? | 14:50 |
| ogra_ | om26er, you can intall the classic snap though .... so you have a "normal" deb env | 14:51 |
| kyrofa | morphis_, something within the snap can change config via `snapctl set`, and get it with `snapctl get` | 14:51 |
| ogra_ | sudo snap install classic --devmode --edge | 14:51 |
| ogra_ | then: sudo classic | 14:51 |
| om26er | ogra_, is that persistent now ? I was once told here that it will be wiped on reboot. | 14:51 |
| ogra_ | that gives you a classic shell env | 14:51 |
| morphis_ | kyrofa: you mean snap set or snap get, right? | 14:51 |
| kyrofa | morphis_, no, snapctl | 14:51 |
| om26er | I do use classic already in virt-manager | 14:52 |
| zyga | morphis_: snapctl is not the same as snap | 14:52 |
| morphis_ | kyrofa: as for snapctl you need SNAP_CONTEXT being set | 14:52 |
| ogra_ | it wont be wiped ... but services started in that enmv wont be started | 14:52 |
| zyga | morphis_: it uses another socket | 14:52 |
| morphis_ | zyga: I know | 14:52 |
| kyrofa | snap get/set is for a user, it'll cause the hook to be called | 14:52 |
| kyrofa | morphis_, snap get/set allows one to change settings for all snaps | 14:52 |
| ogra_ | *services installed in | 14:52 |
| kyrofa | morphis_, snapctl uses a context generated for hooks to determine the snap which is being altered, so snaps can't alter the config of other snaps | 14:52 |
| morphis_ | kyrofa: so where do I get that context from when I want to change the config for my own snap from within an application of that snap? | 14:53 |
| kyrofa | morphis_, again though, we're missing a little bit of the picture for config, as you've noticed | 14:53 |
| om26er | ogra_, Whats the footprint you aiming for the core snap ? | 14:53 |
| morphis_ | kyrofa: yeah, but trying to understand what you guys have in mind | 14:53 |
| ogra_ | om26er, aiming for 0 ... :P ... reality is between 60 and 75MB | 14:54 |
| morphis_ | kyrofa: as this conflicts with what we've build for a snap where snap actually has the authority over the configuration data | 14:54 |
| ppisati | morphis_: what's the kernel version? | 14:55 |
| kyrofa | morphis_, long-term I imagine we'll have a hook that runs upon install that the snap can use to pre-load snapd with its config | 14:55 |
| === JanC is now known as Guest96823 | ||
| === JanC_ is now known as JanC | ||
| kyrofa | morphis_, or something similar | 14:55 |
| niemeyer | kyrofa: Not long term, today | 14:55 |
| kyrofa | niemeyer, we have that today? | 14:55 |
| morphis_ | ppisati: added the kernel snap rev to the bug | 14:55 |
| niemeyer | kyrofa: Yep ;) | 14:56 |
| morphis_ | niemeyer: how? :-) | 14:56 |
| kyrofa | niemeyer, ha! | 14:56 |
| ppisati | morphis_: 4.4.0-1023-raspi2 29 apparently | 14:56 |
| niemeyer | morphis_: The configure hook is called on every install and every refresh of the snap | 14:56 |
| morphis_ | ppisati: yeah, just verified: 4.4.0-1023-raspi2 #29 | 14:56 |
| niemeyer | morphis_: What exactly are you looking for? | 14:56 |
| ogra_ | thats the current one | 14:56 |
| kyrofa | niemeyer, even without a configuration? | 14:56 |
| niemeyer | kyrofa: Right | 14:57 |
| morphis_ | niemeyer: nothing urgent we have to discuss now if you have more important things to do for feature-freeze | 14:57 |
| kyrofa | morphis_, so upon first install, the snap can just `snapctl set` its config, basically | 14:57 |
| niemeyer | morphis_: Well, I'd like to clarify these points now, to ensure we don't have confusion on this area | 14:57 |
| morphis_ | niemeyer: just trying to understand how these things are supposed to work as we have a snap which assume it has the authority over its configuration data which slightly conflicts with what snapd does with the config hook | 14:57 |
| kyrofa | morphis_, the snap still has authority, it just doesn't have the responsibility of storing it all. It can still change configs and veto change requests | 14:58 |
| niemeyer | morphis_: Every snap can continue to have authority of its configuration, and they don't even have to implement the configure hook | 14:58 |
| niemeyer | morphis_: snap set will fail if the configure hook is not in place, telling the user that's the case | 14:58 |
| ogra_ | ppisati, perhaps i'm missing something in th config.txt for that image ? http://paste.ubuntu.com/23280174/ | 14:59 |
| morphis_ | niemeyer: yeah sure, but having a generic mechanism would make sense | 14:59 |
| morphis_ | to not reinvent the wheel again and again | 14:59 |
| niemeyer | morphis_: Yes, and we've implemented that generic mechanism.. | 14:59 |
| morphis_ | niemeyer: yeah, which is great :-) | 14:59 |
| morphis_ | niemeyer: as said, I don't say its incorrect or wrong, I am just trying to understand how its supposed to work :-) | 15:00 |
| niemeyer | morphis_: Right now snapctl get/set must be done from within a hook (any hook), but in the near future the snap as a whole will be able to use snapctl anywhere, and adjust its configuration accordingly | 15:00 |
| morphis_ | niemeyer: yeah, that was the point I was missing | 15:01 |
| niemeyer | morphis_: Every time snap get/set is done, the configure hook is called again, and has a chance to adjust its configuration in any way it wants, and it may also reject the configuration proposed | 15:01 |
| om26er | ogra_, on another question, can I assume that installation of an all-snap Ubuntu Personal (read: desktop) would technically be even faster than it is today ? Just dump of the image on the partition and account setup ? | 15:01 |
| ogra_ | om26er, well, it'd be closer to a phone or the M10 tablet we have today ... but yeah, dump it to disk and a (graphical) first-setup too runs | 15:02 |
| ogra_ | *too | 15:03 |
| ogra_ | pfft | 15:03 |
| morphis_ | niemeyer: with the sync mechanism via snapctl set it makes more sense as then I can tell snapd when something else has changed the configuration item | 15:03 |
| ogra_ | *tool | 15:03 |
| niemeyer | morphis_: The configure hook is called with the _whole_ configuration, not just the requested changes | 15:03 |
| niemeyer | morphis_: Yes, that's what the earlier point addresses | 15:03 |
| niemeyer | This, specifically: | 15:04 |
| niemeyer | 12:00:34 <niemeyer> morphis_: Right now snapctl get/set must be done from within a hook (any hook), but in the near future the snap as a whole will be able to use snapctl anywhere, and adjust its configuration accordingly | 15:04 |
| morphis_ | niemeyer: what you mean with the whole configuration? I have to do a snapctl get call to get specific items in my configure hook implementation | 15:04 |
| niemeyer | morphis_: That's right.. I just mean the whole configuration is at hand | 15:04 |
| morphis_ | ah | 15:04 |
| niemeyer | morphis_: Not just the delta that was requested via snap set | 15:05 |
| morphis_ | niemeyer: what about the changes stored in the snapd transaction database, when I revert to an earlier revision of a snap are all configuration changes reverted back to that revision as well? | 15:06 |
| niemeyer | morphis_: Not yet, but I'm planning to fix that for the RC | 15:06 |
| niemeyer | Have a good idea for how to do that in a simple way already | 15:07 |
| om26er | Whats the speed difference of reading a file from ext4 and reading from a squashfs based snap(do we use compression of some sort?) place on ext4, have we measured that ? | 15:07 |
| elopio | sergiusens: kyrofa: does this make sense? https://github.com/elopio/QGIS/blob/snapcraft/snapcraft.yaml#L66 | 15:09 |
| elopio | I had to move the stage packages to a different part, because otherwise it wouldn't find them during build. | 15:09 |
| kyrofa | elopio, so it only looks in stage, eh? | 15:10 |
| kyrofa | elopio, although you don't use `after` it seems? | 15:10 |
| kyrofa | elopio, oh nevermind, I'm blind | 15:10 |
| kyrofa | elopio, how does qgis find deps? cmake modules? pkg-config? | 15:11 |
| kyrofa | elopio, those deps, specifically | 15:11 |
| elopio | lots of cmake find modules | 15:11 |
| kyrofa | elopio, let me take a look, hold on | 15:12 |
| ogra_ | morphis_, does your pi image with the oops actually use an unmodified config.txt ? i wonder if we are missing something there, the default is http://paste.ubuntu.com/23280174/ | 15:12 |
| elopio | thanks | 15:13 |
| morphis_ | niemeyer: sounds good | 15:13 |
| morphis_ | ogra_: its the default one | 15:13 |
| morphis_ | ogra_: that what comes via ubuntu-image/snap prepare-image | 15:14 |
| ogra_ | ok ... well, i wonder i ppisati might find some missing option regarding the uart there | 15:14 |
| ogra_ | morphis_, right, straight from the gadget snap | 15:14 |
| ppisati | ogra_: i'm flasging an image that i just preapared | 15:14 |
| ogra_ | oki | 15:14 |
| elopio | ralsina: I think I removed the coverage checks on integration and snaps tests. But it makes sense to check the coverage of unit tests. If a line is not executed, it's very likely that it should be removed, don't you think? | 15:15 |
| ppisati | using the model posted in lp1630586 | 15:15 |
| ppisati | let's see | 15:15 |
| mup | PR snapcraft#853 opened: Simplify the handler from uri tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/853> | 15:15 |
| ralsina | elopio: could be. I was just a it frustrated about being -0.006% but then I removed an unused line ;-) | 15:15 |
| elopio | ralsina: anyway, we don't really pay a lot of attention to those numbers, because coveralls is know to be bad at math. We only care when there's a clear missing test. | 15:16 |
| ralsina | elopio: cool with me :-) | 15:16 |
| ogra_ | morphis_, woah, reading your syslog in bug 1630586 i see a lot of errors i dont see on any standard image ... specifically the squashfs errors are interesting | 15:17 |
| mup | Bug #1630586: Pi3 kernel crash and is unreliable <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586> | 15:18 |
| morphis_ | ogra_: yeah possible that those come after the first boot or so | 15:20 |
| ogra_ | hmm, actually i havent ooked into my syslog of the running pi3 here for a while ... i got the same here | 15:20 |
| ogra_ | this is worrying | 15:20 |
| ogra_ | mvo, ^^^^ did anything regarding squashfs change recently in snapd ? | 15:21 |
| ogra_ | mvo, http://paste.ubuntu.com/23280252/ | 15:21 |
| ogra_ | and thre are a lot more errors | 15:22 |
| SuperJonotron | Trying to figure out the correct way to setup the environment variables for my snap to access the writable sections. I know I can hard code the "current" version of the snap install but it seems like this should be the version number | 15:24 |
| SuperJonotron | not sure how to dynamically grab the version number when the snap launches | 15:24 |
| mvo | ogra_: auto-probe magic for assertion | 15:24 |
| mvo | ogra_: harmless | 15:24 |
| mvo | ogra_: but noisy:/ | 15:24 |
| ogra_ | phew ! | 15:24 |
| ogra_ | that had me shocked for a moment | 15:25 |
| kyrofa | SuperJonotron, have you seen this? https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data | 15:26 |
| SuperJonotron | I have seen that but I was unclear on whether or not just accessing those variables alone would do the trick or if they needed to be initialized | 15:27 |
| kyrofa | SuperJonotron, just accessing them should be enough | 15:28 |
| SuperJonotron | I'll give that a shot. I also have to figure out how the snap can generate a configuration file within it's read only folder where it's packaged or reference it's creation in the SNAP_DATA folder | 15:29 |
| SuperJonotron | is this possible with say a symbolic link? | 15:29 |
| morphis_ | mvo: auto-probe magic for assertions? are they stored in squashfs? | 15:29 |
| ogra_ | likely in /writable | 15:29 |
| ogra_ | but the squashfses are matched against them i guess | 15:30 |
| kyrofa | elopio, hmm... this isn't just using cmake, it actually shells out to python scripts as well | 15:32 |
| kyrofa | elopio, you might need to set those variables for the build | 15:32 |
| elopio | kyrofa: but I think I'm misunderstanding stage packages. Shouldn't they be in the stage dir, before the part builds? | 15:32 |
| kyrofa | elopio, no, they're in the part's installdir | 15:33 |
| kyrofa | elopio, and they get migrated along with the rest of the part to stage | 15:33 |
| elopio | kyrofa: and they get to the installdir, before the part builds? | 15:33 |
| kyrofa | elopio, indeed | 15:34 |
| elopio | kyrofa: so, shouldn't the installdir be added to the paths, just like the stage dir? | 15:34 |
| mvo | morphis_: the code will probe any block device | 15:34 |
| morphis_ | mvo: ah | 15:34 |
| kyrofa | elopio, yeah, that's what I mean to say. The find modules will need a PYTHONPATH looking in the installdir in order to find anything, it seems | 15:35 |
| kyrofa | elopio, but I'm a bit surprised this works with the stagedir, honestly | 15:35 |
| kyrofa | elopio, are you sure pyqt5-dev actually needs to be staged? | 15:36 |
| elopio | kyrofa: well, I meant that it should work magically using installdir, like it does with stage dir ^_^ | 15:36 |
| kyrofa | elopio, haha, I agree! It just means we need to figure out the magic first :P | 15:37 |
| elopio | kyrofa: as a build package, it doesn't find it. | 15:37 |
| kyrofa | elopio, huh, that's interesting | 15:37 |
| elopio | and qgis does some weird things on loading, with python. So I think it's also needed in the final package. But I'm not totally sure. | 15:37 |
| kyrofa | Yeah, whenever I see -dev packages in stage-packages, I know something is off | 15:37 |
| kyrofa | Hmm | 15:37 |
| mup | Bug #1630652 opened: snap revert and refresh forwards and backwards causes breakage <Snappy:New for chipaca> <https://launchpad.net/bugs/1630652> | 15:53 |
| ppisati | ogra_: did you try to generate a pi3 image? | 16:02 |
| ogra_ | ppisati, ? | 16:03 |
| ogra_ | my scripts do that every day, why ? | 16:03 |
| ppisati | ogra_: i'm referring to morphis_ bug | 16:03 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 16:03 |
| ppisati | ogra_: and does your image have that stack trace on boot? | 16:04 |
| * ppisati tries without the eth cable | 16:04 | |
| ogra_ | ppisati, it used to last week ... i havent freshly installed since | 16:04 |
| ogra_ | but nothing changed afaik ... so it should still have it | 16:04 |
| ppisati | ogra_: ok, me tries without the eth cable and then tries your image | 16:05 |
| SuperJonotron | I have an application wrapped up in a snap and running but I know it lacks a license to operate fully and the application will want to write this license into a folder within the application structure (the read only section). I have no control over changing this behavior and need to know how to give this folder writable access when it needs to update and/or create the license file | 16:08 |
| ara | pedronis, OK, it looks now that it takes those env variables into account, as i am getting a lot more debug messages | 16:09 |
| kyrofa | SuperJonotron, you can't tell it where to write with a cli parameter or anything? | 16:09 |
| ara | pedronis, but it looks like it still tries to connect to login.ubuntu.com (instead of loging.staging.ubuntu.com) | 16:09 |
| SuperJonotron | kyrofa, I am porting a piece of existing software into the ubuntu snappy os and so I have limitations on what is exposed. I do have direct contact with the manufacturer so I can double check what I am allowed to do but as of right now, I have not found a way to overwrite this method. What would you suggest a solution be to overwrite the apps behavior to write into the snap environment? | 16:10 |
| ara | pedronis, Oct 5 18:10:23 sushirider /usr/lib/snapd/snapd[21445]: logger.go:66: DEBUG: > "POST /api/v2/tokens/discharge HTTP/1.1\r\nHost: login.ubuntu.com\[...] | 16:11 |
| SuperJonotron | kyrofa, I would also imagine I would need to create a link to the file back into the application where it expects it to be? | 16:11 |
| kyrofa | SuperJonotron, that means the application could never be installed into e.g. /usr/local/bin either, since it's owned as root | 16:11 |
| kyrofa | SuperJonotron, if the app requires where it is to be writable, then really your only option is to copy the entire thing into writable space | 16:12 |
| kyrofa | And run from there | 16:12 |
| kyrofa | SuperJonotron, but that's kinda terrible | 16:12 |
| SuperJonotron | what about just the licensing section and create a link back to the file? | 16:13 |
| SuperJonotron | is that allowed or will the read only status block a link being made? | 16:13 |
| kyrofa | SuperJonotron, you can't write in $SNAP, plain and simple. No files, no links | 16:13 |
| mup | PR snapd#2101 opened: image: support gadget specific cloud.conf file <Created by mvo5> <https://github.com/snapcore/snapd/pull/2101> | 16:15 |
| SuperJonotron | kyrofa, thanks, I'll see if I can work with the manufacturer to overwrite the default licensing folder to reference one of the writable snap locations | 16:15 |
| kyrofa | SuperJonotron, yeah, I'd ask for either a CLI parameter or support for an environment variable | 16:17 |
| elopio | davidcalle: ping. Did you find the mapbox contact? | 16:23 |
| morphis_ | zyga: what's the state now? | 16:26 |
| morphis_ | zyga: can you drop me a mail before you leave tomorrow on where you leave this and what the next steps are? | 16:28 |
| elopio | kyrofa: synapse working \o/ https://gist.github.com/elopio/dffcda326f5b51feedeb09f012ac9a44 | 16:36 |
| zyga | morphis_: yes, sure | 16:43 |
| ogra_ | jdstrand, so mvo said core should auto-land in the store now ? | 16:44 |
| zyga | morphis_: still working on it, testing is slow | 16:44 |
| ogra_ | jdstrand, i.e. i can enable the cron build now ? | 16:45 |
| pedronis | ara: it's my fault, the env var is SNAPPY_USE_STAGING_STORE=1 | 16:48 |
| pedronis | ara: I totally went by memory, and it seems my brain has dropped the prefix | 16:48 |
| zyga | jdstrand: hey, I need your review on this https://github.com/zyga/snapd/pull/2/files | 16:48 |
| mup | PR zyga/snapd#2: Make sure gpio exported before apparmor setup <Created by jocave> <https://github.com/zyga/snapd/pull/2> | 16:48 |
| zyga | jdstrand: joc figured out how to solve the gpio issue but it requires that the permanent slot snippet exports the gpio to userspace | 16:49 |
| zyga | jdstrand: so by the time apparmor snippet needs to be comoputed the gpio directory already exists and we can run realpath on it (dereference all the symlinks) | 16:49 |
| zyga | jdstrand: I think that's okay but I wante to check with you first | 16:49 |
| zyga | joc: ^^ | 16:50 |
| zyga | joc: good work and good thinking :) (unless jdstrand disagrees) I didn't think about it | 16:50 |
| zyga | s/about it/of it/ | 16:50 |
| ogra_ | these wifiSD cards are fun ! | 16:50 |
| zyga | ogra_: do they work? | 16:51 |
| zyga | ogra_: tell me which you got, | 16:51 |
| zyga | I'll drop some to amazon inbox | 16:51 |
| joc | zyga: thanks, lets see what jamie says! | 16:51 |
| ogra_ | zyga, well, i have to solder a serial port on ... seems the documented hacker backdoors hhave been fixed (some of them at least) | 16:51 |
| ogra_ | but i guess we can actually use them for flashing the pi's for testing images | 16:52 |
| ogra_ | they come with a very tiny linux | 16:52 |
| ogra_ | and AP mode ... | 16:52 |
| ogra_ | i guess i can hack the initrd on them to give us a flashsher tool | 16:52 |
| ogra_ | zyga, transcend seems to be hackeble pretty well ... | 16:53 |
| zyga | ogra_: OMG :D | 16:53 |
| ogra_ | i got a toshiba one as well, but that doesnt seem to run linux :/ | 16:53 |
| zyga | ogra_: can you share the link to the product you think is woth getting | 16:54 |
| ogra_ | zyga, https://www.amazon.de/dp/B010MQ13E8 ... i didnt get the transcend one from amazon though | 16:56 |
| ogra_ | they only have the flashair toshiba one in germany atm | 16:56 |
| ogra_ | or eyefi ... | 16:56 |
| ogra_ | but afaik both arent easily hackeable | 16:56 |
| zyga | joc: please add that comment and I'll merge it into my branch | 16:56 |
| zyga | joc: this will update the pull requast | 16:56 |
| zyga | *request | 16:56 |
| zyga | the main one | 16:56 |
| zyga | joc: and if jdstrand gives it a +1 we'll be good to go | 16:57 |
| mup | PR snapd#2093 closed: cmd/snap,ctlcmd: fix behavior of snap(ctl) get <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2093> | 16:59 |
| zyga | ogra_: thanks, it is even cheaper on amazon.es | 16:59 |
| ogra_ | heh | 17:00 |
| * zyga -> afk | 17:02 | |
| zyga | I'll be back later, I need to rest | 17:02 |
| mup | PR snapcraft#853 closed: Simplify the handler from uri tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/853> | 17:03 |
| mup | PR snapd#2101 closed: image: support gadget specific cloud.conf file <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2101> | 17:09 |
| mup | PR snapd#2098 closed: store: retry store operations (WIP) <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2098> | 17:11 |
| jdstrand | ogra_: yes | 17:31 |
| ogra_ | ok, let me try that ... you will have to approve each single one if you lied ;) | 17:32 |
| mup | Bug #1630690 opened: A snap with git fails because it can't access /etc/mailname <Snappy:New> <https://launchpad.net/bugs/1630690> | 17:33 |
| morphis_ | zyga: aye | 17:49 |
| morphis_ | zyga: please just drop me a note per mail where you leave this | 17:51 |
| ogra_ | jdstrand, GOSH ! ... IT WORKS ! | 17:59 |
| ogra_ | :) | 17:59 |
| ogra_ | http://people.canonical.com/~ogra/core-builds/ ... | 18:00 |
| ogra_ | :) | 18:00 |
| rharper | hi, looking for any docs on creating assertions, like account and account-id; I want to test out creating assertions, signing them and acking them; I see various assertions in the snapd source but not sure of the required key and inputs | 18:03 |
| jdstrand | ogra_: yay :) | 18:07 |
| === fginther` is now known as fginther | ||
| om26er | I cannot set password on all-snap image on RPi, it gives me: | 18:09 |
| om26er | om26er@localhost:~$ sudo passwd | 18:09 |
| om26er | passwd: Authentication token manipulation error | 18:09 |
| om26er | passwd: password unchanged | 18:09 |
| sergiusens | om26er shouldn't it be `sudo passwd $USER` ? | 18:10 |
| om26er | sergiusens, my bad, it worked that way. | 18:10 |
| om26er | I am actually used to digitalocean droplets where I am root and `passwd` just works | 18:11 |
| === davmor2_ is now known as davmor2 | ||
| om26er | I have a new project https://github.com/om26er/pigpio, its specifically for the RPi but I haven't been able to find a way to build armhf snap. The only piece I found is https://developer.ubuntu.com/en/snappy/guides/cross-build/ | 18:27 |
| om26er | which doesn't help much as there is no mention of snapcraft in that. Whats the recommended way to build armhf snaps ? | 18:27 |
| om26er | oh, btw upload to snap store was instant, much faster than I had expected. | 18:27 |
| om26er | brb | 18:29 |
| mup | PR snapd#2102 opened: cmd/snap: rename is-managed to managed and tune <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2102> | 18:38 |
| mup | PR snapd#2097 closed: snap: add `snap is-managed` for console-conf <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2097> | 18:47 |
| SuperJonotron | Is there a system variable when running a snap for the current version folder and/or the latest version number? http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data mentions where to find the writable directories but can't seem to find where the app install directory is defined as a variable | 18:48 |
| cjwatson | om26er: You can build armhf snaps on Launchpad | 19:21 |
| om26er | cjwatson, do I need to register my project on launchpad for that ? | 19:22 |
| cjwatson | om26er: Yes. Import the repository to a Launchpad branch (either push the same git repository manually to LP, or cross your fingers and do a git->bzr import, or wait for us to finish git-to-git imports), then you can create a snap package from the LP UI | 19:22 |
| cjwatson | om26er: We'll be automating this further in future | 19:23 |
| cjwatson | I think the guide you found is how to cross-build snapd itself, and it's out of date anyway ... | 19:23 |
| cjwatson | (refers to cmd/snappy, which isn't a thing any more) | 19:24 |
| om26er | cjwatson, ok, I will try that now. | 19:25 |
| om26er | cjwatson, is there a change in future when git becomes the primary version control for Launchpad ? | 19:25 |
| cjwatson | om26er: what would "primary" mean, in your opinion? | 19:25 |
| cjwatson | om26er: I mean, in what particular sense is it not that would be changed by being primary | 19:26 |
| om26er | cjwatson, launchpad code currently rings a be of bzr in my head, while we do have git support, most docs that we see around only refer to bzr. | 19:27 |
| cjwatson | om26er: there are probably a bunch of docs to update spread all over the place, it's a pretty Sisyphean task | 19:27 |
| cjwatson | om26er: many of them not maintained by us either | 19:27 |
| cjwatson | om26er: our git hosting is lacking maybe about two or three substantial features compared to our bzr hosting, but it's definitely the way forward | 19:28 |
| cjwatson | (imports, more useful subscriptions, direct translation commits) | 19:29 |
| om26er | cjwatson, ok, good to know. | 19:29 |
| cjwatson | om26er: shifting ten years of perception is going to take a while no matter what way you slice it though | 19:30 |
| mup | PR snapd#2095 closed: snapstate: fix hanging `snap remove` if a try mount dir is no longer mounted <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2095> | 19:32 |
| mup | PR snapcraft#851 closed: catkin plugin: nicely handle an invalid rosdistro <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/851> | 19:37 |
| kyrofa | Hey jdstrand, I lost track of the seccomp arg filtering, particularly relating to setpriority. Is that stuff still waiting to land? | 19:47 |
| jdstrand | kyrofa: the feature landed. the policy to use it has not. it was deprioritized in favor of a bunch of rtm interfaces and now other rtm/ga stuff. once that stuff is done, I'm back to dbus-app PR and after that, these seccomp arg policy | 19:50 |
| jdstrand | policies | 19:51 |
| kyrofa | jdstrand, sounds good, thanks for the update! | 19:51 |
| jdstrand | np | 19:51 |
| om26er | snap install gives me 401 on all-snap. | 20:04 |
| om26er | something broken in the image or server side ? | 20:04 |
| om26er | om26er@localhost:~$ sudo snap install classic --devmode --edge | 20:09 |
| om26er | error: cannot perform the following tasks: | 20:09 |
| om26er | - Download snap "classic" (17) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/QbSFwGGAgvG8zHl9nWLY7vEee8lhgFsp_17.snap) | 20:09 |
| mwhudson | morning | 20:11 |
| lool | kyrofa: I sense you're about to snap cartografer for ROS! http://opensource.googleblog.com/2016/10/introducing-cartographer.html :-) | 20:15 |
| lool | damn, the laser seems to be 1000 USD | 20:20 |
| lool | there are some 150 USD ones, unidirectional though | 20:23 |
| kyrofa | lool, haha, awesome | 20:30 |
| kyrofa | lool, yeah, stereo SLAM is usually cheaper | 20:32 |
| kyrofa | optical, I mean | 20:32 |
| lool | kyrofa: I wonder if we could do the same kind of mapping with just a sonic depth sensor | 20:33 |
| lool | kyrofa: there is one on the slam dunk | 20:33 |
| lool | NB: running ubuntu and ROS :-D | 20:34 |
| kyrofa | lool, sonic sensors don't typically have great range though-- do you know what that one is? | 20:34 |
| lool | kyrofa: I'm afraid not, but you're right, it was in range at about 1m and out of range at <0.5 and >2m | 20:35 |
| lool | it was more for collisions | 20:35 |
| kyrofa | Yeah that's a typical use-case | 20:35 |
| kyrofa | And for some platforms, it might be enough for mapping (i.e. small and slow-moving) | 20:36 |
| kyrofa | Resolution wouldn't be great | 20:36 |
| rharper | mwhudson: hey; I playing with snap ack and assertions, and I can't seem to construct anything that snap will actually ack; I looked at the json input you used for system-user; but was hoping to have an account and account-id one so I can test out acking multiple assertions ; any pointers to the right json format for account-id or such ? | 20:37 |
| mwhudson | rharper: you need a model where you are the authority, do you have that bit set up? | 20:38 |
| lool | kyrofa: did you manage to move our ros support to indigo before roscon? :) | 20:38 |
| mwhudson | there is a google doc with instructions for that, let me dig it up | 20:38 |
| kyrofa | lool, indigo has been supported for ever. I'm assuming you mean kinetic? Yessir! | 20:38 |
| lool | err sorry kinetic | 20:38 |
| kyrofa | lool, yeah, just landed in 2.19 | 20:39 |
| lool | nice! | 20:39 |
| mwhudson | rharper: https://docs.google.com/document/d/1cJvRnpoQyLvY6pOLFPgUxMHrFVBCDNwAlrORARBiZlU/edit | 20:39 |
| mwhudson | hm that doc could/should probably be updated to include the unattended user creation flow | 20:40 |
| rharper | mwhudson: yeah, I've followed that but I didn't build a new image; I wanted to just ack the system-user (or in my case an account-id ) assertion | 20:41 |
| rharper | mwhudson: but I think you're suggesting that I have to boot into an image with my own model assertion enabled | 20:42 |
| mwhudson | rharper: i don't know about account-id assertions, but for system-user the authority has to be the brand, so you need an image where you can sign for the brand | 20:42 |
| mwhudson | presumably there is/will be some way to sign system-user assertions for the canonical brand but i certainly don't know what that is | 20:42 |
| rharper | mwhudson: right; I'm hoping to test importing any type of assertion via the cloud-init user-data; so I was hoping to have *some* valid assertions that snap could actually ack | 20:42 |
| mwhudson | rharper: ahh | 20:42 |
| rharper | and right now I've got zero | 20:43 |
| rharper | so that makes testing a bit hard | 20:43 |
| mwhudson | rharper: use snap download to download a snap, this also downloads assertions | 20:43 |
| mwhudson | $ snap download hello | 20:44 |
| rharper | ok | 20:44 |
| mwhudson | $ ls hello_20.snap* | 20:44 |
| mwhudson | hello_20.snap hello_20.snap.assertions | 20:44 |
| rharper | indeed | 20:44 |
| mwhudson | i assume snap will ack hello_20.snap.assertions ? | 20:44 |
| mwhudson | haven't tried but seems likely | 20:44 |
| rharper | yay | 20:44 |
| rharper | % sudo snap ack hello_20.snap.assertions | 20:44 |
| rharper | error: cannot assert: cannot decode request body into an assertion: assertion body length and declared body-length don't match: 3494 != 717 | 20:44 |
| rharper | I've been seeing that a lot key body not matching | 20:44 |
| rharper | so maybe I did get one right | 20:44 |
| rharper | hard to tell | 20:45 |
| mwhudson | uhhh | 20:45 |
| mwhudson | now i guess you need someone who knows what they are talking about i guess :) | 20:45 |
| rharper | I'm one step further, so many thanks for your help | 20:46 |
| mwhudson | snap (on my desktop) seems happy with that file | 20:46 |
| rharper | lemme try on a fresh system | 20:46 |
| rharper | who knows what I've got on my laptop | 20:46 |
| caio1982 | rharper, mwhudson: i am not very familiar with ack and dunno if it's a bug or by design but the assertions file download fetches contains *multiple* assertions and ack parses a single one, so you need to split it into (currently) 3: account-key, declaration and revision, then ack will work for each one of them | 20:49 |
| caio1982 | that explains the body-length mismatch above | 20:49 |
| mwhudson | i really thought snap ack was supposed to handle that | 20:49 |
| caio1982 | me too | 20:50 |
| mwhudson | but that would explain the problem indeed | 20:50 |
| caio1982 | but as i said, i dont even use ack right now so i dont know if it's on purpose | 20:50 |
| rharper | caio1982: mwhudson: yes I think that's a bug; I've been told to put multiple assertions into a single file | 20:58 |
| rharper | the assert.Decode() code comments suggests it's similar to a multi-part MIME format, with new lines separating portions | 20:59 |
| rharper | so certainly feels like a bug | 20:59 |
| caio1982 | i would certainly subscribe to it if it was filed ;-) | 21:00 |
| rharper | fwiw, the 717 is the right size for the public-key | 21:00 |
| lool | rharper: hey have you by any chance latest email from MikeB on the devices list? he brings up a bunch of cloud-init start time questions, would you think we could extract some cloud-init runtimes from his system? | 21:01 |
| lool | run times, not runtimes sorry | 21:01 |
| rharper | lool: do we know if the image has the cache purged or not ? | 21:01 |
| lool | rharper: I do not | 21:01 |
| mup | PR snapd#2090 closed: interfaces,overlord/ifacestate: initial cleaning up of no arg AutoConnect related bits <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2090> | 21:02 |
| rharper | the python cache stuff that was discussed on the console-conf thread | 21:02 |
| lool | rharper: https://lists.snapcraft.io/archives/devices/2016-October/000082.html | 21:02 |
| lool | rharper: oh the missing cache creates performance issues? | 21:03 |
| lool | rharper: that might be it, but I'd be surprized it'd be that bad; these switches are supposed to be x86-64, typically some GHz and SSD storage | 21:03 |
| lool | the processing power is not crazy, it's more like a laptop configuration | 21:03 |
| rharper | it's not that bad on x86; it's more likely something to do with the cloud-config | 21:04 |
| lool | Yes, I figured it would be more like timeouts | 21:04 |
| lool | he mentions an instance-data http connection | 21:04 |
| lool | you know, the AWS stuff | 21:04 |
| rharper | and which cloud-init; the version in yakkety until yesterday or so had issues with DNS due to ordering around systemd's dbus socket | 21:04 |
| lool | that seemed weird | 21:04 |
| rharper | right, if those show up, very likely that the no-cloud seed was never embedded | 21:04 |
| lool | rharper: how about I ask these questions and Cc: you on it? | 21:04 |
| rharper | sure | 21:04 |
| lool | rharper: I guess you're not on the devices@ list | 21:05 |
| rharper | I am | 21:05 |
| rharper | I can reply | 21:05 |
| lool | thanks, that'd be great | 21:05 |
| rharper | and if you know how to create account-id or account assertions and be able to ack them; that'd help me work cloud-init importing snap assertions (or point me to who does know) | 21:05 |
| lool | rharper: I wish I knew! :-) | 21:06 |
| lool | rharper: let me check the snap login code | 21:06 |
| lool | rharper: at least I can point at sample data for it; check snapd/tests/main/ack/alice.account | 21:08 |
| rharper | heh | 21:08 |
| rharper | yeah, I'm looking for the json format for account-id or account, so I can pipe that through snap sign, and then snap ack the output of sign | 21:09 |
| mup | PR snapd#2103 opened: store: send correct JSON type of string for expected payment amount <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2103> | 21:09 |
| mup | PR snapd#2102 closed: cmd/snap: rename is-managed to managed and tune <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2102> | 21:12 |
| lool | rharper: so to dump account assertions of a system, snap known account; you can import with snap ack | 21:15 |
| lool | rharper: but I guess you wanted to create the contents from scratch? | 21:16 |
| rharper | that might be good enough | 21:18 |
| tyhicks | jdstrand, zyga: I'm trying to decide if a bug I'm seeing while running a snap inside a lxd container is caused by the container environment or possibly by snap-confine mount oddness - have you seen anything like this before? https://paste.ubuntu.com/23281705/ | 21:25 |
| mup | PR snapcraft#854 opened: Decouple state handling from plugin options <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/854> | 21:34 |
| jdstrand | tyhicks: never seen that | 21:48 |
| jdstrand | tyhicks: but I've not tried running snaps in a container yet | 21:49 |
| jdstrand | getting there | 21:49 |
| tyhicks | jdstrand: no problem, I'm fairly confident that it is a container issue | 21:51 |
| mup | PR snapcraft#855 opened: tools: script to talk to the staging servers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/855> | 21:52 |
| zyga | tyhicks: looking | 22:01 |
| zyga | tyhicks: interesting | 22:02 |
| zyga | tyhicks: is 'd????????? ? ? ? ? ? 27 | 22:02 |
| zyga | tyhicks: is that caused by stat failure? | 22:02 |
| === drizztbsd is now known as timothy | ||
| zyga | do you get any apparmor denials? | 22:02 |
| zyga | tyhicks: to answer, I haven't seen anything like this | 22:03 |
| tyhicks | zyga: that's what happens when a dentry in the kernel doesn't have a corresponding inode (negative dentry) | 22:04 |
| tyhicks | zyga: I'm not sure if there are other situations where that output is display | 22:04 |
| tyhicks | displayed* | 22:04 |
| zyga | tyhicks: oh | 22:04 |
| tyhicks | zyga: there are no apparmor denials | 22:04 |
| zyga | tyhicks: I did see sooome of that | 22:04 |
| rharper | caio1982: mwhudson: snapd 2.16 in xenial-proposed will snap ack the hello.snap.assertion just fine | 22:04 |
| zyga | tyhicks: can you cat mountinfo please? | 22:04 |
| zyga | tyhicks: does it contain "deleted" anywhere? | 22:04 |
| tyhicks | zyga: no "deleted" in mountinfo | 22:05 |
| zyga | tyhicks: I'm sure you know but there are a few pending pull requests on snap confine up | 22:05 |
| rharper | as well as the 'snap known account' output as well ; cool | 22:06 |
| zyga | tyhicks: it looks all sane? | 22:06 |
| zyga | tyhicks: and they relate to lxd | 22:06 |
| tyhicks | zyga: it does look sane | 22:06 |
| tyhicks | zyga: hmmm | 22:06 |
| tyhicks | zyga: btw, this is a yakkety environment with snapd from yakkety-proposed | 22:06 |
| tyhicks | zyga: thanks for your help, I'll file a bug and get some more eyes on the report | 22:07 |
| zyga | tyhicks: please do, I'll try to look at it when I can | 22:09 |
| zyga | I'm off next week though | 22:09 |
| zyga | and tomorrow/day after I'm flying | 22:09 |
| zyga | and then roscon | 22:09 |
| mup | PR snapd#2104 opened: debian, tests: enable spread tests on trusty <Created by vosst> <Conflict> <https://github.com/snapcore/snapd/pull/2104> | 22:09 |
| tyhicks | stgraber: are there still any pending snapd/snap-confine changes (outside of snapd from yakkety-proposed) needed for bug #1611078? I see that you have fix-committed for the Snappy task but I'm not sure what that represents | 22:13 |
| mup | Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <Snappy:Fix Committed by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <https://launchpad.net/bugs/1611078> | 22:13 |
| tyhicks | stgraber: I'm having trouble running snap commands as a normal user inside a container | 22:14 |
| pedronis | rharper: yes, we changed snap ack to take streams of assertions only in 2.16 | 22:15 |
| mup | PR snapcraft#856 opened: Call organize() after building <Created by josepht> <https://github.com/snapcore/snapcraft/pull/856> | 22:25 |
| mup | Bug #1630789 opened: normal users can't run snaps inside of LXD containers <Snappy:New> <https://launchpad.net/bugs/1630789> | 22:28 |
| mwhudson | rharper: ah ok, good to hear | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
