[05:09] <sitter> jdstrand, mhall119: about KDE dbus usage... org.kde.$name-$pid is used when the application can have multiple instances running at the same time. they all claim their own address on the bus due to their pid, but you can still find them all due to the basename. applications where multiple instances make no sense do simply not use the pid extension. that being said we do generally know which of the two forms an application will use and we do generally
[05:09] <sitter> know the basename
[07:47] <dholbach> hey hey
[07:58] <mup> PR snapd#2366 closed: interfaces: apparmor support for classic confinement <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2366>
[08:00] <mup> Bug #1645605 opened: No alsa module on ubuntu core image <Snappy:New> <https://launchpad.net/bugs/1645605>
[08:03] <mup> PR snapd#2361 closed: snap: fix try command when daemon linie is added <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2361>
[08:09] <didrocks> renato__: hey! Did you open a bug for snap connect not working after the first run of a snap using the content interface? If not, do you mind opening one?
[08:09] <mup> Bug #1645606 opened: Default ubuntu core Pi2 configuration doesn't allow to use fullscreen browser <Snappy:New> <https://launchpad.net/bugs/1645606>
[08:30] <zyga> ogra_: hey, I was thinking about simplifying the various repos on https://code.launchpad.net/snappy-hub
[08:30] <zyga> ogra_: specifically I'd like to move the gadget snaps for reference platforms over to github.com/snapcore/
[08:31] <zyga> and to give them their proper projects on launchpad so that they can have bugs associated with them
[09:08] <ogra_> zyga, well, i'd like to start auto-builds for the gadgets before end of year ... i dont think we have that for github projects yet (ICBW though)
[09:09] <ogra_> i'd prefer to wait with the move til github is fully supported
[09:12] <zyga> ogra_: my idea is to mirror them to launchpad
[09:12] <zyga> ogra_: but use git in both places
[09:12] <zyga> ogra_: and to really make the reference code discoverable
[09:13] <zyga> ogra_: can you show me which of the 50 branches on snappy-hub contains the published pi2 and pi3 gadgets? I'd like to start with those
[09:13] <ogra_> dunno, do we have auto-buiollds for that in place (i.e. you can bump the version and out comes a snap )
[09:13] <ogra_> huh ? 50 branches ?
[09:13] <zyga> ogra_: github -> (git mirror) -> launchpad project -> (snapcraft.yaml auto build to edge) -> store
[09:13] <zyga> https://code.launchpad.net/snappy-hub
[09:14] <ogra_> doesnt open here
[09:15] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
[09:15] <zyga> odd, this works here: https://code.launchpad.net/snappy-hub
[09:15] <ogra_> thats the master branch we always used
[09:15] <zyga> ok
[09:15] <zyga> thanks, I'll use that
[09:15] <ogra_> i didnt even know that there was anything else under snappy-hub :P
[09:15] <zyga> how does it auto build
[09:16] <ogra_> but i had plabnned to re-work it comp,ltely to use archive packages for the bootloader binaries etc
[09:16] <ogra_> and for auto builds
[09:16] <ogra_> (we dont have that yet ... this move kind of trashes my plans then)
[09:16] <zyga> ogra_: hmm, why?
[09:16] <ogra_> why what ?
[09:16] <zyga> ogra_: (it's not a plan, I want to make the sources for gadgets discoverable)
[09:16] <zyga> why does it trash that plan?
[09:17] <zyga> I want people to be able to find them, report bugs against them and fork them for local tinkering
[09:17] <ogra_> well, it adds complexity, it doesnt "trash"them ... sorry :)
[09:17] <zyga> ah
[09:17] <zyga> I hope you just use git
[09:17] <zyga> and that's it
[09:17] <zyga> the rest should be automatic
[09:17] <zyga> ogra_: later on we should be able to build them with snapcraft as well
[09:17] <zyga> ogra_: right now I'll just add a readme file and we can work from there
[09:18] <zyga> ogra_: does that sound good to you? anything I'm missing"
[09:18] <ogra_> well, i'd like to sdo the snapcraft (and first of all the deb part) first
[09:18] <ogra_> we dont have sources for some of the uboot builds etc
[09:18] <ogra_> and foundations insists these should all be deb based in the archive
[09:19] <ogra_> i think it would make sense to have a meeting before we change the world
[09:19] <zyga> hmm
[09:20] <ogra_> i.e. we need all the binaries in these trees packaged and reviewed (which is partially their responsibiliry)
[09:20] <zyga> the archive part is interesting, I suspect we're going to use archives but everyone building their own won't care about that
[09:20] <ogra_> exactly
[09:20] <zyga> right now it's pretty hard to find our gadgets and even harder to make sense of this all and how to tweak e.g. the pi2 one
[09:20] <ogra_> apart from BBB these are all official bits that need a classic image equivalent
[09:20] <zyga> I think the git move is separate and should not wait on this
[09:20] <ogra_> which means they need to have debs for the bootloader
[09:21] <ogra_> so to not do the work twice we should start with the debs
[09:21] <zyga> I think I'm still missing something
[09:21] <zyga> If all I do is move the current branch to git and publish it on snapcore/*
[09:21] <ogra_> turning on auto-builds and have snapcraft builds is indeed a side job but moving away from LP adds a lot of complexity
[09:21] <zyga> then everyone working on this can continue to do what they do there
[09:21] <zyga> and it's easier to find
[09:22] <zyga> no
[09:22] <ogra_> i'd prefer to have everything ready and done and*then*Ü do the move)
[09:22] <zyga> remember: lp can mirror git!
[09:22] <zyga> we can do the move in 3 hours and then all git commits on github show up in launchpad (as git) and can be acted upon
[09:22] <ogra_> without any intervention now ?
[09:22] <zyga> yes, I think so
[09:22] <ogra_> last i chercked you needed to manually do that first every time
[09:23] <zyga> manually do the git mirrors?
[09:23] <zyga> I can check, give me a sec
[09:23] <ogra_> yes
[09:23] <zyga> ogra_: btw, I also feel this should be a repo-per-gadget
[09:24] <ogra_> we should have a reference repo for porters ... but i like to have all bits in one place for the official images
[09:24] <ogra_> though if you insist ...
[09:24] <zyga> ogra_: this means no snapcraft builds
[09:24] <zyga> ogra_: one repo per snapcraft.yaml I think
[09:24] <ogra_> (makes everything harder imho)
[09:24] <zyga> ogra_: and also, bbb is not officially supported so it'd have to be somewhere else
[09:25] <zyga> ogra_: I understand the transition is difficult but current situation is very bad for everyone trying to figure out how this works and fork something to expeirment
[09:25] <ogra_> well, irt is the only one that can use unpartitioned bootloader paertitions ... which makes it a good example
[09:26] <ogra_> but well, go ahead and rip it apart ... it will take me a lot longer to sort everything then though
[09:26] <zyga> ogra_: that's all fair, we need to just find a spot for all the (large) number of non-officially supported devices
[09:26] <zyga> ogra_: don't get me wrong, I don't want to make your life harder
[09:26] <zyga> ogra_: I hope we can all benefit from this
[09:26] <zyga> ogra_: please help me help everyone
[09:26] <ogra_> (kind of trashes my planning ... but it wasnt high on my TODO (i.e. notz before EOY) anyway)
[09:27] <abeato> mvo, hi, I re-pushed https://github.com/snapcore/snapd/pull/2252 to re-run the tests, most of them worked this time. The few that did not seem to be due to infrastructure: "cannot connect to linode:..." etc
[09:27] <mup> PR snapd#2252: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2252>
[09:27] <zyga> ogra_: can you still execute your plan the way you want when this is on git on github in snapcrore?
[09:27] <ogra_> sure, i just need more time to adapt to the new stuff first
[09:28] <zyga> ogra_: to git vs bzr or is there something else?
[09:28] <ogra_> to a completely new setup and all the possible (and unplanned) differences in that
[09:29] <zyga> ogra_: but all I want to do is to move the repository, is that what you mean?
[09:29] <ogra_> my plan was simply a different order and not to sit down and find out how/if auto-builds work, to re-arrange the world etc etc as the first step
[09:29] <ogra_> i.e. make things work first and *then* do the chasnges
[09:30] <zyga> ogra_: I see, if we waited till next year would that make it eaier for you?
[09:30] <ogra_> but as i said, i only have two weeks before EOY ... i wont finish that stuff in that time anyway
[09:31] <ogra_> and we need to coordinate with foundations somehow for everything but BBB
[09:31] <ogra_> since they will want a central place for the binaries that also the debs can use
[09:32] <ogra_> (uboot, blobs etc)
[09:32] <zyga> ogra_: can that be the git repo perhaps?
[09:32] <ogra_> no
[09:32] <didrocks> zyga: on alsa: if I'm correct, there are multiple sound modules and they have different names depending on the card
[09:32] <zyga> ogra_: why not?
[09:32] <ogra_> not if the git repo has not been completely changed from what the LP one contains today
[09:33] <didrocks> ogra_: do you know if this is correct? ^
[09:33] <zyga> didrocks: interesting, how does it work on classic?
[09:33] <ogra_> the repo will end up to only have a snapcraft.yaml in the end
[09:33] <didrocks> zyga: it's a very good question, I never dive into this part, pulseaudio worked for me :p
[09:33] <zyga> ogra_: interesting, and where will all the source code be?
[09:33] <ogra_> zyga, preferably debs in the archive
[09:33] <ogra_> so the classic images can use them
[09:34] <zyga> ogra_: hmm, I see
[09:34] <zyga> ogra_: I think this is somewhat difficult for others (poor reference) because they will start with uboot tree
[09:34] <zyga> ogra_: not with any debss
[09:34] <zyga> ogra_: but perhaps we can find a way to accomodate that somehow
[09:34] <didrocks> zyga: can you try to lsmod | grep snd on your machine?
[09:34] <didrocks> I do have:
[09:34] <didrocks> snd                    81920  18 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,thinkpad_acpi,snd_seq_device
[09:34] <didrocks> (notice the thinkpad_acpi)
[09:34] <ogra_> zyga, the only arch that can use a uboot tree only is the BBB
[09:35] <ogra_> zyga, all others need additional blobs
[09:35] <zyga> ogra_: that's fine but my point is that the snapcraft.yaml that is deb based is not aligned with people that want to create a gadget for their board that uses some bootloader and they build it from sources
[09:35] <didrocks> zyga: ah, the machine-dependant one for me is: cat /proc/asound/modules
[09:35] <didrocks>  0 snd_hda_intel
[09:35] <ogra_> didrocks, there are /usr/share/alsa/cards and /usr/share/alsa/ucm
[09:36] <zyga> didrocks: I'm on a VM here, on my thinkpad natively I'd probably get the same thing
[09:36] <ogra_> they have the default configs for certain cards
[09:36] <ogra_> zyga, yes, so using our official gadget trees as reference is perhaops the wrong thing altogether
[09:36] <didrocks> zyga: and look at /etc/modprobe.d/alsa-base.conf
[09:36] <didrocks> those are the rules
[09:36] <ogra_> zyga, like our kernel snaps are not even remotely related to what the kernel snapcraft plugin gives you
[09:37] <mvo> abeato: aha, I have a look, thank you
[09:37] <abeato> great, np
[09:37] <didrocks> ogra_: context is bug #1645605
[09:37] <mup> Bug #1645605: No alsa module on ubuntu core image <snapd-interface> <Snappy:Incomplete by zyga> <https://launchpad.net/bugs/1645605>
[09:38] <ogra_> zyga, anyway, do what you feel you need to do ...
[09:38] <mvo> didrocks: hey, thanks for the additional info in the download bug \o/ I'm going through it now and try to make sense of it
[09:39] <ogra_> didrocks, BSPs usually have their sound bits builtin ... also arm boards usually use UCM
[09:39] <didrocks> mvo: thanks! If there is anything else I can do to help debugging, I have my setup started here
[09:46] <ogra_> didrocks, anyway ... your alsa bug is a kernbel bug in the first place
[09:47] <ogra_> (if you dont find a soundcard there is either the UCM setup or the module missing in the kernel)
[09:47] <ogra_> i thought we had that enabled but /proc/asound/cards is empty on all boards here
[09:48] <ogra_> so first of all the kernel needs the bits enabled to turn on UCM ... and it should ship the right UCM config
[09:51] <zyga> re
[09:51] <zyga> ogra_: that's true
[09:51] <zyga> ogra_: I guess we have to decide what to do then
[09:51] <zyga> ogra_: perhaps we need "both" to the point where those are identical (long term plan)
[09:51] <zyga> ogra_: perhaps something else entirely
[09:52] <ogra_> well, rolling a gadget isnt "have that ubioot tree and drop a snbapcraft.yaml in"
[09:52] <ogra_> it is sadly a lot more complex
[09:53] <zyga> ogra_: indeed
[09:53] <zyga> ogra_: do you think it can be, eventually, a snapcraft.yaml in a tree of sources (and blobs if there's no source for them) that builds all the way?
[09:53] <ogra_> anyway, if you feel it is urgent to do that github move and split of trees right now, go ahead
[09:53] <ogra_> no
[09:54] <ogra_> you need a lot of manual work, tinkering and testing to find the right setup before being able to build your first gadget if it is a completely new arch
[09:54] <zyga> ogra_: oh, sure, I mean our references
[09:54] <ogra_> we should have a reference tree for every bigger setup imho
[09:54] <zyga> ogra_: do you think we can eventually build them from source all the way?
[09:55] <ogra_> (i.e. we dont have anything for sunxi boards ... proting to that will be a pain for users)
[09:55] <ogra_> we can surely build parts opf them from source ... really depends on the board
[09:55] <zyga> ogra_: I see, thanks for the input
[09:55] <zyga> ogra_: I'm not going to do anything right now, I've added a card to track this
[09:55] <ogra_> the only arches where booting does nto depend on binary blobs are x86 and BBB thogh
[09:56] <ogra_> *not
[09:56] <zyga> ogra_: I'd like to improve the visibility of the gadgets
[09:56] <zyga> ogra_: and perhaps de-mystify them a little
[09:56] <ogra_> +1
[09:56] <zyga> ogra_: but it's a complex topic and I don't want to just break more than I improve
[09:57] <seb128> is there any documentation about the dump plugin?
[09:57] <ogra_> well, i think forst of all we should have a meeting or so with foundations
[09:57] <seb128> http://snapcraft.io/docs/reference/plugins/dump is virtually empty
[09:57] <ogra_> to clearly line out a plan ...
[09:57] <zyga> ogra_: that's a good idea
[09:57] <seb128> the "examples" also sends you to an empty page
[09:57] <zyga> ogra_: preferably early so that everyone can think about this over xmas
[09:57] <ogra_> i had hoped to do that in the hague ... but there was not much foundations there
[09:58] <ogra_> (i want steve and adam in that meeting)
[10:01] <zyga> ogra_: so slangasek and ...  (slipped my head)
[10:01] <zyga> (and looking at /names doesn't help)
[10:01] <ogra_> the infinite one ;)
[10:02] <ogra_> infinity in case that wasnt clear :)
[10:15] <mup> PR snapd#2369 opened: snap: disable support for socket activation <Created by stolowski> <https://github.com/snapcore/snapd/pull/2369>
[10:29] <Chipaca> does adt-buildvm-ubuntu-cloud on xenial not work to build yakkety images?
[10:30] <mvo> Chipaca: you need the version from xenial-backports iirc
[10:31] <mvo> Chipaca: apt install autopkgtest/xenial-backports
[10:32] <Chipaca> mvo, ah! thanks
[10:33] <Chipaca> that works, indeed
[10:33] <mup> PR snapd#2363 closed: snap: support "daemon: notify" in snap.yaml <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2363>
[10:49] <zyga> ogra_: right, that was clear, thanks :)
[10:50] <ogra_> :)
[11:05] <mup> PR snapd#2370 opened: i18n: use github.com/ojii/gettext.go (pure go) for i18n to avoid cgo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2370>
[11:23] <gerry_> snappy-debug suggestion "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" anybody have any idea how to do this?
[11:26] <mup> Bug #1402536 changed: snappy install should support version/hash to get specific version from the store <Snappy:Invalid> <https://launchpad.net/bugs/1402536>
[11:26] <mup> Bug #1413185 changed: Snappy remote install requires password three times <snappy> <Snappy:Fix Released> <https://launchpad.net/bugs/1413185>
[11:35] <mup> Bug #1457491 changed: Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode) <snappy-robustness> <Snappy:Won't Fix> <https://launchpad.net/bugs/1457491>
[11:35] <mup> Bug #1459642 changed: If a gadget install fails, udev is not cleaned up <Snappy:Won't Fix> <Snappy 15.04:Won't Fix> <https://launchpad.net/bugs/1459642>
[11:50] <mup> Bug #1464944 changed: no way to configure keyboard layout <Snappy:Fix Released> <https://launchpad.net/bugs/1464944>
[11:50] <mup> Bug #1466682 changed: Docker unix socket permission issue on ubuntu-core update <Snappy:Fix Released> <https://launchpad.net/bugs/1466682>
[11:50] <zyga> ogra_: invinte sent, let me know if that's that's too late for you
[11:53] <mup> Bug #1468958 changed: selftests print "no such file or directory" on error <Snappy:Fix Released> <https://launchpad.net/bugs/1468958>
[11:53] <renato__> didrocks, hey, I saw someone complaining about that on the ml, I think there is a bug already. Let me find it
[11:54] <ogra_> zyga, hmm, its ok ... are you sure that short of a notice works for the others though ?
[11:56] <mup> Bug #1472721 changed: snappy update shows no message when there are no updates <Snappy:Fix Released> <https://launchpad.net/bugs/1472721>
[11:57] <mup> PR snapd#2371 opened: daemon, store: let snap info find things in any channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/2371>
[11:59] <mup> Bug #1472802 changed: ubuntu-core timezone config has no effect <Snappy:Won't Fix> <https://launchpad.net/bugs/1472802>
[12:01] <zyga> ogra_: if not we can move
[12:02] <mup> Bug #1474125 changed: Image got in a broken state after update -> rollback -> update (wrong kernel) <Snappy:Fix Released> <Snappy 15.04:Fix Released by sergiusens> <https://launchpad.net/bugs/1474125>
[12:03] <renato__> didrocks, ohh, just saw that you replied the e-mail asking to open the bug, but did not get reply. Let me open it
[12:08] <mup> Bug #1479027 changed: package.yaml docs missing releases OR frameworks fields <snap-docs> <Snappy:Won't Fix> <https://launchpad.net/bugs/1479027>
[12:08] <mup> Bug #1481086 changed: Need API/cli method to know if "is_snappy" <Snappy:Fix Released> <https://launchpad.net/bugs/1481086>
[12:11] <mup> Bug #1484982 changed: service description whitelist unnecessarily strict <Snappy:Invalid> <https://launchpad.net/bugs/1484982>
[12:14] <mup> Bug #1495059 changed: cannot add new sudo users <Snappy:Fix Released> <https://launchpad.net/bugs/1495059>
[12:17] <mup> Bug #1495452 changed: auto upgrade unintentionally updates /etc/udev/rules.d/70-persistent-net.rules <Snappy:Fix Released by ogra> <Snappy 15.04:Fix Released by ogra> <Snappy trunk:Fix Released by ogra> <https://launchpad.net/bugs/1495452>
[12:17] <mup> Bug #1495662 changed: Services and binaries allow _ # <Snapcraft:Fix Released by sergiusens> <Snappy:Fix Released> <Snappy 15.04:Won't Fix> <Snappy trunk:Fix Released> <https://launchpad.net/bugs/1495662>
[12:20] <gerry_> hi I have this suggestion by snappy-debug: "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" anybody have experience of this?
[12:20] <mup> Bug #1496319 changed: Could not create symlink to hw device with udev rules <Snappy:Won't Fix> <https://launchpad.net/bugs/1496319>
[12:20] <mup> Bug #1499109 changed: hw-assign and oem assign are inconsistent <Snappy:Won't Fix> <https://launchpad.net/bugs/1499109>
[12:23] <mup> Bug #1499478 changed: snappy install failure if service doesn't start does not cleanup <Snappy:Fix Released> <https://launchpad.net/bugs/1499478>
[12:23] <mup> Bug #1499662 changed: boot partition size should be configurable <Snappy:Fix Released> <https://launchpad.net/bugs/1499662>
[12:26] <mup> Bug #1499993 changed: U-d-f uses hardcoded names for kernel and initrd instead of the ones defined in hardware.yaml <Snappy:Fix Released> <https://launchpad.net/bugs/1499993>
[12:26] <mup> Bug #1500020 changed: /var/lib/opencryptoki needs to be in /etc/system-image/writable-paths <Snappy:Fix Released> <ubuntu-core-config (Ubuntu):Fix Released> <https://launchpad.net/bugs/1500020>
[12:29] <foxmask> bonjello
[12:29] <mup> Bug #1502810 changed: Implement "snappy try" <Snappy:Fix Released> <https://launchpad.net/bugs/1502810>
[12:44] <longsleep> zyga: i tried snap-confine from the use-aa-support branch but it segfaults : http://paste.ubuntu.com/23553160/ - do you have any suggestion?
[12:47] <zyga> longsleep: looking
[12:48] <zyga> longsleep: any chance to get a backtrace?
[12:48] <longsleep> zyga: yeah let me install gdb
[12:54] <mup> Bug #1504649 changed: dns-nameserver, dns-nameservers and dns-search not documented for snappy config for static ip addresses <Snappy:Won't Fix> <https://launchpad.net/bugs/1504649>
[12:55] <mup> PR snapd#2372 opened: interfaces/seccomp: add support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2372>
[12:55] <longsleep> zyga: here you go: http://paste.ubuntu.com/23553195/
[12:55] <zyga> longsleep: checking
[12:55] <longsleep> not much in there :/
[12:55] <zyga> longsleep: oh, nice
[12:56] <zyga> longsleep: up
[12:56] <zyga> longsleep: (one sec, switching branches)
[12:56] <zyga> longsleep: print label
[12:57] <mup> Bug #1504938 changed: invalid character '<' looking for beginning of value <Snappy:Won't Fix> <https://launchpad.net/bugs/1504938>
[12:57] <mup> Bug #1505696 changed: SquashfsTestSuite.TestRunCommandUgly fails if you have a non-english locale <Snappy:Fix Released> <https://launchpad.net/bugs/1505696>
[12:57] <mup> Bug #1505717 changed: prefer vmlinuz-*.efi.signed over vmlinuz in device tarball <Snappy:Fix Released> <https://launchpad.net/bugs/1505717>
[12:57] <zyga> longsleep: print mode
[12:57] <zyga> longsleep: perhaps something I dind't account for, I can fix that quickly
[12:58] <longsleep> zyga: http://paste.ubuntu.com/23553198/
[12:58] <zyga> longsleep: let me cook a patch
[12:58] <zyga> longsleep: nice, thanks
[12:58] <longsleep> zyga: let me see if i can resolve the not found
[12:58] <zyga> longsleep: nah, that's all good
[12:58] <zyga> longsleep: I know what the bug is already
[12:58] <zyga> longsleep: thank you!!! :)
[12:58] <longsleep> zyga: awesome :)
[13:00] <mup> Bug #1507607 changed: move boot-ok to before sessions <Snappy:Fix Released> <https://launchpad.net/bugs/1507607>
[13:01] <longsleep> zyga: fixed the not-found - see here http://paste.ubuntu.com/23553206/
[13:02] <zyga> longsleep: I just pushed a fix
[13:02] <longsleep> zyga: rebuilding
[13:02] <zyga> longsleep: feel free to comment on the pull request as well once you get this working
[13:03] <mup> Bug #1511435 changed: ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1511435>
[13:04] <longsleep> zyga: looks better now
[13:04] <longsleep> /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env
[13:04] <longsleep> SNAP_NAME is not set
[13:04] <longsleep> zyga: so do you have a suggestion how i could fully test this now?
[13:05] <longsleep> zyga: still does not seem to work though
[13:05] <longsleep> SNAP_NAME=hello-world /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env
[13:05] <longsleep> cannot change apparmor hat. errmsg: Operation not permitted
[13:05] <longsleep> support process for mount namespace capture exited abnormally
[13:05] <longsleep> [157896.731125] type=1400 audit(1480424709.523:33): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 profile="unconfined" pid=17652 comm="snap-confine"
[13:09] <zyga> longsleep: (just in a call now, I'll be with you in 15 minutes0
[13:09] <longsleep> zyga: all right thanks - take your time and just ping me when you are available
[13:09] <mup> PR snapcraft#918 closed: create the deltas package/class with xdetal generation implementation <Created by seawaywen> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/918>
[13:16] <zyga> longsleep: nice
[13:16] <zyga> longsleep: you now need snapd and snap-run to get this to work
[13:16] <zyga> longsleep: oh, that's super odd, let me check why this happens (the hat thing which is what this was supposed to fix)
[13:18] <longsleep> zyga: is there a way i can make snapd/snap-run use my custom snap-confine?
[13:18] <zyga> longsleep: fixed again
[13:18] <longsleep> zyga: you are awesome, rebuilding
[13:19] <zyga> longsleep: yes, do a bind mount so it shows up in /usr/lib/snapd
[13:19] <zyga> longsleep: sudo mount --bind some/custom/snap-confine /usr/lib/snapd/snap-confine
[13:19] <zyga> longsleep: and make sure it's stuid root
[13:19] <zyga> setuid*
[13:19] <zyga> longsleep: (no wonder this doens't work, there's no spread test for it yet)
[13:19] <zyga> longsleep: thank you for trying this
[13:20] <longsleep> zyga: seems to work now
[13:21] <zyga> longsleep: great!
[13:21] <longsleep> zyga: http://paste.ubuntu.com/23553265/ so what does that tell us now?
[13:21] <zyga> longsleep: thank you!
[13:21] <mup> Bug #1511447 changed: snapcraft stage does not work with Go and Launchpad <Snapcraft:Confirmed> <https://launchpad.net/bugs/1511447>
[13:21] <longsleep> zyga: that branch will get merged into release eventually and it wont matter that my kernel does what it does?
[13:21] <zyga> longsleep: that it should be good
[13:21] <zyga> longsleep: you can set SNAP_CONFINE_DEBUG=yes
[13:21] <zyga> longsleep: to see what's going on
[13:21] <zyga> longsleep: yes
[13:22] <zyga> longsleep: I plan to merge it as soon as I get a review from security
[13:22] <zyga> longsleep: well..
[13:22] <zyga> longsleep: if your snap-confine is unconfined it won't try to switch hat
[13:22] <zyga> longsleep: there are other places that care about apparmor
[13:22] <zyga> longsleep: (in snapd)
[13:22] <zyga> longsleep: but some of the work I'm doing will make that more flexible
[13:22] <zyga> longsleep: I want to know one more thing
[13:22] <zyga> longsleep: can you run
[13:23] <zyga> longsleep: apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine
[13:23] <zyga> longsleep: that probalbly crashes but I want to see why
[13:23] <longsleep> zyga: sure, this is the debug output http://paste.ubuntu.com/23553270/
[13:24] <mup> Bug #1511448 changed: ubuntu-snappy.firstboot fails when oem snap contains config for snaps not preinstalled, built-in <Snappy:Won't Fix> <https://launchpad.net/bugs/1511448>
[13:24] <longsleep> zyga: the apparmor_parser -r does not print anything
[13:24] <zyga> longsleep: odd
[13:24] <zyga> longsleep: hmmm
[13:24] <zyga> longsleep: I'll get back to you
[13:34] <jamespage> anyone had any success in allowing a confined snap to manage network namespaces?
[13:39] <zyga> jamespage: hey
[13:39] <jamespage> zyga, hello
[13:39] <zyga> jamespage: jdstrand is working on supporting it, the current idea is that /run/something-used-by-ip-netns will be like /media today
[13:39] <jamespage> I was just reading https://bugs.launchpad.net/snappy/+bug/1624675
[13:39] <mup> Bug #1624675: Please add network-namespace interface <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1624675>
[13:39] <zyga> jamespage: and then you can use ip setns
[13:39] <zyga> jamespage: I'll try to sync with jamie today, adding that directory should be trivial
[13:40] <zyga> jamespage: would that be sufficient for you?
[13:40] <jamespage> zyga, it might be - the neutron agents do a load of things with namespaces to support overlapping ip address ranges and alike
[13:40] <jdstrand> jamespage: note that as of today, you can use devmode to create network namespaces via 'ip netns' that will work for that snap
[13:40] <zyga> jdstrand: hey!
[13:41] <jamespage> jdstrand, yeah - have my snaps working ok with the hypervisor snap in devmode
[13:41] <zyga> jdstrand: I sent you an invite for a call today (if you can get there please let me know)
[13:41] <jdstrand> zyga: hi!
[13:41] <jamespage> I think that this netns bit is the last part that means I still need devmode
[13:41] <jamespage> (looking at the kernel log at least)
[13:42] <jamespage> well for now
[13:42] <jdstrand> jamespage: do you have a wiki page for testing this? I've never gotten very far with neutron/etc in the past. ideally this would be to run in a vm
[13:42] <jamespage> jdstrand, yeah - we do
[13:42] <zyga> jdstrand: I replied to your question on https://github.com/snapcore/snap-confine/pull/193 -- I'd love to know if I can merge that and if my explanation is correct, I'm working on addressing the remaining things in a new pull request
[13:42] <mup> PR snap-confine#193: Replace mkpath with sc_nonfatal_mkpath <Created by zyga> <https://github.com/snapcore/snap-confine/pull/193>
[13:42] <jdstrand> jamespage: do you know otoh if these things are using 'ip netns' or are they doing something else?
[13:42] <jamespage> jdstrand, https://github.com/openstack-snaps/snap-test
[13:43] <jamespage> I need to add in the bit for the nova-hypervisor snap - however that is a little dependent on some of the interface work I have inflight atm
[13:43] <jamespage> jdstrand, they all use ip netns
[13:44] <jdstrand> jamespage: ok, I'll be poking at this soon (ie, this week)
[13:44] <jamespage> but I guess using in devmode would be supportable
[13:44] <jamespage> I'll need to drop the newer interface bits from the snap for now
[13:45] <jdstrand> I can deal with interface bits fine
[13:45] <jdstrand> so don't do anything extra on my account
[13:46] <jamespage> jdstrand, ack
[13:46] <jdstrand> zyga: re the meeting later, I'll talk to tyhicks and one of us will join
[13:47] <jamespage> tbh most of my time in the last few days was burnt on trying to get libvirt to work from within a snap
[13:47] <jamespage> I parked that for now
[13:47] <jdstrand> eek
[13:48] <zyga> jdstrand: perfect, that's exactly what I suggested in the meeting notes
[13:48] <jdstrand> jamespage: definitely start with devmode. libvirt as a snap is going to need to be super-privileged like docker-support and lxd-support
[13:49] <jamespage> jdstrand, most of my pain was due to the amount of build time detection and path encoding that libvirt does
[13:49] <jdstrand> yeah, I can imagine
[13:49] <jamespage> anyway I'm aiming for on host os libvirt and ovs for now
[13:50] <jamespage> I have another interface to propose - openvswitch in the style of libvirt - just allows access to the ovs db socket on the host
[13:51] <mup> Bug #1516351 changed: Consider changing release id <Snappy:Fix Released> <https://launchpad.net/bugs/1516351>
[13:56] <mhall119> tedg: do you know what's keeping inkscape from being published to the stable channel?
[13:57] <mup> Bug #1520093 changed: ugly error when trying to set config without sudo <Snappy:Won't Fix> <https://launchpad.net/bugs/1520093>
[13:57] <mup> Bug #1521927 changed: Package operations are not atomic. <Snappy:Fix Released> <https://launchpad.net/bugs/1521927>
[14:00] <mup> Bug #1563737 changed: Bootloader type detection ignores the actual bootloader in use <Snappy:Fix Released> <initramfs-tools-ubuntu-core (Ubuntu):Fix Released> <https://launchpad.net/bugs/1563737>
[14:06] <mup> Bug #1564316 changed: classic dist-upgrade fails on sudo and tzdata... <Snappy:Fix Released> <https://launchpad.net/bugs/1564316>
[14:08] <didrocks> renato__: hey, did you file it? I would like a link I can reference :)
[14:09] <mup> Bug #1569577 changed: please remove var/lib/snapd/apparmor/additional from debian/snapd.dirs <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1569577>
[14:10] <renato__> didrocks, https://bugs.launchpad.net/ubuntu-app-platform/+bug/1645731
[14:10] <mup> Bug #1645731: Fail to access the shared content if app starts before connect interface <Ubuntu App Platform:New> <https://launchpad.net/bugs/1645731>
[14:11] <didrocks> renato__: thanks! :)
[14:11] <didrocks> renato__: hum, no snappy ref?
[14:12] <didrocks> renato__: didn't Mirv said this was a snappy bug? mind adding this task?
[14:12] <mup> Bug #1570280 changed: snap and snappy man pages incomplete <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1570280>
[14:12] <renato__> didrocks, this is a snapd bug I think
[14:13] <didrocks> renato__: please add an upstream snappy task then
[14:13] <zyga> didrocks, renato__: I just assigned that bug to mysel
[14:13] <zyga> f
[14:14] <renato__> zyga, ok thanks
[14:14] <didrocks> zyga: thanks :)
[14:15] <mup> Bug #1570261 changed: Snappy does not deal well with non-existing/non-working daemon command <Snappy:Fix Released> <https://launchpad.net/bugs/1570261>
[14:15] <mup> Bug #1645731 opened: Fail to access the shared content if app starts before connect interface <Snappy:Confirmed for zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
[14:24] <tedg> mhall119: Yes
[14:24] <mup> Bug # changed: 1570618, 1571710, 1571721, 1572151, 1572463
[14:25] <tedg> mhall119: It's based on a pre-release version that hasn't been released yet. Will be pushed to stable once 0.92 is released.
[14:26] <mhall119> ah, cool, ok
[14:27] <mhall119> is that happening soon? If not, would they snap up the current stable?
[14:30] <mup> PR snapd#2373 opened: debian: remove unneeded conflict against the "snappy" package <Created by mvo5> <https://github.com/snapcore/snapd/pull/2373>
[14:33] <mup> Bug #1574526 changed: x11 plug doesn't allow getsockname, breaks xeyes <snappy-interfaces> <verification-done> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1574526>
[14:33] <mup> Bug #1574556 changed: apparmor denials reported for encrypted HOME <apparmor> <Snappy:Fix Released> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <ubuntu-core-launcher (Ubuntu Xenial):Fix Released by jdstrand> <https://launchpad.net/bugs/1574556>
[14:36] <mup> Bug #1574829 changed: snappy install requires root or login, but doesn't tell you so <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1574829>
[14:36] <mup> Bug #1575399 changed: Half installation for a snap <verification-done> <Snappy:Fix Released> <https://launchpad.net/bugs/1575399>
[14:39] <mup> Bug #1576263 changed: Installing a non-existent app from the store results in core being downloaded but not installed <Snappy:Fix Released> <https://launchpad.net/bugs/1576263>
[14:42] <mup> Bug #1577228 changed: "Ubuntu Core Snappy AutoUpdate" service failed with "error: the required argument `<snap>` was not provided" <amd64> <apport-bug> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1577228>
[14:45] <mup> Bug #1577441 changed: No way to rollback a snap since the move to snap command <Snappy:Fix Released> <https://launchpad.net/bugs/1577441>
[14:46] <wxl> interesting
[14:46] <wxl> oops wrong channel
[14:46] <wxl> sheesh
[14:46] <wxl> is there a snappy core channel?
[14:52] <mup> Bug #1577439 changed: No more -u/-v options for "list" <Snappy:Fix Released> <https://launchpad.net/bugs/1577439>
[14:52] <mup> Bug #1579932 changed: The user acceptance test suite is called integration-tests <Snappy:Fix Released by elopio> <https://launchpad.net/bugs/1579932>
[14:52] <mup> Bug #1580403 changed: snap tries to manage bootloader in snappy-on-ubuntu-classic mode <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1580403>
[14:54] <didrocks> wxl: this is this one
[14:55] <mup> Bug #1583259 changed: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:Fix Released> <click-reviewers-tools
[14:55] <mup> (Ubuntu):Fix Released> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
[14:56] <wxl> didrocks: great. is there a prepared snappy image i could use in virtualbox or do i just need to go ahead and install one?
[14:58] <didrocks> wxl: hum, there is a qemu image, I don't think there is one for virtualbox
[14:58] <didrocks> Trevinho: hey! I would need the bug reference for the snapcraft parser now please :)
[14:58] <wxl> didrocks: great thanks
[14:59] <Trevinho> didrocks: I already subscribed to you there...
[14:59] <didrocks> Trevinho: oh?
[14:59] <Trevinho> didrocks: see https://github.com/snapcore/snapcraft/pull/930
[14:59] <mup> PR snapcraft#930: Parser support remote dependencies <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/930>
[14:59] <Trevinho> didrocks: https://bugs.launchpad.net/snapcraft/+bug/1645350
[14:59] <mup> Bug #1645350: Parts depending on other remote parts aren't properly added <Snapcraft:In Progress by 3v1n0> <https://launchpad.net/bugs/1645350>
[14:59] <didrocks> Trevinho: thanks!
[14:59] <didrocks> Trevinho: you didn't subscribe me to the bug
[15:00] <Trevinho> didrocks: I did...  https://usercontent.irccloud-cdn.com/file/sJNTn1yT/
[15:01]  * Trevinho has to fix the branch now... :-/
[15:01] <didrocks> Trevinho: I only see Joe and you on my launchpad bug
[15:01] <Trevinho> weird
[15:02] <didrocks> you are talking about #1645350, right?
[15:02] <mup> Bug #1645350: Parts depending on other remote parts aren't properly added <Snapcraft:In Progress by 3v1n0> <https://launchpad.net/bugs/1645350>
[15:02] <Trevinho> yes
[15:02] <didrocks> this is weird, I definitively have only you two in this section :/
[15:02] <Trevinho> who knows.... maybe you filter out something... but I did subscribe you just after filing it
[15:03] <jdstrand> zyga: 193 approved
[15:04] <didrocks> Trevinho: well, my filter wouldn't change launchpad page :p
[15:04] <mup> Bug #1584586 changed: First snap install should fail fast rather than download OS snap <Snappy:Fix Released> <https://launchpad.net/bugs/1584586>
[15:04] <Trevinho> didrocks: yeah I mean... Something related to lp project options?
[15:04] <didrocks> Trevinho: could be… I don't think, first time I see that
[15:05] <zyga> jdstrand: thanks!
[15:05] <jdstrand> zyga: thanks for the cleanups :)
[15:05] <zyga> jdstrand: I'm taking a different approach for mode/uid/gid mkdir, that will be easier to verify I hope
[15:06] <gerry_> hi I get this output when I try to run my program as sudo  "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" could anyone advise me how to deal with this please?
[15:07] <gerry_> sorry meant to say while running snappy-debug
[15:09] <jdstrand> gerry_: if you get it while running sudo, it sounds like the unix permissions are being ignored because you are root. eg, perhaps a user owned directory that is 755 that root is writing to, a file that is 644 that isn't root owned, etc
[15:09] <jdstrand> that is usually what triggers that sort of thing
[15:10] <gerry_> ok so I change the permissions of my file?
[15:10] <jdstrand> if that is the issue, that would fix it, yes. change perms or owner
[15:12] <gerry_> jdstrand : thank you for your help I will try
[15:14] <mup> PR snapd#2374 opened: snap: tweak snap install output as designed by Mark <Created by mvo5> <https://github.com/snapcore/snapd/pull/2374>
[15:18] <gerry_> jdstrand: no I still  have the same problem my program run when installed in devmode but crashes with "No protocol specified Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server" when I try to run it with sudo, while installed in dangerous mode
[15:19] <mup> Bug # changed: 1586248, 1587175, 1587445, 1587676
[15:26] <wxl> um, so is ubuntu core (http://cdimage.ubuntu.com/ubuntu-core/16/stable/) and ubuntu snappy core different???
[15:31] <mup> Bug #1596243 changed: snap gets stuck removing snap <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1596243>
[15:31] <mup> Bug #1597417 changed: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1597417>
[15:31] <didrocks> wxl: no, it's the same, ubuntu core is the official name
[15:31] <didrocks> (yeah, naming was bad, sorry)
[15:34] <mup> Bug #1597948 changed: github.com/snapcore/snapd/cmd/snap TestSnapRunSnapExecEnv fails if HOME is set in environment <Snappy:Fix Released> <https://launchpad.net/bugs/1597948>
[15:37] <mup> Bug #1599919 changed: SnapOpSuite unit tests interfere with the user's $HOME/.snap directory <Snappy:Fix Released> <https://launchpad.net/bugs/1599919>
[15:38] <wxl> didrocks: ok. well when i boot that image, it asks me to configure networking. it doesn't seem to give me an option for wifi, which is understandable, i guess. is there a workaround besides building a custom image? also, is there official documentation that goes over things like this?
[15:39] <didrocks> wxl: you are in a VM, correct? This is why you don't have wifi option
[15:39] <didrocks> but your VM should share connexions
[15:40] <mup> Bug #1600260 changed: Support paravirtualization <Snappy:Fix Released by ogra> <initramfs-tools-ubuntu-core (Ubuntu):Fix Released by ogra> <https://launchpad.net/bugs/1600260>
[15:41] <wxl> didrocks: omg. derp.
[15:43] <mup> Bug #1600719 changed: The camera interface only grants access to /dev/video0 <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1600719>
[15:44] <wxl> didrocks: the "store" refers to where exactly?
[15:46] <mup> Bug #1603018 changed: snap create-user gets bad username <create-user> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1603018>
[15:46] <didrocks> wxl: ubuntu snap store (which is the same than click store)
[15:46] <didrocks> I thought there was a link to register, correct?
[15:46] <mup> PR snapd#2375 opened: store: retry tweaks and logging <Created by stolowski> <https://github.com/snapcore/snapd/pull/2375>
[15:47] <wxl> not that i saw
[15:47] <wxl> is that apps.ubuntu.com?
[15:48] <wxl> or maybe myapps.developer.ubuntu.com?
[15:48] <didrocks> yeah, the latter
[15:49] <wxl> sorry for all the noob questions but i'm not really finding any great docs anywhere and the answers aren't immediately obvious
[15:49] <mup> Bug #1603610 changed: Snaps have no screenshots <verification-done> <snapd-glib:Fix Released by robert-ancell> <Snappy:Fix Released by robert-ancell> <gnome-software (Ubuntu):Fix Released by robert-ancell> <gnome-software (Ubuntu Xenial):Fix Committed by robert-ancell> <gnome-software (Ubuntu
[15:49] <mup> Yakkety):Fix Released by robert-ancell> <https://launchpad.net/bugs/1603610>
[15:49] <wxl> so does it create a login based on that account? if so, given i got in via SSO, what's my password?
[15:50] <didrocks> wxl: yeah, there is few starting guide
[15:50] <didrocks> create an account for myapps
[15:51] <mvo> jdstrand is bug #1603879 something straightforward ? or very tricky?
[15:51] <mup> Bug #1603879: Requesting additions to optical-drive interface for cdparanoia. <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1603879>
[15:51] <seb128> wooot, it looks like the snappy team is triaging their bugs ;-)
[15:51] <mvo> seb128: *cough*
[15:52] <seb128> :-)
[15:52] <mvo> seb128: did I ever mention how much I hate bug triage?
[15:52] <seb128> haha
[15:52] <seb128> you might :p
[15:52] <mup> Bug #1604016 changed: Snap requires sudo if not logged in <Snappy:Fix Released> <https://launchpad.net/bugs/1604016>
[15:53] <seb128> but yeah, it's borring but useful!
[15:53] <zyga> slangasek, ogra_: will you be able to make the call/hangout on gagets later today?
[15:53] <seb128> speaking of bugs, where does one report issues about the snapcraft.io documentation bugs?
[15:53] <wxl> didrocks: ok got the account. it accepted my email. now i'm confronted with a request for credentials and have no clue what they are.
[15:54] <didrocks> well, it's just your email address, correct?
[15:54] <didrocks> the "store account"
[15:54] <wxl> yep, but there's no password given SSO
[15:54] <didrocks> you don't know password
[15:54] <wxl> unless i'm meant to use my launchpad password
[15:55] <didrocks> on the ubuntu core image vm
[15:55] <didrocks> just the email address is asked
[15:55] <didrocks> s/know/need any/
[15:55] <mup> Bug #1604880 changed: Missing inhibit interface <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1604880>
[15:55] <mup> Bug #1604885 changed: Access to mounted USB drives <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1604885>
[15:55] <wxl> i already gave it that, which is accepted
[15:55] <wxl> so now i'm beyond that
[15:56] <didrocks> ah, I see what you mean
[15:56] <didrocks> did you read the last line?
[15:56] <wxl> now i'm presented with a localhost login
[15:56] <slangasek> zyga: yes, though I'm surprised this needs a hangout.  I had talked with sergiusens at the last sprint about the fact that we needed pointers to sources from binary snaps, and that it should preferably be done officially in snapcraft - since we don't have any way to add arbitrary things to meta if we're using snapcraft
[15:56] <didrocks> you can ssh to your vm now
[15:56] <didrocks> better to ssh
[15:56] <wxl> oic
[15:56] <didrocks> your ssh key was copied over to it
[15:56] <mvo> seb128: yeah
[15:56] <mvo> seb128: snapcraft.io bugs, not sure, dholbach probably knows
[15:57] <zyga> slangasek: this is an informal call driven mainly by me; I want gadgets to be easier to find and (eventually) serve as a reference
[15:57] <didrocks> seb128: https://github.com/ubuntudesign/snapcraft.io/issues/new
[15:57] <didrocks> see bottom of the page :)
[15:57] <mvo> thanks didrocks
[15:57] <zyga> slangasek: since I don't own then I cannot decide by myself and I want to share my (simple) plan/idea with you to get feedback and see if you like the idea
[15:57] <zyga> slangasek: right now it's hard to find where each gadget comes from and harder to report bugs against them
[15:58] <seb128> didrocks, right, I was unsure if the content for the plugins section is coming from the site or autogenerated from the code
[15:58] <zyga> slangasek: I talked to ogra about this in the morning and he suggested that I add you and adam to the mix
[15:58] <didrocks> seb128: long long discussion…
[15:58] <didrocks> seb128: in summary, file them there, and normally davidcalle retargets, fixes
[15:58] <slangasek> zyga: ok. do you have a proposed layout under github for them?  How will I have commit access to them once moved there?
[15:58] <seb128> didrocks, lol, let's not reboot it then, thanks for the url
[15:58] <mup> Bug #1604964 changed: huge download for nothing - snap does not exist <Snappy:Fix Released> <https://launchpad.net/bugs/1604964>
[15:58] <mup> Bug #1605216 changed: cups-control interface doesn't allow printing <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1605216>
[15:58] <seb128> thanks
[15:59] <zyga> slangasek: my layout idea is super simple, either move them as-is (perhaps not ideal, see below) and start making them nicer (commit rights are super easy to manage)
[15:59] <ogra_> slangasek, the question was also about the uboot sources (deb sources shared with classic images) etc ...
[15:59] <zyga> slangasek: or split them so that later on launchpad can import separate repos and do github->launchpad->(Snapcraft)->store pipeline
[15:59] <zyga> slangasek: but even the split can be step two
[15:59] <zyga> slangasek: correspodning to this I'd like to have a place to file bug against each specific reference gadget (all 4 of them)
[16:00] <gerry_> hi snappy debug has this output "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" when I try to start my program with sudo any help gratefully received
[16:00] <davidcalle> seb128: didrocks: "fixes"? that's debatable :p
[16:00] <ogra_> slangasek, my assumption is that the github "tree" is in the end just a snapcraft.yaml and that we can have the gadgets auto-built if someone bumps a version in the tree
[16:00] <zyga> slangasek: and lastly, not sure what to do with bbb, it's not the same support status but we should find some way to have it live (as a community gadget) somewhere and perhaps share the benefits
[16:00] <ogra_> at least that was the plan with lsunchpad
[16:00] <ogra_> i think github is a little further from that automation plan atm
[16:01] <davidcalle> seb128: this location is fine, lp:snappy with snap-docs tag works as well if you prefer your bug mail on lp
[16:01] <ogra_> zyga, i'm the maintainer of BBB ... i'lll keep it in LP if you dont mind
[16:01] <zyga> slangasek: perhaps we can do a project for gadgets/kernels that are not officially supported
[16:01] <ogra_> (BBB is community supported ... )
[16:02] <slangasek> zyga: as it's not supported by us, but by ogra, you should ask ogra what works for that :)
[16:02] <ogra_> zyga, kernels are a totally different story
[16:02] <zyga> ogra_: no, I don't mind but if you can use bbb as a way to show how to build an ecosystem (if we agree on how that would look like)
[16:02] <zyga> slangasek: my main goal is to make the gadgets easier to find, easier to fork and more of a reference
[16:02] <zyga> slangasek: all I want to do is take a first step
[16:02] <ogra_> i wont go my own path here but i prefer to have things easier maintainable ... gihub is a pain i'd like to avoid for my own projects
[16:02] <zyga> slangasek: and move them out of the rather hard-to-find project on launchpad branch
[16:03] <ogra_> (until LP stops to support bzr completely :) )
[16:03] <seb128> davidcalle, ok, thanks
[16:03] <zyga> ogra_: that's okay, let's not complicate this over with bbb, focus just on the reference platforms
[16:03] <seb128> davidcalle, in any case the bug as been fixed it seems, so for next time
[16:03] <davidcalle> seb128: best kind of bugs
[16:03] <seb128> davidcalle, the "examples" at the bottom of the plugins descriptions was giving a github page stating that queries needs a project or user specified
[16:04] <seb128> but seems to work now
[16:04] <zyga> slangasek: apart from what we have there in the lp branches now I'd like to add a readme to each repository so that it explains what the content is, how it can be built and how it ends up in the store
[16:04] <zyga> slangasek: as well as a link to launchpad for bug tracking
[16:05] <ogra_> zyga, regarding kernels, the stuff is already moving to kernel.ubuntu.com (sadly) and will be 100% in the kernel team hands ... apart from the builds for the edge chaynnel where we need group mgmt from LP
[16:05] <zyga> slangasek: and anything else we can come up that's useful over time
[16:05] <zyga> ogra_: interesting
[16:05] <ogra_> the kernel team will take ovber everything
[16:05] <zyga> ogra_: I think that's fine, my focus is on gadgets today :) for kernels there will be another day (maybe) to look at how people can do their own kenrel easily with snapcraft / store
[16:06] <ogra_> (but we need edge in a state that everyone can make changes to the non-kernel components in the kernel snap)
[16:06] <ogra_> zyga, well, such people should use the snapcraft plugin ... but that will make you end up with something completely different indeed
[16:07] <zyga> ogra_: step by step, let's work on gadgets first, set up git trees, lp mirrors etc
[16:07] <zyga> ogra_: sergiusens made a pull request that snapcraftifies one of the gadgets
[16:07] <zyga> ogra_: that's a great first step and IMHO the way to go with all of them
[16:08] <ogra_> zyga, yes, i have sergiusens commit open here because i planned to look into it before EOY
[16:08] <wxl> is there a juju snap? i'm not immediately finding one and i'm surprised
[16:08] <zyga> ogra_: +1 thank you
[16:09] <zyga> slangasek: so that's the rough idea, the call is there just so that we can all share concerns and plans and align
[16:10] <mup> PR snapd#2376 opened: docs: document SNAP_DEBUG_HTTP in HACKING.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/2376>
[16:11] <wxl> correction: i find https://uappexplorer.com/app/juju-nskaggs.nskaggs but i cannot for whatever reason find it with snap
[16:11] <ogra_> wxl, probably not in the stable channel or perhaps it uses devmode
[16:12] <wxl> ogra_: oh, you know what. it's amd64 only.
[16:13] <ogra_> :)
[16:13] <seb128> sergiusens, hey, what do you mean by "allowing" in  "we agreed on allowing /snap/<snap_name>/current"?  That's its a stable interface garanty that it's not going to change/go away and that any snap can rely on the dir to be there for ever?
[16:13] <wxl> awww fooey
[16:18] <mup> PR snapd#2377 opened: snap: provide friendlier `snap find` message when no snaps are found <Created by mvo5> <https://github.com/snapcore/snapd/pull/2377>
[16:20] <jdstrand> zyga: hey, tyhicks was wondering if the meeting re snap-confine and snapd merging just to convince the security team it is ok, or is it something else?
[16:20] <jdstrand> s/just/was just/
[16:20] <tyhicks> hey zyga :)
[16:20] <jdstrand> well, I was wondering too after he mentioned it :)
[16:21] <zyga> jdstrand: I want do convince you that it is better to merge it into snapd
[16:21] <zyga> tyhicks: hey, how are you :)
[16:21] <tyhicks> doing well :)
[16:22] <zyga> tyhicks: I discovered that a gamy my son likes has a special easter egg for thanksgiving :)
[16:22] <zyga> tyhicks: (too bad we cannot do those in snap-confine) ;)
[16:22] <tyhicks> hehe
[16:22] <jdstrand> zyga: well, if that is all the meeting is about, we can probably cancel it-- tyhicks and I don't have strong objections
[16:22] <zyga> jdstrand: ah, in that case +1
[16:22] <mup> Bug # changed: 1606813, 1606815, 1606893, 1606932, 1606961
[16:22] <zyga> jdstrand: do you want to have the security label that requires a security +1 on pull requests?
[16:22] <tyhicks> zyga: I don't know that we need a meeting for that. We understand the positives and only have a preference for keeping it a seperate project (no hard blockers against it)
[16:23] <zyga> jdstrand: or some other way to track this?
[16:23]  * zyga nod
[16:23]  * zyga nods
[16:23] <tyhicks> zyga, jdstrand: I'll leave a +0 comment in the bug
[16:24] <zyga> thank you
[16:24] <jdstrand> zyga: we probably need a way to track things better that need security team awareness/review, yes
[16:25] <tyhicks> we will need that
[16:25] <tyhicks> zyga's idea for labels is probably the best that we'll get
[16:25] <jdstrand> zyga: it was easy before to see the changes to snap-confine
[16:25] <jdstrand> is there a way to auto-label?
[16:25] <jdstrand> like, if it is in this dir, then it gets a label?
[16:25] <mup> Bug # changed: 1607121, 1607129, 1607344, 1607604
[16:26] <tyhicks> oh, that's a nice idea
[16:26] <zyga> jdstrand: not that I know of, it will require some though on our end
[16:27] <zyga> jdstrand: maybe with a bot later (it can do this in pull requests)
[16:27] <zyga> thought*
[16:27] <jdstrand> zyga: having it separate in github meant that there was a mental separation that snap-confine was special and needed special attention. I'm not sure how to achieve that once it is merged
[16:27] <jdstrand> sometimes the smallest changes can result in disaster in a setuid executable
[16:28] <mup> Bug #1608608 changed: Snapweb avahi service is still called webdm.local <Snappy:Fix Released> <https://launchpad.net/bugs/1608608>
[16:28] <mup> Bug #1608807 changed: create-user fails on classic <create-user> <Snappy:Fix Released> <https://launchpad.net/bugs/1608807>
[16:28] <mup> Bug #1586248 opened: 96boards-kernel need change name <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1586248>
[16:29] <tyhicks> I don't see a way to automatically tag PRs like that
[16:29] <tyhicks> a bot is likely needed
[16:31] <mup> Bug #1609930 changed: Support license acceptance <Snappy:New> <https://launchpad.net/bugs/1609930>
[16:34] <sergiusens> seb128 it will be a stable interface yes; if it changes we burn zyga's place down
[16:34] <seb128> sergiusens, good! :-)
[16:34] <sergiusens> :-)
[16:34] <mup> Bug #1611063 changed: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1611063>
[16:37] <zyga> jdstrand: note that many things in snapd are already special (all interface reviews)
[16:37] <mup> Bug #1611384 changed: Change detection not working, have to "snapcraft clean" between builds when modifying snap contents <Snapcraft:New> <https://launchpad.net/bugs/1611384>
[16:38] <mup> Bug #1616006 changed: clean remove of snapd <Snappy:Fix Released> <https://launchpad.net/bugs/1616006>
[16:38] <zyga> jdstrand: how do you manage those currently?
[16:38] <zyga> sergiusens, seb128: AFAIK we're not changing the current symlink in 16 series (it will stay as-is)
[16:38] <seb128> zyga, I'm glad to read that!
[16:39] <zyga> timothy: hey, you reported bug 1604346 a while ago
[16:39] <mup> Bug #1604346: snapd apparmor tests fail on ArchLinux <Snappy:Incomplete by zyga> <https://launchpad.net/bugs/1604346>
[16:39] <zyga> timothy: can you check if that still happens with latest snapd?
[16:48] <timothy> zyga: I had to reboot  with apparmor kernel
[16:48] <attente> sergiusens: is there a way to make an exception for a snapcraft integration test to allow network access?
[16:52] <zyga> timothy: no rush, if you can please add this to the bug report
[16:52] <zyga> timothy: how is arch btw?
[16:52] <seb128> where can one find detailed descriptions of interfaces?
[16:53] <seb128> http://snapcraft.io/docs/reference/interfaces is a good list
[16:53] <zyga> timothy: I didn't do much cross distro work lately and when I did I was stuck on fedora and selinux
[16:53] <seb128> but it has no details/example of how to use those
[16:54] <zyga> seb128: only in the code for now, I've added one page to the wiki to describe the content interface, I want to do this for all interfaces: https://github.com/snapcore/snapd/wiki/Content-Interface
[16:54] <zyga> seb128: (I actually didn't link it from the main list of interfaces yet)
[16:55] <zyga> seb128: it's a wiki though so editors welcome, if you have a specific interface we could work on documenting it
[16:56] <zyga> tyhicks, jdstrand: could you guys have a look at https://github.com/snapcore/snap-confine/pull/188
[16:56] <mup> PR snap-confine#188: Add apparmor support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/188>
[16:56] <seb128> zyga, wooot, the content interface was the one I was after so thanks for that ;-)
[16:56] <zyga> seb128: :D my pleasure, feedback welcome, this is my first edit on the wiki
[16:56] <seb128> k, will do
[16:56] <wxl> how does one add a new group on snappy?
[16:57] <zyga> wxl: you mean system group?
[16:57] <zyga> wxl: that's not supported yet
[16:57] <wxl> fooey
[16:57] <wxl> i found an lxd beta snap but it doesn't seem to add the lxd group
[16:57] <zyga> wxl: but we have some plans to do that, many daemons would like that
[16:57] <zyga> mvo: ^ did we add lxd hack to snapd?
[16:59] <ogra_> hack ? i thought the hacks were gone
[16:59] <ogra_> :P
[16:59] <ogra_> iirc you need to manually call addgroup if you use the snap on a core image
[16:59] <timothy> zyga: I see Fedora uses /var/ directory instead of /snap, did you create a migrate procedure?
[16:59] <ogra_> (with the --extrausers option)
[17:00] <zyga> timothy: no, we decided not to,
[17:00] <zyga> timothy: we didn't publish any packages that use that yet either because of confinement issues
[17:00]  * zyga jumps into a call
[17:01] <jdstrand> zyga: usually someone manually pings me are adds @jdstrand. this is not great and I'd want to tie changes to interfaces/ (for example) to be tagged in some way
[17:01] <wxl> ogra_: --extrausers is a snap option?
[17:01] <ogra_> wxl, nope ... passwd/adduser etc
[17:01] <jdstrand> zyga: ie, do for interfaces what we do for snap-confine
[17:01] <wxl> oh right, so you're talking about building the snap then
[17:02] <ogra_> nope about the core image
[17:02] <wxl> oh
[17:02] <wxl> even worse XD
[17:03] <seb128> zyga, it's a bit confusing in the examples to have the same word used for slots/plugs names and as an attribute
[17:05] <zyga> slangasek: hey, do you have the time to attend the gadget call now?
[17:05] <zyga> seb128: aha, thanks, I'll see if I can change that or make it more obviou
[17:05] <wxl> ogra_: i was sure hoping that core→snap juju/lxd→juju deploy mysql/wordpress would do the trick, but i guess i'm still a bit ahead of my time
[17:05] <seb128> zyga, yw :-)
[17:12] <seb128> zyga, hum, also is it required to have a "interface: content"? your example doesn't have it
[17:23] <mup> Bug #1639952 opened: When running in unity8 desktop snap, snap application icons aren't found in app scope <Canonical System Image:New> <Snapcraft:Confirmed> <Snappy:New> <ubuntu-app-launch (Ubuntu):New> <https://launchpad.net/bugs/1639952>
[17:26] <sergiusens> attente integration tests do have network access, unit tests do not (those are also run on package build which is networkless)
[17:31] <zyga> slangasek: can you point me to the official branch?
[17:34] <zyga> slangasek: there were some more commits on the vorlon one AFAIK
[17:39] <zyga> seb128: interface: content?
[17:39]  * zyga looks
[17:39] <tyhicks> zyga (cc jdstrand): I'm in the middle of reviewing snap-confine PR 188
[17:40] <zyga> tyhicks: thanks!
[17:41] <seb128> zyga, well other examples I found have an "interface: content" line, I guess it needs to know what interface to use?
[17:41] <mup> Bug # changed: 1617250, 1617251, 1617264, 1617278
[17:42] <zyga> seb128: is "interface" there an attribute?
[17:42] <zyga> seb128: of a plug or a slot?
[17:42] <zyga> seb128: that attribute doesn't mean anything, we only look at "content"
[17:42]  * zyga triple checks
[17:43] <seb128> zyga, I don't know, that thing is undocumented, I'm basing my comment on the read of http://askubuntu.com/questions/841004/cannot-get-basic-content-interface-example-working-with-snapcraft
[17:44] <zyga> ah
[17:44] <zyga> seb128: "interface: content" is required when the interface itself is not named "content"
[17:44] <seb128> oh
[17:44] <zyga> seb128: the plug / slot name can be anything
[17:44] <seb128> k
[17:44] <mup> Bug #1617770 changed: Snap cannot exec tput <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1617770>
[17:44] <zyga> seb128: but we create an implicit "interface: $PLUG_OR_SLOT_NAME"
[17:44] <seb128> some more magic ;-)
[17:44] <zyga> seb128: so when things all match is shorter and more magic
[17:44] <seb128> good to know
[17:44] <seb128> thanks zyga
[17:45] <zyga> seb128: I'll document that, thanks for pointing that out!
[17:47] <zyga> ogra_, slangasek: can you confirm that
[17:47] <zyga> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
[17:48] <zyga> is the place that has all the commits
[17:48] <ogra_> yep
[17:48] <zyga> thanks!
[17:49] <mup> PR snapd#2356 closed: cmd/snap: have some completers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2356>
[17:50] <seb128> zyga, thanks!
[17:50] <mup> Bug #1619455 changed: classic does not work with connsole-conf created user <Snappy:Fix Released by ogra> <https://launchpad.net/bugs/1619455>
[17:55] <zyga> ogra_: the latest commit there is
[17:55] <zyga> timestamp: Fri 2016-10-28 13:06:29 +0200
[17:55] <zyga> ah, 2016, I read that like 2015
[17:55] <zyga> sorry :)
[17:55] <ogra_> heh
[17:55] <ogra_> no, i bumped the dragonboard last ... right before release
[17:55] <ogra_> adding a second console= kernel option like on all other arches
[17:59] <mup> Bug #1617232 changed: subiquity goes into endless configuration loop, no way to get out <Snappy:Invalid> <subiquity (Ubuntu):Invalid by mwhudson> <https://launchpad.net/bugs/1617232>
[18:05] <jamespage> jdstrand, zyga: are you ok with me proposing pull requests with stacked commits? or do you want me todo them as standalone commits?
[18:05] <jamespage> happy todo either
[18:05] <zyga> jamespage: to snap-confine?
[18:05] <jamespage> to snapd
[18:06] <zyga> jamespage: in snapd we don't do squashing, so more commits is fine
[18:06] <zyga> ogra_: this is the first one
[18:06] <zyga> slangasek: ^^
[18:06] <zyga> https://github.com/snapcore/pi2
[18:07] <ogra_> looks good
[18:07] <zyga> ogra_: no tags?
[18:07] <mup> PR snapd#2378 opened: Openvswitch interface <Created by javacruft> <https://github.com/snapcore/snapd/pull/2378>
[18:07] <ogra_> nope
[18:07] <zyga> ah, no tags in bzr either, ok
[18:09] <ogra_> dunno if we want to start to have two branches (one for edge, one that migrates through beta->canididate->stable, for the second one i'd use tags
[18:10] <zyga> slangasek: master == edge
[18:10] <zyga> er
[18:10] <zyga> ogra_: ^^
[18:10] <zyga> ogra_: I think the rest is up to you
[18:10] <ogra_> yeah, thats what we did in the past
[18:11] <zyga> ogra_: you can also work with QA on this
[18:11] <ogra_> i just dont know if we want to kkeep that setup
[18:11] <ogra_> i'd actually like to have a "go wild" branch for edge
[18:11] <ogra_> where you can try out the evil stuff without harming the branch that gos later into stable
[18:11] <ogra_> *goes
[18:12] <zyga> ogra_: I think those are pull requests
[18:12] <zyga> ogra_: if we set this right, pull requests can even go to named channels
[18:12] <mup> PR snapcraft#933 opened: _filedir takes an extension, not a glob <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/933>
[18:13] <ogra_> you mean a PR would land in edge so you can trigger an img build from it ?
[18:18] <mup> PR snapd#2376 closed: docs: document SNAP_DEBUG_HTTP in HACKING.md <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2376>
[18:19] <kyrofa> ogra_, no, a PR would land in its own custom channel
[18:19] <kyrofa> "here, try this bugfix"
[18:19] <ogra_> kyrofa, right ... not what i want
[18:20] <ogra_> kyrofa, i want to land a fix and have it show up in tomorrows daily img without me doing anything
[18:20] <ogra_> (or land "the test of a fix" ... this is edge ... that is what it is for)
[18:21] <zyga> ogra_: that's edge
[18:21] <ogra_> right
[18:21] <zyga> ogra_: but even before you land someone's PR you can use a branch channel
[18:21] <zyga> ogra_: and try that out
[18:21] <ogra_> why would i ?
[18:22] <ogra_> sounds like we'd have a lot fragementation then
[18:22] <zyga> ogra_: you see a pull request, you do code review, you check that on a real device with a channel switch
[18:22] <kyrofa> ogra_, right, reading more backlog your use-case isn't the custom channels thing. You just want a branch essentially assigned to edge
[18:22] <kyrofa> That doesn't necessarily get merged into anything more stable
[18:23] <ogra_> zyga, how does a channel switch help me with some initial boot stuff (i.e. gadget)
[18:23] <zyga> ogra_: you switch and reboot
[18:23] <ogra_> i need an imag to dd
[18:23] <zyga> ogra_: no
[18:23] <zyga> ogra_: you switch and reboot :)
[18:23] <zyga> ogra_: maybe with a helper to wipe first-boot logic
[18:23] <ogra_> gadgets very very rarely have anything that helps via a channel switch
[18:24] <zyga> ogra_: if that doesn't do enough it's a bug in snapd, eventually that should be enough
[18:24] <ogra_> usually fixes are in the firstboot area etc
[18:25] <ogra_> anyway ... whatever works ...
[18:34] <zyga> jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/195/files
[18:34] <mup> PR snap-confine#195: Fix creation of $XDG_RUNTIME_DIR and $SNAP_USER_DATA <Created by zyga> <https://github.com/snapcore/snap-confine/pull/195>
[18:35] <zyga> I'm still going to add more unit tests and spread tests for this
[18:35] <zyga> for $SNAP_USER_DATA
[18:35] <zyga> and for chown logic (unit tests)
[18:35] <zyga> and for the hint callback
[18:35] <zyga> but have a look please for the overall aproach
[18:35] <zyga> approach*
[18:48] <zyga> slangasek: I did all the repos, look at github please
[18:48] <zyga> slangasek: I'll do all the launchpad repos next (I did pi2 as launchpad.net/snap-pi2)
[18:48] <zyga> slangasek: and I'll work on snapcraft.yaml's
[18:48] <zyga> slangasek: and publication to edge
[18:49] <zyga> but now, some time for my son, ttyl
[19:13] <mterry> jdstrand: were you the person that pmcgowan talked to about policykit in the unity8-session snap?  I wanted to discuss that a bit
[19:14] <mterry> Specifically the suggestion to just bundle polkitd.  One problem with that is that we'd need to patch policykit to get rid of the setuid requirement for the libpolkit agent helper.  Which you security folks might not be thrilled with
[19:15] <jdstrand> mterry: I'm working on a response to that bug. it is quite a complicated prospect overall
[19:15] <mterry> jdstrand: ok cool we can talk in the bug
[19:15] <jdstrand> mterry: as for the setuid bit, why is it setuid?
[19:16] <mterry> jdstrand: I don't know?  /usr/lib/policykit-1/polkit-agent-helper-1 is setuid and last time I looked, I think it verifies that setuid is set?  Maybe I'm wrong that it verifies, and we could try faking it...
[19:17] <jdstrand> mterry: also, it is possible to ship a snap with a setuid binary. it will fail review, but there is a way to override that
[19:17] <mterry> jdstrand: not my favorite path but sure  :)
[19:20] <jdstrand> mterry: from the security team notes: http://paste.ubuntu.com/23554639/
[19:22] <jdstrand> seems it is only needed for password prompts. since iirc Touch didn't have any of those, you could probably skip it. But you'd need to be sure to undo this once you added password prompts
[19:23] <mterry> jdstrand: well we only don't have password prompts in Touch because we added a lot of polkit policy files that said "don't ask for a password if the phablet user makes this call"
[19:23] <mterry> I'm not sure we want to go down that route again
[19:27] <jdstrand> mterry: that's a fair observation. I commented in the bug
[19:38] <jdstrand> mterry: you might refresh-- I made two more comments
[19:40] <mterry> jdstrand: guh I don't like supporting both classic and all-snap in one  :(
[19:40] <jdstrand> I would imagine you wouldn't
[19:40] <mterry> :)
[19:40] <jdstrand> :)
[19:41] <mterry> jdstrand: it might be a better use of eng resources on my side to not implement any of the workarounds until a bit more guidance comes from you snappy folks -- u8 isn't broken without this, we just can't install more snaps through the ui.  But I'll leave that to product folks to decide
[19:42] <mterry> let me put that in the bug
[19:43] <jdstrand> mterry: note, I'm not tasked with this. like you, would need product folks to bubble that up. it probably isn't on the snappy team's radar either, so that stakeholder meeting would need to include Ja mieBennett, rat liff and whoever from your side and product
[19:44] <mterry> jdstrand: got it.  Thanks for the comments!
[19:44] <jdstrand> np!
[19:45] <mup> Bug #1645841 opened: Separate Signature Keys topic from Image Building flow <Snappy:New> <https://launchpad.net/bugs/1645841>
[20:07] <jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/2366#discussion_r90101320
[20:07] <mup> PR snapd#2366: interfaces: apparmor support for classic confinement <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2366>
[20:39] <mup> Bug #1559248 changed: Support unversioned data directory (i.e. data shared between versions) <Snappy Launcher:Invalid by kyrofa> <Snappy:Fix Released by kyrofa> <https://launchpad.net/bugs/1559248>
[21:54] <mup> PR snapcraft#934 opened: Migrate from xdelta to xdelta3 <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/934>
[22:01] <zyga> jdstrand: thanks, checking
[22:03] <mup> PR snapcraft#935 opened: Utilize MakePlugin build logic within CMakePlugin. (LP: #1645853) <Created by larryprice> <https://github.com/snapcore/snapcraft/pull/935>