mup | PR snapcraft#1026 opened: Add support for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1026> | 01:36 |
---|---|---|
=== chihchun is now known as chihchun_afk | ||
mup | Bug #1654130 opened: Adding a tag indicating manual connection is needed when displaying interfaces <Snappy:New> <https://launchpad.net/bugs/1654130> | 03:41 |
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:42 |
Croepha | netplan | 03:45 |
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
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:22 |
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. | 06:30 |
zyga | o/ | 08:21 |
davidcalle | kyrofa: sergiusens: when is the next snapcraft release? | 08:21 |
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:43 |
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> | 09:44 |
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:16 |
mvo | ogra_: throw it out please, we have no equivalent for this currently | 10:18 |
ogra_ | yeah, thought so | 10:18 |
=== mardy_ is now known as mardy | ||
mardy | hi, can anyone help me with this snapcraft error? https://lists.ubuntu.com/archives/snapcraft/2016-December/002186.html | 10:42 |
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> | 11:45 |
=== rumble is now known as grumble | ||
=== chihchun is now known as chihchun_afk | ||
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:00 |
=== hikiko_ is now known as hikiko|ln | ||
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:20 |
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:21 |
=== chihchun_afk is now known as chihchun | ||
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:38 |
zyga | jdstrand: the mup thing is buggy, use "issues" not "issue" (missing "s") | 13:39 |
zyga | https://github.com/snapcore/snapd/issues/2559 | 13:39 |
jdstrand | zyga: perhaps the application is a statically compiled application that uses mmap2? perhaps the application is using a library that uses mmap2? | 13:40 |
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:41 |
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:42 |
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:43 |
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:56 |
zyga | jdstrand: thank you | 13:58 |
=== iahmad_ is now known as iahmad | ||
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:22 |
mup | Bug #1645605 changed: No alsa module on ubuntu core image <snapd-interface> <Snappy:New for zyga> <https://launchpad.net/bugs/1645605> | 14:32 |
=== hikiko|ln is now known as hikiko | ||
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) | 14:56 |
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:08 |
sergiusens | mardy sure, work with josepht who maintains that or Trevinho who started playing with it | 15:28 |
mardy | sergiusens: thanks! | 15:29 |
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:30 |
sergiusens | popey I CCed you on an email that led me to the anatine yaml | 15:40 |
popey | sergiusens: thanks | 15:41 |
josepht | mardy: Go for it. I'm happy to help. | 15:44 |
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:47 |
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 | 15:56 |
popey | jdstrand: is there a workaround for this http://paste.ubuntu.com/23746854/ - (apps wanting to mknod in /dev/shm/foo) ? | 16:06 |
ogra_ | use /dev/shm/$SNAP/foo ? | 16:07 |
ogra_ | (iirc thats what the security check tool tells you) | 16:07 |
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:10 | |
popey | It's a python app. | 16:11 |
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:14 |
popey | :( | 16:17 |
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:21 |
sergiusens | popey snapcraft update; snapcraft define preload | 16:31 |
sergiusens | jdstrand ^ | 16:31 |
popey | ooh | 16:35 |
jdstrand | sergiusens: oh, neat! is that documented somewhere? I don't see a mention of that in the bug | 16:40 |
sergiusens | jdstrand yeah, I removed snapcraft from the problem | 16:41 |
sergiusens | jdstrand popey but it did solve most of someone's problem's on rocket/snapcraft | 16:42 |
popey | sergiusens: so basically after: [preload] and then what? Add a preload or something to the launcher? | 16:56 |
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:57 |
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:58 |
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 | 16:59 |
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:00 |
mup | PR snapd#2562 opened: cmd/snap-confine: check for rst2man on configure <Created by zyga> <https://github.com/snapcore/snapd/pull/2562> | 17:01 |
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:02 |
mup | PR snapd#2565 opened: store: setting of fields for details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/2565> | 17:05 |
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:14 |
zyga | jdstrand: good call! | 17:17 |
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:18 |
popey | sergiusens: :( preload didn't work. still wants to write to /dev/shm/foo | 17:39 |
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:51 |
kyrofa | azubieta, Chipaca is probably your guy | 17:52 |
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:53 |
azubieta | zyga: monitor the install, remove, update tasks | 17:54 |
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:55 |
azubieta | zyga: I saw the change id but I was unable to find the path where should I make the query | 17:56 |
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:57 |
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 | 17:58 |
azubieta | Chipaca: right now i´m making the http requests by hand and sending then throud the /run/snapd.socket | 18:00 |
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:02 |
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:03 |
zyga | azubieta: gnome-software | 18:05 |
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:06 |
azubieta | Chipaca: would you recomend using snapd-glib instead talking directly to the REST API ? | 18:07 |
=== Skuggen_ is now known as Skuggen | ||
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:08 |
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:09 |
Chipaca | azubieta, either way, do shout if you find things that don't work as you'd expect | 18:10 |
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:11 |
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:12 |
vigo | ogra_, confirmed | 18:18 |
vigo | I just created an image from edge and config.txt is updated | 18:18 |
=== jkridner|pd is now known as jkridner | ||
ogra_ | vigo, i would be shocked if it wasnt :) | 18:39 |
sabdfl | elopio, elmo and me | 18:56 |
matteo | http://pastebin.ubuntu.com/23747897/ | 19:07 |
matteo | is there something wrong with this control interface? | 19:07 |
mup | Bug #1636931 changed: Configure hook not running <Snappy:Fix Released> <https://launchpad.net/bugs/1636931> | 19:12 |
mup | Bug #1654362 opened: updating pi3 snap does not update config file <Snappy:New> <https://launchpad.net/bugs/1654362> | 19:18 |
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:21 |
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:34 |
mup | Bug # changed: 1613686, 1614269, 1615124, 1615262 | 19:37 |
mup | Bug # changed: 1620442, 1624533, 1624675, 1627813, 1639988 | 19:40 |
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:43 |
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:46 |
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:47 |
mup | Bug #1598266 changed: Cannot read/write to usb device [libusb][hidapi] <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1598266> | 19:49 |
mup | Bug #1577897 changed: auto-connection should cover snaps other than OS snap <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1577897> | 19:55 |
mup | Bug #1591839 changed: Can't read/write to USB devices <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1591839> | 20:01 |
mup | Bug #1611819 changed: implement a way for daemons to play audio <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1611819> | 20:04 |
kyrofa | davidcalle, it seems I lied: with the sprint next week, we're delaying release by one week | 20:06 |
davidcalle | kyrofa: ok :) | 20:07 |
kyrofa | davidcalle, were you looking for a specific feature, or just generally curious? | 20:07 |
davidcalle | kyrofa: generally planning, although I could use being walked through scriptlets, I've only seen one example so far | 20:09 |
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:10 |
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:13 |
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:16 |
mup | Bug #1618004 changed: Need a classic-bin interface to see classic binaries <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1618004> | 20:25 |
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:30 |
mup | Bug #1617314 changed: Services can only run as root <snapd-interface> <Snapcraft:Invalid> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1617314> | 20:31 |
kyrofa | Croepha, you're `snap try`ing, I assume? | 20:44 |
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:45 |
kyrofa | Croepha, pointing to a valid location? | 20:46 |
kyrofa | (a prime directory) | 20:46 |
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:47 |
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:48 |
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:49 |
kyrofa | Croepha, any chance you have an encrypted home? | 20:50 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
zyga | Croepha: did you create that symlink? | 20:59 |
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:00 |
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:01 |
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:02 | |
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:03 |
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:04 |
zyga | jdstrand: in any case, you answered my earlier question, thanks | 21:05 |
zyga | jdstrand: I'll keep digging | 21:05 |
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:07 |
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:13 |
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:20 |
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:23 |
Croepha | zyga: a regular snap install works as expected | 21:27 |
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:29 |
jdstrand | zyga: and I of course meant this: dmesg|grep 'type=1326'|tail -1 | 21:30 |
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:31 |
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:46 |
grapestomper_1 | in 15.04 I could change the grub.d file - not an option now | 21:47 |
Croepha | grapestomper_1, do you really need a kernel console or will a login console work fine? | 21:48 |
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:49 |
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:50 |
Croepha | there might be an easier way, i don't know of it though, sorry | 21:52 |
grapestomper_1 | np - thanks | 21:52 |
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:06 |
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:09 |
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:10 |
kyrofa | mwhudson, do you have any ideas? You're involved with that, no? | 22:11 |
kyrofa | Oh darn, he's gone | 22:11 |
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:12 |
kyrofa | Taking a quick peek at the src | 22:14 |
kyrofa | I bet if there is something though, it won't be accessible to snaps | 22:15 |
kyrofa | kgunn, I kinda feel like no services should run until console-conf has run | 22:18 |
kyrofa | kgunn, yeah, /var/lib/console-conf/complete | 22:20 |
kyrofa | kgunn, nothing you can reach from a confined snap | 22:21 |
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:22 |
alvarolb | If i execute the click-review manually, I get a RUNTIME_ERROR, but no any other hint | 22:23 |
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:24 |
kyrofa | cyphermox, do you know if there's a way to tell if it's been run from within a confined snap? | 22:25 |
kgunn | kyrofa: thanks... yep, can bring up tomorrow | 22:28 |
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:29 |
kyrofa | kgunn, curious to hear the answer myself | 22:30 |
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:43 |
Croepha | so /mnt/ is empty in the confined environment | 22:44 |
Croepha | zyga: So bind mounting /mnt/2 under my home directory and running it there fixed my issue | 22:47 |
Croepha | fyi | 22:48 |
Croepha | I still have no clue as to why it worked before but not now | 22:58 |
mup | PR snapcraft#1026 closed: Add support for hooks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1026> | 23:23 |
mwhudson | kyrofa: if kgunn comes back the answer is really $(snap managed) | 23:26 |
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:27 | |
* niemeyer listens (and reads) | 23:28 | |
niemeyer | No, managed isn't yet available on snapctl, but seems sensible and trivial to add | 23:29 |
kyrofa | niemeyer, though do you think it makes sense to not fire up snap services until console conf has completed? | 23:32 |
niemeyer | @kyrofa: No, that'd render the device broken until managed | 23:33 |
nothal | niemeyer: No such command! | 23:33 |
kyrofa | niemeyer, though it doesn't even have network at that point, does it? | 23:34 |
niemeyer | kyrofa: I don't need network to run my fridge, tv, projector, etc | 23:35 |
kyrofa | Ah fair enough | 23:35 |
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:38 |
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:39 |
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:40 |
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:41 |
mcphail | Your hard work is much appreciated | 23:42 |
kyrofa | mcphail, it's not perfect! But we're getting there. And thank you! | 23:42 |
mcphail | Just one more question - does the snap make the Let's Encrypt certs automatically renew? | 23:44 |
kyrofa | mcphail, yes | 23:48 |
mcphail | kyrofa: perfect! Cheers | 23:48 |
kyrofa | davidcalle, are you still around? | 23:55 |
davidcalle | kyrofa: I am | 23:56 |
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 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!