| mwhudson | is there a getting started guide to snappy on the dragonboard? | 00:03 |
|---|---|---|
| mwhudson | oh, it works! | 00:12 |
| mwhudson | slowly | 00:12 |
| mwhudson | and i still don't have serial | 00:12 |
| mup | PR snapd#1700 closed: add mir to implicit for running gui snaps on unity8 classic desktop <Created by kgunnfront> <Closed by kgunnfront> <https://github.com/snapcore/snapd/pull/1700> | 01:35 |
| mup | PR snapd#1948 opened: add run/udev/data paths to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1948> | 02:02 |
| mwhudson | blargh | 04:06 |
| mwhudson | where is the/a dragonboard model assertion? | 04:07 |
| mwhudson | ah http://people.canonical.com/~vorlon/official-models/ | 04:07 |
| slangasek | mwhudson: right, obviously ;) | 04:07 |
| mwhudson | slangasek: where else could they possibly be! | 04:07 |
| mwhudson | slangasek: actually the hardest part was remembering your unix username | 04:08 |
| slangasek | hahaha | 04:08 |
| zyga | o/ | 05:26 |
| dholbach | hey hey | 06:38 |
| didrocks | good morning dholbach | 06:39 |
| dholbach | happy snappy playpen day: https://daniel.holba.ch/blog/2016/09/get-your-software-snapped-tomorrow/ :-) | 06:40 |
| * zyga works on snap-confine SRU paperwork | 06:43 | |
| seb128 | hey dholbach, happy snappy day to you ;-) | 06:51 |
| dholbach | and the same to you seb128! | 06:57 |
| dholbach | nice to see we have a bunch of new bits added to the sandpit: https://github.com/ubuntu/snappy-playpen/wiki/SandPit | 07:10 |
| dholbach | ^ can you add your almost-fully-working snaps to that list too? | 07:11 |
| mup | Bug #1624963 changed: pulseaudio interface (still) missing permissions <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1624963> | 07:24 |
| dholbach | seb128, is https://github.com/wandrewkeech/snappy-playpen/blob/gimp-git/gimp-git/README.md easy to fix? do you know? | 07:42 |
| dholbach | diddledan, does corebird work with devmode? | 07:43 |
| seb128 | dholbach, no idea sorry, I didn't try to use gobjectintrospection in snaps | 07:45 |
| dholbach | ok | 07:45 |
| mwhudson | ogra_: hey i pushed a new probert / subiquity into the canonical-foundations/ubuntu-image ppa today | 07:48 |
| mwhudson | ogra_: copy to snappy-dev/image? | 07:48 |
| mwhudson | quite a lot of fixes | 07:48 |
| === chihchun is now known as chihchun_afk | ||
| diddledan | dholbach: I can't remember. I'll need to check this evening | 07:51 |
| dholbach | cool, thanks diddledan | 07:56 |
| === chihchun_afk is now known as chihchun | ||
| zyga | mwhudson: I'm pushing through the 1.0.41 SRU process, that will probably take all my day; As a part of that I will have to upload it to yakkety | 08:36 |
| zyga | mwhudson: do you think you could do the yakkety upload? | 08:36 |
| mwhudson | zyga: you don't want to upload it to debian and wait until we can sync it, i guess? | 08:37 |
| zyga | mwhudson: no, because we're running out of time | 08:37 |
| mwhudson | zyga: ok | 08:37 |
| zyga | mwhudson: mainly on the SRU overhead | 08:37 |
| zyga | mwhudson: I pushed packaging to git.launchpad.net/snap-confine | 08:38 |
| zyga | mwhudson: the master branch there can be merged into the 16.10 branch for yakkety | 08:38 |
| mwhudson | zyga: want to put the 1.0.41 release on github? | 08:40 |
| zyga | mwhudson: it's there already | 08:40 |
| mwhudson | oh wait you did | 08:40 |
| zyga | mwhudson: yep :) | 08:40 |
| * mwhudson pokes uscan with a stick | 08:40 | |
| zyga | hehe | 08:40 |
| zyga | mwhudson: fedora has a live system where it detects the tag and files an update bug | 08:40 |
| zyga | it's pretty damn impressive | 08:40 |
| zyga | s/damn/darn/ | 08:41 |
| zyga | but fedora will be more complex as I need to work on the /snap move there as well and this needs some more handholding | 08:41 |
| mwhudson | zyga: oh, there's no snap-confine-1.0.41.tar.gz | 08:41 |
| mwhudson | zyga: just the 1.0.41.tgz | 08:41 |
| mwhudson | zyga: do you usually do a make dist & upload that or something? | 08:42 |
| davidcalle | dholbach: I'm writing a snap that uses autotools and doesn't have an install step, how do I get everything in parts/<part>/build into the snap? | 08:42 |
| zyga | mwhudson: oh? that's odd | 08:42 |
| zyga | mwhudson: oh right!!! | 08:42 |
| zyga | mwhudson: let me upload it, I forgot :/ | 08:42 |
| dholbach | davidcalle, custom plugin and copy over? :-( | 08:42 |
| dch | mhall119: ping | 08:42 |
| dholbach | dch, mhall119 lives in the US to it might take a while until he responds | 08:43 |
| dch | aha | 08:43 |
| dholbach | anything anyone else could help with? | 08:43 |
| davidcalle | dholbach: hmmm, I already did one to get rid of the Install step of the default autotools... Yeah, I guess that's the way to go | 08:44 |
| dch | dholbach: thanks. I'm one of the committers for apache couchdb & am working on the debian packages as well atm. so I'm quite interested to pair up wrt snaps. I'm pretty sure I can save him quite a bit of time with questions | 08:44 |
| zyga | mwhudson: done | 08:44 |
| dch | mhall119: ^ I'm in EU time zone but will be online tonight ~ 20h00 UTC if we can cross paths. I'm usually in #couchdb-dev of course | 08:44 |
| dch | dholbach: one of the questions I did have was is it possible to allow a snap to access data dirs from the previous debian-style package | 08:45 |
| kasper | hello, i would like to install Niagara Supervisor on Ubuntu Core. Supervisor need librariers with dependencies, how i can do use APT manager or can i use another manager? | 08:45 |
| dholbach | dch, nice! did anyone of the two of you start the snap journey for couchdb yet? | 08:46 |
| dch | specifically /var/lib/couchdb/ and /var/log/couchdb and /etc/couchdb/ | 08:46 |
| dch | dholbach: apparently he is already underway | 08:46 |
| mwhudson | zyga: so there's no non-trivial packaging changes this time? | 08:46 |
| dch | I have a customer who does medical appliances, so snaps are a little *too* new for them -- updates are very very hard to do, the whole thing needs re-certification. But I hope we can get the community underway very soon. | 08:46 |
| dholbach | dch, yes, that sounds like a good plan :) | 08:47 |
| dholbach | dch, http://snapcraft.io/docs/reference/env explains the world view of a snap quite well | 08:47 |
| zyga | mwhudson: no, it should be a relatively smooth ride | 08:47 |
| zyga | mwhudson: there's a new executable | 08:48 |
| zyga | mwhudson: but nothing else | 08:48 |
| zyga | mwhudson: oh wait | 08:48 |
| zyga | mwhudson: maybe there is | 08:48 |
| zyga | mwhudson: I believe we need to bump our dependency on apparmor | 08:48 |
| mwhudson | zyga: that doesn't seem to be in your packaging? | 08:48 |
| mwhudson | zyga: debian/patches/0001-Don-t-shellcheck-files-spread-prepare-script.patch can be dropped i take it | 08:48 |
| zyga | mwhudson: the packag contains it automatically, no change was required | 08:48 |
| mwhudson | oh ok | 08:48 |
| zyga | mwhudson: (spread tests ran against this packaging all the time so if it wasn't packaged it would not be possible to test it) | 08:49 |
| dch | dholbach: the main issue is /var/lib/couchdb as people have 100gb upwards in these and "just" copying them around is dangerous & slow. from what I've read so far, I've not seen anything about making that possible to access. | 08:49 |
| mwhudson | zyga: heh | 08:49 |
| zyga | mwhudson: since I change spread to use packaging and real dist tarballs releases should be relatively painless | 08:49 |
| zyga | mwhudson: let me grep for the right apparmor version to depend on | 08:49 |
| mwhudson | zyga: and 0001-Stop-using-deprecated-readdir_r.patch too? | 08:49 |
| zyga | mwhudson: all patches are dropped | 08:50 |
| mwhudson | cool | 08:51 |
| zyga | mwhudson: 17:44 < tyhicks> zyga: you should depend on 2.10.95-0ubuntu2.2 or newer | 08:52 |
| zyga | mwhudson: please merge that change into master if you can | 08:52 |
| zyga | mwhudson: do you have commit access to git.launchpad.net/snap-confine? | 08:52 |
| mwhudson | zyga: i doubt it | 08:52 |
| * zyga looks | 08:52 | |
| mwhudson | zyga: 'master' ? | 08:53 |
| mwhudson | in my tree master is upstream master | 08:53 |
| mwhudson | there is a debian branch, and i guess i'm about to create one called ubuntu, or ubuntu-yakkety or something like that :) | 08:53 |
| zyga | mwhudson: you need to request access https://launchpad.net/~snappy-dev | 08:53 |
| zyga | mwhudson: | 08:53 |
| mwhudson | zyga: restricted team, i can only be added | 08:54 |
| zyga | mvo: ^ can you please add mwhudson there | 08:54 |
| dholbach | dch, I'm not quite sure - I'll ping the snapd guys to get an answer on this one. :) | 08:54 |
| zyga | mwhudson: so that repo is a bit weird; it contains just the debian directory and has branches for each distro version | 08:54 |
| * mwhudson updates his schroots | 08:54 | |
| zyga | mwhudson: I found this easier to work with than a few separate repos for the "traditional" approach | 08:55 |
| mwhudson | ah ok | 08:55 |
| zyga | mwhudson: I'm happy to change it as long as we can also use it in spread | 08:55 |
| zyga | mwhudson: note that spread just branches the appropriate branch and builds the package against the debian directory there and the tarball | 08:56 |
| zyga | mwhudson: if we had the full git tree it would probably work as well but might be less obvious that only the debian directory is relevant | 08:56 |
| zyga | mwhudson: and no dedicated tooling seems to work with this approach | 08:56 |
| mwhudson | zyga: uupdate? | 08:57 |
| zyga | mwhudson: (because it is uncommont to maintain many distro revisions in the debian world; I suspect) | 08:57 |
| zyga | uupdate? | 08:57 |
| mwhudson | you could use that with the debian branch from alioth i think | 08:58 |
| mwhudson | bah i have too many chroots | 08:58 |
| zyga | mwhudson: I want to include debian in this repo | 08:58 |
| zyga | mwhudson: and merge those | 08:58 |
| zyga | mwhudson: (those repositories) | 08:58 |
| mwhudson | yes, makes sense | 08:59 |
| zyga | mwhudson: ideally there'd be one repo with a branch per release and master where all new things get added | 08:59 |
| zyga | mwhudson: we can keep it on alioth, that's perfectly fine, I just need to finally do that paperwork for it | 08:59 |
| mwhudson | zyga: branch per distro, surely? | 08:59 |
| zyga | mwhudson: yes | 08:59 |
| mwhudson | good :) | 08:59 |
| zyga | mwhudson: branch per distro*release | 08:59 |
| mwhudson | well distroseries, in launchpad terminology | 08:59 |
| mwhudson | yeah | 08:59 |
| zyga | mwhudson: nice :) | 09:00 |
| mwhudson | zyga: what i do for go (and i don't know if this really makes sense here) is to have the debian bits on alioth but i only push the ubuntu bits to git.lp.net | 09:00 |
| mwhudson | (except occasionally when i screw up and have to delete 10s of tags from alioth) | 09:01 |
| zyga | mwhudson: I guess we might do that, it is per-branch after all | 09:01 |
| zyga | :D | 09:01 |
| mwhudson | zyga: where are the spread bits that make the packages? | 09:03 |
| mwhudson | zyga: ok, builds fine in my yakkety and sid chroots, just waiting on that apparmor version :-) | 09:16 |
| zyga | mwhudson: ^ | 09:20 |
| mwhudson | zyga: oops | 09:20 |
| zyga | mwhudson: I pasted it above | 09:20 |
| zyga | sorry, on a call | 09:20 |
| zyga | mwhudson: in snap-confine master, look for spread-prepare.sh | 09:21 |
| mwhudson | zyga: i guess i'll depend on >= 2.10.95-0 for the debian upload | 09:23 |
| mwhudson | er -1 | 09:23 |
| mwhudson | actually no, the ubuntu version should be fine there | 09:24 |
| mwhudson | no sense carrying a delta for no reason | 09:24 |
| ara | zyga, lost you :) | 09:26 |
| mwhudson | zyga: ok, ready to upload, do you want to look at a debdiff or do you trust me? :) | 09:27 |
| mwhudson | zyga: http://paste.ubuntu.com/23206344/ | 09:32 |
| zyga | re | 09:42 |
| * zyga looks | 09:42 | |
| zyga | mwhudson: I trust you but I can review it :) | 09:42 |
| mwhudson | :) | 09:42 |
| zyga | ouch :) | 09:43 |
| zyga | I stopped at ~1000 | 09:43 |
| zyga | let's get it in | 09:43 |
| mwhudson | zyga: heh maybe search for debian :) | 09:43 |
| mwhudson | but ok | 09:43 |
| mup | PR snapd#1911 closed: snap: add additional checks for snap run symlinks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1911> | 09:43 |
| mup | PR snapd#1774 closed: tests: add test for current snapd with ubuntu-core/edge interactions <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1774> | 09:44 |
| mwhudson | zyga: uploaded to yakkety & sid | 09:47 |
| zyga | mwhudson: woot, thank you | 09:50 |
| ypwong | when I install a snap that I packaged and uploaded some time ago on the latest image, I got this error: | 09:51 |
| ypwong | - Fetch and check assertions for snap "shadowsocks" (5) (cannot verify snap "shadowsocks", no matching signatures found) | 09:51 |
| ypwong | what does that mean? | 09:51 |
| kalikiana | Try --force-dangerous | 09:55 |
| ypwong | trying now | 09:55 |
| ypwong | kalikiana, doesn't work :( | 09:56 |
| zyga | ypwong: upload it again to the store | 09:56 |
| zyga | ypwong: store will sign it now | 09:57 |
| ypwong | zyga, thx, will try that | 09:57 |
| mup | PR snapd#1949 opened: ensure http{,s}_proxy is defined inside the fake-store <Created by mvo5> <https://github.com/snapcore/snapd/pull/1949> | 10:10 |
| mwhudson | zyga: ftbfs https://launchpadlibrarian.net/285513548/buildlog_ubuntu-yakkety-amd64.snap-confine_1.0.41-0ubuntu1_BUILDING.txt.gz | 10:25 |
| mwhudson | zyga: possibly old kernel on the builders? | 10:25 |
| zyga | mwhudson: possibly | 10:32 |
| zyga | mwhudson: hmm | 10:32 |
| zyga | mwhudson: but perhaps not | 10:33 |
| mwhudson | zyga: only failed on intel fwiw | 10:33 |
| zyga | mwhudson: intel as in i386? | 10:33 |
| mwhudson | zyga: i386 & amd64 | 10:33 |
| mwhudson | zyga: https://launchpad.net/ubuntu/+source/snap-confine/1.0.41-0ubuntu1 | 10:33 |
| zyga | mwhudson: NSFS_MAGIC is taken from an include file, I don't hardcode it | 10:34 |
| zyga | mwhudson: hmm hmm, thanks, let me see if I can reproduce it | 10:34 |
| mwhudson | zyga: kernel version is just my go-to blame target when a build fails on the builders but not my machine | 10:34 |
| zyga | mwhudson: but it builds for you in sbuild, right? | 10:34 |
| mwhudson | yes | 10:34 |
| mwhudson | just building again to be sure... | 10:34 |
| zyga | mwhudson: right, so I'm not going crazy | 10:35 |
| * zyga does the same | 10:35 | |
| mwhudson | zyga: well, not for this reason anyway | 10:35 |
| mwhudson | yeah, built fine here again | 10:35 |
| zyga | mwhudson: what kind of options do we have? | 10:36 |
| mwhudson | zyga: the failing kernels are much older, 3.13 vs at least 4.2 for the others | 10:36 |
| zyga | mwhudson: disable that test or .. dunno? | 10:36 |
| mwhudson | zyga: i guess disabling the test for now if uname -r < whatever | 10:36 |
| zyga | mwhudson: can you please look at the test and tell me if the code there makes sense to you? | 10:36 |
| mwhudson | zyga: i hear people want snappy to work on trusty, so some lucky person gets to figure out if this matters :-) | 10:37 |
| zyga | mwhudson: that's tvoss but the solution is to use new kernels | 10:37 |
| fgimenez | hey ogra_ :) i'm not able to boot the latest dragonboard beta image http://paste.ubuntu.com/23206434/ it hangs in the last line, is this a known issue? | 10:37 |
| mwhudson | ah ok | 10:37 |
| zyga | mwhudson: as for 3.1X for devices, lots of backporting I guess | 10:37 |
| zyga | mwhudson: so wait, what is the kernel version on the builders? | 10:37 |
| cjwatson | we have a ticket open to upgrade builders to xenial, but it will take a while | 10:37 |
| cjwatson | zyga: it's on the third line of the build log mwhudson pasted above | 10:37 |
| mwhudson | zyga: it's the first or second line in the build log | 10:38 |
| zyga | mwhudson: Kernel: Linux 3.13.0-96-generic amd64 (x86_64) | 10:38 |
| zyga | is that i? | 10:38 |
| zyga | it | 10:38 |
| cjwatson | yes | 10:38 |
| mwhudson | yeah | 10:38 |
| zyga | okay, that might explain it | 10:38 |
| zyga | let me try that kernel locally | 10:38 |
| zyga | that's trusty kernel with xenial/yakkety chroot? | 10:38 |
| cjwatson | yes | 10:38 |
| cjwatson | yakkety, in this case | 10:38 |
| zyga | perfect | 10:38 |
| zyga | mwhudson: I guess we'll need a patch but let me explore it first | 10:38 |
| mwhudson | NSFS_MAGIC changing between kernel versions would be ... something | 10:39 |
| zyga | mwhudson: can you fild a bug for tracking this with the relevent part of the log | 10:39 |
| mwhudson | maybe older kernels just didn't set it at all or something | 10:40 |
| mwhudson | zyga: on github or lp? | 10:40 |
| zyga | mwhudson: on launchpad please | 10:40 |
| mwhudson | 40864 seems to be PROC_SUPER_MAGIC | 10:44 |
| mwhudson | zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1625565 | 10:44 |
| mup | Bug #1625565: 1.0.41-0ubuntu1 ftbfs on amd64, i386 <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1625565> | 10:44 |
| zyga | mwhudson: thanks | 10:44 |
| mwhudson | and NSFS_MAGIC was only added to the kernel in a commit from Sat Nov 1 10:57:28 2014 -0400 | 10:45 |
| mwhudson | so that's not going to be in the 14.04 release kernel | 10:45 |
| mwhudson | 3.19+ | 10:46 |
| zyga | mwhudson: so even the kernel headers have that macro, the relevant files in the kernel don't use it? | 10:46 |
| mwhudson | zyga: well the kernel headers you are building against are from yakkety presumably | 10:47 |
| zyga | mwhudson: yes, I just checked that :/ | 10:47 |
| zyga | mwhudson: the mount namespace file in the kernel is indeed procfs | 10:47 |
| zyga | mwhudson: I guess this test needs to be skipped | 10:47 |
| zyga | mwhudson: and we might need a separate check for this in snap-confine proper | 10:47 |
| zyga | so that if we open and see PROC_SUPER_MAGIC we can die() | 10:48 |
| zyga | mwhudson: I'll work on a patch, can you still upload it in £30 minutes? | 10:48 |
| zyga | ~ | 10:48 |
| mwhudson | zyga: getting pretty late, i'm sure you can find another core dev | 10:49 |
| zyga | ok | 10:49 |
| zyga | thanks, I'll talk to you tomoror :) | 10:49 |
| zyga | tomorrow :) | 10:49 |
| mwhudson | zyga: ttyl! | 10:49 |
| zyga | o/ | 10:49 |
| ogra_ | mvo, how hard would it be to make snap prepare-image alo print the revision number when printing the "Fetching $package" ? | 11:02 |
| ogra_ | *also | 11:02 |
| ogra_ | (that would really help regarding getting the manifest) | 11:03 |
| jgdx | possible to use a ppa in addition to whatever snapcraft uses to install debs? | 11:06 |
| ogra_ | yes, just have it in your hosts sources.list | 11:06 |
| jgdx | ogra_, okay, that's great | 11:07 |
| ogra_ | (not sure how you do it with cleanbuild though, i guess you need a pre-made lxc image for that) | 11:08 |
| jgdx | ogra_, what uses cleanbuild? | 11:08 |
| mvo | ogra_: I like the idea | 11:08 |
| ogra_ | you ? | 11:08 |
| ogra_ | mvo, i'll file a bug | 11:08 |
| jgdx | ogra_, I use $ snapcraft | 11:09 |
| ogra_ | jgdx, to build a snap you can call "snapcraft cleanbuild" ... while a normal call of snapcraft will just use the host, cleanbuild does the build inside a clean lxc container | 11:09 |
| jgdx | good to know, thanks | 11:11 |
| ogra_ | ppisati, hmm, more OOPS fun on bbb ... http://paste.ubuntu.com/23206676/ | 11:14 |
| === hikiko is now known as hikiko|ln | ||
| ogra_ | it seems to hang in resizing the disk and eventually oopses after a few min | 11:14 |
| ypwong | To install a snap locally, do I always need to provide --force-dangerous argument? | 11:20 |
| zyga | mwhudson: if around by any chance: https://github.com/snapcore/snap-confine/pull/150/files | 11:20 |
| mup | PR snap-confine#150: Skip tests that require Linux kernel 3.19+ <Created by zyga> <https://github.com/snapcore/snap-confine/pull/150> | 11:20 |
| * zyga needs a reviewer for a simple patch ^^ | 11:20 | |
| ogra_ | ypwong, the option will soon change to just be --dangerous ... and --devmode selets it automatically ... if you install a local snap you always need it (but dont need to specify it when using --devmode) | 11:21 |
| ypwong | ogra_, | 11:23 |
| ypwong | ogra_, will plugs be automatically connected? | 11:23 |
| ypwong | seems when i use --force-dangerous, it doesn't | 11:23 |
| ogra_ | the auto-connect ones will, sure ... | 11:23 |
| ypwong | hmm | 11:23 |
| ypwong | strange, let me dig deeper then | 11:23 |
| ypwong | I use network and network-bind, these should be auto-connect | 11:24 |
| ogra_ | yes | 11:24 |
| === Michaela is now known as Mikaela | ||
| ogra_ | though i'm not sure actually ... zyga should know if --dangerous kills auto-connect | 11:25 |
| zyga | ogra_: I don't think so but let me grep | 11:25 |
| ogra_ | mwhudson, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has the latest probert/subiquity | 11:26 |
| zyga | ogra_: no, it has no inpact on this | 11:27 |
| ogra_ | thought so ... | 11:28 |
| ogra_ | thanks | 11:28 |
| ogra_ | ypwong, ^^^^ | 11:28 |
| ypwong | ogra_, zyga: thx, i will investigate what's wrong | 11:29 |
| ppisati | ogra_: i'm looking into the previous one | 11:30 |
| ppisati | ogra_: i stuck some debug code in the sysfs code, but i still can't find where it writes | 11:31 |
| ogra_ | ppisati, heh, yeah, i was just hoping that brings perhaps more hints | 11:31 |
| ppisati | ogra_: my bet is that it removes all the network devices | 11:31 |
| mup | PR snapcraft#808 closed: Don't litter /tmp with test artifacts <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/808> | 11:31 |
| ppisati | i've seen quite some fixes about PM code and TI device removal | 11:31 |
| ppisati | so i'll give that a shot too | 11:32 |
| ppisati | but this one is new | 11:32 |
| ppisati | doh! | 11:32 |
| ppisati | :P | 11:32 |
| ppisati | ogra_: btw, is is so difficult to roll a new image for BB? | 11:32 |
| ogra_ | you need a signed assertion and the snap that you want to replace locally | 11:32 |
| ogra_ | ppisati, see pm | 11:34 |
| ppisati | ogra_: ok, i'll give it shot later on | 11:36 |
| * ppisati is accumulating later shots | 11:36 | |
| zyga | jdstrand: hey | 11:43 |
| zyga | jdstrand: could you please add a comment to https://github.com/snapcore/snap-confine/pull/97 that confirms you are okay with the change that lowers the restriction on encrypted home directory (we drop the owner stanza) | 11:43 |
| mup | PR snap-confine#97: Restore creation of $SNAP_USER_DATA <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/97> | 11:43 |
| zyga | jdstrand: just some paperwork for SRU | 11:43 |
| zyga | jdstrand: I recall you +1'd it but I need a paper trail for the whole process | 11:43 |
| zyga | jdstrand: and I cannot see that +1 on the pull request there | 11:44 |
| jdstrand | zyga: I don't recall ever giving a +1 on that. I recall a +1 on the 'new-style encrypted $HOME' | 11:47 |
| jdstrand | zyga: why doesn't owner match work? shouldn't we have already dropped privs to the user when creating SNAP_USER_DATA? | 11:47 |
| zyga | jdstrand: beuse we run as root via sudo | 11:49 |
| zyga | *because | 11:49 |
| zyga | jdstrand: this is just for the sudo case | 11:49 |
| zyga | the bug https://bugs.launchpad.net/snap-confine/+bug/1612291 has a lot more details now | 11:49 |
| mup | Bug #1612291: cannot create $SNAP_USER_DATA when using ecryptfs and sudo <verification-done> <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1612291> | 11:49 |
| zyga | (this is in xenial for a while FYI) | 11:50 |
| ogra_ | OH GEEZ !!!!! | 11:51 |
| zyga | ogra_: ?!? | 11:51 |
| ogra_ | so i wasted a full day trying to fix a prob that wasn't actually one, just because i missed that the store did unset the channel for a manually published snap ! | 11:52 |
| ogra_ | (well, it was actually auto-published, but failed the review ... seems the manual review approval auto-unsets the channel that had been originally selected for the package) | 11:53 |
| ogra_ | so the uploaded fix never made it into the image ... since it caused snap list to not work i couldnt actually find out that the fixed snap was a revision behind ... | 11:53 |
| ogra_ | what a mess | 11:54 |
| jdstrand | niemeyer: let me know if I am not using the 'Reviewed' tag correctly. I see you like to mark things 'Reviewed' after you leave feedback. If I respond to your feedback, I remove 'Reviewed'. If the process is different, please let me know | 12:00 |
| zyga | jdstrand: the reviewed tag is gone now | 12:00 |
| zyga | jdstrand: with new github features it is not required | 12:00 |
| zyga | jdstrand: same as blocked | 12:01 |
| jdstrand | zyga: well, maybe, but it showed up with a review from last night/this morning | 12:01 |
| pedronis | zyga: no, after futher thinking, we are still using the labels | 12:02 |
| pedronis | zyga: you don't see the other stuff in the PRs list for one | 12:02 |
| zyga | pedronis: yes? | 12:02 |
| zyga | pedronis: I think gustavo wrote about this yesterday but perhaps I didn't see a follow-up that undoes it | 12:03 |
| jdstrand | zyga: right, so I read that bug but I think this is just papering over the larger issue of sudo creating things in the user's dir rather than /root | 12:03 |
| pedronis | zyga: he wrote something else, we are using the features and we are using the labels | 12:03 |
| pedronis | the discussion about the labels was in chat | 12:03 |
| zyga | jdstrand: that's interesting, I think we could consider switching to /root when sudo is used but I don't think we made that choice yet | 12:03 |
| zyga | pedronis: ah, that explains it, I only read my mail about that | 12:04 |
| zyga | pedronis: thanks! | 12:04 |
| jdstrand | zyga: I maintain we should not be doing that. HOME should be set to the root user if run under sudo because we will never get the permissions right in the user's directory cause half the time we will be right and half the time wrong regardless of the decision, but if creating in /root at least it is consistent | 12:04 |
| jdstrand | zyga: I was literally just going to ask if an architect took a definitive stance on that | 12:05 |
| jdstrand | I thought someone did, and I thought it was for /root, but I may be misremembering | 12:05 |
| zyga | jdstrand: I think we did that for /root and *services* | 12:06 |
| jdstrand | 'it is consistent and we aren't creating permissions problems for the user' | 12:06 |
| zyga | jdstrand: well, FYI this is in xenial :/ | 12:06 |
| zyga | jdstrand: I'm just massaging the paperwork now | 12:06 |
| zyga | jdstrand: I think there's a strong distinction between servies and sudo | 12:07 |
| zyga | jdstrand: but still, regardless, I wonder how to proceed now | 12:07 |
| * zyga is *sure* we talked about this | 12:07 | |
| * ogra_ grumbles and files bug 1625605 | 12:07 | |
| mup | Bug #1625605: manual review should not unset the channel for auto-uploaded snap <Snappy:New> <Software Center Agent:New> <https://launchpad.net/bugs/1625605> | 12:07 |
| zyga | perhaps that was tyhicks | 12:07 |
| mup | Bug #1625605 opened: manual review should not unset the channel for auto-uploaded snap <Snappy:New> <Software Center Agent:New> <https://launchpad.net/bugs/1625605> | 12:08 |
| jdstrand | zyga: I gave a +0 that at least gives you a "won't block" from the security team | 12:10 |
| jdstrand | zyga: (see comment in the PR) | 12:10 |
| zyga | jdstrand: thank you | 12:12 |
| zyga | jdstrand: I'll raise this today with gustavo | 12:12 |
| zyga | jdstrand: I'm happy to change it if we so desire though I wonder if we should just change sudo | 12:12 |
| zyga | jdstrand: after all, this is sudo's code that preserves HOME | 12:12 |
| jdstrand | there is a bug on that | 12:12 |
| zyga | jdstrand: and that was a vert conscious choice on our end (our == ubuntu) | 12:13 |
| jdstrand | yes | 12:13 |
| zyga | jdstrand: can you share the bug please? | 12:13 |
| zyga | s/vert/very/ | 12:13 |
| jdstrand | the difference is that in ubuntu running the sudo command, the command most often does not create files in the user's home dir (it is highly application dependent). in snappy, running a snap command 100% of the time creates the directories and files with root ownership | 12:14 |
| jdstrand | (when they don't already exist) | 12:14 |
| ogra_ | mvo, bug 1625607 for you | 12:14 |
| mup | Bug #1625607: snap prepare-image should print the revision used in the "Fetching $package" output <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1625607> | 12:14 |
| === hikiko|ln is now known as hikiko | ||
| zyga | jdstrand: that's true though I'd say that "it is application dependent" is very common | 12:17 |
| mup | Bug #1625607 opened: snap prepare-image should print the revision used in the "Fetching $package" output <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1625607> | 12:17 |
| jdstrand | zyga: https://bugs.launchpad.net/snappy/+bug/1466234/comments/6 | 12:17 |
| mup | Bug #1466234: Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root <Snappy:Fix Released> <ubuntu-core-launcher (Ubuntu):Invalid> <ubuntu-core-security (Ubuntu):Fix Released by jdstrand> <ubuntu-snappy (Ubuntu):Fix Released> <https://launchpad.net/bugs/1466234> | 12:17 |
| jdstrand | zyga: in fact, it looks like we decided on option #1 (using /root) but no one implemented it | 12:18 |
| jdstrand | zyga: seems it was undone at some point | 12:18 |
| zyga | jdstrand: interesting, I wasn't aware of it | 12:20 |
| jdstrand | zyga: so yes, it came up, options were presented, one was decided on, it was implemented, then reintroduced later | 12:21 |
| jdstrand | s/then reintroduced/then the issue was reintroduced/ | 12:21 |
| zyga | cjwatson: crazy idea, let launchpad bugs affect snap names | 12:30 |
| zyga | cjwatson: like packages in a distro or upstream projects | 12:31 |
| ogra_ | zyga, awesome idea ... but would indeed only work for snaps that are built in LP | 12:31 |
| zyga | ogra_: no, why? | 12:32 |
| cjwatson | Conceptually useful, but we'd have to model the snap names somehow, which is complex since LP doesn't own them. | 12:32 |
| zyga | ogra_: just any snap | 12:32 |
| cjwatson | ogra_ is incorrect | 12:32 |
| zyga | cjwatson: I bet we can eventually figure it out | 12:32 |
| cjwatson | If we did this we'd do it by syncing snap names from the store | 12:32 |
| zyga | cjwatson: just realized that more and more of what I do will be fixed in a given revision of a given snap | 12:32 |
| ogra_ | cjwatson, well, you just said yourself that LP doesnt own them ... except for a snap LP builds, there it knows the store name | 12:33 |
| cjwatson | ogra_: See the last thing I said. | 12:33 |
| cjwatson | It doesn't own them, but it could know them. | 12:33 |
| zyga | ogra_: launchpad doesn't own other things it can track | 12:33 |
| ogra_ | right, i was just referring to the ones it already knows :) | 12:33 |
| cjwatson | It won't be soon, but by all means file a bug. | 12:34 |
| zyga | cjwatson: with pleasure | 12:35 |
| jdstrand | pstolowski: ok, I gave my +1 on the kmod backend, but think you want to have niemeyer take a quick look. that could happen in the PR if you prefer | 12:36 |
| cjwatson | It might be easier to do if we didn't try to overlap the namespace with the existing "ubuntu", though. | 12:36 |
| jdstrand | pstolowski: I can't help wanting to not require the json file, but understand why you have it and can't come up with a cleaner solution that doesn't introduce parsing metadata in /etc/modules-conf.d | 12:37 |
| jdstrand | or loading modules twice | 12:38 |
| zyga | cjwatson: https://bugs.launchpad.net/launchpad/+bug/1625617 | 12:38 |
| mup | Bug #1625617: Allow bugs to affect snap (snap names) <Launchpad itself:New> <https://launchpad.net/bugs/1625617> | 12:38 |
| zyga | jdstrand: json? | 12:38 |
| zyga | pstolowski: where's the pull request? | 12:38 |
| jdstrand | zyga: https://docs.google.com/document/d/1-kSrNGLxIeSHJOZJBdumAL8QQIt0DBa_TLMzYDQEPM4/edit# | 12:39 |
| jdstrand | zyga: no pull request-- design doc | 12:39 |
| zyga | pstolowski: This database is persistent and stored in /var/lib/snapd/kmod-state.json (restored on startup). | 12:39 |
| popey | ogra_: got a pi handy with classic enabled? libssl-dev seems broken on arm:- libssl-dev : Depends: libssl1.0.0 (= 1.0.2g-1ubuntu4.2) but 1.0.2g-1ubuntu4.3 is to be installed | 12:39 |
| zyga | pstolowski: why do you think this is needed? | 12:39 |
| jdstrand | zyga: see my comments | 12:39 |
| pstolowski | jdstrand, thanks for your time! | 12:40 |
| jdstrand | (in the doc) | 12:40 |
| ogra_ | popey, only half eaten pi's here (all broken atm) ... but i'll check once i get to one ... which image is that ? | 12:40 |
| jdstrand | zyga: basically, it boils down to disconnect | 12:40 |
| jdstrand | zyga: if two snaps are connected and one isn't, you need to know if other snaps are connected | 12:40 |
| zyga | pstolowski: this database is redundant information, it is completely derived from connections, am I missing something? | 12:40 |
| zyga | jdstrand: snapd knows all of this | 12:41 |
| jdstrand | that didn't come out right | 12:41 |
| popey | ogra_: previous beta (not yesterdays) | 12:41 |
| popey | ogra_: with classic enabled. | 12:41 |
| jdstrand | zyga: if two snaps are connected and one of those is later disconnected, you need to know if other connections are available | 12:41 |
| ogra_ | popey, there was an issue that we used to build ubuntu-core against -proposed which got fixed after first beta | 12:41 |
| popey | ok | 12:41 |
| jdstrand | s/available/still in effect/ | 12:41 |
| popey | am about to try yesterdays | 12:41 |
| popey | with a pi3 | 12:41 |
| ogra_ | popey, well, snap refresh should theoretically just get you all the latest snaps | 12:41 |
| ogra_ | theoretically there is no need to ever reinstall | 12:42 |
| zyga | jdstrand: to be more accurate, since we restore this on startup we can just keep this in memory | 12:42 |
| zyga | jdstrand: so no computational overhead on disconnect | 12:42 |
| ogra_ | (practically there are differences in the setup process ... but not in the runtime) | 12:42 |
| zyga | jdstrand: unless someone proves me wrong I'd -1 the extra json file | 12:42 |
| jdstrand | zyga: so, if I snap disconnect foo:firewall-control, then snapd will be able to know that bar is still connected and make decisions? where is an example of that, cause I only see the snap name in current code | 12:42 |
| zyga | jdstrand: yes | 12:43 |
| zyga | jdstrand: specifically snapd knows about all the backends and all the connections | 12:43 |
| zyga | jdstrand: we need a channel to convey this to the backend | 12:43 |
| jdstrand | zyga: hey, I'm fine without the json file-- I don't like it :) | 12:43 |
| popey | ogra_: well, i was gonna test the new one anyway, so neat to have them side by side to compare | 12:43 |
| zyga | jdstrand: but the extra json file does not help there | 12:43 |
| zyga | pstolowski: ^^ | 12:43 |
| popey | if i can find my pi 3 | 12:43 |
| pstolowski | i'm happy to get rid of it too | 12:43 |
| zyga | pstolowski: look at the startup sequence in overlord/ifacestate | 12:43 |
| pstolowski | jdstrand, zyga need to digest that | 12:43 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ LC_ALL=C df -h /dev/sdc1 /dev/sdc2 | 12:44 |
| ogra_ | Filesystem Size Used Avail Use% Mounted on | 12:44 |
| ogra_ | /dev/sdc2 475M -32T 33T - /media/ogra/writable | 12:44 |
| ogra_ | /dev/sdc1 127M 23M 104M 19% /media/ogra/system-boot | 12:44 |
| ogra_ | wow ... | 12:44 |
| ogra_ | -32T | 12:44 |
| zyga | pstolowski: think about it, perhaps I am missing something but if not we just drop some complexity | 12:44 |
| ogra_ | (thats definitely not what they printed on this SD card) | 12:44 |
| zyga | ogra_: that's a nice SD card you have there | 12:44 |
| ogra_ | yeah ! | 12:44 |
| zyga | ogra_: care for a copy of the internet? | 12:44 |
| ogra_ | haha | 12:45 |
| zyga | don't foret to unmount before ejecting | 12:45 |
| zyga | ;D | 12:45 |
| ogra_ | right ... on the beaglebone i use it in ... | 12:45 |
| ogra_ | seems it doesnt really get along with SDXC | 12:45 |
| * ogra_ tries to find out if he even actually owns plain old SD ones still | 12:46 | |
| zyga | ogra_: to quote hrw "no sata, meh" | 12:47 |
| ogra_ | LOL | 12:47 |
| jdstrand | zyga: so you are suggesting that pstolowski use getConns() from helpers.go to see if there are still connected interfaces. if so, on connect, do nothing, on disconnect, do nothing? | 12:47 |
| jdstrand | zyga: something along those lines? | 12:47 |
| zyga | jdstrand: without any deeper understanding the json file can be just maintained in memory | 12:48 |
| pstolowski | zyga, all I need is to know if I should rmmod module(s) or not, depending on whether there are other connected interfaces needing them | 12:48 |
| pstolowski | jdstrand, ^ | 12:48 |
| zyga | jdstrand: this is all an in-memory problem | 12:48 |
| pstolowski | jdstrand, zyga also, note there may be overlapping modules for different interfaces | 12:48 |
| pstolowski | jdstrand, zyga interfaceA needs module1 & module2, interfaceB needs module2 | 12:48 |
| ogra_ | pstolowski, please "modprobe -r" not rmmod ... else the dependencies stay in ram | 12:48 |
| jdstrand | pstolowski: well, you need to know if to rmmod and to update the file in /etc/modules-conf.d to remove the modules | 12:48 |
| zyga | pstolowski: just track this on connect/disconnect, the persistent file gains you nothing | 12:48 |
| pstolowski | jdstrand, yes, sure | 12:49 |
| pstolowski | ogra_, noted, thanks! | 12:49 |
| zyga | pstolowski: and if you need persistent state you have one already, the extra file will be likely NAKed by gustavo | 12:49 |
| jdstrand | zyga: ok, so you can either reconstruct the 'json file' in memory on startup like you said, or you could query the state of interfaces connections (getConns()(?)) each time | 12:50 |
| zyga | jdstrand: yes | 12:50 |
| zyga | jdstrand: in either case the file is redundant and overlaps in responsibilty with state.json | 12:51 |
| jdstrand | ok cool | 12:51 |
| zyga | jdstrand: state tracks connections today | 12:51 |
| zyga | jdstrand: (that's why they exist on restart) | 12:51 |
| zyga | jdstrand: the interface repository has in-memory representation of this | 12:51 |
| jdstrand | I think that querying getConns() each time will be easier to implement than trying to maintain a global map | 12:51 |
| jdstrand | (a separate global map) | 12:52 |
| zyga | pstolowski: FYI, you will probabl have to introduce some changes as currently backends are stateless | 12:52 |
| jdstrand | ie, no need to recreate the map if we can query an existing one | 12:52 |
| zyga | pstolowski: so either make them stateful (perhaps not desired) or let them peek at the state (easy) | 12:52 |
| mhall119 | dch: pong, and good morning :) | 12:53 |
| pstolowski | zyga, jdstrand one bit i'm missing with getCons() is that i'm actually interested in their security snippets | 12:54 |
| zyga | pstolowski: if you want I can talk to you about this after the standup | 12:57 |
| pstolowski | zyga, okay | 12:59 |
| jdstrand | pstolowski: well, are you? consider the firewwall-control interface. you need only ask getConns() if anything other than you is using the interface. then maintain a file called /etc/modules-conf.d/snapd-firewall-control.conf. then for the ppp interface, you ask what else is using the ppp interface and maintain a file called /etc/modules-conf.d/snapd-ppp.conf. that said, do talk to zyga-- he has thought about it more than I | 13:01 |
| ogra_ | sigh ... so setting up the store account on the bbb takes almost 20min | 13:01 |
| ogra_ | this is below sub-optimal | 13:02 |
| dch | mhall119: hey | 13:03 |
| zyga | ogra_: cpu bound? ram bound? ? | 13:04 |
| ogra_ | zyga, python bound i bet ... (which indeed boils down to only single core CPU and 512MB | 13:04 |
| ogra_ | ) | 13:04 |
| ogra_ | remember why we re-wrote snappy from python initially ? :) | 13:05 |
| ogra_ | great ... and it seems console-conf was still busy in bg, even though it had "finished" | 13:06 |
| ogra_ | [ 937.295627] systemd-shutdown[1]: Remounting '/' read-only with options ''. | 13:06 |
| ogra_ | [ 937.304326] systemd-shutdown[1]: Remounting '/writable' read-only with options 'data=ordered'. | 13:06 |
| ogra_ | [ 937.314808] systemd-shutdown[1]: Unmounting /writable. | 13:06 |
| ogra_ | [ 937.320368] systemd-shutdown[1]: Could not unmount /writable: Device or resource busy | 13:06 |
| popey | ogra_: tried pi3 image, it just sits at 4 raspberrys and heartbeat blinks at me... should it take a long time first boot? | 13:06 |
| * ogra_ has about 1000 lines of that on the console now | 13:06 | |
| ogra_ | popey, whats on the serial ? | 13:07 |
| popey | serial? | 13:07 |
| popey | i only have ethernet and hdmi connected | 13:07 |
| ogra_ | yes, you are using an embedded board ... so i expect you to have a serial console attached :P | 13:07 |
| popey | hahah, olde ogra_ | 13:07 |
| popey | hello, welcome to 2016 | 13:07 |
| ogra_ | this is really essential | 13:07 |
| popey | le sigh | 13:08 |
| ogra_ | (how else would i get any debug info from you :P ) | 13:08 |
| zyga | ogra_: from python!? really?! | 13:08 |
| zyga | ogra_: wow | 13:08 |
| zyga | ogra_: I didn't know this | 13:08 |
| ogra_ | zyga, we dropped the pythjon based snappy back then because even installing a package could take 20min on the bbb (which back then was still an official target) | 13:09 |
| popey | ogra_: this is the first time I have ever had someone ask me about a serial cable on the pi.. ever. | 13:09 |
| zyga | ogra_: ouch | 13:09 |
| zyga | ogra_: lesson learned | 13:09 |
| popey | so forgive me if I don't own onw :( | 13:09 |
| popey | *one | 13:09 |
| ogra_ | popey, well, because the pi foundation makes you think that this embedded board is a PC :P | 13:10 |
| zyga | ogra_: that board is x100 faster than linus' first pc | 13:10 |
| ogra_ | popey, anyway, you can hack cmdline.txt on the sysstem-boot partition of the SD ... and change the console= arg tp point to tty1 | 13:10 |
| ogra_ | though i would suggest doing a fresh flash first ... the beta images are no safe against rebooting before console-conf finished (thats fixed in the dailies) | 13:11 |
| popey | it is a fresh flash | 13:12 |
| popey | from 20 mins ago | 13:12 |
| ogra_ | did you power on the pi with the SD plugged in ? | 13:12 |
| ogra_ | (then it is tainted if you were not able to finish console-conf) | 13:12 |
| popey | ok | 13:13 |
| * popey reflashes | 13:13 | |
| ogra_ | the dailies are already miles ahead (new console-conf today) but well ... use edge ... | 13:13 |
| popey | will flash, edit cmdline.txt and try again | 13:14 |
| pstolowski | jdstrand, i think we need more awareness, down to individual modules, because some modules can be used by different interfaces and we need to know when it's safe to unload them from kernel. i'm happy to get rid of the persistent json file but I need to derive this information from somewhere else (all connections + their list of modules returned by SecurityKMod snippet). | 13:20 |
| mup | PR snapd#1641 closed: interfaces/builtin: implement systemd-control <Decaying> <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/1641> | 13:20 |
| csutherl | mhall119, hi | 13:22 |
| zyga | pstolowski: that sounds good | 13:22 |
| zyga | pstolowski: I'm not disputing the data that is needed to complete this | 13:22 |
| popey | ogra_: tried that, now I get perma green and red light and no display :( | 13:24 |
| popey | gonna try again after meetings, but any other suggestions welcome | 13:24 |
| ogra_ | i dont have any | 13:25 |
| ogra_ | it works fine to run it without HDMI on a serial console | 13:25 |
| * zyga finished paperwork for 1.0.40 update | 13:30 | |
| zyga | https://launchpad.net/snap-confine/+milestone/1.0.40 | 13:30 |
| jdstrand | pstolowski: or you could skip the modprobe -r altogether... starting to think that it might always fail cause of modules that depend on those | 13:30 |
| zyga | now time for 1.0.41 :/ | 13:30 |
| zyga | jdstrand: hmm, good point | 13:30 |
| jdstrand | pstolowski: always in practice that is. | 13:30 |
| zyga | jdstrand: so just modprobe | 13:30 |
| zyga | jdstrand: and just reboot to alter | 13:30 |
| jdstrand | eg, firewall control will for sure | 13:30 |
| zyga | jdstrand: the module might not be possible to remove perhpas | 13:30 |
| jdstrand | yeah | 13:30 |
| mhall119 | hello csutherl | 13:31 |
| ogra_ | jdstrand, the kernel shoudl know which deps are stiull in use and modprobe -r should actually leave them alone | 13:31 |
| zyga | pstolowski: ^^ I think simplifies your problem a lot | 13:31 |
| pstolowski | zyga, it does but i'm not convinced :/ | 13:31 |
| zyga | ogra_: should we fail when modprobe -r fails? | 13:31 |
| ogra_ | i'd check if the module you called -r on is still there ... and then fail ... but only then | 13:32 |
| pstolowski | no, i'd say we try to unload modules, but never fail | 13:32 |
| jdstrand | why? | 13:32 |
| ogra_ | well, or warn | 13:32 |
| jdstrand | who cares if it doesn't unload | 13:32 |
| pstolowski | exactly | 13:32 |
| pstolowski | and there may be users of the modules outside of snap world. we don't know | 13:32 |
| jdstrand | yes, good point | 13:32 |
| csutherl | mhall119, i figured it's probably easiest for me to talk to you in real time :) im a bit busy, but im always on irc | 13:33 |
| jdstrand | perhaps the admin add a file to /etc/modules-load.d that happens to overlap | 13:33 |
| csutherl | mhall119, i created a snap from your config, but haven't tested it or anything yet. the idea of snaps seems similar to containers, right? | 13:33 |
| jdstrand | added* | 13:33 |
| mhall119 | similar in spirit, not in implementation | 13:33 |
| jdstrand | then we just go and unload it | 13:33 |
| jdstrand | that wouldn't be good | 13:33 |
| mhall119 | snaps are run on the local host, but confined with apparmor (and selinux in the future) | 13:33 |
| pstolowski | jdstrand, hmm, that's a valid point & case | 13:34 |
| jdstrand | mhall119: s/and/or/ (nitpick, but it won't ever be both at the same time) | 13:34 |
| pstolowski | jdstrand, zyga no unloading then? that simplifies it quite a lot | 13:35 |
| jdstrand | pstolowski: I think I just convinced myself no unloading | 13:35 |
| ogra_ | mhall119, csutherl, well, a container means your snap would actually be installed in / and run against a VM or chroot or some such ... snaps dont do that, there is no such path mangling like in chroot or VM environments | 13:36 |
| csutherl | ogra_, ah. thanks for the explanation. i haven't had much time to look into it other than to install and run snapcraft :) | 13:37 |
| ogra_ | the paths are actually all underneath $SNAP ... | 13:37 |
| csutherl | interesting | 13:37 |
| jdstrand | csutherl: snaps integrate with the system and with each other and we use some container technologies to do that | 13:37 |
| csutherl | neat | 13:38 |
| csutherl | so why would i use a snap instead of docker, for instance? | 13:38 |
| csutherl | im just trying to get an overview of use cases | 13:38 |
| ogra_ | right, but we do not make it look like $SNAP/usr/bin is actually /usr/bin ... which a container does | 13:38 |
| zyga | csutherl: it is easier to let one snap to work with other snaps and with the system | 13:38 |
| zyga | csutherl: and the snap might be smaller as it re-uses the core snap | 13:38 |
| ogra_ | there is strict separation in our setup | 13:39 |
| jdstrand | csutherl: it depends on what you want. with docker, you manage the app with docker and it doesn't integrate with the system (maybe that is your workflow, that's fine). with snappy, normal tools like ps, top, ls, etc all work as expected for the snap and that snap might connect to another snap-- eg, download the bluez snap and then another snap that uses it | 13:40 |
| zyga | csutherl: snanps also integrate better with regular users on the system and allow them to have per-user state | 13:40 |
| jdstrand | csutherl: that is harder to do with docker | 13:40 |
| jdstrand | csutherl: it just depends on what you want and what your workflows are | 13:41 |
| csutherl | gotcha | 13:41 |
| csutherl | jdstrand, zyga ogra_ thanks for the responses :) | 13:42 |
| ogra_ | :) | 13:42 |
| jdstrand | you're welcome :) | 13:42 |
| csutherl | mhall119, ok. back to you. what exactly were you looking for help with ? just testing your snap or something more? | 13:44 |
| jdstrand | pstolowski: do you have everything you need at this point? | 13:44 |
| pstolowski | jdstrand, yes! thank you for feedback! | 13:44 |
| jdstrand | pstolowski: you're welcome and thanks to zyga for reminding me that the state is right there at your fingertips :) | 13:45 |
| pstolowski | jdstrand, fyi.. i've already made some progress on the impl (well, it's 90% ready the way I described it in the doc with persistent state). so now i only need to rework it a bit ;) | 13:48 |
| mhall119 | csutherl: I'm really looking for help testing and improving the snap right now, and getting it upstream once it's in a good state | 13:48 |
| pstolowski | jdstrand, so I hope to have something ready for review this week | 13:49 |
| jdstrand | pstolowski: nice! | 13:49 |
| csutherl | mhall119, what does 'getting it upstream' mean? | 13:49 |
| csutherl | i dont know anything about the infrastructure, etc atm, so assume i know nothing :) | 13:49 |
| mhall119 | in the not to distant future I wanted to make it possible to deploy .war files as snaps that connect to the tomcat snap, or to make tomcat a snapcraft "part" that developers could use to bundle it with their webapp | 13:49 |
| mhall119 | csutherl: getting the snapcraft.yaml into the upstream source code, and building snaps as part of the normal CI process rather than as a one-off manual task | 13:50 |
| csutherl | mhall119, upstream as in asf tomcat or some snap store type thing? | 13:51 |
| mhall119 | asf tomcat | 13:51 |
| csutherl | b/c asf afaik doesn't generally accept distribution stuff :) | 13:51 |
| csutherl | which is why im the only person that responded to you | 13:51 |
| csutherl | i maintain fedora/rhel tomcat | 13:51 |
| mhall119 | who could then upload it to the snap store or make it available as a download (or both) | 13:51 |
| mhall119 | csutherl: it would be more inline with asf project packages for windows or mac, rather than distro-specific | 13:52 |
| csutherl | mhall119, you can always give it a shot and see | 13:53 |
| mhall119 | since the snap could be installed on to Arch or Debian, for example | 13:53 |
| csutherl | yep | 13:53 |
| mhall119 | csutherl: if you can help me figure out why the JSP views aren't working, that would be a huge help :) | 13:57 |
| mhall119 | my guess is that it's trying to write the compiled pages somewhere that is read-only, but I've forgotten where Tomcat tries to do that | 13:57 |
| csutherl | mhall119, gotcha. sure | 14:00 |
| csutherl | mhall119, it writes the compiled jsps into the work dir (or temp, i dont remember) | 14:00 |
| csutherl | mhall119, do the example apps fail? | 14:00 |
| mhall119 | only on the JSP side, the servlet works fine | 14:00 |
| mhall119 | it's created $CATALINA_BASE/work/Catalina/localhost/sample just fine | 14:01 |
| mhall119 | so maybe it's trying to use a temp directory it doesn't have | 14:02 |
| csutherl | probably | 14:02 |
| csutherl | ill pok earound with it when i get freed up later today | 14:02 |
| mhall119 | thanks csutherl | 14:02 |
| csutherl | mhall119, np | 14:02 |
| mup | PR snapcraft#814 opened: Make source-depth a parameter and opt-in <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/814> | 14:16 |
| mup | PR snapd#1949 closed: tests: ensure http{,s}_proxy is defined inside the fake-store <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1949> | 14:18 |
| mup | PR snapcraft#809 closed: make plugin: improve artifact copying (LP: #1624798) <Created by jaymell> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/809> | 14:25 |
| mup | PR snapcraft#792 closed: Fix `git clone` when transport is http and it does not support --depth <Created by ehbello> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/792> | 14:28 |
| mup | PR snapcraft#802 closed: Add the TEST_STORE environment variable to the travis script <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/802> | 14:31 |
| ppisati | ogra_: FYI, i think i fixed the BB panic | 14:32 |
| ogra_ | awesome ! | 14:32 |
| ogra_ | what was it ? | 14:32 |
| mup | PR snapcraft#761 closed: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/761> | 14:34 |
| ppisati | ogra_: the PM code tried to suspend (IOW access) a device that was already removed | 14:36 |
| ppisati | and kaboom! | 14:36 |
| ppisati | but i'm running another test now | 14:36 |
| ogra_ | lovely ! | 14:36 |
| ppisati | fingers crossed | 14:36 |
| ogra_ | sadly i didnt get much firther with console-conf on the bbb nor with making the FS resize operate at a bearable speed :/ | 14:37 |
| ogra_ | using a 64GB SDXC card takes about 30min to resize the writable partition :/ | 14:38 |
| ogra_ | it works all fine using something like a 4GB SD though | 14:38 |
| ogra_ | though the fact that console-conf is python bites badly :( setting up the user account is also in the tens of minutes | 14:39 |
| ogra_ | but if you can live with the inital slowness the board works quite well after the first setup :) | 14:39 |
| mup | PR snapd#1871 closed: snap: lessen annoyance of implicit interface tests <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1871> | 14:41 |
| dholbach | Ubuntu Community Q&A with Michael Vogt starting in 15m (15 UTC) on http://ubuntuonair.com | 14:47 |
| zyga | ooo | 14:47 |
| zyga | way to go mvo! :) | 14:47 |
| === JanC is now known as Guest12202 | ||
| === JanC_ is now known as JanC | ||
| === dpm_ is now known as dpm | ||
| mup | PR snapd#1950 opened: store,snap: initial support for delta downloads <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1950> | 14:58 |
| Saviq | hi all, any idea about http://pastebin.ubuntu.com/23207400/ ? I'm trying to follow https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ but can't even create the image... grub-install is obviously there on my machine | 15:03 |
| ogra_ | grub-install ??? | 15:04 |
| * ogra_ reads the paste | 15:04 | |
| ogra_ | hmm, if it would open | 15:05 |
| sergiusens | Saviq migt want to tell kgunn to update that guide to use ubuntu-image | 15:05 |
| Saviq | sergiusens, ~same args? | 15:05 |
| ogra_ | Sano, completely diffferent | 15:06 |
| ogra_ | *Saviq | 15:06 |
| Saviq | yay | 15:06 |
| sergiusens | Saviq I have been completely decoupled (finally) from image building :-) \o/ !!! | 15:06 |
| Saviq | where do I get ubuntu-image? snap find doesn't yield anything | 15:06 |
| ogra_ | sigh .. so this was 12min waiting for console-conf to set up the user ... go python | 15:06 |
| sergiusens | use --edge | 15:07 |
| ogra_ | Saviq, see PM ... though whats the reason to actually create an image instead of using either the beta or daily ones that we already have ? | 15:09 |
| * ogra_ points to http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ (for beta) and http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ for dailies | 15:11 | |
| ogra_ | there shoudl really be no reason to build your own image | 15:11 |
| niemeyer | jdstrand: Super easy one (I hope), for when you have a few seconds: snapd#1948 | 15:12 |
| mup | PR snapd#1948: interfaces/builtin: add run/udev/data paths to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1948> | 15:12 |
| Saviq | ogra_, I suppose to give it more space or something? | 15:12 |
| jdstrand | yeah, that is. we discussed it | 15:12 |
| jdstrand | niemeyer: fyi, pushed the docker change | 15:12 |
| niemeyer | jdstrand: Thanks! | 15:12 |
| Saviq | dunno, really - will try with the published image | 15:13 |
| ogra_ | Saviq, well, the beta ones have 3.8G ... the dailies around 3G ... | 15:13 |
| Saviq | ogra_, ack, trying the daily | 15:13 |
| ogra_ | (at least for kvm ... ) | 15:13 |
| Saviq | 500 kBps on a 600Mbps link... why, oh why!? | 15:13 |
| mup | PR snapd#1948 closed: interfaces/builtin: add run/udev/data paths to mir interface <Created by kgunnfront> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1948> | 15:14 |
| niemeyer | jdstrand: Don't see the docker change..? | 15:15 |
| ogra_ | there is a new PR | 15:15 |
| ogra_ | (for docker) | 15:16 |
| * ogra_ noticed it in the mail spam ... | 15:16 | |
| niemeyer | ogra_: That's the one we're discussing, I think/hope | 15:16 |
| popey | ogra_: tried both pi 2 and pi3 images from http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ and neither gives any output on HDMI | 15:17 |
| ogra_ | ah | 15:17 |
| popey | i set console=tty1 and nothing | 15:17 |
| ogra_ | popey, they do for me | 15:17 |
| Saviq | kgunn, do you know if we still need the self-built image for https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ ? ogra_'s proposing either http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ or http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ | 15:17 |
| Saviq | ah d'oh | 15:17 |
| * Saviq needs to read better, is all | 15:18 | |
| ogra_ | popey, i always test using HDMI for one of them to run the console-conf wizard ... (and the other i test purely via serial) | 15:19 |
| ogra_ | usually alternating between them for each test ... | 15:19 |
| ogra_ | it might be that the boot stalls if there is no serial at all though ... i doubt anyone of us has ever tested without serial attached | 15:19 |
| dholbach | how do I resolve something like this? | 15:20 |
| dholbach | daniel@daydream:~/dev/snappy/snappy-playpen$ snap remove sayonara | 15:20 |
| dholbach | error: cannot remove "sayonara": snap "sayonara" has changes in progress | 15:20 |
| dholbach | daniel@daydream:~/dev/snappy/snappy-playpen$ | 15:20 |
| ogra_ | dholbach, snap changes | 15:20 |
| ogra_ | find the change in progress | 15:20 |
| ogra_ | then "snap abort $changenumber" | 15:21 |
| dholbach | nice one | 15:21 |
| dholbach | thanks | 15:21 |
| dholbach | let's see how this goes | 15:22 |
| popey | ogra_: it brings up IP and no hdmi, but ssh with ubuntu@ the password 'ubuntu' fails. I don't understand this | 15:24 |
| ogra_ | popey, there is no ubuntu user anymore | 15:25 |
| popey | ok, can i ssh in at all? before any setup? | 15:25 |
| ogra_ | no | 15:25 |
| popey | ssh is running though | 15:25 |
| ogra_ | well, the network setup is also interim | 15:25 |
| popey | so, what's a way forward here? | 15:25 |
| ogra_ | you only get proper configs in place after you ran through console-conf ... | 15:26 |
| popey | I am using an announced image on commodity hardware and I get nothing on the screen | 15:26 |
| niemeyer | jdstrand: There's probably a push missing on the docker branch | 15:26 |
| ogra_ | popey, it is an IoT image ... use it in this context ... really ... | 15:27 |
| jdstrand | oh, I did! | 15:27 |
| ogra_ | (read: there will most likely *not* be any 20" HDMI screen on top of your robot or drone) | 15:28 |
| popey | this is quite possibly the most frustrating I have felt for some time. | 15:28 |
| popey | I give up | 15:29 |
| jdstrand | niemeyer: ok, pushed for real | 15:29 |
| ogra_ | well, i cant really help you if you dont use a serial cable | 15:29 |
| niemeyer | jdstrand: Thanks! | 15:29 |
| popey | don't worry, I'll put them in a box and forget they exist | 15:29 |
| ogra_ | how am i even supposed to knwo whats going on without you being able to give me any debug info from the console | 15:29 |
| popey | this worked with a previous image | 15:29 |
| popey | my expectations clearly need a reset | 15:30 |
| ogra_ | it works every day here on my Pi's | 15:30 |
| popey | I am happy for you. | 15:30 |
| ogra_ | and i cant tell if your SD has issues or anything if i cant get your serial output | 15:30 |
| popey | the sd card worked fine, then i had to reflash because of the libssl issue I mentioned earlier | 15:31 |
| popey | I have tried two sd cards and two generations of pi | 15:31 |
| ogra_ | do you see the rainbow square on screen when waiting for it to come up ? | 15:31 |
| popey | no | 15:31 |
| popey | nothing | 15:31 |
| ogra_ | then it just idles | 15:31 |
| popey | i see heartbeat and network flash | 15:31 |
| popey | and ssh on that port | 15:31 |
| ogra_ | how big is your SD ? | 15:31 |
| popey | 32GB | 15:31 |
| ogra_ | hmm, that should take less than a minute to resize | 15:32 |
| dholbach | ogra_, have you seen anything like this before? http://paste.ubuntu.com/23207556/ | 15:32 |
| ogra_ | dholbach, oh, nope,. thats new | 15:32 |
| popey | dholbach: yes, i have, make sure you kill all shells in that directory | 15:33 |
| popey | dholbach: probably a bash running or something in there | 15:33 |
| dholbach | ok, I'll restart after the hangout :) | 15:33 |
| ogra_ | popey, you can try something else and completely dumb down HDMI ... edit config.txt on the system-boot partition and add hdmi_safe=1 ... see if that helps in any way | 15:34 |
| ogra_ | and as before ... if you dont use the daily image, re-flash before first boot | 15:34 |
| ogra_ | else the setup is likely messed up | 15:34 |
| popey | ok | 15:35 |
| ogra_ | (or just use the daily, thats way more robust) | 15:36 |
| ogra_ | (and 10x faster to flash) | 15:36 |
| popey | where is the pi3 daily image please? | 15:37 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 15:37 |
| popey | before I flash, here's the syslog http://paste.ubuntu.com/23207584/ | 15:38 |
| popey | fwiw | 15:39 |
| mup | Bug #1625698 opened: console-conf on beaglebone takes unbearable long <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1625698> | 15:39 |
| dduffey | matteo, morphis : i am using the current xenial pi3 image and when it boots i configure the network (just accept the defaults, it gets a dhcp address on eth0), and then enter my david.duffey@canonical.com. I then can ssh into the pi3 ... but as soon as i reboot it goes back into "configure" first boot and then fails to create the existing user | 15:40 |
| ogra_ | popey, looks all fine ... it is most likely sitting theer waiting for input on the console | 15:41 |
| ogra_ | Sep 20 14:52:52 localhost systemd[1]: Started Ubuntu Core Firstboot Configuration tty1 | 15:41 |
| ogra_ | that is what i see close to the end | 15:41 |
| dduffey | matteo, are you using the current pi3 for your openwrt testing, or daily / edge? | 15:41 |
| matteo | I made an image witu ubuntu-device-flash | 15:42 |
| mup | PR snapcraft#742 closed: Handle missing source type packages in the parser <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/742> | 15:43 |
| ogra_ | dduffey, is that daily or the beta image from cdimage ? | 15:46 |
| dduffey | ogasawara_, the beta image from cdimages | 15:46 |
| ogra_ | hmm | 15:47 |
| dduffey | ogasawara_, dates sept 19 | 15:47 |
| ogra_ | yes | 15:47 |
| dduffey | ogasawara_, it may have something to do with on first boot it doesn't see wlan0 | 15:47 |
| dduffey | and then when you reboot it finds wlan0 | 15:47 |
| ogra_ | (you should use three chars for your autocompletion ... though i guess leann is happy to collect pings) | 15:47 |
| dduffey | ogasawara_, sorry | 15:47 |
| ogra_ | dduffey, yes, most likely ... that should be a bit better in the daily image ... | 15:48 |
| dduffey | ogra_, the daily image pulls snap from the edge channel, right? | 15:48 |
| ogra_ | but even if the wlan0 issue is at fault, it should never bring you back to the config screen | 15:48 |
| ogra_ | yep | 15:48 |
| ogra_ | there landed a new console-conf today in the ubuntu-core snap in edge | 15:49 |
| ogra_ | so todays daily might not have that issue anymore (i havent tested pi's today, so ui cant really tell) | 15:49 |
| * ogra_ was battling with the beaglebone images ... | 15:50 | |
| dduffey | ogra_, okay, I will try ... another question ... in the past the snappy list -v showed all the snaps (including the prior installed snap) ... what is the 16 equivalent | 15:50 |
| ogra_ | snap list ... | 15:50 |
| ogra_ | but i dont think it shows former snaps ... | 15:51 |
| ogra_ | but the new snap keeps logs ... you can check with "snap changes" | 15:51 |
| dduffey | I ask because on this image yesterday a "snap refresh" downloaded an ubuntu-core, today it said there was no updated but i think that is because it already snap refreshed on it's own ... I just want to verify | 15:51 |
| dduffey | cool | 15:51 |
| ogra_ | and you can see details with "snap change $number" | 15:51 |
| ogra_ | (with the number listed in "snap changes") | 15:52 |
| dduffey | you read my mind ... thanks! | 15:52 |
| dduffey | yes, i see that it did update ubuntu-core on it's own | 15:52 |
| popey | ogra_: so, cmdline.txt:- dwc_otg.lpm_enable=0 console=tty1,115200 elevator=deadline | 15:53 |
| popey | right? | 15:53 |
| popey | (also hdmi_safe) | 15:53 |
| dduffey | ogra_, so this is where you would recommend downloading from? (and I'm assuming this will move out of your account someday): people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 15:54 |
| ogra_ | popey, yeah, that should work ... and in config.txt you set the hdmi option from above | 15:54 |
| popey | yeah | 15:54 |
| ogra_ | dduffey, yeah, for the dailies use that url for now ... once infinity has set up dailies on cdimage i will shut that place down | 15:54 |
| popey | ogra_: i get output! | 15:55 |
| ogra_ | great | 15:55 |
| popey | thanks. | 15:56 |
| ogra_ | sadly the Pi will now never read your EDID :) | 15:56 |
| ogra_ | or any useful info from your monitor | 15:56 |
| dduffey | matteo, once I try the pi3 daily, what do you recommend I do before installing the openwrt snap ... i.e during the first boot config ... dhcp on eth0 (so service it an ip address and browse to luci) ... and what about wlan0 setup? | 15:56 |
| popey | ogra_: now it's been sat at "random: nonblocking pool is initialized" for 3 mins | 16:00 |
| matteo | when you start openwrt it will always configure eth as wan interface, and wlan as lan | 16:00 |
| matteo | so, dhcp on eth0 | 16:01 |
| matteo | an access point will bringed up on wlan0 | 16:01 |
| dduffey | matteo, okay thanks ... should i pre-setup a static config at first boot ... it seems like ubuntu core doesn't let me leave wlan0 "unconfigured" (i.e. it wants me to fill out the ssid) | 16:05 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | popey, whats above that ? | 16:14 |
| popey | ogra_: it finally finished :) | 16:15 |
| ogra_ | (there should be some info abnout resizing ... that might take a few mins) | 16:15 |
| popey | was doing the resize for aaaaaaaaaaaaaaaaaaaaages | 16:15 |
| ogra_ | yeah, 32GB ... | 16:15 |
| ogra_ | the image is only like 300MB ... | 16:15 |
| popey | and now I have lots of space :) | 16:16 |
| * popey presses enter to configure, as told | 16:16 | |
| ogra_ | it seems to only be that slow on non GPT installs ... | 16:16 |
| ogra_ | i wonder if we could switch the Pi's to GPT | 16:17 |
| ogra_ | but i guess that will make the proprietary bootloader fall over | 16:17 |
| popey | I *love* this console setup thing | 16:18 |
| popey | properly LOVE it | 16:18 |
| popey | who made it? | 16:18 |
| ogra_ | yeah, it is great if it works :P | 16:18 |
| ogra_ | (still has a good bunch of issues, but getting better with every release) | 16:18 |
| ogra_ | popey, thats mwhudson ... and a bit cyphermox | 16:19 |
| ogra_ | "subiquity" | 16:19 |
| popey | even if the keyboard layout isn't right :) | 16:19 |
| popey | (i saw the thread) | 16:19 |
| ogra_ | the new installer | 16:19 |
| ogra_ | well and it cant realyl be right | 16:19 |
| ogra_ | we dont ship any keymap | 16:19 |
| ogra_ | s | 16:19 |
| ogra_ | the advantage is that the current install is only 160MB big :) ... and given you always only log in via ssh, the console keymap only kicks in at the config tool | 16:21 |
| ogra_ | ssh will use your hosts keymap and we dont set up local logins | 16:21 |
| popey | but first setup the layout is wrong, for logging into the store | 16:21 |
| popey | so I get my password wrong | 16:22 |
| popey | although this time wasn't needed I guess because it recognised my device from last time? | 16:22 |
| ogra_ | your password ?!? | 16:22 |
| * ogra_ has never seen a password prompt | 16:23 | |
| popey | it used to ask for pw/2fa? | 16:23 |
| popey | or am I imagining that? | 16:23 |
| ogra_ | well, if it does, it has not asked me since i know that tooL (about a month now and i use it daily) | 16:23 |
| ogra_ | it should only ask for your LP email ... | 16:24 |
| popey | ok | 16:24 |
| popey | pretty sure I typed my 2fa in at least once | 16:24 |
| ogra_ | which means the @ is an issue | 16:24 |
| popey | will see on the pi3, which I haven't ever setup like this | 16:24 |
| ogra_ | it really shouldnt ask for anything | 16:25 |
| popey | ok | 16:25 |
| ogra_ | are you on the daily now or on beta still ? | 16:26 |
| popey | daily | 16:26 |
| ogra_ | good | 16:26 |
| ogra_ | and the pi3 where you think you saw that, was that an official release or something rolled with ubuntu-device-flash | 16:26 |
| popey | daily from same place | 16:27 |
| popey | i havent set that up yet, doing now | 16:28 |
| ogra_ | btw bug 1621378 | 16:28 |
| mup | Bug #1621378: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621378> | 16:28 |
| cyphermox | well, we'll actually make it do proper keyboarding | 16:29 |
| popey | ta | 16:29 |
| ogra_ | cyphermox, how ? | 16:29 |
| cyphermox | US only is bad for the fr_FR | 16:29 |
| cyphermox | there is a way to pick keyboards, and to apply keyboard settings | 16:29 |
| ogra_ | we dont have any keympas, locales or other language related bits on the image ... | 16:29 |
| ogra_ | deliberately | 16:29 |
| cyphermox | I'm sure you have enough | 16:29 |
| ogra_ | pretty much zero | 16:30 |
| cyphermox | or I'll find out that I'm wrong and cry myself to sleep | 16:30 |
| cyphermox | :) | 16:30 |
| ogra_ | not sure, can you generate one on the fly ? | 16:30 |
| cyphermox | or let mwhudson to do all that, if it happens that I'm pulled into somethign else | 16:30 |
| ogra_ | without any of the ablev | 16:30 |
| cyphermox | I'm not sure | 16:30 |
| ogra_ | *above | 16:30 |
| cyphermox | I need to go steal code from console-setup to do that | 16:30 |
| ogra_ | well, even that has input files | 16:31 |
| cyphermox | my problem :) | 16:31 |
| popey | ship a free US keyboard with every image | 16:31 |
| ogra_ | well, if you grow by more than 1MB it becomes mine :P | 16:31 |
| cyphermox | I mean, US-only keyboard is really bad when your keyboard keys really don't have anything to do with US | 16:31 |
| cyphermox | ogra_: I don't think it will have to grow by that much | 16:32 |
| ogra_ | i'll quote you on that :) | 16:32 |
| cyphermox | from what I see right now, maybe 22k? | 16:32 |
| ogra_ | oh, thats good | 16:33 |
| popey | bet ogra_ is sucking air over his teeth now... "oooh.. 22k.. can't do that guv" | 16:33 |
| cyphermox | that's assuming I need all that console-setup currently needs, which is probably not quite true | 16:33 |
| ogra_ | haha | 16:33 |
| * ogra_ looks around fro the hidden mic | 16:33 | |
| cyphermox | the truth is, I don't know right now how much we'll need, so we'll have to do some testing to find out | 16:33 |
| ogra_ | well, d-i doesnt need much either ... i guess you can steal from there | 16:34 |
| cyphermox | yeah, that's the initial plan, I would say | 16:34 |
| ogra_ | that should be even less than console-setup | 16:34 |
| cyphermox | well, it *is* console-setup | 16:34 |
| ogra_ | unless it switched to it nowadays | 16:34 |
| cyphermox | console-setup-udeb; but still console-setup, minus some weight | 16:35 |
| ogra_ | (i remember there were times before console-setup ) | 16:35 |
| ogra_ | yeah, that should be fine | 16:35 |
| cyphermox | I think I can get away with a subset of that, where we don't deal with as many corner-cases and migration from old things | 16:35 |
| cyphermox | and probably no keyboard detection | 16:35 |
| * ogra_ is just scared to having to add locales back or some such | 16:35 | |
| cyphermox | it doesn't include locales | 16:36 |
| ogra_ | no, "... now that we have proper keyboard support, couldnt we also have localized firstboot setup ?" | 16:36 |
| ogra_ | this is the line that scares me :) | 16:36 |
| ogra_ | and boom, the install is back from 160MB to 500 or so | 16:37 |
| ogra_ | ogra@localhost:~$ df -h /writable | 16:37 |
| ogra_ | Filesystem Size Used Avail Use% Mounted on | 16:37 |
| ogra_ | /dev/mmcblk0p2 3.5G 168M 3.1G 6% /writable | 16:37 |
| ogra_ | ogra@localhost:~$ | 16:37 |
| ogra_ | :D | 16:37 |
| ogra_ | i really like that :) | 16:37 |
| cyphermox | heh | 16:37 |
| cyphermox | what can you do really | 16:38 |
| ogra_ | (and there is still stuf ui could rip out) | 16:38 |
| cyphermox | or we can decide that it should just be US-only and that's it | 16:38 |
| cyphermox | but this is a policy decision that is not mine to take | 16:38 |
| ogra_ | right, but we need a note on screen if we do that | 16:38 |
| cyphermox | yes | 16:38 |
| * ogra_ guesses if he would be super-size-nazi we could go down to half of the above | 16:39 | |
| cyphermox | my question is, is this just an appliance thing, so we don't need to care much about the keyboard and ssh and VT access ? | 16:39 |
| ogra_ | i.e. *really* rip out everything that is not used | 16:39 |
| ogra_ | well, it is an IoT image ... | 16:39 |
| ogra_ | but ... | 16:40 |
| cyphermox | or is it already targetting more hands-on access where the keyboard matters more? | 16:40 |
| ogra_ | it migth be the base for other stuff | 16:40 |
| cyphermox | sure | 16:40 |
| dduffey | ogra_, morphis just an update that I tried the daily and don't see the same issue (first boot config comes up a second time after reboot) | 16:40 |
| cyphermox | but we can ship keymaps and locales as separate snaps later | 16:40 |
| ogra_ | if there is a unity8 snappy image for the dragonboard one day, it might use the current image underneath | 16:40 |
| cyphermox | ie. we can later have a french pack that give you all the magic. | 16:40 |
| ogra_ | dduffey, awesome to hear ... does the IP setup persist too ? | 16:41 |
| ogra_ | cyphermox, yeah, and given the image sitze we could perhaps even have per-country images :) | 16:41 |
| popey | ogra_: pi 2 and pi 3 all setup, thanks for the help, sorry for the grumpyness | 16:41 |
| ogra_ | popey, well, you are totalyl correct to be grumpy ... after all kgunn wants to run mir on all these boards one day | 16:42 |
| cyphermox | ogra_: who would make that policy decision on keyboard? | 16:42 |
| dduffey | ogra_, yes ... although first boot did not show wlan0, there is a similar bug already filed (you pointed to it in your announcement) | 16:42 |
| ogra_ | popey, i'm pondering to use hdmi_safe by default, but i am scared we lost to much on proper monitors then | 16:42 |
| ogra_ | cyphermox, dunno, lets bring it up at the sprint | 16:43 |
| ogra_ | s/lost/lose/ | 16:43 |
| popey | ogra_: is there a new way to enable classic? | 16:44 |
| ogra_ | cyphermox, given that mark ran into it, it will surely get some more attention :) | 16:44 |
| dduffey | ogra_, it looks like your daily is actually using the stable store (had to snap install --edge snapweb) | 16:44 |
| cyphermox | ogra_: is that a sprint I'm going to? do you need to get this by email or something so that it's not forgotten? | 16:44 |
| ogra_ | popey, sudo snap install classic --devmode --edge && sudo classic | 16:44 |
| popey | ta | 16:45 |
| ogra_ | cyphermox, the le hague sprint in oct ... i would expect you to go there ... its also the final snappy sprint | 16:45 |
| ogra_ | before final release | 16:45 |
| cyphermox | ogra_: is this a subjet you could bring up for us? I don't think I or mwhudson are going. | 16:47 |
| ogra_ | hmm | 16:47 |
| ogra_ | you realyl should be there, given you work on an essential part of snappy | 16:47 |
| cyphermox | or tell me if I can put it down somewhere so it comes up | 16:47 |
| ogra_ | well, feel free to abuse bug 1621378 for it | 16:48 |
| mup | Bug #1621378: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1621378> | 16:48 |
| ogra_ | as a whishlist item | 16:48 |
| ogra_ | i guess we could wlak on from there | 16:48 |
| ogra_ | *walk | 16:48 |
| cyphermox | ack | 16:50 |
| ogra_ | yeah, i dont see you on the attendees list ... not even slangasek ... but infinity is listed (without any dates thoguh) | 16:51 |
| seb128 | ogra_, yeah, foundations are not in UES anymore so not invited | 16:52 |
| seb128 | invited->included | 16:53 |
| ogra_ | seb128, well, given it is the final snappy sprint before we release golden images i was expecting anyone who works on snappy related bits to be invited alongside | 16:53 |
| seb128 | no p_itti either | 16:53 |
| ogra_ | paolo is there as well ... semmingly as the only kernel team person ... | 16:53 |
| lucacome | hello | 17:03 |
| lucacome | quick question, does snap use LXD? | 17:04 |
| ogra_ | normally not, but they can | 17:06 |
| ogra_ | i.e. there is an lxd snap that you supposedly can use in your snap through an interface ... and also a docker snap ... both would need special setup for your snap though ... by default snaps dont use any container technology | 17:07 |
| lucacome | thanks ogra_ | 17:08 |
| lucacome | I was reading "is confined from the OS and other apps through security mechanisms" | 17:08 |
| lucacome | but it's not very detailed :) | 17:08 |
| nacc | lucacome: https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ might have more details | 17:09 |
| ogra_ | i thihnk there is some online docs ... | 17:09 |
| ogra_ | ah, nacc is fast :) | 17:09 |
| lucacome | :) | 17:10 |
| lucacome | thank you | 17:10 |
| ogra_ | wow, compared to the sikipages we had in 15.04 that became a "rainy sunday afternoon reading" | 17:11 |
| ogra_ | *wikipages | 17:11 |
| * ogra_ EODs --- | 17:14 | |
| mup | PR snapcraft#815 opened: Replacing deprecated API for searching snaps <Created by cprov> <https://github.com/snapcore/snapcraft/pull/815> | 17:20 |
| mup | PR snapcraft#791 closed: Enable crosscompilation for dump and copy plugins <Created by ehbello> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/791> | 17:32 |
| mup | PR snapcraft#816 opened: Report the proper line number on bad yaml errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/816> | 17:32 |
| Ishu | Can we install snappy on rpi3? | 17:38 |
| Is | Can we install | 17:39 |
| Is | Snappy on rpi3 | 17:40 |
| Is | ? | 17:40 |
| Is | Can i install snappy on raspberry pi 3? | 17:41 |
| Is | ? | 17:41 |
| mup | PR snapd#1951 opened: interfaces/builtin: improve testability and add regression test for LP: #1625291 <Created by zyga> <https://github.com/snapcore/snapd/pull/1951> | 18:05 |
| zyga | launchpad seems to fail on writes for me | 18:06 |
| mup | Bug #1625291 changed: ConnectedSlotSnippet not invoked when connecting two snaps <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1625291> | 18:09 |
| === chihchun_afk is now known as chihchun | ||
| zyga | jdstrand: hey, do you think you could add something here https://bugs.launchpad.net/snap-confine/+bug/1621624 | 18:36 |
| mup | Bug #1621624: /dev/pts/# denial when running snap-confine under sshd configured for pam-apparmor <Snappy Launcher:Fix Released by jdstrand> <https://launchpad.net/bugs/1621624> | 18:36 |
| zyga | jdstrand: speciically to the [Test Case] section, this is a part of the SRU paperwork | 18:36 |
| jdstrand | zyga: the test case requires a pretty advanced setup. I think so long as the policy compiles and you can login via and use hello-world, then you are good. I can then do the pam-apparmor testing on my system to mark it as verification done | 18:38 |
| jdstrand | login via ssh* | 18:38 |
| zyga | jdstrand: thanks I'll think of something | 18:41 |
| jdstrand | zyga: well, I'm trying to save us time :) | 18:42 |
| mup | PR snapd#1942 closed: store,snap: initial support for delta downloads <Reviewed> <Created by absoludity> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1942> | 18:42 |
| mup | PR snapd#1950 closed: store,snap: initial support for delta downloads <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1950> | 18:42 |
| zyga | eh, three more bugs to describe | 18:42 |
| zyga | this is a _lot_ of work | 18:42 |
| jdstrand | zyga: all it does is expand access in a corner case configuration. all that is needed for that with SRUs is to prove it didn't regress | 18:42 |
| jdstrand | zyga: that's how we normally do apparmor policy SRUs | 18:42 |
| jdstrand | zyga: if it compiles and you only added access, the SRU is fine. ping me when verification-needed and I'll verify it works for my configuration | 18:43 |
| zyga | jdstrand: thanks :) | 18:47 |
| zyga | one bug to describe left | 19:03 |
| * zyga is starving, brb | 19:08 | |
| zyga | I left the hardest bug till the end | 19:08 |
| zyga | jdstrand: I'm EOD now but if you want to add anything to https://bugs.launchpad.net/snappy/+bug/1611444 please do | 19:38 |
| mup | Bug #1611444: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP <snapd-interface> <Snappy Launcher:Fix Released by zyga> <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1611444> | 19:38 |
| zyga | jdstrand: I've added SRU information to each bug in the 1.0.40 and 1.0.41 milestones and I will see what's the next step tomorrow | 19:39 |
| zyga | jdstrand: I suspect I need a version of snap-confine from yakkety that has a long changelog entry that includes two dozen bug numbers | 19:39 |
| zyga | jdstrand: and have someone upload that | 19:39 |
| zyga | mwhudson: (perhaps you can do that?) | 19:39 |
| zyga | jdstrand: I've done my part for today, I really need to take a break now | 19:40 |
| jdstrand | zyga: thanks! | 19:40 |
| jdstrand | zyga: I think I'll treat that bug the same as the other and demonstrate that ip netns works when it gets the verfication-needed tag | 19:41 |
| jdstrand | zyga: enjoy your evening :) | 19:41 |
| niemeyer | Spread has been updated. Please report any fires. | 19:58 |
| mup | PR snapd#1925 closed: tests: adjust regex after changes in stat output <Reviewed> <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1925> | 20:03 |
| diddledan | just informational: corebird snapped by github.com/diddledan/corebird-snap in devmode launches but cannot open browser windows to login to twitter with error: Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files | 20:08 |
| mup | PR snapd#1930 closed: many: support snapctl -h <Reviewed> <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1930> | 20:08 |
| mup | PR snapcraft#817 opened: lxd: use built-in image streams <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/817> | 20:09 |
| === beisner is now known as beisner-food | ||
| === beisner-food is now known as beisner | ||
| mup | PR snapd#1872 closed: tests: use in-tree snap{ctl,-exec} for all tests <Reviewed> <Created by mvo5> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1872> | 20:18 |
| mup | PR snapcraft#816 closed: Report the proper line number on bad yaml errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/816> | 20:21 |
| mup | PR snapcraft#811 closed: Support deb files as sources <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/811> | 20:30 |
| mup | Bug #1625805 opened: arm64 kernel panic for l2 mmu with unity8 session snap <Snappy:New> <https://launchpad.net/bugs/1625805> | 20:34 |
| mup | Bug #1625813 opened: hardware-observe does not allow reading temperatures <Snappy:New> <https://launchpad.net/bugs/1625813> | 21:01 |
| * mwhudson waves at zyga | 21:03 | |
| mup | Bug #1625817 opened: Document snap prepare-image options <Snappy:New> <https://launchpad.net/bugs/1625817> | 21:16 |
| Chipaca | ogra_, you around? | 21:17 |
| Chipaca | ogra_, n/m, nothing urgent, i'll pester you tomorrow if i have a chance :-) | 21:19 |
| oparoz | Hello, have people tried to snap dockers yet? | 21:29 |
| zyga | mwhudson: hey | 21:51 |
| zyga | mwhudson: I did some untold number of SRU paperwork bug updates, if you want to collect them in a xenial upload that would help me a lot | 21:53 |
| zyga | mwhudson: each bug from 1.0.4{0,1} qualifies, some are already in xenail and I marked them as such | 21:53 |
| kyrofa | oparoz, might be worth emailing the list | 21:59 |
| oparoz_ | kyrofa, you're probably right | 22:06 |
| mwhudson | argh does the systemd journal not persist between boots on snappy systems? | 22:07 |
| mwhudson | zyga: so you want me to write the changelog entry and upload? | 22:07 |
| mup | PR snapd#1952 opened: configstate,hookstate: add snapctl set <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1952> | 22:10 |
| zyga | mwhudson: you'd have to mkdir /var/log/journald AFAIK | 22:25 |
| zyga | mwhudson: yes, please add a changelog entry, link to the gazillion bugs and upload if you can | 22:25 |
| mup | PR snapd#1785 closed: many: add vendoring of dependencies by default <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1785> | 22:25 |
| zyga | mwhudson: we'll fight the SRU dragon :) | 22:25 |
| mwhudson | zyga: ok | 22:25 |
| mwhudson | heh i seem to spend a lot of time doing that | 22:26 |
| mup | PR snapd#1862 closed: tests: add tests for the classic dimension <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1862> | 22:31 |
| mup | PR snapd#1640 closed: tests: add gsettings interface spread test <Decaying> <Reviewed> <Created by fgimenez> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1640> | 22:44 |
| === bschaefer_ is now known as bschaefer | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!