[00:02] kyrofa: not really, just came back online to finish a snapcraftio deployment. Would you have time tomorrow? [00:02] davidcalle, certainly, I'll ping you when I get in [00:02] kyrofa: sounds good! ty [00:08] PR snapcraft#920 closed: pluginhandler: ensure staged files are included in the prime step [00:33] hi! anyone knows why my snap package does not pass the click-review? It reports RUNTIME ERROR, although the package install fine with snap [00:37] alvarolb, you probably want jdstrand [00:38] thanks kyrofa. [00:39] He may be out today, you might try tomorrow [00:40] ok, will try tomorrow :) as I cannot upload my snap package with this error [00:49] kyrofa: I'll be back on Monday [00:49] kyrofa: console-conf AFAIK runs unconfined, as part of the OS snap. [00:50] cyphermox, no worries, we got it sorted, thank you! [00:50] aka. core snap. [00:53] I submitted a bug in the meanwhile: https://bugs.launchpad.net/snappy/+bug/1654451 [00:53] Bug #1654451: ubuntu store snap click-review error [00:54] Bug #1654451 opened: ubuntu store snap click-review error === tasdomas` is now known as tasdomas === slangase` is now known as slangasek === macnibblet is now known as mac_nibblet [01:14] PR snapcraft#1027 opened: tests: fix broken unit test in master === devil is now known as Guest89704 === mac_nibblet is now known as Guest41430 [02:02] PR snapcraft#1027 closed: tests: fix broken unit test in master [02:05] PR snapcraft#1004 closed: tests: add aliases integration test === chihchun is now known as chihchun_afk === madprops_ is now known as madprops [03:38] does anyone know how to change the default console output from ttyS0 to ttyUSB0 [03:39] snappy series 16 (core 16?) [03:39] kernel console output (I want to see the boot process) === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [04:30] PR snapcraft#1028 opened: [Highly experimental] Run the integration suite in parallel === JanC_ is now known as JanC [05:27] PR snapcraft#1029 opened: rust plugin: add conditional compilation [05:30] PR snapcraft#952 closed: rust plugin: add features for conditional compilation === JanC is now known as Guest22782 === JanC_ is now known as JanC [06:17] grapestomper, you may refer to the picture http://img.blog.csdn.net/20160912142114476?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center [06:18] grapestomper, open the file and change it there dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline === Guest89704 is now known as devil_ [07:40] PR snapd#2566 closed: tests: disable some ppc64el on yakkety and zesty too === mup_ is now known as mup [08:31] PR snapd#2128 closed: many: finalize trusty support === ahasenack is now known as Guest99073 === ahayzen_ is now known as Guest32468 [09:08] Issue snapd#2568 opened: snapd needs a SELinux profile to run on Fedora [09:11] Issue snapd#2569 opened: snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN [09:15] PR snapd#2548 closed: snap: show `snap --help` output when just running `snap` [09:23] Issue # closed: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#2569 [09:23] PR # closed: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2562, snapd#2563, snapd#2564, snapd#2567 [09:54] Issue # opened: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#2569 [09:54] PR # opened: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2563, snapd#2564, snapd#2567 [09:55] PR snapd#2570 opened: snap: add support: line in `snap info === DanChapman_ is now known as DanChapman [10:18] PR snapcraft#1030 opened: tests: fix broken delta upload unit test [10:27] PR snapd#2571 opened: tests: generate higher local version than any "ubuntuN" version from the archive === jamespag` is now known as jamespage === mup_ is now known as mup === Mikaela[m] is now known as Ciblia === Guest99073 is now known as ahasenack === ahasenack is now known as Guest76687 === perrito667 is now known as perrito666 [11:34] morphis, yo ... trying your pulse snap on pi3 ... [11:34] Jan 6 11:33:42 pi3 kernel: [100001.213596] audit: type=1326 audit(1483702422.800:99): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=3658 comm="pulseaudio" exe="/snap/pulseaudio/12/usr/bin/pulseaudio" sig=31 arch=40000028 syscall=206 compat=0 ip=0x76df5456 code=0x0 [11:34] Jan 6 11:33:42 pi3 snap[3647]: Bad system call [11:35] looks like some seccomp love is needed there [11:43] morphis, 206 is setgroups32, that doesnt exist on 64bit arches, that might be the reason why it works on amd64 but not on armhf (and likely also not on i386) [11:47] * ogra_ tries --devmode [11:47] ogra_: hm, koza told me that it works and this thing is fixed, which core snap revision are you using? [11:48] not sure if it requires the latest from candidate and already works with the one from stable [11:48] ogra@pi3:~$ sudo pulseaudio.parec foo.wav [11:48] ^C [11:48] ogra@pi3:~$ ls -l foo.wav [11:48] -rw-r--r-- 1 root root 520856 Jan 6 11:48 foo.wav [11:48] ogra@pi3:~$ [11:48] works with --devmode [11:48] (no idea what it recorded there, i have no mic :P ) [11:49] my pi doesnt find one in stable btw ... [11:49] i'm using edge [11:50] * ogra_ checks --candidate [11:51] also needs --devmode to start [11:51] Is there a plan to allow daemons to run as non-root in snaps, or allow snaps to create users? [11:52] yes... but i dont know how far out that is [11:52] is there a work item / card / bug? [11:52] definitely on the long term, list of the security team [11:52] It's a blocker for an ISV with a postgresql database as a part [11:52] you gotta ask jdstrand [11:53] ok === chihchun is now known as chihchun_afk [12:09] popey it was recently (these past few days) discussed on the mailing list under "Process privileges and owners in snaps" [12:18] sergiusens: thanks === Guest76687 is now known as ahasenack [12:57] jdstrand: I'm getting some odd behaviour with anonymous sockets under snappy, I've currently got a simple app armor rule of: unix (bind, send, receive) addr="@/tmp/maliit-server/dbus-*" but when maliit attempts to create a QtDbus server using that socket it gets stuck in a pthread_wait (which doesn't happen if its in devmode); any ideas what my be causing that before I dive into qtdbus's internals to see what's happening? [13:03] Issue snapd#2572 opened: .fstab files generated by snapd for the content interface do not follow the snap. scheme [13:10] Hey! I'm having what now seems to be an issue with automatic releasing of my snap on the edge channel. I have an lp builder publishing to the store but i'm having to manually release each revision after the store review using `snapcraft release`. [13:11] Is this a known issue or some setting i might have accidently changed in myapps.d.u.c [13:11] DanChapman, what's the name of your snap? [13:11] (hi!) [13:11] nessita, hey! it's dekko [13:12] DanChapman, let me dig a little [13:12] thanks! [13:13] cjwatson, hi there, would you help me confirm if the issue Dan explained above is on LP or the store end? will LP builder try to release the revno? if they fail is there a log? [13:14] DanChapman, note that there is usually a delay between it passing the tests and the auto-publisher ... like ... 20-30 min [13:15] could it be that you just hit that ? [13:15] ogra_, good point, thanks for pointing that out [13:21] ogra_: oh it could be that! I didn't know there was a delay. [13:22] nessita: i'll test again just to be sure. get back to you shortly :-) [13:25] will check logs after this call [13:29] DanChapman, thanks! [13:29] nessita,DanChapman: LP is consistently getting a 200 response from /dev/api/snap-release/ according to our logs, so not our problem :-) [13:29] [2017-01-03 12:04:13,678: DEBUG/Worker-3] "POST /dev/api/snap-release/ HTTP/1.1" 200 None [13:29] e.g. [13:30] cjwatson, thanks for checking! [13:30] PR snapcraft#990 closed: tests: fix snaps tests in armhf [13:31] (waiting for it to get round to the most recent build so that I can give you a more recent timestamp to use for SCA log checking) [13:34] [2017-01-06 13:34:15,294: DEBUG/Worker-3] "POST /dev/api/snap-release/ HTTP/1.1" 200 None [13:34] DanChapman: has the most recent ppc64el build in https://launchpad.net/~dpniel/+snap/dekko-edge been released? [13:35] the log entry above is LP asking the store to do so [13:37] cjwatson: yes that has been released fine. [13:37] nessita: seems to be ok. I must not have left it long enough last time. [13:37] nessita: cjwatson: thanks for your help and sorry for the noise :-) [13:37] DanChapman, thanks for confirmin [13:37] g [13:37] :) [13:39] Elleo: addr="@/tmp/maliit-server/dbus-*" is part of a rule for an abstract socket, but you said you are having trouble with anonymous sockets. can you clarify? [13:41] np [13:42] jdstrand: sorry, I meant abstract not anonymous [13:43] popey: there are open bugs for that. also (cc ogra, ratliff and JamieBennett), the security team is currently not tasked with implementing opt-in users though I have ideas on the design that I've discussed with people. what I plan to do very soon (if it doesn't get bumped again, next week) to allow daemons to drop to 'daemon' [13:45] popey (cc ogra, ratliff and JamieBennett): that would allow things like postgresql to drop to a non-root user that already exists (specifically, 'daemon') [13:45] Elleo: can you disable kernel rate limiting with: sudo sysctl -w kernel.printk_ratelimit=0 [13:45] jdstrand, sounds good, a long requested feature so will be nice to see some solution [13:46] Elleo: then do 'tail -f /var/log/syslog|grep DEN' and see if there are any denials when trying to use maliit? [13:47] jdstrand: no denials [13:48] jdstrand: without that apparmor rule it was previously getting denials when trying to create the socket, so that's obviously having an effect at least [13:49] popey (cc ogra_, ratliff and JamieBennett): see https://lists.ubuntu.com/archives/snapcraft/2017-January/002286.html for my thoughts on how opt-in users could be implemented [13:51] Elleo: if there are no denials it shouldn't be apparmor. what is likely happening is that there are multiple problems. the first was the socket creation, then you allow that and moved to the next problem [13:51] jdstrand: it works if the snap is installed with devmode though, so presumably it's something confinement related [13:52] Elleo: sure, but not necessarily apparmor. before diving into qtdbus internals, you might strace it [13:53] PR snapd#2571 closed: tests: generate higher local version than any "ubuntuN" version from the archive [13:53] Elleo: and to be super sure-- you are observing /var/log/syslog, not kern.log, not dmesg and not using a tool like snappy-debug and still not seeing denials? [13:56] Elleo: the other parts of confinement are seccomp (do you see any seccomp denials in syslog? look for 'type=1326' or use snappy-debug), device cgroups (not used by most interfaces, but what interfaces are you plugging?) or mount namespace [13:56] jdstrand: yep, and if I grep for ALLOWED there's a line for the binding: http://pastebin.ubuntu.com/23752229/ [13:56] jdstrand: although, what's the "denied_mask" property? [13:58] Elleo: the mount namespace shouldn't affect an abstract socket, but depending on your testing, it could affect something file related if you are trying to access something in the snap from outside the snap and inside the snap gets confused [13:58] * jdstrand doubts that is the case) [13:58] Elleo: denied_mask is the part of requested_mask that got denied [13:59] Elleo: all my questions regarding denials are for when running in strict mode. ALLOWED shows you are in devmode [13:59] xnox, yo ! [13:59] jdstrand: ah right, that'd have been from when I double checked it worked okay in devmode then [13:59] jdstrand: aha, there are seccomp entries: http://pastebin.ubuntu.com/23752238/ [14:00] $ scmp_sys_resolver 50 [14:00] listen [14:01] use 'network-bind' [14:01] if you are writing an interface for maliit, then add 'listen' to you seccomp filter [14:01] jdstrand: ah okay, thanks :) [14:06] PR snapcraft#1031 opened: store: fix sso_host for dev sso [14:09] jdstrand: that's fixed it, thanks very much! [14:10] Elleo: great! :) [14:22] mvo: hi! if you are going to plan a new upload for trusty snapd, you might adjust the Build-Depends from 'libseccomp-dev (>= 2.1.1-1ubuntu1~trusty1)' to 'libseccomp-dev (>= 2.1.1-1ubuntu1~trusty3)'. 'trusty3' is the one that fixed amd64. certainly don't respin just for that though [14:29] jdstrand, hmm, looking at /var/lib/snapd/seccomp/profiles/snap.pulseaudio.pulseaudio i see setgroups and setgroups32 commented out at the top but then setgroups at the bottom uncommented ... why the duplication ? [14:31] jdstrand: thank you [14:32] ogra_: the top comes from the default template. the bottom from a slot snippet [14:32] ah, k, thanks [14:32] ogra_: the top is a reminder that we don't (yet) support privilege dropping [14:33] ogra_, que? [14:33] xnox, on your quest to look at swapfiles, did you happen to look at the "swapspace" package ? [14:34] (dynamically creates swap files on demand and deletes them afterwards) [14:34] jdstrand, heh, so adding setgroups32 just leads me to the next blocker ... "send" (289 on armhf) [14:36] hmm, i see pulse connected to the network interface, but not to network-bind [14:36] jdstrand: updated [14:36] mvo: thanks! [14:37] Bug #1654451 changed: ubuntu store snap click-review error [14:38] ogra_, yes and we don't what that. [14:38] ogra_, yes and we don't want that. [14:38] xnox, whats the reason ? [14:38] (we're considering such a feature for snappy images, thats why i ask) [14:39] (when system is under memory preassure you don't want to randomly start eating into disk space, and consuming memory to allocate swap. We only need swap as a contingency and want it allocated up front. Also things like btrfs rebalance east a lot of memory and you can't really create swap whilst that is in progress) [14:40] using memory to create swap; when swap is actually needed; is the worst time to do it =) [14:40] so you will be going with a fixed snap file set up by the installer ? [14:40] ogra_, please don't do that. Ideally snap gadgets whould e.g. declare none or an appropriate sized swall swapfile /relevant/ for that device workload and that's it. [14:40] yes. [14:41] well ... we'Re often operating on devicers with very low ram but a lot of diskspace [14:41] on classic one can resize and/or remove it. on all-snaps systems i would not think that it needs to be amendable (outside e.g. gadget snap upgrading and changing the swapfile size) [14:42] ogra_, if it's flash storage rather than SSD storage you will kill the device with swap =) there is only so many write cycles on flash storage. [14:42] but we dont want swap to be used at all if avoidable to avoid any slowness indeed [14:42] yes, i know [14:42] in that light dynamic swap file creation will help a lot though [14:42] you have to use less memory - that's the best win, for size, performance, longivity. [14:42] no, it won't. [14:42] you only wear out flash if you write a lot to the same place [14:43] due to dynamic creation that cant happen [14:43] hahahahahahahaha [14:43] (compared to a fixed swapfile) [14:43] hahahahaha [14:43] it's the same. [14:43] or will happen less at least :) [14:43] because silly micro-controllers abstract filesystem and round-robin the physical locations to what filesystem and kernel sees, on cheap storage. [14:44] not the same ... if you need i.e. 1GB swap swapspace will create 100 swap files each 100MB ... [14:44] therefore with dynamic you get either the same wear as static, or possibly more wear =) [14:44] and dynamically delete them again if you dont need the space anymore [14:44] on average, it's the same wear. [14:44] it's best not to use swap to avoid pointless wear =) [14:44] so the filesystem usage will be different from having a permanent gigantic 1GB file [14:44] at all. [14:44] right, but we have user demand for it [14:45] so we need to provide *something* [14:45] and dynamic feels safe than permanent [14:45] how so again? the device blocks you see, are virtual to you, and you never know what physical block they correspond to. because cheap flash microcontrollers.... [14:45] *safer [14:45] PR snapcraft#1028 closed: [Highly experimental] Run the integration suite in parallel [14:45] it's fragile =) [14:45] true indeed ... but if the blocks are in use new blocks will be used [14:46] which can remap to the old physical block. [14:46] which is more likely if you have small fragmented files [14:46] it's really random walk on most of these controllers. [14:46] microcontroller has no visilibity to FS files. [14:46] and does not care about virtual blocks either. [14:46] inded [14:46] it really picks any =) [14:47] ok, so much for that theory :P [14:47] anyway, it will not permanently eat disk space ... thats still one advantage [14:47] so on reboot, your static swapfile may write to new physical locations =/ (that is quite scary....) [14:47] ogra_, does not work on btrfs or zfs..... [14:47] or lvm. [14:48] which we currenmtly dont care for on core images [14:48] the OS is currently hardcoded to ext4 [14:48] ... [14:48] indeed it will bite once we support other FSes [14:48] think this trough a little. [14:48] talk to ubuntu-image developers about this. [14:49] (which i'm not sure we'll do anytime soon) [14:49] we are shipping lvm cloud images soon. [14:49] snappy based ? [14:49] that will require a ton of changes in the OS [14:49] everything everywhere currently expects ext4 [14:50] i thought ext2 was the end-game for filesystems too at one point =) [14:50] and that armhf will rule them all [14:50] etc. [14:50] well, its a legacy we carry from system-image setups [14:50] things will change, because things do change =) [14:50] it can surely be changed to other filesystems but will need a lot of changes [14:51] code changes i mean [14:53] so if anyone wants these cloud images any time soon, they should better look at the boot pürocess or talk to someone who knows about it :) [14:54] jdstrand, so adding send additionally to setgroups32 makes it work ... i'll file a bug for you ... funnily the send syscall is enabled in all the pulse oprofiles, just not for the daemon itself :) [14:55] thanks jdstrand for reviewing the bug in click-reviewer-tools [14:56] does anyone know how the change the default kernel output from ttyS0 to tty??? (ex. ttyUSB0)? [14:58] grapestomper_1, edit the console= arg of your bootloader [14:58] I used to do this in grub.d but that is not there. what file is it now [14:58] somewhere in /boot/grub/ [14:59] iirc [14:59] * ogra_ rarely touches x86 images [14:59] I looked at there but all the files are read-only [14:59] hmm, i thought the grub.cfg is rw [15:00] I see a 50-system-image.cfg that is rw [15:01] I take that back [15:01] no, there needs to be a grub.cfg [15:01] -rw-r--r-- 1 root root [15:02] agreed :) but I dont see one [15:02] well, the other option is to roll your own gadget snap with changed cmdline [15:02] to do that you clone https://github.com/snapcore/pc-amd64-gadget [15:03] and then edit prebuilt/grub.cfg (commandline is at the bottom there) and call snapcraft in the toplevel dir of the branch [15:03] ok, thanks - I will look into that [15:06] the new dbus slot mechanism in snapd 2.20 works. I've tried uploading corebird-diddledan to the store using the working config but the store has complained that "not allowed by 'deny-connection/slot-attributes' in base declaration declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus)" [15:10] Bug #1654585 opened: seccomp profile of pulseaudio snap misses syscalls on armhf [15:17] niemeyer: hey there, kyrofa thot you might be the right guy to ping [15:17] we're creating a mir-kiosk image [15:17] but trouble is mir-kiosk launches before i can run console-conf [15:18] is there a way i could check in my launcher file to not launch in the case where console-conf hasn't run? [15:23] kgunn, console-conf writes /var/lib/console-conf/completed when it was run successfully [15:23] but i have no idea how you would be able to see this from a snap [15:24] (might need some special interface) [15:28] ogra_: it would seem like this might be something that other people would want to know as snap image creation proliferates in the world [15:34] ogra_: mvo told me to poke you about https://bugs.launchpad.net/snappy/+bug/1654588 [15:34] Bug #1654588: Make /etc/systemd/logind.conf.d writable [15:35] Bug #1654588 opened: Make /etc/systemd/logind.conf.d writable [15:35] claimed :) [15:39] morphis_, uploaded to the PPA ... will be in the next core [15:41] Bug #1654590 opened: docker interface should account for /run/shm/ in addition to /dev/shm [15:46] ogra_: you're my hero :-) [15:48] PR snapcraft#1032 opened: Use more secure temporary directory for parser runs [16:04] PR snapd#2573 opened: snap: add information about tracking channel (not just actual channel) [16:15] lool: hey, fyi, testing docker on trusty/i386 (note bug 1654590 which I'm going to fix): [16:15] Bug #1654590: docker interface should account for /run/shm/ in addition to /dev/shm [16:15] $ sudo docker run ubuntu:trusty uptime [16:15] docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: exec format error". [16:16] lool: oh, nm, I'm dumb [16:16] I think I pulled a 64 bit image [16:16] eh [16:19] lool: do you know how to pull a 32 bit image? sudo docker pull ??? [16:20] jdstrand: they only introduced multiarch images recently; the armhf image is named differently: arm/ubuntu instead of ubuntu [16:20] jdstrand: docker run 32bit/ubuntu [16:21] can someone advise on https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1649620? where to put stuff in "pull()" so that its not deleted and can be used during "build()" -- best without creating extra copies? [16:21] Bug #1649620: stuff downloaded during "pull()" is deleted before "build()" [16:21] jdstrand: TBH 32-bits images might not be maintained anymore [16:21] lool: that is what I tried: [16:21] $ sudo docker pull 32bit/ubuntu [16:21] Using default tag: latest [16:21] Pulling repository docker.io/32bit/ubuntu [16:21] Tag latest not found in repository docker.io/32bit/ubuntu [16:23] I think I'll just focus on amd64 for docker for my testing [16:24] jdstrand: Yes, i386 is not officially supported upstream and they dont really support biarch either [16:24] they need docker support libraries for the 64 bits docker binary inside the 32bits container [16:24] ah [16:24] amd64 is a better base [16:24] or armhf [16:24] or even arm64 [16:24] wonder if the i386 snap makes sense then [16:28] Sweet5hark, what is it that you refer as 'pull()' and 'build()'? snapcraft isn't deleting anything if you don't use 'clean' afaiik [16:30] Sweet5hark, you said it's only doing that on launchpad and not on local builds? [16:34] Sweet5hark, oh, I see, you override things with a plugin ... your build() is calling "make clean", you are sure that's not what clean things for you? [16:46] kgunn: Heya [16:46] hey o/ [16:46] kgunn: What's the actual outcome from console-conf that mir-kiosk depends on? [16:47] niemeyer: so from my usage perspective, i dl and flash a mir-kiosk image onto dragonboard....boots, but i can't set up wifi via console conf b/c mir-kiosk steals the screen [16:48] kgunn: Hmm [16:49] seb128: nope. the make clean should never delete the source. FWIW, I put the call to "./autogen.sh" _before_ the make clean just to be sure and it fails to find ./autogen.sh. so between "pull()" and "build()" something clears the parts dir ... [16:49] niemeyer: i was thinkin', i could just add access to the /var/lib/console-conf/completed [16:49] to the mir interface [16:50] to prevent launching in the instance it's not there... [16:50] thots? [16:50] Sweet5hark, but only on launchpad? [16:50] kgunn: The idea of snapctl managed felt nice [16:50] PR snapd#2565 closed: store: setting of fields for details endpoint [16:51] kgunn: But both of these feel slightly awkward from the perspective that console-conf is going away for good.. it also feels slightly magic [16:51] Finish console-conf and BAM, you're off into something else altogether [16:52] kgunn: If we're exposing console-conf as an actual UI, why isn't the enablement of the kiosk an explicit action? [16:52] mir-kiosk.takeover [16:53] kgunn: That'd feel a lot less like a behind-my-back action, if you see what I mean [16:55] niemeyer: yeah, i see what you mean [16:55] seb128: nope, locally too. [16:56] Sweet5hark, sorry, just saw your new comment ... so yeah, snapcraft issue [16:56] sergiusens or kyrofa might have some clue what could be going on there [16:56] seb128: locally, I can work around that by just doing everything in build(). But that doesnt work on lp, as in "build()" you cannot use the network there. [16:57] niemeyer: to make sure i understand what you mean tho, are you saying that mir-kiosk.takeover would be somehow built into the tail end of console-conf? [16:57] AlbertA: fyi ^ [16:58] Sweet5hark, you can use the network in build now [16:58] kgunn: No.. I mean you'd have an actual command that once called would make the kiosk takeover [16:58] niemeyer: k, just thinking it thru....like a real kiosk maker, how they'd install the device..and steps they'd go thru [16:59] Sweet5hark, see email https://lists.ubuntu.com/archives/snapcraft/2016-December/001978.html [17:00] elopio - (tz differences withstanding) I think i made some progress here - https://gist.github.com/9ce253608b1be84fafd27ed0e63afa32 i've got the bins placed and i'm looking into the plugins/slots i need to enable strict mode. [17:00] kgunn: A polished device experience would hopefully avoid console-conf altogether [17:01] i gave up on trying to fix their symlink issue and went for using their pressed bin delivery for now, so there's no hope of this ever building in launchpad [17:01] kgunn: So it really depends quite a bit on what we want to have [17:01] AlbertA: so with this idea ^ we just need to make it not be a daemon [17:02] seb128: ah, cool. will give that a try as a workaround. [17:18] niemeyer: kgunn: would "takeover" be similar to calling a config hook? [17:18] or would console-conf just call that command? [17:21] AlbertA: iiuc, it would be a separate thing from console-conf [17:22] and what would replace connsole-conf, some sort of provisioning tool on the host computer? [17:22] do we have any info on how to interface with systemd via installed snap? My google-fu is failing me [17:39] PR snapd#2561 closed: many: obtain installed snaps developer/publisher username through assertions