[01:36] <mup> PR snapcraft#1026 opened: Add support for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1026>
[03:41] <mup> Bug #1654130 opened: Adding a tag indicating manual connection is needed when displaying interfaces <Snappy:New> <https://launchpad.net/bugs/1654130>
[03:42] <Croepha> Whats the name of the network config stuff thats on core? the thing that replaces etc/interfaces ... trying to find documentation on it and its been a while forgot what it was called
[03:45] <Croepha> netplan
[06:22] <longsleep> mwhudson: well that particular wifi driver is crap in any case, so i would not bother much as the rest seems to work fine. Will try the new edge build on the weekend and then hopefully can report that everything is working
[06:30] <liuxg> Croepha, I have a Chinese blog article at http://blog.csdn.net/ubuntutouch/article/details/53500874 you may use google translate to translate it.
[08:21] <zyga> o/
[08:21] <davidcalle> kyrofa: sergiusens: when is the next snapcraft release?
[09:43] <mup> Bug #1637611 opened: snappy images should not ship /etc/profile.d/Z99-cloud-locale-test.sh <Snappy:In Progress by ogra> <livecd-rootfs (Ubuntu):In Progress by ogra> <https://launchpad.net/bugs/1637611>
[09:44] <mup> PR snapd#2558 opened: snapstate: move refresh from a systemd timer to the inernal snapstate Ensure() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2558>
[10:16] <ogra_> mvo, /etc/profile.d/snappy-oem-branding.sh still looks in /oem for stuff ... should we update it to look somewhere else or just throw it out ?
[10:18] <mvo> ogra_: throw it out please, we have no equivalent for this currently
[10:18] <ogra_> yeah, thought so
[10:42] <mardy> hi, can anyone help me with this snapcraft error? https://lists.ubuntu.com/archives/snapcraft/2016-December/002186.html
[11:45] <mup> PR snapd#2395 closed: make state and squashes immutable when appropriate <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2395>
[13:00] <mup> Issue snapd#2559 opened: seccomp tests fail on Ubuntu 16.04 in when running in qemu or linode <Created by zyga> <https://github.com/snapcore/snapd/issue/2559>
[13:20] <zyga> jdstrand: hey
[13:20] <zyga> jdstrand: any chance you could have a look at ^^
[13:20] <zyga> jdstrand: just as a sanity check, to answer one question
[13:21] <zyga> jdstrand: specifically if this part looks fishy:
[13:21] <zyga> DEBUG: Input line: mmap2
[13:21] <zyga> DEBUG: seccomp rule: ALLOW sycall -10029
[13:21] <zyga> when loading the profile, we seemingly parse "mmap2" to syscall number -10029 (int)
[13:38] <jdstrand> zyga: https://github.com/snapcore/snapd/issue/2559 gives a 404. based on what you pasted, it is saying that mmap2 is allowed by the snappy policy but is unknown on the system that snapd is running on. based on http://people.canonical.com/~ubuntu-security/syscalls/, mmap2 was introduced in kernel 3.19
[13:39] <zyga> jdstrand: the mup thing is buggy, use "issues" not "issue" (missing "s")
[13:39] <zyga> https://github.com/snapcore/snapd/issues/2559
[13:40] <jdstrand> zyga: perhaps the application is a statically compiled application that uses mmap2? perhaps the application is using a library that uses mmap2?
[13:41] <zyga> jdstrand: we run /bin/true
[13:41] <zyga> jdstrand: that's the old test
[13:41] <jdstrand> zyga: nothing in your paste indicates the profile is malformed
[13:41] <zyga> jdstrand: right
[13:41] <zyga> jdstrand: anyway, if you can and are interested in this puzzle, read the bug report
[13:41] <zyga> jdstrand: it has all the facts
[13:41] <jdstrand> zyga: does it have the kernel version?
[13:42] <zyga> jdstrand: kernel is the same as on my machine where the same test works
[13:42] <zyga> jdstrand: the failure occurs in qemu
[13:42] <zyga> jdstrand: running xenial adt cloud image
[13:43] <zyga> jdstrand: for context, I'm trying to re-enable those tests: https://github.com/snapcore/snapd/pull/2433
[13:43] <mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
[13:56] <jdstrand> zyga: I left some questions but I need to prepare for a meeting and then work on the trusty seccomp issue after. I'll swing back around and check in on this later if I'm able to
[13:58] <zyga> jdstrand: thank you
[14:22] <zyga> jdstrand: I added the kernel log snippet, taking a break from this topic now but I suspended a VM that has the environment so I can resume ant any time
[14:32] <mup> Bug #1645605 changed: No alsa module on ubuntu core image <snapd-interface> <Snappy:New for zyga> <https://launchpad.net/bugs/1645605>
[14:56] <mardy> sergiusens: hi! I completely morphed bug 1652290, now it's a bit more interesting
[14:56] <mup> Bug #1652290: Error with remote part depending on another remote part <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1652290>
[14:56] <mardy> sergiusens: I can work on that, if you like (and maybe have some hint for me)
[15:08] <mup> PR snapd#2560 opened: snap: fix missing sizes in `snap info <remote-snap>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2560>
[15:28] <sergiusens> mardy sure, work with josepht who maintains that or Trevinho who started playing with it
[15:29] <mardy> sergiusens: thanks!
[15:30] <mardy> josepht, Trevinho: do you have some last words to say, before I start banging my head into that? :-)   (bug 1652290)
[15:30] <mup> Bug #1652290: Error with remote part depending on another remote part <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1652290>
[15:40] <sergiusens> popey I CCed you on an email that led me to the anatine yaml
[15:41] <popey> sergiusens: thanks
[15:44] <josepht> mardy: Go for it. I'm happy to help.
[15:47] <mup> PR snapd#2561 opened: many: obtain installed snaps developer/publisher username through assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2561>
[15:56] <kyrofa> davidcalle, new version should be in proposed this week
[15:56] <kyrofa> davidcalle, then some testing to do... probably in updates middle of next week
[16:06] <popey> jdstrand: is there a workaround for this http://paste.ubuntu.com/23746854/ - (apps wanting to mknod in /dev/shm/foo) ?
[16:07] <ogra_> use /dev/shm/$SNAP/foo ?
[16:07] <ogra_> (iirc thats what the security check tool tells you)
[16:10] <popey> I used the word "workaround" to mean, "not have to patch upstream"
[16:10] <davidcalle> kyrofa: thanks!
[16:10] <ogra_> :)
[16:10]  * ogra_ doubts there is one
[16:11] <popey> It's a python app.
[16:14] <jdstrand> popey: no workaround. what ogra_ said is the current situation. this is bug #1577514
[16:14] <mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
[16:17] <popey> :(
[16:21] <popey> SamYaple: I note you are/were affected by the above bug. Is that still the case? Did you do anything specific to work around it?
[16:31] <sergiusens> popey snapcraft update; snapcraft define preload
[16:31] <sergiusens> jdstrand ^
[16:35] <popey> ooh
[16:40] <jdstrand> sergiusens: oh, neat! is that documented somewhere? I don't see a mention of that in the bug
[16:41] <sergiusens> jdstrand yeah, I removed snapcraft from the problem
[16:42] <sergiusens> jdstrand popey but it did solve most of someone's problem's on rocket/snapcraft
[16:56] <popey> sergiusens: so basically after: [preload] and then what? Add a preload or something to the launcher?
[16:57] <sergiusens> popey yeah `commmand: preload <whatever>`
[16:57] <popey> winner, thanks. will give that a try
[16:57] <popey> that could fix a few broken snaps I've had in the past.
[16:57] <sergiusens> popey yeah `commmand: preload desktop-launch <whatever>`
[16:57] <popey> I may have to buy you beer
[16:58] <sergiusens> no need, took me long enough to promote this as much ;-)
[16:58] <sergiusens> also, no need for the `after` at all, these can be independent
[16:58] <popey> eh?
[16:58] <sergiusens> but you might need it now that I think of it as you won't be overriding anything
[16:58] <popey> how do I tell snapcraft to use it though?
[16:59] <popey> s/use/include/
[16:59] <kyrofa> sergiusens, yeah, if you leave the plugin out you need _something_ else
[16:59] <kyrofa> sergiusens, probably a schema bug
[17:00] <sergiusens> popey this is the only way by design unless you do the override dance
[17:00] <sergiusens> popey http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
[17:01] <mup> PR snapd#2562 opened: cmd/snap-confine: check for rst2man on configure <Created by zyga> <https://github.com/snapcore/snapd/pull/2562>
[17:02] <mup> PR snapd#2563 opened: cmd/snap-confine: small tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/2563>
[17:02] <mup> PR snapd#2564 opened: cmd/snap-confine: build non-installed libsnap-confine-private.a <Created by zyga> <https://github.com/snapcore/snapd/pull/2564>
[17:05] <mup> PR snapd#2565 opened: store: setting of fields for details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/2565>
[17:14] <mup> PR snapd#2566 opened: tests: disable some ppc64el on yakkety and zesty too <Created by mvo5> <https://github.com/snapcore/snapd/pull/2566>
[17:17] <zyga> jdstrand: good call!
[17:18] <zyga> jdstrand: snap-confine itself needs more syscalls to finish working
[17:18] <zyga> jdstrand: presumably due to debug writes etc
[17:18] <zyga> jdstrand: I trully wonder why this didn't fail on my box though, I'll keep digging
[17:39] <popey> sergiusens: :( preload didn't work. still wants to write to /dev/shm/foo
[17:51] <azubieta> Hello guys! I´m making software center (https://github.com/nomad-shell/nx-software-center) to manage snaps wich uses the snapd REST api in the backend. I was reading the api specifications at the wiki but i found very little about the background process. Is there any place were I can read how to monitor such tasks? Thanks
[17:52] <kyrofa> azubieta, Chipaca is probably your guy
[17:53] <kyrofa> azubieta, attente might also be able to help (or point you in the right direction) from our software center point of view
[17:53] <zyga> azubieta: hey
[17:53] <azubieta> hello
[17:53] <zyga> azubieta: we had an event api but it was removed as it was not finished
[17:53] <zyga> azubieta: what do you need exactly?
[17:54] <azubieta> zyga: monitor the install, remove, update tasks
[17:55] <Chipaca> azubieta, I'm your guy, but I'm in a meeting and then I'm out of here
[17:55] <attente> azubieta: you might also want to look at https://launchpad.net/snapd-glib that robert_ancell maintains
[17:55] <Chipaca> azubieta, john.lenton@canonical.com (or tomorrow, same place, a little earlier)
[17:55] <zyga> azubieta: you can do what snap CLI does
[17:55] <zyga> azubieta: issue the operation
[17:55] <zyga> azubieta: this gives you change ID
[17:55] <zyga> azubieta: then query snapd about that change
[17:55] <azubieta> Chipaca: thanks!
[17:56] <azubieta> zyga: I saw the change id but I was unable to find the path where should I make the query
[17:57] <zyga> azubieta: look at snap changes
[17:57] <Chipaca> azubieta, if you want to "poke" at the api, i'd recommend `snap install http` and then e.g. `http snapd:///v2/changes`
[17:57] <zyga> azubieta: it's not documented on the wiki
[17:58] <zyga> azubieta: but look at /v2/changes/{id}
[17:58] <zyga> azubieta: or at /v2/changes/
[17:58] <zyga> azubieta: you can control changes as well (abort)
[17:58] <azubieta> zyga: thanks!
[17:58] <azubieta> zyga: that´s what I was loking for
[18:00] <azubieta> Chipaca: right now i´m making the http requests by hand and sending then throud the /run/snapd.socket
[18:02] <Chipaca> azubieta, yeah, http is just convenient (it does the same)
[18:02] <Chipaca> it's httpie + unix socket support + magic for snapd:/// urls
[18:03] <azubieta> Chipaca: sounds good, does it has a c/c++ api ?
[18:03] <azubieta> by the way, is there any other software center for snaps ?
[18:05] <zyga> azubieta: gnome-software
[18:06] <Chipaca> azubieta, there's glib-snapd i think?
[18:06] <Chipaca> libsnapd-glib-dev etc
[18:06] <mup> PR snapd#2567 opened: debian: skip snap-confine unit tests on nocheck <Created by zyga> <https://github.com/snapcore/snapd/pull/2567>
[18:07] <azubieta> Chipaca: would you recomend using snapd-glib instead talking directly to the REST API ?
[18:08] <Chipaca> azubieta, I'm probably the wrong person to ask :-) I think if your focus is the software centre, then working with snapd-glib will let you ignore the vagaries of the rest api
[18:09] <Chipaca> azubieta, me personally i like poking at the rest api directly
[18:09] <Chipaca> :-D
[18:09] <azubieta> Chipaca: jeje, i´ll take your advice
[18:10] <Chipaca> azubieta, either way, do shout if you find things that don't work as you'd expect
[18:11] <azubieta> Chipaca: i´m reading a post about snapd-glib they say that they will make a qt/qml port so if it is finished it would be mucho more easier for me
[18:11] <azubieta> Chipaca: i will
[18:12] <azubieta> Chipaca: thanks again
[18:12] <Chipaca> azubieta, the snapd-glib author is in NZ timezone afaik
[18:12] <Chipaca> anyway, i've got to run
[18:18] <vigo> ogra_, confirmed
[18:18] <vigo> I just created an image from edge and config.txt is updated
[18:39] <ogra_> vigo, i would be shocked if it wasnt :)
[18:56] <sabdfl> elopio, elmo and me
[19:07] <matteo> http://pastebin.ubuntu.com/23747897/
[19:07] <matteo> is there something wrong with this control interface?
[19:12] <mup> Bug #1636931 changed: Configure hook not running <Snappy:Fix Released> <https://launchpad.net/bugs/1636931>
[19:18] <mup> Bug #1654362 opened: updating pi3 snap does not update config file <Snappy:New> <https://launchpad.net/bugs/1654362>
[19:21] <lazyPower> elopio  - heyo, looking @ the etcd snap as a possible drop in for the etcd v3 migration. Is what's in the snappy-playpen the latest work on this snap?
[19:34] <mup> Bug #1587448 changed: Can't reboot device from snap <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1587448>
[19:34] <mup> Bug #1590679 changed: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1590679>
[19:34] <mup> Bug #1612871 changed: Permission denied to exec /bin/stty <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1612871>
[19:37] <mup> Bug # changed: 1613686, 1614269, 1615124, 1615262
[19:40] <mup> Bug # changed: 1620442, 1624533, 1624675, 1627813, 1639988
[19:43] <mup> Bug #1644810 changed: snapd system-observe interface is missing rules to allow memory usage analysis <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1644810>
[19:46] <mup> Bug #1596515 changed: IIO access and configuration from a snap <apparmor> <iio> <snapd> <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1596515>
[19:46] <mup> Bug #1639967 changed: Add support to access to some Avahi methods from org.freedesktop.Avahi <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1639967>
[19:46] <mup> Bug #1641869 changed: openvswitch-support interface <snapd-interface> <Snappy:Fix Released by james-page> <https://launchpad.net/bugs/1641869>
[19:47] <Croepha> so, not sure what happened, I have used --try many times before with no trouble, but after a reboot I am getthing this error when trying to use something inside of a --try snap :  cannot snap-exec: cannot read info for "my-snap": stat /var/lib/snapd/snaps/my-snap_x1.snap: no such file or directory
[19:47] <Croepha> that file totally exists
[19:47] <Croepha> its a simlink to the prime dir
[19:49] <mup> Bug #1598266 changed: Cannot read/write to usb device [libusb][hidapi] <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1598266>
[19:55] <mup> Bug #1577897 changed: auto-connection should cover snaps other than OS snap <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1577897>
[20:01] <mup> Bug #1591839 changed: Can't read/write to USB devices <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1591839>
[20:04] <mup> Bug #1611819 changed: implement a way for daemons to play audio <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1611819>
[20:06] <kyrofa> davidcalle, it seems I lied: with the sprint next week, we're delaying release by one week
[20:07] <davidcalle> kyrofa: ok :)
[20:07] <kyrofa> davidcalle, were you looking for a specific feature, or just generally curious?
[20:09] <davidcalle> kyrofa: generally planning, although I could use being walked through scriptlets, I've only seen one example so far
[20:10] <kyrofa> davidcalle, yeah we could use some real docs for that. Happy to help you there (though note those were released in 2.24)
[20:13] <mup> Bug #1645410 changed: interface required: openvswitch <snapd-interface> <snap-nova-hypervisor:New> <Snappy:Fix Released> <https://launchpad.net/bugs/1645410>
[20:13] <davidcalle> kyrofa: thanks
[20:16] <mup> Bug #1613775 changed: cannot access /mnt/storage even through symlinks from $HOME <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1613775>
[20:25] <mup> Bug #1618004 changed: Need a classic-bin interface to see classic binaries <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1618004>
[20:30] <Croepha> any ideas on how to make sense of this: cannot snap-exec: cannot read info for "my-snap": stat /var/lib/snapd/snaps/my-snap_x1.snap: no such file or directory ?
[20:31] <mup> Bug #1617314 changed: Services can only run as root <snapd-interface> <Snapcraft:Invalid> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1617314>
[20:44] <kyrofa> Croepha, you're `snap try`ing, I assume?
[20:45] <Croepha> kyrofa: yes, try --devmode
[20:45] <kyrofa> Croepha, and does /var/lib/snapd/snaps/my-snap_x1.snap exist? It should be a symlink
[20:45] <Croepha> yes, and it is
[20:46] <kyrofa> Croepha, pointing to a valid location?
[20:46] <kyrofa> (a prime directory)
[20:47] <zyga> jdstrand: quick question about old snap-confine unit tests, do I remember correctly that they were only going to pass on amd64?
[20:47] <zyga> jdstrand: I'm seeing a list of errors on i386
[20:47] <zyga> jdstrand: (details are burried under links from https://github.com/snapcore/snapd/pull/2433)
[20:47] <mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
[20:48] <Croepha> kyrofa: yes: /var/lib/snapd/snaps/my-snap_x1.snap/*.wrapper returns several results
[20:48] <Croepha> meant to say that I `ls`d that and got several results
[20:49] <Croepha> my only guess is that snap is running in some other file system context (name space or chroot) where it can't stat that path?
[20:50] <kyrofa> Croepha, any chance you have an encrypted home?
[20:54] <Croepha> kyrofa, no, but I am running in Vmware, and use a mapped home directory, but not sure how that would be affected, it lives in /mnt/hgfs/
[20:54] <jdstrand> zyga: they should work. I just tried them locally with snapd 2.20 on trusty
[20:55] <kyrofa> Croepha, ah indeed, that's probably the issue. zyga may know more
[20:55] <zyga> jdstrand: on i386?
[20:55] <jdstrand> yes
[20:55] <Croepha> kyrofa my prime doesn't live in my home or in that hgfs
[20:55] <zyga> Croepha: hey
[20:55] <zyga> Croepha: try snap run --shell yournsap
[20:55] <zyga> Croepha: snaps do run in a different context
[20:56] <jdstrand> zyga: I'm trying to fix the amd64 snapd/snap-confine testsuite failure and ran the tests on i386 to make sure I didn't break anything (I didn't)
[20:56] <zyga> Croepha: that will give you a (confined) shell in the same context as a given snap/app
[20:56] <zyga> jdstrand: it seems to work on my real box
[20:56] <zyga> jdstrand: but never works in spread (neither qemu nor linode)
[20:56] <zyga> jdstrand: gustavo suggested that it might be caused by those things running as root but I didn't investigate yet
[20:56] <Croepha> zyga run --shell gives the same error
[20:57] <zyga> jdstrand: I'd love if you could drop patches to unbreak https://github.com/snapcore/snapd/pull/2433/files (tip: you can git push to my branch directly!)
[20:57] <mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
[20:57] <zyga> Croepha: can you givem e more context?
[20:57] <Croepha> zyga: this is the error: cannot snap-exec: cannot read info for "tanager-flock": stat /var/lib/snapd/snaps/my-snap_x1.snap: no such file or directory
[20:58] <zyga> jdstrand: maybe spread is breaking something, I see 7 failures on i386 and (finally) 0 failures on amd64
[20:58] <Croepha> zyga: that path does exist and is valid, it is a symlink to a prime dir
[20:58] <zyga> Croepha: is that file around in "real space"?
[20:59] <zyga> Croepha: did you create that symlink?
[21:00] <zyga> jdstrand: can you tell me how are you running tests?
[21:00] <jdstrand> zyga: I'll talk to ratliff on how to prioritize the i386 test failures in https://github.com/snapcore/snapd/pull/2433
[21:00] <mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
[21:00] <jdstrand> zyga: I did debian/rules build
[21:00] <jdstrand> zyga: I would also do: make -C cmd check
[21:01] <jdstrand> zyga: I can't get to those tests today. still working on trusty/libseccomp
[21:01] <zyga> jdstrand: did you try spread?
[21:01] <zyga> jdstrand: that's ok
[21:01] <zyga> jdstrand: thanks!
[21:01] <jdstrand> zyga: no. you said unit tests. is it the unit tests or the spread tests?
[21:01] <zyga> jdstrand: spread runs them
[21:02] <zyga> jdstrand: we don't run unit tests when building the package in spread
[21:02] <zyga> jdstrand: so I wanted to run them as a task
[21:02] <jdstrand> well, I'd have to look at what is happening. I didn't run in spread as I was debugging a testsuite failure from the build
[21:02] <Croepha> zyga: not sure what is meant by "real space", but  I see that in the context where I login via ssh.... I did not create that symlink, I used  snap try --devmode and it made the symlink
[21:02] <zyga> jdstrand: all regular unit tests run but the older tests that exercise seccomp don't pass
[21:02] <zyga> Croepha: I see
[21:02]  * jdstrand is curious why you don't run the unit tests during the build in spread
[21:03] <zyga> Croepha: can you tell me where the source directory was located?
[21:03] <zyga> Croepha: we don't run them at package build time (in spread) because it takes extra time (snapd build) and we run the separately along with other spread tasks
[21:03] <zyga> er
[21:03] <zyga> jdstrand: ^ that was for you
[21:04] <zyga> jdstrand: I fixed a few issues but it's still broken, I need to make the debug output better
[21:04] <zyga> jdstrand: (that tail of kern log for instance)
[21:05] <zyga> jdstrand: in any case, you answered my earlier question, thanks
[21:05] <zyga> jdstrand: I'll keep digging
[21:07] <jdstrand> zyga: I noticed we have a lot of 'dmesg | tail -1' in the seccomp tests. that should be 'dmesg | grep 'audit=1326' | tail -1'
[21:07] <zyga> 1326?
[21:13] <Croepha> zyga: this is the prime dir: /mnt/2/flock21_build/prime  if that is what you are asking  and this is the related findmnt line: ├─/mnt/2                              /dev/sda3                       ext4                rw,relatime,data=ordered
[21:20] <jdstrand> zyga: ok, I've got the trusty/seccomp thing, then several customer items for snappy then can circle back around to this. it won't be today. it will hopefully be tomorrow, it may be monday
[21:23] <zyga> Croepha: does it work if you don't snap try but rather build a regular snap?
[21:23] <zyga> Croepha: that symlink is, I believe, what is causing the problem
[21:27] <Croepha> zyga: a regular snap install works as expected
[21:29] <jdstrand> zyga: 1326 is the code for seccomp
[21:29] <Croepha> zyga: I agree, im just not sure how to remedy it, before kyrofa got back to me, I was thinking of just doing a fresh install of ubuntu and starting over....  it was working fine for a long time, but it just stopped working
[21:30] <jdstrand> zyga: and I of course meant this: dmesg|grep 'type=1326'|tail -1
[21:31] <jdstrand> eg:
[21:31] <jdstrand> $ dmesg|grep 'type=1326'|tail -1
[21:31] <jdstrand> [ 9653.865938] audit: type=1326 audit(1483637031.980:825): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=24498 comm="snap-confine" exe="/home/ubuntu/sbuild/snapd/trusty/snapd-2.20.1~14.04/cmd/snap-confine/snap-confine" sig=31 arch=40000003 syscall=201 compat=1 ip=0x55609c89 code=0x0
[21:46] <grapestomper_1> does anyone know how to change the default console output from ttyS0 to ttyUSB0
[21:46] <grapestomper_1> snappy series 16 (core 16?)
[21:47] <grapestomper_1> in 15.04 I could change the grub.d file - not an option now
[21:48] <Croepha> grapestomper_1, do you really need a kernel console or will a login console work fine?
[21:49] <Croepha> because you can add a tty service to run on that usb device if you want
[21:49] <grapestomper_1> hmmm dont know - I want to be able to watch the boot process. Is that kernel?
[21:49] <Croepha> yeah, thats kernel
[21:50] <grapestomper_1> is kernel tty set at snap cration?
[21:50] <grapestomper_1> creation
[21:50] <Croepha> well, i don't know how to do it, but I think you will need to make your own gadget or kernel snap
[21:52] <Croepha> there might be an easier way, i don't know of it though, sorry
[21:52] <grapestomper_1> np - thanks
[22:06] <kgunn> hey is there a clever way a snap can determine if the console config has been run?
[22:06] <kgunn> working with a mir-kiosk image, but the server is currently launching before i can run through the config to get wifi etc
[22:09] <kgunn> kyrofa: ^ know of anything?
[22:09] <kyrofa> kgunn, does it die if it runs before then?
[22:09] <kgunn> kyrofa: no, mirkiosk happily runs...but takes over the screen
[22:10] <kyrofa> Ah of course, so console conf can't be run, how fun!
[22:10] <kgunn> so we're thinking to add some logic in the launcher file to check if console has run or not
[22:10] <kyrofa> kgunn, hmm, you could do hacky things like see if you have an IP address, but there must be a better way
[22:11] <kyrofa> mwhudson, do you have any ideas? You're involved with that, no?
[22:11] <kyrofa> Oh darn, he's gone
[22:12] <kgunn> yeah, i would think this might be a common theme....people wanting to add snaps to their own image, but wanting console conf to run prior to daemon launching
[22:14] <kyrofa> Taking a quick peek at the src
[22:15] <kyrofa> I bet if there is something though, it won't be accessible to snaps
[22:18] <kyrofa> kgunn, I kinda feel like no services should run until console-conf has run
[22:20] <kyrofa> kgunn, yeah, /var/lib/console-conf/complete
[22:21] <kyrofa> kgunn, nothing you can reach from a confined snap
[22:22] <kyrofa> kgunn, I suggest discussing it with niemeyer and mwhudson
[22:22] <alvarolb> Hi all!! I am trying to upload a snap package to the ubuntu store, but I always get the error: Unexpected output from click-review. click-review
[22:23] <alvarolb> If i execute the click-review manually, I get a RUNTIME_ERROR, but no any other hint
[22:24] <alvarolb> the verbose show some checks that are all passed OK
[22:24] <alvarolb> anyone with the same issue? I am using snapcraft for building the package for amd64
[22:24] <kyrofa> cyphermox, are you familiar with console-conf?
[22:25] <kyrofa> cyphermox, do you know if there's a way to tell if it's been run from within a confined snap?
[22:28] <kgunn> kyrofa: thanks... yep, can bring up tomorrow
[22:29] <mup> PR snapcraft#1007 closed: lifecycle: clean without parsing if possible <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1007>
[22:30] <kyrofa> kgunn, curious to hear the answer myself
[22:43] <Croepha> zyga: So i got /usr/lib/snapd/snap-confine to run for me, and the symlink is definitely broken in the confined environnment
[22:44] <Croepha> so /mnt/ is empty in the confined environment
[22:47] <Croepha> zyga: So bind mounting /mnt/2 under my home directory and running it there fixed my issue
[22:48] <Croepha> fyi
[22:58] <Croepha> I still have no clue as to why it worked before but not now
[23:23] <mup> PR snapcraft#1026 closed: Add support for hooks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1026>
[23:26] <mwhudson> kyrofa: if kgunn comes back the answer is really $(snap managed)
[23:27] <kyrofa> mwhudson, ah, good to know. But that can't be run from within a snap-- do you know if that command has been added to snapctl?
[23:27] <mwhudson> ah good point
[23:27] <mwhudson> i do not know, and suspect not
[23:27] <kyrofa> I suspect the same
[23:27]  * mwhudson points at niemeyer
[23:28]  * niemeyer listens (and reads)
[23:29] <niemeyer> No, managed isn't yet available on snapctl, but seems sensible and trivial to add
[23:32] <kyrofa> niemeyer, though do you think it makes sense to not fire up snap services until console conf has completed?
[23:33] <niemeyer> @kyrofa: No, that'd render the device broken until managed
[23:33] <nothal> niemeyer: No such command!
[23:34] <kyrofa> niemeyer, though it doesn't even have network at that point, does it?
[23:35] <niemeyer> kyrofa: I don't need network to run my fridge, tv, projector, etc
[23:35] <kyrofa> Ah fair enough
[23:38] <mcphail> kyrofa: if the nextcloud snap was to upgrade to version 11, would an already-running server upgrade gracefully? Would it be necessary to stop and restart?
[23:39] <kyrofa> mcphail, an already running server meaning a current nextcloud snap install?
[23:39] <mcphail> kyrofa: yes
[23:39] <kyrofa> mcphail, yeah, when the upgrade it pulled down it'll stop the server momentarily
[23:40] <kyrofa> mcphail, snapd does it as part of the upgrade process. Stop old services, mount new snap, start new services
[23:40] <mcphail> kyrofa: very cool. Thanks!
[23:40] <kyrofa> mcphail, no problem. Since you asked, FYI v11 should be released as soon as I fix this https bug
[23:41] <mcphail> kyrofa: no rush. Just trying the snap on a vps to see if it is a viable alternative to a manual install. Sounds as if you have cracked it :)
[23:42] <mcphail> Your hard work is much appreciated
[23:42] <kyrofa> mcphail, it's not perfect! But we're getting there. And thank you!
[23:44] <mcphail> Just one more question - does the snap make the Let's Encrypt certs automatically renew?
[23:48] <kyrofa> mcphail, yes
[23:48] <mcphail> kyrofa: perfect! Cheers
[23:55] <kyrofa> davidcalle, are you still around?
[23:56] <davidcalle> kyrofa: I am
[23:58] <kyrofa> davidcalle, I had to put out a fire, but if you've got a few minutes I'd love to show you around the scriptlet stuff