[01:36] PR snapcraft#1026 opened: Add support for hooks === chihchun is now known as chihchun_afk [03:41] Bug #1654130 opened: Adding a tag indicating manual connection is needed when displaying interfaces [03:42] 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] netplan === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:22] 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] 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] o/ [08:21] kyrofa: sergiusens: when is the next snapcraft release? [09:43] Bug #1637611 opened: snappy images should not ship /etc/profile.d/Z99-cloud-locale-test.sh

[09:44] PR snapd#2558 opened: snapstate: move refresh from a systemd timer to the inernal snapstate Ensure() [10:16] 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] ogra_: throw it out please, we have no equivalent for this currently [10:18] yeah, thought so === mardy_ is now known as mardy [10:42] hi, can anyone help me with this snapcraft error? https://lists.ubuntu.com/archives/snapcraft/2016-December/002186.html [11:45] PR snapd#2395 closed: make state and squashes immutable when appropriate === rumble is now known as grumble === chihchun is now known as chihchun_afk [13:00] Issue snapd#2559 opened: seccomp tests fail on Ubuntu 16.04 in when running in qemu or linode === hikiko_ is now known as hikiko|ln [13:20] jdstrand: hey [13:20] jdstrand: any chance you could have a look at ^^ [13:20] jdstrand: just as a sanity check, to answer one question [13:21] jdstrand: specifically if this part looks fishy: [13:21] DEBUG: Input line: mmap2 [13:21] DEBUG: seccomp rule: ALLOW sycall -10029 [13:21] when loading the profile, we seemingly parse "mmap2" to syscall number -10029 (int) === chihchun_afk is now known as chihchun [13:38] 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] jdstrand: the mup thing is buggy, use "issues" not "issue" (missing "s") [13:39] https://github.com/snapcore/snapd/issues/2559 [13:40] zyga: perhaps the application is a statically compiled application that uses mmap2? perhaps the application is using a library that uses mmap2? [13:41] jdstrand: we run /bin/true [13:41] jdstrand: that's the old test [13:41] zyga: nothing in your paste indicates the profile is malformed [13:41] jdstrand: right [13:41] jdstrand: anyway, if you can and are interested in this puzzle, read the bug report [13:41] jdstrand: it has all the facts [13:41] zyga: does it have the kernel version? [13:42] jdstrand: kernel is the same as on my machine where the same test works [13:42] jdstrand: the failure occurs in qemu [13:42] jdstrand: running xenial adt cloud image [13:43] jdstrand: for context, I'm trying to re-enable those tests: https://github.com/snapcore/snapd/pull/2433 [13:43] PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task [13:56] 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] jdstrand: thank you === iahmad_ is now known as iahmad [14:22] 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] Bug #1645605 changed: No alsa module on ubuntu core image === hikiko|ln is now known as hikiko [14:56] sergiusens: hi! I completely morphed bug 1652290, now it's a bit more interesting [14:56] Bug #1652290: Error with remote part depending on another remote part [14:56] sergiusens: I can work on that, if you like (and maybe have some hint for me) [15:08] PR snapd#2560 opened: snap: fix missing sizes in `snap info ` [15:28] mardy sure, work with josepht who maintains that or Trevinho who started playing with it [15:29] sergiusens: thanks! [15:30] josepht, Trevinho: do you have some last words to say, before I start banging my head into that? :-) (bug 1652290) [15:30] Bug #1652290: Error with remote part depending on another remote part [15:40] popey I CCed you on an email that led me to the anatine yaml [15:41] sergiusens: thanks [15:44] mardy: Go for it. I'm happy to help. [15:47] PR snapd#2561 opened: many: obtain installed snaps developer/publisher username through assertions [15:56] davidcalle, new version should be in proposed this week [15:56] davidcalle, then some testing to do... probably in updates middle of next week [16:06] jdstrand: is there a workaround for this http://paste.ubuntu.com/23746854/ - (apps wanting to mknod in /dev/shm/foo) ? [16:07] use /dev/shm/$SNAP/foo ? [16:07] (iirc thats what the security check tool tells you) [16:10] I used the word "workaround" to mean, "not have to patch upstream" [16:10] kyrofa: thanks! [16:10] :) [16:10] * ogra_ doubts there is one [16:11] It's a python app. [16:14] popey: no workaround. what ogra_ said is the current situation. this is bug #1577514 [16:14] Bug #1577514: Support preloading to make snaps feel at home [16:17] :( [16:21] 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] popey snapcraft update; snapcraft define preload [16:31] jdstrand ^ [16:35] ooh [16:40] sergiusens: oh, neat! is that documented somewhere? I don't see a mention of that in the bug [16:41] jdstrand yeah, I removed snapcraft from the problem [16:42] jdstrand popey but it did solve most of someone's problem's on rocket/snapcraft [16:56] sergiusens: so basically after: [preload] and then what? Add a preload or something to the launcher? [16:57] popey yeah `commmand: preload ` [16:57] winner, thanks. will give that a try [16:57] that could fix a few broken snaps I've had in the past. [16:57] popey yeah `commmand: preload desktop-launch ` [16:57] I may have to buy you beer [16:58] no need, took me long enough to promote this as much ;-) [16:58] also, no need for the `after` at all, these can be independent [16:58] eh? [16:58] but you might need it now that I think of it as you won't be overriding anything [16:58] how do I tell snapcraft to use it though? [16:59] s/use/include/ [16:59] sergiusens, yeah, if you leave the plugin out you need _something_ else [16:59] sergiusens, probably a schema bug [17:00] popey this is the only way by design unless you do the override dance [17:00] popey http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/ [17:01] PR snapd#2562 opened: cmd/snap-confine: check for rst2man on configure [17:02] PR snapd#2563 opened: cmd/snap-confine: small tweaks to seccomp support code [17:02] PR snapd#2564 opened: cmd/snap-confine: build non-installed libsnap-confine-private.a [17:05] PR snapd#2565 opened: store: setting of fields for details endpoint [17:14] PR snapd#2566 opened: tests: disable some ppc64el on yakkety and zesty too [17:17] jdstrand: good call! [17:18] jdstrand: snap-confine itself needs more syscalls to finish working [17:18] jdstrand: presumably due to debug writes etc [17:18] jdstrand: I trully wonder why this didn't fail on my box though, I'll keep digging [17:39] sergiusens: :( preload didn't work. still wants to write to /dev/shm/foo [17:51] 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] azubieta, Chipaca is probably your guy [17:53] azubieta, attente might also be able to help (or point you in the right direction) from our software center point of view [17:53] azubieta: hey [17:53] hello [17:53] azubieta: we had an event api but it was removed as it was not finished [17:53] azubieta: what do you need exactly? [17:54] zyga: monitor the install, remove, update tasks [17:55] azubieta, I'm your guy, but I'm in a meeting and then I'm out of here [17:55] azubieta: you might also want to look at https://launchpad.net/snapd-glib that robert_ancell maintains [17:55] azubieta, john.lenton@canonical.com (or tomorrow, same place, a little earlier) [17:55] azubieta: you can do what snap CLI does [17:55] azubieta: issue the operation [17:55] azubieta: this gives you change ID [17:55] azubieta: then query snapd about that change [17:55] Chipaca: thanks! [17:56] zyga: I saw the change id but I was unable to find the path where should I make the query [17:57] azubieta: look at snap changes [17:57] 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] azubieta: it's not documented on the wiki [17:58] azubieta: but look at /v2/changes/{id} [17:58] azubieta: or at /v2/changes/ [17:58] azubieta: you can control changes as well (abort) [17:58] zyga: thanks! [17:58] zyga: that´s what I was loking for [18:00] Chipaca: right now i´m making the http requests by hand and sending then throud the /run/snapd.socket [18:02] azubieta, yeah, http is just convenient (it does the same) [18:02] it's httpie + unix socket support + magic for snapd:/// urls [18:03] Chipaca: sounds good, does it has a c/c++ api ? [18:03] by the way, is there any other software center for snaps ? [18:05] azubieta: gnome-software [18:06] azubieta, there's glib-snapd i think? [18:06] libsnapd-glib-dev etc [18:06] PR snapd#2567 opened: debian: skip snap-confine unit tests on nocheck [18:07] Chipaca: would you recomend using snapd-glib instead talking directly to the REST API ? === Skuggen_ is now known as Skuggen [18:08] 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] azubieta, me personally i like poking at the rest api directly [18:09] :-D [18:09] Chipaca: jeje, i´ll take your advice [18:10] azubieta, either way, do shout if you find things that don't work as you'd expect [18:11] 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] Chipaca: i will [18:12] Chipaca: thanks again [18:12] azubieta, the snapd-glib author is in NZ timezone afaik [18:12] anyway, i've got to run [18:18] ogra_, confirmed [18:18] I just created an image from edge and config.txt is updated === jkridner|pd is now known as jkridner [18:39] vigo, i would be shocked if it wasnt :) [18:56] elopio, elmo and me [19:07] http://pastebin.ubuntu.com/23747897/ [19:07] is there something wrong with this control interface? [19:12] Bug #1636931 changed: Configure hook not running [19:18] Bug #1654362 opened: updating pi3 snap does not update config file [19:21] 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] Bug #1587448 changed: Can't reboot device from snap [19:34] Bug #1590679 changed: Apps can't own session bus names (unity7 interface)

[19:34] Bug #1612871 changed: Permission denied to exec /bin/stty [19:37] Bug # changed: 1613686, 1614269, 1615124, 1615262 [19:40] Bug # changed: 1620442, 1624533, 1624675, 1627813, 1639988 [19:43] Bug #1644810 changed: snapd system-observe interface is missing rules to allow memory usage analysis [19:46] Bug #1596515 changed: IIO access and configuration from a snap

[19:46] Bug #1639967 changed: Add support to access to some Avahi methods from org.freedesktop.Avahi [19:46] Bug #1641869 changed: openvswitch-support interface [19:47] 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] that file totally exists [19:47] its a simlink to the prime dir [19:49] Bug #1598266 changed: Cannot read/write to usb device [libusb][hidapi] [19:55] Bug #1577897 changed: auto-connection should cover snaps other than OS snap [20:01] Bug #1591839 changed: Can't read/write to USB devices [20:04] Bug #1611819 changed: implement a way for daemons to play audio [20:06] davidcalle, it seems I lied: with the sprint next week, we're delaying release by one week [20:07] kyrofa: ok :) [20:07] davidcalle, were you looking for a specific feature, or just generally curious? [20:09] kyrofa: generally planning, although I could use being walked through scriptlets, I've only seen one example so far [20:10] 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] Bug #1645410 changed: interface required: openvswitch

[20:13] kyrofa: thanks [20:16] Bug #1613775 changed: cannot access /mnt/storage even through symlinks from $HOME

[20:25] Bug #1618004 changed: Need a classic-bin interface to see classic binaries [20:30] 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] Bug #1617314 changed: Services can only run as root [20:44] Croepha, you're `snap try`ing, I assume? [20:45] kyrofa: yes, try --devmode [20:45] Croepha, and does /var/lib/snapd/snaps/my-snap_x1.snap exist? It should be a symlink [20:45] yes, and it is [20:46] Croepha, pointing to a valid location? [20:46] (a prime directory) [20:47] jdstrand: quick question about old snap-confine unit tests, do I remember correctly that they were only going to pass on amd64? [20:47] jdstrand: I'm seeing a list of errors on i386 [20:47] jdstrand: (details are burried under links from https://github.com/snapcore/snapd/pull/2433) [20:47] PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task [20:48] kyrofa: yes: /var/lib/snapd/snaps/my-snap_x1.snap/*.wrapper returns several results [20:48] meant to say that I `ls`d that and got several results [20:49] 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] Croepha, any chance you have an encrypted home? [20:54] 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] zyga: they should work. I just tried them locally with snapd 2.20 on trusty [20:55] Croepha, ah indeed, that's probably the issue. zyga may know more [20:55] jdstrand: on i386? [20:55] yes [20:55] kyrofa my prime doesn't live in my home or in that hgfs [20:55] Croepha: hey [20:55] Croepha: try snap run --shell yournsap [20:55] Croepha: snaps do run in a different context [20:56] 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] Croepha: that will give you a (confined) shell in the same context as a given snap/app [20:56] jdstrand: it seems to work on my real box [20:56] jdstrand: but never works in spread (neither qemu nor linode) [20:56] jdstrand: gustavo suggested that it might be caused by those things running as root but I didn't investigate yet [20:56] zyga run --shell gives the same error [20:57] 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] PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task [20:57] Croepha: can you givem e more context? [20:57] 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] jdstrand: maybe spread is breaking something, I see 7 failures on i386 and (finally) 0 failures on amd64 [20:58] zyga: that path does exist and is valid, it is a symlink to a prime dir [20:58] Croepha: is that file around in "real space"? [20:59] Croepha: did you create that symlink? [21:00] jdstrand: can you tell me how are you running tests? [21:00] zyga: I'll talk to ratliff on how to prioritize the i386 test failures in https://github.com/snapcore/snapd/pull/2433 [21:00] PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task [21:00] zyga: I did debian/rules build [21:00] zyga: I would also do: make -C cmd check [21:01] zyga: I can't get to those tests today. still working on trusty/libseccomp [21:01] jdstrand: did you try spread? [21:01] jdstrand: that's ok [21:01] jdstrand: thanks! [21:01] zyga: no. you said unit tests. is it the unit tests or the spread tests? [21:01] jdstrand: spread runs them [21:02] jdstrand: we don't run unit tests when building the package in spread [21:02] jdstrand: so I wanted to run them as a task [21:02] 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] 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] jdstrand: all regular unit tests run but the older tests that exercise seccomp don't pass [21:02] Croepha: I see [21:02] * jdstrand is curious why you don't run the unit tests during the build in spread [21:03] Croepha: can you tell me where the source directory was located? [21:03] 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] er [21:03] jdstrand: ^ that was for you [21:04] jdstrand: I fixed a few issues but it's still broken, I need to make the debug output better [21:04] jdstrand: (that tail of kern log for instance) [21:05] jdstrand: in any case, you answered my earlier question, thanks [21:05] jdstrand: I'll keep digging [21:07] 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] 1326? [21:13] 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] 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] Croepha: does it work if you don't snap try but rather build a regular snap? [21:23] Croepha: that symlink is, I believe, what is causing the problem [21:27] zyga: a regular snap install works as expected [21:29] zyga: 1326 is the code for seccomp [21:29] 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] zyga: and I of course meant this: dmesg|grep 'type=1326'|tail -1 [21:31] eg: [21:31] $ dmesg|grep 'type=1326'|tail -1 [21:31] [ 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] does anyone know how to change the default console output from ttyS0 to ttyUSB0 [21:46] snappy series 16 (core 16?) [21:47] in 15.04 I could change the grub.d file - not an option now [21:48] grapestomper_1, do you really need a kernel console or will a login console work fine? [21:49] because you can add a tty service to run on that usb device if you want [21:49] hmmm dont know - I want to be able to watch the boot process. Is that kernel? [21:49] yeah, thats kernel [21:50] is kernel tty set at snap cration? [21:50] creation [21:50] 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] there might be an easier way, i don't know of it though, sorry [21:52] np - thanks [22:06] hey is there a clever way a snap can determine if the console config has been run? [22:06] 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] kyrofa: ^ know of anything? [22:09] kgunn, does it die if it runs before then? [22:09] kyrofa: no, mirkiosk happily runs...but takes over the screen [22:10] Ah of course, so console conf can't be run, how fun! [22:10] so we're thinking to add some logic in the launcher file to check if console has run or not [22:10] kgunn, hmm, you could do hacky things like see if you have an IP address, but there must be a better way [22:11] mwhudson, do you have any ideas? You're involved with that, no? [22:11] Oh darn, he's gone [22:12] 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] Taking a quick peek at the src [22:15] I bet if there is something though, it won't be accessible to snaps [22:18] kgunn, I kinda feel like no services should run until console-conf has run [22:20] kgunn, yeah, /var/lib/console-conf/complete [22:21] kgunn, nothing you can reach from a confined snap [22:22] kgunn, I suggest discussing it with niemeyer and mwhudson [22:22] 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] If i execute the click-review manually, I get a RUNTIME_ERROR, but no any other hint [22:24] the verbose show some checks that are all passed OK [22:24] anyone with the same issue? I am using snapcraft for building the package for amd64 [22:24] cyphermox, are you familiar with console-conf? [22:25] cyphermox, do you know if there's a way to tell if it's been run from within a confined snap? [22:28] kyrofa: thanks... yep, can bring up tomorrow [22:29]