[04:32] <mup> PR snapcraft#948 opened: Use testtools as the base of all unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/948>
[06:06] <mac_nibblet> Can someone please explain the workflow when developing stuff with snapcraft ?
[06:06] <mac_nibblet> I find it rather tedious to run a clean, download everything again and then install just to test changes to our application
[06:21] <mac_nibblet> Anybody up for some paid support
[06:21] <mac_nibblet> ?
[07:10] <Omou> ?
[07:10] <Omou> is here somebody
[08:29] <mup> PR snapd#2401 closed: snap: abort install with ctrl+c <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2401>
[09:44] <ogra_> mvo, hmm, there was just a new set of kernels released
[09:45] <zyga> ogra_: hey :)
[09:45] <ogra_> yo
[09:45] <mvo> ogra_: cool, did the new lp script tell you? or some other way?
[09:45] <ogra_> mvo, my mail client did :P
[09:45] <mvo> ogra_: new -update? if so, I think we want that in beta and then candidate
[09:45] <mvo> ogra_: heh
[09:46] <ogra_> ok, i'll take care
[09:49] <mvo> ta
[09:51] <mup> PR snapd#2412 opened: snap: add description to `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2412>
[10:03] <mup> PR snapd#2413 opened: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2413>
[10:59] <ogra_> mvo, all kernels in beta, do we have any specific criteria before releasing to candidate atm ?
[10:59] <ogra_> (the store is so sloooow)
[11:00] <mvo> ogra_: a smoke test for now, I think we want something better long term but for now booting all supported boards with the new kernel is the sufficient
[11:00] <ogra_> ok
[11:08] <mup> PR snapd#2414 opened: store: switch default delta format from xdelta to xdelta3 <Created by wgrant> <https://github.com/snapcore/snapd/pull/2414>
[11:25] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2413
[11:25] <mup> PR snapd#2413: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2413>
[11:32] <mup> PR snapd#2415 opened: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <https://github.com/snapcore/snapd/pull/2415>
[11:34] <zyga> jdstrand: ^^
[11:37] <mup> PR snapd#2406 closed: many: add support for classic confinement <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2406>
[11:52] <mup> PR snapd#2416 opened: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[12:14] <liuxg> ogra_, ping
[12:14] <ogra_> yo
[12:15] <liuxg> ogra_, I just followed your suggestion to extract the arm64 file at http://cdimage.ubuntu.com/ubuntu-base/xenial/daily/current/, I unziped the file, and now when I use "sudo chroot rootfsarm64". it gives me an error like http://paste.ubuntu.com/23588275/
[12:15] <liuxg> ogra_, what could be the problem for it? thanks
[12:16] <ogra_> liuxg, did you copy the qemu-$arch-static binary in place ?
[12:16] <liuxg> ogra_, yeah, I just realized that. thanks for your reminding :)
[12:16] <ogra_> this isnt different from using debootstrap ;)
[12:16] <ogra_> (just that you save all the deb unpacking and configuring time)
[12:17] <liuxg> ogra_, yes, it works now. thanks. I will try to explore it and see how it works :)
[12:17] <ogra_> :)
[12:17] <mup> PR snapd#2417 opened: Add uhid interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2417>
[12:33] <liuxg> ogra_, after I enter the chroot, some things are not there. for example, vi is not in the package. I need to install more things
[12:35] <mup> PR snapcraft#931 closed: parser: add support for origin-{branch,commit,tag} <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/931>
[12:35] <mup> PR snapcraft#946 closed: meta: support classic confinment <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/946>
[12:37] <ogra_> liuxg, hmm, vi should definitely be in there, thats weird
[12:38] <ogra_> oh, no, it shouldnt, since thats a buildd tarball
[12:38] <liuxg> ogra_, http://paste.ubuntu.com/23588349/, this is what looks like here.
[12:38] <ogra_> yeah
[12:38] <ogra_> it is what you would get using debootstrap --minbase
[12:38] <ogra_> a typical build chroot
[12:39] <Chipaca> didrocks, could you strace the 'plain' schmurl?
[12:39] <Chipaca> didrocks, (hello! etc :-/)
[12:39] <liuxg> ogra_, also I got some installation issues like http://paste.ubuntu.com/23588353/. it looks not so predicable :)
[12:40] <didrocks> Chipaca: hey! sure, do we have a snap ready with it? I think I will just copy the armhf binary there if not
[12:40] <Chipaca> didrocks, i've always just copied the binary
[12:40] <didrocks> ok!
[12:40] <didrocks> you want a full strace, no option?
[12:40] <ogra_> liuxg, did you "apt update" first (thats not different to how you should do debootstrap)
[12:41] <liuxg> ogra_, yes, I did that in the first place
[12:41] <Chipaca> didrocks, -f -s 4096, i think
[12:41] <ogra_> weird
[12:41] <mup> PR snapd#2418 opened: snapstate/backend: add backend methods to manage aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2418>
[12:42] <didrocks> Chipaca: will give it to you in a few minutes
[12:42] <ogra_> (given that all our build machines use these tarballs ...)
[12:42] <Chipaca> didrocks, perfect
[12:42] <liuxg> ogra_, yeah, it looks like it is not so doable in this method. :)
[12:43] <ogra_> well, looks like not all components are switched on in sources.list (perhaps only main ?)
[12:43] <ogra_> it is definitely the cleaner way ... but if it starts getting to complex to explain in the howto better go with debootstrap
[12:44] <liuxg> ogra_, if I try to use apt-get -f install, I get http://paste.ubuntu.com/23588370/. yeah, I think you have a point. A lot of things are commented out there.
[12:45] <liuxg> ogra_, in fact, the installation is very straightforward, just extract it, and that's it. could it be that it is not daily build?
[12:45] <ogra_> oh, you need to mount /sys and /proc (and if you feel like also devpts), but thats not different with the debootstrap chroot
[12:46] <ogra_> without these dirs mounted any chroot will have issues
[12:46] <ogra_> (regarding package installs at least)
[12:46] <ogra_> the "current" tarballs are definitely from tonight
[12:46] <didrocks> Chipaca: here we go: http://paste.ubuntu.com/23588377/
[12:47] <Chipaca> ah
[12:47] <popey> sergiusens: bug 1612818 - Is there any plan to up the priority of this from wishlist?
[12:47] <mup> Bug #1612818: Ruby breaks when snapped <isv> <new-plugin> <Snapcraft:Triaged> <https://launchpad.net/bugs/1612818>
[12:47] <Chipaca> didrocks, could you do it again, but this time redirecting stdout?
[12:48] <didrocks> Chipaca: sure
[12:48] <Chipaca> didrocks, so i don't need to wade through the pretty progress bar thing :-)
[12:48] <popey> sergiusens: we have software we've rejected snapping because of the lack of ruby plugin)
[12:48]  * Chipaca lazy
[12:48] <liuxg> ogra_,  yeah, I think it is better go with the debootstrap solution :)
[12:49] <ogra_> liuxg, wqell, 80% of the above needs to be solved there too ... you always need to mount /proc and /sys if you enter a chroot (and unmount it when you leave) etc ... but yeah, missing bits in sources.list is indeed bad
[12:49] <didrocks> Chipaca: wait, I didn't take it in the first place to the logs so that you are not bothered with it
[12:49] <didrocks> Chipaca: so, you meant, you want me to redirect stdout to /dev/null so that you don't have the write()/ioctl?
[12:49] <Chipaca> didrocks, the progress bar addds ioctl()s and weird prints to the log
[12:49] <Chipaca> exactly
[12:50] <didrocks> yeah, you detect the output type and disable it
[12:50] <didrocks> got it :)
[12:50] <Chipaca> as all progress bars should :-D
[12:50] <didrocks> Chipaca: don't force me to give some examples of python modules I know of :)
[12:51] <Chipaca> didrocks, there's a reason i wrote this progress bar myself :-)
[12:51] <didrocks> Chipaca: btw, what's the name of the go progressbar project you are using? I'm interesting for some personal projects :)
[12:51] <didrocks> ah, it's yours ;)
[12:51] <Chipaca> didrocks, i think next weekend i'll be publishing it
[12:51] <Chipaca> it's not "there" yet
[12:52] <didrocks> great! keep me posted
[12:52] <didrocks> Chipaca: http://paste.ubuntu.com/23588390/
[12:52] <didrocks> (file is a little bit bigger as the download went further down)
[12:54] <liuxg> ogra_, anyway, thanks for your tips :)
[12:54] <Chipaca> didrocks, and i have a bug in progress where it's still doing ioctls :-) darnit
[12:54] <ogra_> np, sad it doesnt work out for you
[12:54] <Chipaca> didrocks, anyway, thank you; this is what i needed
[12:55] <liuxg> ogra_, anyway, I still learn a lot out of it :)
[12:55] <didrocks> Chipaca: yeah, I noticed it ;) at least, you don't have the write()
[12:56]  * Chipaca nods
[12:56] <ogra_> :)
[12:56] <Chipaca> didrocks, it's just checking whether the fd suddenly became a terminal, by magic
[12:56] <Chipaca> didrocks, it should do that check once at the start methinks -- unless file descriptors can suddenly become terminals :-)
[12:56] <didrocks> "suddenly" :-)
[12:57] <didrocks> yeah, only once will make sense :)
[12:57] <ogra_> everything is a file !
[12:59] <Chipaca> didrocks, could you also strace curl?
[12:59] <didrocks> yep, doing
[13:03] <didrocks> Chipaca: hum, logs are 50M
[13:03] <Chipaca> hehe
[13:04] <Chipaca> didrocks, gzip it and put it on p.c.c?
[13:04] <didrocks> Chipaca: yep, ofc, you have the 30M snap in it :)
[13:04] <didrocks> with the write() ops
[13:05] <sergiusens> popey well we need someone who knows ruby, lately all the plugins have been externally contributed except for the python a go ones which I've catered for; also wishlist is the status only because it is not a bug, it is a feature request
[13:06] <Chipaca> didrocks, ah, you can drop the -s option there if you want
[13:06] <Chipaca> didrocks, :-/
[13:06] <popey> sergiusens: so we basically need someone who knows python + ruby?
[13:06] <didrocks> Chipaca: ok, doing, will be easier for you to read
[13:06] <sergiusens> popey if we can get someone that knows ruby I can work on the plugin code itself
[13:07] <popey> ok
[13:08] <didrocks> Chipaca: less than 2 Megs: http://paste.ubuntu.com/23588441/
[13:14] <mup> PR snapcraft#949 opened: project: support building classic snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/949>
[13:18] <renato__> mvo, hey, could you review the pending reviews for package: 6453
[13:20] <kalikiana_> snapd master seems to be aborting instantly on startup for me - could there be a regression? Or something changed that'd require updating something else?
[13:23] <zyga> kalikiana_: can you share any error messages or logs please?
[13:23] <kalikiana_> zyga: None, except for "Terminated" as far as I can see
[13:23] <zyga> kalikiana_: anything in journalctl -u snapd
[13:24] <kalikiana_> -- No entries --
[13:25] <kalikiana_> Non-snapd entries are there for failing to connect to snapd
[13:25] <kalikiana_> (Because it's not running, obviously)
[13:26] <kalikiana_> zyga: ^^
[13:26] <zyga> interesting and odd
[13:27] <kalikiana_> I tried going back some revisions but even a half month makes no difference
[13:27] <kalikiana_> So I suspect something in the system other than snapd changed
[13:29] <kalikiana_> zyga: There was a dependency change that required "go get" at one point, any idea if that might be related?
[13:29] <kalikiana_> It's the only change I'm aware of
[13:30] <kalikiana_> Other than whatever might've changed in an update of the base system
[13:40] <Chipaca> didrocks, in the curl strace with the big -s, could you grep for HTTP/ (including the /) please?
[13:41] <didrocks> Chipaca: no result
[13:41] <jdstrand> zyga: I don't really understand the motivation for 2413
[13:41] <Chipaca> didrocks, are you sure that's in the big trace?
[13:41] <Chipaca> didrocks, ah, case-insensitively please
[13:42] <jdstrand> zyga: basically, we have the default template that allows certain reads, and this rule that allows reading everything
[13:42] <didrocks> Chipaca: ah, case-insensitivity returns 2 results:
[13:42] <didrocks> send(4,
[13:42] <didrocks> "\26\3\1\1\21\1\0\1\r\3\3XF\277\341\302\237M\257\205\355\207\344\36\372i\307\21\250\350d\246\257\357\307\17oxUl\303\324m\0\0l\300+\300,\300\206\300\207\300\t\300#\300\n\300$\300r\300s\300\254\300\255\300\10\300/\3000\300\212\300\213\300\23\300'\300\24\300(\300v\300w\300\22\0\234\0\235\300z\300{\0/\0<\0005\0=\0A\0\272\0\204\0\300\300\234\300\235\0\n\0\236\0\237\300|\300}\0003\0g\0009\0k\0E\0\276\0\210\0\304\30
[13:42] <didrocks> 0\236\300\237\0\26\1\0\0x\0\27\0\0\0\26\0\0\0\5\0\5\1\0\0\0\0\0\0\0\33\0\31\0\0\26public.apps.ubuntu.com\377\1\0\1\0\0#\0\0\0\n\0\f\0\n\0\27\0\30\0\31\0\25\0\23\0\v\0\2\1\0\0\r\0\26\0\24\4\1\4\3\5\1\5\3\6\1\6\3\3\1\3\3\2\1\2\3\0\20\0\v\0\t\10http/1.1", 278, MSG_NOSIGNAL) = 278
[13:42] <didrocks> send(5, "\26\3\1\1\32\1\0\1\26\3\3XF\277\260\330B\204g\307@\n(\271\22\31\257I\n\312\335\21\7
[13:42] <didrocks> \n\256\341L\264\f\347\17\222\0\0l\300+\300,\300\206\300\207\300\t\300#\300\n\300$\300r\300s\300\254\300\255\300\10\300/\3000\300\212\300\213\300\23\300'\300\24\300(\300v\300w\300\22\0\234\0\235\300z\300{\0/\0<\0005\0=\0A\0\272\0\204\0\300\300\234\300\235\0\n\0\236\0\237\300|\300}\0003\0g\0009\0k\0E\0\276\0\210\0\304\300\236\300\237\0\26\1\0\0\201\0\27\0\0\0\26\0\0\0\5\0\5\1\0\0\0\0\0\0\0$\0\"\0\0\037068ed04f2
[13:42] <didrocks> 3.site.internapcdn.net\377\1\0\1\0\0#\0\0\0\n\0\f\0\n\0\27\0\30\0\31\0\25\0\23\0\v\0\2\1\0\0\r\0\26\0\24\4\1\4\3\5\1\5\3\6\1\6\3\3\1\3\3\2\1\2\3\0\20\0\v\0\t\10http/1.1", 287, MSG_NOSIGNAL) = 287
[13:42] <Chipaca> thx
[13:42] <didrocks> I guess it's the first request + redirect?
[13:43] <jdstrand> zyga: and why do classic snaps care about about this? if they do care, can't we add this rule conditionally on jailmode (plus, I thought that we didn't support jailmode with --classic)
[13:43] <Chipaca> didrocks, yep
[13:44] <mup> PR snapd#2419 opened: store: retry downloads on io.Copy errors <Created by stolowski> <https://github.com/snapcore/snapd/pull/2419>
[13:45] <Chipaca> didrocks, are you in a position to wireshark the pi's connection?
[13:47] <Chipaca> didrocks, forget it, https. Let me think some more.
[13:50] <ahasenack> is there a way to prevent snaps from auto-upgrading?
[13:51] <zyga> jdstrand: because gustavo argued to have --jailmode that turns classic snaps into regular confined snaps
[13:52] <Chipaca> didrocks, could you run it again, the very first schmurl, pointing at http://lenticularis.chipaca.com/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap please?
[13:54] <alex-abreu> Chipaca, quick question, ... the List & Find snapd client results dont contains the list of plugs & slots requested & defined by the snap, I was thinking about creating a PR to add them to the snapinfo as strings, wdyt?
[13:55] <mup> PR snapd#2268 closed: many: merge snap-confine into snapd <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2268>
[13:55] <Chipaca> alex-abreu, what for?
[13:55] <didrocks> Chipaca: 3 downloads in a row, they all completed with success. So clearly a store <-> client interaction
[13:55] <Chipaca> didrocks, not so quick, little one :-p
[13:56] <alex-abreu> Chipaca, they are required in snapweb, as snap met ainfo
[13:56] <didrocks> ;)
[13:59] <Chipaca> didrocks, and now https://people.canonical.com/~john/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap
[14:02] <didrocks> Chipaca: success as well
[14:02] <Chipaca> alex-abreu, how would you get the ones from the store?
[14:03] <Chipaca> didrocks, and https://068ed04f23.site.internapcdn.net/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?t=2016-12-07T13:58:28Z&h=35c698e528ac75d574ed395ecc3144ebff6a238b ? (don't forget to quote it)
[14:03] <alex-abreu> Chipaca, the store lists the plugs & slots
[14:04] <Chipaca> alex-abreu, but you don't talk to the store
[14:05] <alex-abreu> Chipaca, maybe I am missing your point, but snapd/client/packages.go Find does in the backend ...
[14:05] <didrocks> Chipaca: dropping after few Kb or Mb downloaded
[14:05] <didrocks> with the same reset by peer
[14:06] <Chipaca> didrocks, and https://public.apps.ubuntu.com/anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?cdn=local
[14:08] <zyga> jdstrand: snap-confine is in snapd now :)
[14:08] <zyga> :)
[14:09] <didrocks> Chipaca: works with the local cdn parameter (so internapcdn.net is behaving in some unexpected fashion?)
[14:09] <didrocks> let me try to curl that one (in case curl is redirected to another one)
[14:09] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2416
[14:09] <mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[14:10] <didrocks> (curl worked)
[14:11] <Chipaca> alex-abreu, sorry, my point is that it's going to be a big branch, because not only client doesn't know it, neither does daemon, nor store, nor state
[14:12] <Chipaca> alex-abreu, and I don't understand the design that would benefit from including this information, but I'm not inherently opposed to the idea
[14:12] <alex-abreu> Chipaca, yes I had a quick look at it and yes, ... the overlord needs to be updated etc.
[14:14] <Chipaca> noise][1, ping
[14:14] <alex-abreu> Chipaca, it is not a super high prio, but having it seems like a strong requirement for them
[14:14] <noise][1> Chipaca: so we have curl->internap OK, snapd->internap not, snapd->elsewhere OK ?
[14:15] <Chipaca> noise][1, go http client, not snapd, but yes
[14:15] <Chipaca> i took snapd out of the equation to make it simpler
[14:15] <Chipaca> just a regular `http.Get(...)`
[14:15] <noise][1> yeah, have you tweaked any tcp options yet?
[14:16] <Chipaca> noise][1, not usefully, why?
[14:16] <noise][1> mostly thinking timeouts, keepalives
[14:17] <Chipaca> noise][1, keepalives are to keep the connection alive, aren't they?
[14:18] <Chipaca> anyway gustavo had me set keep alives to a very small time and nothing changed
[14:18] <noise][1> in that strace - is getting a read timeout?
[14:18] <Chipaca> no, a ECONNRESET
[14:20] <noise][1> ah, missed that, yeah
[14:20] <Chipaca> I'll write something to dump the whole request we make
[14:20] <Chipaca> let's see what gives
[14:25] <renato__> mvo, could you upload the first version of this package to store? https://code.launchpad.net/~phablet-team/+snap/mediaplayer-app
[14:26] <noise][1> Chipaca: trying to think what curl might be doing differently than go here
[14:26] <noise][1> any consistency on the timing from start to conn reset?
[14:26] <noise][1> didrocks: ^^
[14:26] <didrocks> noise][1: no, can be 1s or up to 4s of download
[14:27] <didrocks> (mostly between 1 & 2s though)
[14:28] <noise][1> didrocks: and this is mainly happening on your pi2? routed/nat'd through your desktop?
[14:28] <didrocks> noise][1: indeed, I never have any issue on my desktop
[14:30] <kgunn> morphis hey wanted to catch you before your eod, i cloned the master of pulseaudio snap, built local, installed on a series16 Core running as a kvm/qemu vm....and i'm having trouble getting it to work, when i call
[14:31] <kgunn> pulseaudio.paplay somfile.ogg
[14:31] <kgunn> it acts like there's no server up to connect to so
[14:31] <kgunn> i didn't know if i need to start a server ?
[14:31] <ogra_> ps ax ?
[14:31] <mvo> renato__: sure
[14:32] <mvo> renato__: btw, nice to see that the snaps are quite small now
[14:32] <renato__> mvo, yes, thanks to ubuntu-app-platform
[14:32] <mvo> indeed
[14:32]  * zyga solicits code reviews for https://github.com/snapcore/snapd/pull/2416
[14:32] <mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[14:33] <zyga> tvoss, lool: ^^ maybe interested
[14:33] <zyga> this is for the release tomorrow
[14:33] <jdstrand> zyga: it sounds like jailmode for classic is strict plus read of all of the core snap. is that accurate?
[14:33] <renato__> mvo, please review the notes app too if possible
[14:33] <zyga> jdstrand: yes
[14:33] <Chipaca> didrocks, can you get https://people.canonical.com/~john/schmurl_arm_verbose and try again?
[14:33] <zyga> jdstrand: that's exactly right
[14:33] <Chipaca> didrocks, (no strace, just the regular output)
[14:37] <didrocks> Chipaca: http://paste.ubuntu.com/23588841/
[14:38] <Chipaca> didrocks, and you had the verbose curl output with all headers somewhere, yes?
[14:40] <didrocks> I can redo one anyway
[14:40] <didrocks> Chipaca: http://paste.ubuntu.com/23588854/
[14:41] <kgunn> morphis sorry, browser crashed bad...had to get it back up...here's the pastebin
[14:41] <kgunn> http://pastebin.ubuntu.com/23588855/
[14:41] <kgunn> of the issue i'm experiencing
[14:42] <Chipaca> didrocks, and if you add -H "Accept-Encoding: gzip" -H "Accept;" ?
[14:44] <didrocks> Chipaca: download still succeeded
[14:52] <Chipaca> didrocks, I suddenly understand people that drink during work hours
[14:52] <Chipaca> I think a cup of tea would work
[14:52]  * Chipaca goes
[14:53] <didrocks> Chipaca: ahah, sounds sane! ;)
[14:54] <kalikiana_> zyga: FYI it seems using "kill" is a bad idea. After using "sudo systemctl stop snapd.service snapd.socket" I got a go stacktrace - turns out there was an extra space in basedeclarations.go
[15:02] <mup> PR snapcraft#950 opened: tests: Use a more stable ftp source <Created by elopio> <https://github.com/snapcore/snapcraft/pull/950>
[15:08] <Chipaca> jdstrand, ping
[15:11] <jdstrand> Chipaca: hey
[15:14] <Chipaca> jdstrand, i'm told you're the person to talk with about http being non-installable
[15:15] <jdstrand> Chipaca: I need more context, but maybe?
[15:15] <Chipaca> jdstrand, - Mount snap "http" (19) (installation not allowed by "snapd-control" plug rule of interface "snapd-control")
[15:16] <jdstrand> Chipaca: what is 'http'?
[15:16] <Chipaca> jdstrand, httpie, in a snap
[15:16] <jdstrand> Chipaca: it sounds like a webserver. why does it need snapd-control?
[15:16] <Chipaca> jdstrand, so you can do http snapd:///v2/etc
[15:17] <jdstrand> Chipaca: ok I think you may be missing some context of my questions
[15:17] <Chipaca> jdstrand, sorry :-)
[15:17] <Chipaca> it's a web client, not a server
[15:17] <jdstrand> Chipaca: currently, http would need a snap declaration to be able to use the privileged snapd socket
[15:17] <Chipaca> like curl but written in python
[15:18] <Chipaca> pretty-prints and colorizes json and other neat things
[15:18] <jdstrand> Chipaca: I'm trying to understand if that access is legitimate
[15:18] <jdstrand> Chipaca: is this a Canonical snap? is it used by snappy developers for debugging, etc?
[15:18] <Chipaca> jdstrand, it's a chipaca snap, not a canonical snap
[15:19] <Chipaca> it is used by me to talk to snapd directly, yes
[15:19] <Chipaca> but it's also just regular httpie, so you can http google.com and such
[15:19] <jdstrand> it seems reasonable that a snappy developer would be able to use a snappy tool to talk to the snapd socket, so I'll say as much in a comment in the snap and grant the snap declaration
[15:21] <Chipaca> hmm. I'll take it. I'd like to think somebody not working on snappy could still do this if they cared about it enough, though.
[15:21] <jdstrand> jeez, why is the store taking so long
[15:21] <Chipaca> jdstrand, that's noise][1's middle name these days, i hear
[15:22] <jdstrand> hmm, searching for 'http' in the store doesn't yield great results...
[15:22] <ogra_> try google then :P
[15:22] <jdstrand> lol
[15:22] <jdstrand> Chipaca: this https://myapps.developer.ubuntu.com/dev/click-apps/3675/ ?
[15:23] <Chipaca> jdstrand, sorry for the delay (2fa...)
[15:23] <Chipaca> jdstrand, yes
[15:23] <jdstrand> Chipaca: ok done
[15:24] <Chipaca> woo, it works again :-D
[15:34] <lutostag> I can't seem to get lxd to work on core-16, due to https://bugs.launchpad.net/snappy/+bug/1606510, is that truly the case or am I missing something?
[15:34] <mup> Bug #1606510: Mechanism to create system groups <lxd> <Snappy:New> <https://launchpad.net/bugs/1606510>
[15:35] <lutostag> any help would be appreciated
[15:35] <ogra_> lutostag, seen my last comment on that bug ?
[15:36] <lutostag> ogra_: sweet, I did not, I will see if that works, thanks!
[15:36] <ogra_> sadlyx there is still manual work required, but we'll fix that
[15:50] <mup> PR snapd#2420 opened: overlord/snapstate: setup/remove aliases as we link/unlink snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/2420>
[15:53] <lutostag> ogra_: ok, I no longer see that error in syslog (but after a reboot the error reappears). And I can never seem to get the lxd daemon to start properly
[15:54] <ogra_> hmm
[15:55] <lutostag> (started with clean kvm image & rpi2)
[15:55] <ogra_> stgraber, any idea why using extrausers might confuse lxd ? even thjough it works before reboot ?
[15:55] <ogra_> do we need any extra pam or nss magic here ?
[15:57] <stgraber> ogra_: lxd just calls getgrnam which should go through the usual NSS stack
[15:57] <ogra_> hmm
[15:58] <stgraber> does "getent group lxd" succeed on such a system?
[15:58] <lutostag> errorcode 2
[15:58] <lutostag> (no output)
[16:01] <ogra_> ogra@pi3:~$ sudo grep lxd /var/lib/extrausers/*
[16:01] <ogra_> ogra@pi3:~$ getent group lxd; echo $?
[16:01] <ogra_> 2
[16:01] <ogra_> ogra@pi3:~$
[16:01] <ogra_> grr
[16:01] <stgraber> good, so not my fault :)
[16:01] <ogra_> ogra@pi3:~$ sudo grep lxd /var/lib/extrausers/*
[16:01] <ogra_> /var/lib/extrausers/group:lxd:x:112:
[16:01] <ogra_> /var/lib/extrausers/group-:lxd:x:112:
[16:01] <ogra_> /var/lib/extrausers/gshadow:lxd:!::
[16:01] <ogra_> /var/lib/extrausers/gshadow-:lxd:!::
[16:01] <ogra_> ogra@pi3:~$ getent group lxd; echo $?
[16:01] <ogra_> 2
[16:01] <ogra_> ogra@pi3:~$
[16:02] <ogra_> so the getent lies ...
[16:04] <stgraber> something must be busted with your nss setup somehow
[16:04] <stgraber> what do you have in nsswitch.conf?
[16:04] <ogra_> passwd:         compat extrausers
[16:04] <ogra_> group:          compat extrausers
[16:04] <ogra_> shadow:         compat extrausers
[16:04] <ogra_> gshadow:        files
[16:04] <ogra_> hmm
[16:04] <ogra_> gshadow doesnt look right
[16:04] <stgraber> yeah, not sure that it'd cause that problem, but maybe
[16:04] <stgraber> should be easy enough to try, just bind-mount a fixed file onto it and try again :)
[16:06] <ogra_> ogra@pi3:~$ sudo getent group lxd; echo $?
[16:06] <ogra_> 2
[16:06] <ogra_> nope, no change
[16:30] <mup> PR snapd#2421 opened: tests: add basic test for docker <Created by mvo5> <https://github.com/snapcore/snapd/pull/2421>
[16:30] <qamar> hi all
[18:02] <zyga> jdstrand: hey
[18:02] <zyga> jdstrand: will you have the time to review https://github.com/snapcore/snapd/pull/2416 today?
[18:02] <mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[18:08] <kyrofa> Hey ogra_, do you know where our kernel snapcraft.yaml is maintained?
[18:08] <zyga> kyrofa: hehe
[18:08] <zyga> kyrofa: I do
[18:09] <zyga> kyrofa: I asked the kernel team if we can move it
[18:09] <zyga> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc
[18:09] <zyga> (in a galaxy far far away)
[18:09] <kyrofa> zyga, ah, thanks!
[18:13] <zyga> kyrofa: reviews welcome ^ (for snapd)
[18:14] <ogra_> kyrofa, note that the actual building happens with the Makefile that is in the tree under source: ... it has nothing at all in common with a snapcraft kernel plugin created kernel snap
[18:14] <kyrofa> ogra_, indeed, I noticed that
[18:15] <kyrofa> ogra_, is that overcoming a shortcoming, or just using something that was already there?
[18:15] <ogra_> (it is a chroot that grabs a bunch of binaries from the archive and pulls the binaries out of there)
[18:15] <ogra_> it is a necessity
[18:15] <ogra_> we need a bunch of userspace bits and these bits need to come from stable packages
[18:15] <kyrofa> ogra_, ah, it's not "just" the kernel, huh?
[18:15] <ogra_> and we need the kernel binaries signed with the ubuntu archive key for secure boot
[18:16] <ogra_> no, rthe official kernel snap has not much in common with a plain kernel snap from a snapcraft plugin build
[18:16] <ogra_> we do not build anything from source
[18:16] <ogra_> due to the key requirement that wouldnt work outside of the archive
[18:17] <ogra_> we need to use the same secure-boot key for UEFI secure boot as the desktop kernel
[18:17] <ogra_> kyrofa, also, ppisati owns all this now
[18:18] <kyrofa> ogra_, ah, very interesting, okay
[18:18] <kyrofa> ogra_, yeah I just curious what it looked like, no problems with it or anything
[18:18] <kyrofa> Thanks for the info!
[18:20] <ogra_> np
[18:21] <jdstrand> zyga: I wasn't planning on it. this looks like the code churn stuff I thought we were not going to make a high prioirty (with tyhicks)
[18:21] <zyga> ogra_: AFAIK all kernel snaps are owned wholly by the kernel team
[18:22] <zyga> jdstrand: we have today and part of tomorrow still
[18:22] <zyga> jdstrand: I can still prepare alt branches but I wrote this super carefully and I'd love to land if it we can review it on time
[18:23] <jdstrand> zyga: why is this important? it is code churn? snap-confine works fine without it
[18:23] <jdstrand> tyhicks: do you want me to continue to put off my work for this ^
[18:23] <zyga> jdstrand: churn in some way, it's making something that was kind of ad-hoc more reliable
[18:24] <zyga> jdstrand: if you don't have the time to review this it's fine but at some point we may need to just land stuff without being reviwed by security
[18:24] <zyga> jdstrand: if you collectively agree that's okay
[18:24] <jdstrand> zyga: that sounds like a threat :)
[18:24] <zyga> jdstrand: no no, I didn't mean it to sound like that
[18:24] <zyga> jdstrand: I mean we may need to reorg stuff as we have conflicting requirements
[18:25] <zyga> jdstrand: and not enough time to do everything
[18:26] <zyga> jdstrand: e.g. I'll likely work on the live namespace changes code soon and that will involve lots of new stuff
[18:26] <jdstrand> I don't know what you are referring to with reorg, but I'm still on snappy full time. anyway, resourcing is something for ratliff, et al. let's see what tyhicks says
[18:26] <zyga> jdstrand: with reorg I meant that perhaps we could land some pull requests without a security review
[18:27] <zyga> jdstrand: and really put your time where it matters most
[18:27] <jdstrand> zyga: sure, and I'd like to finish dbus-app, network-namespace, get seccomp arg policy in place, and like 20 other snappy cards :)
[18:27] <zyga> jdstrand: I don't think the parser code is particilarly security sensitive
[18:27] <zyga> jdstrand: and I write stuff as defensively as I can now
[18:27] <zyga> jdstrand: right, I undertand, and from my perspective you have to ack almost everything I write :)
[18:27] <jdstrand> zyga: it is sensitive. it is running before privileges are dropped. if something bad happens there, priv escalation
[18:28] <zyga> jdstrand: yep, you are right
[18:28] <tyhicks> yes, it is sensitive
[18:28] <jdstrand> zyga: this is nothing against your coding btw
[18:28] <zyga> jdstrand: (and thus I prefer my super defensive and tested code to the stuff that's in main now :)
[18:28] <jdstrand> there is very little in main that is setuid root
[18:29] <jdstrand> this launcher is ridiculously complex for a setuid executable. I understand it has to be so, but...
[18:29] <zyga> jdstrand: I think parsing was
[18:29] <zyga> jdstrand: I agree but I think we made it as simple as it can
[18:29] <zyga> jdstrand: (be)
[18:29] <jdstrand> sure, hence the 'but'
[18:30] <jdstrand> err
[18:30] <jdstrand> hence the 'understand'
[18:30]  * zyga nods
[18:30] <zyga> jdstrand: could emily review some of my branches?
[18:31] <jdstrand> that would be for ratliff and tyhicks to decide
[18:31] <tyhicks> zyga: why is this PR critical?
[18:31] <jdstrand> honestly, I'd love to get to a point where the launcher is constantly changing
[18:31] <jdstrand> isn't*
[18:31] <tyhicks> me too
[18:32] <tyhicks> closely reviewing PRs to a setuid-root executable takes considerable time
[18:32] <jdstrand> Tyler gave the +1 on the error handling one (which is fine), but I'm starting to feel like I'm losing context with each review
[18:33] <tyhicks> I'd like us to not make changes just for the sake of rewriting existing code
[18:33] <zyga> tyhicks: it's on the critical path for classic confinement, there's just two branches after that (short ones)
[18:33] <tyhicks> that PR only adds new code so I can't see what it is simplifying/hardening/improving
[18:34] <jdstrand> again, changing arg parsing isn't critical to that
[18:34] <jdstrand> I gave an easy path for classic
[18:34] <zyga> tyhicks: the code that changes main is in a separate branch
[18:34] <jdstrand> just modify the current parsing
[18:34] <jdstrand> I'm not saying this should not ever be merged. I'm just saying it isn't critical to classic
[18:35] <jdstrand> and therefore maybe we can land small changes fast as opposed to big changes fast
[18:35] <zyga> ok, I'll adjust after feedback from gutavo and propose a small branch that just adds another strcmp for --classic
[18:36]  * jdstrand notes that tyhicks did not weigh in on if one of us should move away from what we are doing to this
[18:36] <tyhicks> my preference is to not preempt all of our current work with this PR
[18:36] <tyhicks> zyga seems to have agreed with a way forward that doesn't need us to do that
[18:37] <zyga> jdstrand, tyhicks: I think at the root of the problem is the fact that I implicitly assume I can get a review from one of you at any time
[18:37] <zyga> and that's not the case
[18:37] <jdstrand> ok. unless told otherwise, I will postpone reviewing this PR
[18:37] <zyga> tyhicks: well, still but to a smaller degree :)
[18:38] <tyhicks> zyga: yeah, that's probably a bad assumption
[18:38] <zyga> tyhicks: so what do you think we should do?
[18:38] <tyhicks> zyga: I thought you said that you'd go the strcmp() route for --classic?
[18:39] <zyga> tyhicks: yes, I mean in general
[18:39] <zyga> tyhicks: what do we do the next time?
[18:39] <tyhicks> zyga: we have to prioritize all of the work that we have on our plates - critical snappy PRs rank extremely high
[18:40] <jdstrand> zyga: I think that the stakeholder process is not being observed
[18:40] <tyhicks> zyga: we'll make time for those
[18:40] <zyga> jdstrand: what process wasthat?
[18:40] <tyhicks> zyga: PRs that move code around fall below ubuntu security updates, some feature development, etc., and that's the situation that we're facing now
[18:40] <jdstrand> it's assumed that I can do anything asked of me for snappy at any time. this results in the security team's snappy lane not getting enough attention
[18:41] <jdstrand> cause everything gets preempted all the time
[18:41] <zyga> tyhicks: should I be allowed to land such PRs with regular reviews?
[18:42] <zyga> jdstrand: right, I see the bad side effects, I'm looking at what to do in general
[18:42] <tyhicks> zyga: I would hope not. Like we discussed, this code will end up being used in the most critical sections.
[18:42] <jdstrand> zyga: I think what tyhicks is saying is that critical PRs will always be treated with critical priority. a PR that just moves stuff around as part of a critical feature isn't really the same thing. We can get to that PR too, but it needs to be prioritized alongside other items
[18:42] <tyhicks> yes, that's what I'm saynig
[18:43]  * zyga nods
[18:43] <tyhicks> please have a good reason to make a code reorgnization PR as a prereq of a critical feature
[18:43] <jdstrand> for example, people are being driven crazy because setpriority isn't using arg filtering
[18:43] <zyga> one thing I'd like to figure out is how we can do refactorings like this one over time, perhaps we should not do it at random time but I would argue that we should have time and space for refactoring code in s-c
[18:43] <jdstrand> and having that and 20 other seccomp arg filtering bugs should be higher priority than an arg parsing pr
[18:44] <zyga> I see
[18:44] <jdstrand> zyga: we can, it just needs to be prioritized alongside the other stuff
[18:44] <zyga> ack
[18:44] <jdstrand> to date, the other stuff is constantly deprioritized
[18:44] <zyga> I'll just keep proposing them and when you have time just review them
[18:44] <zyga> and I'll try minimalistic branches for everything ele
[18:44]  * jdstrand nods
[18:44] <zyga> else
[18:45] <tyhicks> I think that would work out well
[18:45] <jdstrand> zyga: if something is blocking you, it is totally fine to raise that with tyhicks and ratliff
[18:45] <jdstrand> that is the stakeholder process
[18:45] <zyga> ack
[18:45] <tyhicks> thanks zyga
[18:46] <zyga> tyhicks, jdstrand: FYI, after the merge into snapd I'll spend time on adjusting spread tess to work with and feel more like the snapd tests
[18:46] <zyga> and I'll do some small reorg to have a static library shared by snap-confine, snap-discard-ns, snap-system-shutdown and the upcoming snap-modify-ns (working name)
[18:46] <jdstrand> zyga: for you arg parsing pr... since the code will be more involved, perhaps temporarily drop privs before and raise after like we do a little later
[18:47] <zyga> hopefully just autotools changes though
[18:47] <zyga> jdstrand: sure, I can do that easily
[18:47] <tyhicks> heh, I was going to suggest the same thing that jdstrand just suggested
[18:47] <jdstrand> zyga: it isn't bulletproof to be sure, but adds a hurdle
[18:47] <zyga> yes
[18:47] <tyhicks> I'd like to see a temporary drop of privs
[18:47] <zyga> I can even switch hats
[18:47] <jdstrand> switching hats is an interesting concept
[18:48] <zyga> so I'm all up to do all of that in a nice and tested fashion :) (you know I love to code)
[18:48] <jdstrand> yes! :)
[18:48] <jdstrand> I'd say start with priv dropping for that-- it is super easy
[18:49] <zyga> +1
[18:49] <tyhicks> if you change hats, I wouldn't suggest doing it the way that aa_change_hat() is already used
[18:49] <zyga> tyhicks: what would you suggest?
[18:49] <jdstrand> changing hats, using privilege separation in another process, using a crazy restrictive seccomp sandbox for that process are all things that could possibly be done, but would need to be designed to make sure the benefit outweighs the complexity
[18:49] <tyhicks> zyga: well we currently fork and then change hats and never return back
[18:49] <mup> PR snapd#2422 opened: tests: re-enable snap-confine unit tests via spread <Created by zyga> <https://github.com/snapcore/snapd/pull/2422>
[18:50] <zyga> tyhicks: ah
[18:50] <zyga> tyhicks: I thought you meant that we should use something other than aa_change_hat
[18:50] <tyhicks> zyga: you wouldn't want to fork - you'd just change to a hat and then change back
[18:50] <tyhicks> cool, sounds like we're on the same page
[18:50] <zyga> yes, I think so
[18:51] <tyhicks> ok, I'm off to hack on seccomp some more
[18:51]  * jdstrand goes off to reviews and dbus
[18:53] <zyga> thanks guys!
[18:53] <zyga> and if I can review something for you, ask any time!
[18:53]  * jdstrand hugs zyga :)
[18:53] <zyga> I'd like to help :)
[18:53] <jdstrand> thanks!
[18:53]  * zyga hugs jdstrand and tyhicks :)
[18:54]  * tyhicks hugs zyga and jdstrand :)
[19:16] <mup> PR snapd#2423 opened: overlord,overlord/snapstate: implement snapstate.Alias <Created by pedronis> <https://github.com/snapcore/snapd/pull/2423>
[19:27] <mup> PR snapcraft#948 closed: Use testtools as the base of all unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/948>
[19:27] <mup> PR snapcraft#950 closed: tests: Use a more stable ftp source <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/950>
[20:09] <mup> PR # opened: snapd#1613, snapd#2083, snapd#2128, snapd#2129, snapd#2209, snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2274, snapd#2277, snapd#2302, snapd#2328, snapd#2345, snapd#2347, snapd#2359, snapd#2360, snapd#2365, snapd#2368, snapd#2370, snapd#2374, snapd#2377,
[20:09] <mup> snapd#2378, snapd#2380, snapd#2391, snapd#2392, snapd#2394, snapd#2395, snapd#2397, snapd#2407, snapd#2410, snapd#2411, snapd#2412, snapd#2413, snapd#2414, snapd#2415, snapd#2416, snapd#2417, snapd#2418, snapd#2419, snapd#2420, snapd#2421, snapd#2422, snapd#2423
[20:10] <qengho> dang.
[20:43] <kyrofa> jdstrand, the apparmor needed by snappy isn't available upstream, correct?
[20:44] <tyhicks> kyrofa: the userspace bits are all available upstream
[20:44] <tyhicks> kyrofa: not all of the kernel bits are available upstream
[20:45] <kyrofa> tyhicks, right sorry, should have specified the kernel
[20:45] <kyrofa> tyhicks, alright just wanted to double check. Thanks!
[20:45] <tyhicks> kyrofa: upstreaming those bits is something that we'll have someone working on very soon
[20:46] <kyrofa> tyhicks, makes sense for the long haul, but I'm sure there are higher priorities at the moment
[20:47] <tyhicks> yes :/
[20:52] <kyrofa> zyga, do we still have a classic dimension in the new Ubuntu Core images?
[20:55] <kyrofa> ogra_, I seem to remember you demoing the classic stuff, but don't remember how to do it
[21:12] <mup> PR snapcraft#908 closed: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/908>
[21:13] <ogra_> kyrofa, sudo snap install classic --devmode --edge; sudo classic
[21:14] <kyrofa> ogra_, thank you :)
[21:18] <mup> Bug #1647849 opened: Ubuntu Snappy Core on Raspberry Pi 3 Wi-Fi fails on first boot <Snappy:New> <https://launchpad.net/bugs/1647849>
[21:21] <zyga> kyrofa: yes, but it's called clasisc snap
[21:21] <zyga> classic*
[21:22] <kyrofa> zyga, difficult to discover. Do we plan on documenting that further, or integrate further with snapd itself?
[21:22] <zyga> kyrofa: maybe via motd?
[21:22] <zyga> kyrofa: I think we should document it on the snapd wiki
[21:22] <zyga> kyrofa: in "first steps" perhaps, (a find-your-way-around tutorial)
[21:30] <kyrofa> Indeed
[21:30] <kyrofa> motd is also a good idea
[22:16] <mup> Bug #1609322 changed: snap firstboot can run before /sys/class/net/ is populated <Snappy:Fix Released> <https://launchpad.net/bugs/1609322>
[23:10] <mup> PR snapd#2424 opened: interfaces/builtin: add physical-memory-* and io-ports-control <Created by tonyespy> <https://github.com/snapcore/snapd/pull/2424>
[23:16] <mup> Bug #1647849 changed: Ubuntu Snappy Core on Raspberry Pi 3 Wi-Fi fails on first boot <Snappy:New> <https://launchpad.net/bugs/1647849>