[00:45] <robert_ancell> Is there a method for system services to own (system) D-Bus names or is this the same problem as for sessions? i.e. bug 1590679
[00:45] <mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
[02:13] <mup> PR snapcraft#927 closed: Add a test script to build external snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/927>
[03:12] <mup> Bug #1645961 opened: Snapd generates a wrong udev rule for i2c devices <Snappy:New> <https://launchpad.net/bugs/1645961>
[06:40] <mup> Bug #1627175 changed: RPi3 with only HDMI attached never shows subiquity <Snappy:Fix Released by ogra> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1627175>
[06:43] <mup> Bug #1626121 changed: strict mode snaps crash with Segmentation fault on 16.10 <Snappy Launcher:Invalid> <Snapcraft:New> <Snappy:Fix Released by jdstrand> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1626121>
[07:10] <mup> Bug #1624676 changed: ERROR cannot remove snap file "kicad-dev-snap", will retry in 3 mins: umount: /snap/kicad-dev-snap/x6: mountpoint not found <Snappy:Fix Released> <https://launchpad.net/bugs/1624676>
[07:16] <mup> Bug #1623897 changed: console-conf should show if wired interfaces are connected <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1623897>
[07:16] <mup> Bug #1624329 changed: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1624329>
[07:25] <mup> Bug #1628193 changed: please set TMPDIR=/tmp when launching snaps <Snappy:Fix Released> <snap-confine (Ubuntu):Fix Released> <https://launchpad.net/bugs/1628193>
[07:25] <mup> Bug #1628289 changed: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Fix Released> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
[07:28] <mup> Bug #1628357 changed: A deamon fails with: No home directory found <Snappy:Fix Released> <https://launchpad.net/bugs/1628357>
[07:28] <mup> Bug #1628559 changed: Can't install more than 1 package in one command <Snappy:Fix Released> <https://launchpad.net/bugs/1628559>
[07:28] <mup> Bug #1628640 changed: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Triaged by facundo> <https://launchpad.net/bugs/1628640>
[07:29] <foxmask> bonjello
[07:31] <mup> Bug #1630036 changed: auto import of assertions fails for devices present at boot <Snappy:Fix Released> <https://launchpad.net/bugs/1630036>
[07:38] <mup> Bug #1630520 changed: snap login error message incorrect <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1630520>
[07:38] <mup> Bug #1630586 changed: Pi3 kernel crash and is unreliable <patch> <Snappy:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1630586>
[07:38] <mup> Bug #1630652 changed: snap revert and refresh forwards and backwards causes breakage <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1630652>
[07:41] <mup> Bug #1631159 changed: No way to simply list available snaps via snapd <Canonical System Image:New> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1631159>
[07:44] <mup> Bug #1632305 changed: console-conf cannot be used twice <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1632305>
[07:52] <dholbach> hey hey
[07:53] <mup> Bug #1632336 changed: after first boot /var/lib/snapd/seed/snaps is empty <Snappy:Fix Released> <https://launchpad.net/bugs/1632336>
[07:53] <mup> Bug #1632337 changed: dragonboard beta3 image reboots during snap create-user <Snappy:Fix Released> <https://launchpad.net/bugs/1632337>
[07:59] <mup> Bug #1634089 changed: Cannot activate Chinese input method for Qt app <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1634089>
[08:01] <seb128> hey dholbach!
[08:02] <dholbach> salut seb128
[08:02] <mup> Bug # changed: 1634730, 1634775, 1634822, 1634880
[08:03] <seb128> that bot should tell what the bugs are, giving random numbers as changed is not that useful
[08:04] <didrocks> bingo!
[08:04] <didrocks> seb128: no no, it can be useful :)
[08:04] <mup> PR snapd#2379 opened: snap: remove unused experimental command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2379>
[08:05] <mup> Bug #1634909 changed: Disabling pc||pc-kernel||core should give a warning message <Snappy:Fix Released> <https://launchpad.net/bugs/1634909>
[08:08] <mup> PR snapd#2380 opened: debian: add missing ca-certificates dependency <Created by mvo5> <https://github.com/snapcore/snapd/pull/2380>
[08:08] <abeato> woodrowshen, hi, I  saw you created an alsa-utils package, where could I find the sources?
[08:10] <woodrowshen> abeato: oh, https://github.com/woodrow-shen/snapcraft-alsa-utils/blob/master/snapcraft.yaml
[08:10] <abeato> woodrowshen, awesome, thanks
[08:10] <woodrowshen> abeato: i didn't use interface yet
[08:11] <abeato> woodrowshen, so this for installing with --devmode?
[08:11] <woodrowshen> abeato: yes
[08:11] <abeato> oh, I see
[08:14] <longsleep> So anyone can point me to someone who might be able to help me fix the "Key registration failed: The account-key-request assertion is not valid." - i am not able to register-key any key with snapcraft and my account :/
[08:20] <stub> Are snappy updates being backported to Trusty? I'm interested in some 2.18 fixes in Trusty and Xenial.
[08:25] <mup> PR snapd#2381 opened: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL <Created by mvo5> <https://github.com/snapcore/snapd/pull/2381>
[08:29] <mup> Bug # changed: 1636023, 1636383, 1636419, 1636421
[08:35] <mup> Bug #1636764 changed: Snapd is not correctly initialized with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 and model assertion is invalid <Snappy:Won't Fix> <https://launchpad.net/bugs/1636764>
[08:38] <mup> Bug #1636864 changed: ubuntu-image 0.10+real1 requires sudo <Snappy:Fix Released> <https://launchpad.net/bugs/1636864>
[08:38] <mup> Bug #1636894 changed: [raspberry pi3]pi3 snap is removable  <Snappy:Fix Released> <https://launchpad.net/bugs/1636894>
[08:41] <mup> Bug #1637981 changed: failed snap refresh removes security profiles <Snappy:Fix Released> <https://launchpad.net/bugs/1637981>
[08:44] <mup> Bug #1638656 changed: snapd testsuite fails when run inside an lxd container <Snappy:Fix Released> <https://launchpad.net/bugs/1638656>
[08:44] <mup> Bug #1638798 changed: mir server process goes defunct when a mir client attaches under confinement <Snappy:Fix Released> <https://launchpad.net/bugs/1638798>
[08:47] <mup> Bug #1639234 changed: docs/rest has not url for install (refresh, revert, remove) example <Snappy:Fix Released> <https://launchpad.net/bugs/1639234>
[08:50] <mup> Bug #1639614 changed: Sandbox denials with snap using thumbnailer <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1639614>
[08:54] <kalikiana_> stub: I expect trusty will get backports, considering new interfaces that's pretty much required anyway to run all (new) snaps in the long term
[08:54] <kalikiana_> I'm not sure, though, if that's documented somewhere
[08:54] <kalikiana_> Or in what cadence
[08:58] <mup> PR snapd#2382 opened: snap: Improve `snap --help` output as designed by Mark <Created by mvo5> <https://github.com/snapcore/snapd/pull/2382>
[09:13] <abeato> woodrowshen, how did you test the alsa snap? I'm trying with a kvm machine using "-soundhw hda", and I get these errors when using aplay: http://paste.ubuntu.com/23557271/
[09:16] <mup> PR snapd#2383 opened: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <https://github.com/snapcore/snapd/pull/2383>
[09:19] <mup> PR snapd#2215 closed: tests: spread system user autoimport <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2215>
[09:25] <woodrowshen> abeato: oh, yes, it seems to have /usr/share/alsa/alsa.conf
[09:25] <woodrowshen> abeato: from libasound2-data
[09:26] <woodrowshen> abeato: for early stage, i hacked os snap to workaround it ...
[09:26] <abeato> woodrowshen, you copied the alsa.conf file around, isn't it?
[09:27] <woodrowshen> abeato: right
[09:27] <abeato> noted, thanks
[09:27] <mup> PR snapd#2384 opened: snap: add snap size, description and provided apps to `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2384>
[09:27] <woodrowshen> abeato: np
[09:48] <sil2100> Hey! When running snap prepare-image (through ubuntu-image) I get a sha3-384 mismatch when downloading core
[09:48] <sil2100> Yesterday it worked fine, although then I was getting a similar mismatch when downloading pc-kernel IIRC
[09:49] <sil2100> Is this a known problem?
[09:49] <sil2100> error: sha3-384 mismatch downloading core: got 4ebcade07da9a4d1dfc822efdb300997fd17f5fdd3e91fd0036bb1479fba2ff586cd672b04933d396b2734c57f949c30 but expected 536b4e3795ae66f1962567ce6f129eb979d08054aed874c40772c39b30222dd535e8739769af0e81e794b2136e05adbe
[09:49] <mup> PR snapd#2385 opened: daemon, strutil: move daemon.quotedNames to strutil.Quoted <Created by chipaca> <https://github.com/snapcore/snapd/pull/2385>
[09:53] <sil2100> I'm using snapd 2.17.1
[09:55] <zyga> sil2100: no, can you please report it!
[09:55] <sil2100> On it!
[09:56] <mvo> sil2100: anything in syslog that indicates that there was some retry or something?
[10:00] <mup> PR snapd#2346 closed: Misc libvirt fixes <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapd/pull/2346>
[10:01] <mup> PR snapd#2276 closed: Add openvswitch-support interface <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapd/pull/2276>
[10:02] <sil2100> mvo: nothing, but actually after trying now hm, both core and pc-kernel went fine through
[10:02] <ogra_> sil2100, do you use the canonical VPN ? (due to the recent router attacks mine died a few times since monday without notice)
[10:02] <sil2100> I remember trying to run the same command at least 4 times yesterday and getting mismatches for pc-kernel
[10:02] <sil2100> While now it just succeeded after a re-run
[10:02] <sil2100> Strange
[10:04] <sil2100> Anyway, seems like a false alarm, sorry for the noise
[10:06] <ogra_> hmm, i'm getting a lot of 504 errors on launchpad
[10:06] <ogra_> seems you are not alone
[10:07] <ogra_> err, from the store, sorry ...
[10:07] <mup> PR snapd#2386 opened: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <https://github.com/snapcore/snapd/pull/2386>
[10:08] <zyga> ogra_: hey ogra, how are you
[10:08] <zyga> ogra_: I did some of the things we talked about, please have a look at github.com/snapcore now
[10:08] <zyga> ogra_: I've done the lauchpad project for pi2 so far (snap-pi2), I'll make the rest next
[10:08] <ogra_> zyga, trying to find out why core failed to upload tonights builds :P
[10:08] <zyga> ogra_: pi2 is set so that each commit that lands on master gets pushed to the store
[10:09] <zyga> ogra_: I'll patch all the gadgets to have a skeleton snapcraft.yaml with dump plugin
[10:09] <ogra_> zyga, hmm, i thought you would create a master project for that under snapcore
[10:09] <ogra_> like snapcore/gadgets/$arch
[10:10] <ogra_> alternatively probably putting "gadget-" in the branch name might make sense
[10:11] <ogra_> they kind of vanish in the amount of stuff thats already there
[10:11] <ogra_> (and i guess that will become more)
[10:12] <ogra_> also, while we're moving we should probably also drop "generic-" from the x86 arches
[10:12] <ogra_> in the store they are called pc or pc-i386
[10:15] <zyga> ogra_: on github there are no projects, jsut repositories
[10:16] <zyga> ogra_: in the store both pc gadgets are just called "pc"
[10:16] <zyga> ogra_: once we build more from source we can unify them and drop one
[10:16] <zyga> ogra_: but now we cannot since we need two snapcraft.yaml's that are different
[10:16] <zyga> ogra_: in the end we'll get only four gadgets, pc, pi2, pi3 and dragonboard
[10:16] <zyga> ogra_: but now the pc one has two repos because that's how we need to do it
[10:21] <ogra_> zyga, i'm not talking about merging them but making them better discoverable in the amount of projects there
[10:21] <ogra_> s/projects/branches/
[10:21] <ogra_> and about dropping the "generic"
[10:22] <ogra_> "<ogra_> alternatively probably putting "gadget-" in the branch name might make sense"
[10:22] <ogra_> i find them hard to discover already and there are not many branches under snapcore yet ... in a year that will have doubled
[10:23] <zyga> ogra_: I wanted to match the snap name, we can do that gadget- prefix later (once slangasek owns those, it's just a rename button)
[10:23] <zyga> ogra_: note: those are repos, not branches
[10:23] <ogra_> ok
[10:23] <ogra_> "things"
[10:23] <ogra_> :P
[10:23] <zyga> ogra_: we don't want to add all the gadgets there, just the ones that we support
[10:23] <ogra_> yes
[10:23] <zyga> ogra_: and snap-confine will go away so we'll have less things there
[10:24] <zyga> ogra_: note that you won't see branches, this is essential, you won't see 12s of forks and branches from other people
[10:24] <ogra_> yes, i have used github before :)
[10:26] <zyga> ogra_: sorry, I was just trying to explain how this might look like
[10:26] <ogra_> yeah, no worries :)
[10:26] <zyga> ogra_: ok, now for the publishing pipeline
[10:26] <mup> PR snapd#2385 closed: daemon, strutil: move daemon.quotedNames to strutil.Quoted <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2385>
[10:27] <zyga> tyhicks, jdstrand: could you please review https://github.com/snapcore/snap-confine/pull/189/files -- it is the next one in the apparmor support series, (I've merged it after improvements suggestef by tyler)
[10:27] <mup> PR snap-confine#189: Use apparmor-support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/189>
[10:36] <ogra_> mvo, danm !
[10:36] <ogra_> *damn even
[10:36] <mvo> ogra_: hu?
[10:36] <ogra_> mvo, i'll have to revert your change to bug 1639878
[10:36] <mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <Snappy:Fix Committed by ogra> <https://launchpad.net/bugs/1639878>
[10:36] <mvo> ogra_: why?
[10:37] <ogra_> i'm in the middle if re-working pre-arch modules
[10:37] <ogra_> *per
[10:37] <ogra_> because our initrd gets to big
[10:37] <ogra_> we really dont want the virt stuff on arm
[10:37] <mvo> ogra_: I don't see this module on arm
[10:38] <ogra_> on which arm do you look ?   :)
[10:38] <ogra_> (the generic kernel has it)
[10:38] <mvo> ogra_: pi2, the only one I have
[10:38] <ogra_> right, there we dont build it
[10:39] <ogra_> anyway, i'm already working on a fix and should have it ready later today
[10:39] <ogra_> (there are a bunch of others like virtio that need to go)
[10:39] <mvo> ogra_: *shurg* its 28kb (the hv_storsvc) and 96kb (the hv_vmbus). but yeah, go ahead if thats too big
[10:40] <ogra_> its not about to big but about loading them forcefully ... check lsmod on your rpi
[10:40] <ogra_> they eat ram
[10:41] <mvo> ogra_: we are loading them forcefully? that sounds not ideal, why is that?
[10:41] <ogra_> (we use MODULE=list in the initrd)
[10:41] <ogra_> to keep the number small, thats the only way, all others load a lot of default stuff we dont need and thats megabytes
[10:42] <mvo> ogra_: I get "no such device" when trying to load it here on my machine, so it seems like it will not get loading if not in a hv env?
[10:42] <mvo> ogra_: I don't disagree to fix all that, don't get me wrong
[10:43] <mvo> ogra_: this upload was a drive-by from bug triage and it was less work to fix it than to write the comment about the status etc. and AFAICT it does not harm you in any way, the rework will just superseed it, or am I missing something?
[10:43] <ogra_> mvo, indeed
[10:44] <ogra_> mvo, on another note ... how about we get rid of /etc/system-image and move writable-paths one level up for one of the next releases ?
[10:44] <ogra_> we dont ship the package anymore and the path is an anachronism
[10:44] <mup> PR snapd#2342 closed: client: use typed snap.ConfinementType <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2342>
[10:45] <mvo> ogra_: that makes sense, yes, its slight ugly as it is right now
[10:45] <ogra_> yup
[10:45] <mup> PR snapd#2387 opened: asserts: introduce top-commands header in snap-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2387>
[10:46] <ogra_> not really high prio but it makes me itch every time i have to touch it
[10:47] <mvo> +1
[11:00] <zyga> ogra_, mvo: https://github.com/snapcore/pi2/pull/1
[11:00] <mup> PR pi2#1: Improve the README file <Created by zyga> <https://github.com/snapcore/pi2/pull/1>
[11:01] <ogra_> zyga, perhaps we should have a "BUILDING" file for the old content
[11:02] <ogra_> (which could also point to sources etc and have some more info on where the binaries come from(
[11:04] <zyga> ogra_: for the mkvenvimage line?
[11:04] <ogra_> yeah, it is highly important for oporters to know about it
[11:04] <zyga> ogra_: can you propose that please? I'm sure you'd be more accurate than I am
[11:04] <ogra_> *porters
[11:05] <zyga> ogra_: let's land this branch and iterate
[11:05] <ogra_> though ...
[11:05] <zyga> ogra_: I'll make the snapcraft.yaml with dump plugin now
[11:05] <ogra_> we could switch to the make plugin and simply automate it i guess
[11:05] <zyga> ogra_: :D
[11:05] <zyga> ogra_: I'll do the naive dump plugin
[11:05] <zyga> ogra_: and let you improve, ok?
[11:05] <ogra_> yeah, start with that
[11:05] <zyga> ok!
[11:05] <ogra_> :D
[11:15] <mup> PR snapd#2373 closed: debian: remove unneeded conflict against the "snappy" package <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2373>
[11:22] <gerry_> hi all, I am using the jdk plugin but I need the headers how do I do this?
[11:22] <mup> PR snapd#2379 closed: snap: remove unused experimental command <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2379>
[11:23] <zyga> ogra_, mvo, slangasek: https://github.com/snapcore/pi2/pull/2
[11:23] <mup> PR pi2#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi2/pull/2>
[11:23] <zyga> sergiusens: ^^
[11:24] <zyga> sergiusens: I found a bug in snapcraft, I think, building that with snapcraft twice results in an odd error message about meta/gadget.yam
[11:24] <ogra_> zyga, why didnt you keep the boot-assets" name
[11:24] <zyga> ogra_: I did, it's a subdirectory there
[11:24] <ogra_> oh, sorry
[11:24] <zyga> ogra_: I didn't try booting with that
[11:25] <zyga> ogra_: but the prime/ directory looks identical to the old tree, except for meta/gui/icon.png
[11:27] <ogra_> well, as long as the bits land in boot-assets later all is fine
[11:28] <sergiusens> zyga we deal with bugs through bug reports if you are so sure of it ;-)
[11:30] <zyga> ogra_: can you review it please then
[11:30] <zyga> sergiusens: let me file it quickly :)
[11:32] <zyga> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1646081
[11:32] <mup> Bug #1646081: Gadget snap cannot be built twice <Snapcraft:New> <https://launchpad.net/bugs/1646081>
[11:34] <zyga> sergiusens: does that look sensible?
[11:34] <zyga> sergiusens: I found this on the following pull request: https://github.com/snapcore/pi2/pull/2
[11:34] <mup> PR pi2#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi2/pull/2>
[11:34] <zyga> sergiusens: and btw, since you are here, where should the icon be? am I doing the right thing with setup/gui/icon.png?
[11:36] <zyga> ogra_: I'm waiting for your comment there, if you +1 it we can land it :)
[11:37] <zyga> ogra_: thanks! merged
[11:37] <zyga> ogra_: so now about that makefile part
[11:37] <zyga> ogra_: do you think we should also copy the licenses?
[11:38] <ogra_> dont we do that ? yes, we should
[11:38] <ogra_> like they are upstream
[11:40] <sergiusens> zyga yes, but you can use the dedeprecated `icon` entry to get rid of `setup`
[11:40] <zyga> ogra_: ok, let me fix that
[11:41] <zyga> sergiusens: how can I read about filesets or organize help?
[11:41] <zyga> sergiusens: how can I cope three license files from the root of the project, I tried the copy and dump plugins but my attempts didn't work
[11:42] <zyga> ah
[11:42] <zyga> sorry, there's a typo in the tree itself :)
[11:44] <zyga> ogra_, sergiusens: https://github.com/snapcore/pi2/pull/3
[11:44] <mup> PR pi2#3: Copy licenses to the snap <Created by zyga> <https://github.com/snapcore/pi2/pull/3>
[11:44] <zyga> ogra_: shall I correct the LICENSE vs LICENCE typo?
[11:45] <ogra_> zyga, well, thats also from upstream :)
[11:45] <popey> is it possible to just point to a deb url in a snapcraft yaml?
[11:45] <ogra_> however you feel like ;)
[11:45] <popey> to pull in a pre-built deb and unpack it?
[11:45] <zyga> ogra_: ok, I'll leave it as-is then
[11:47] <ogra_> popey, https://github.com/ogra1/laidout is one way
[11:47] <ogra_> (see the Makefile)
[11:48] <popey> ta
[11:48] <popey> oh
[11:48] <popey> that's icky, can we not just source: foo.deb ?
[11:48] <ogra_> well, it is old ... perhaps we can now :)
[11:48] <popey> ok
[11:48] <popey> :)
[11:48] <ogra_> thats a sergiusens question
[11:49] <mup> Bug #1646085 opened: snapd-interface access to /usr/bin/infocmp denied <Snappy:New> <https://launchpad.net/bugs/1646085>
[11:49] <popey> what I really want is access to a 3rd party archive in a cleanbuild
[11:49] <gerry_> hi when I run snappy-debug and run my app with sudo I get "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" can anybody tell me how to do this?
[11:52] <zyga> ogra_: https://github.com/snapcore/pi2/pull/4
[11:52] <mup> PR pi2#4: Add URL to launchpad build history <Created by zyga> <https://github.com/snapcore/pi2/pull/4>
[11:52] <zyga> gerry_: it probably means that the appliaction tries to touch files that are not owned by root but the process dones't have CAP_DAC_OVERRIDE which typical root processes have
[11:53] <zyga> gerry_: if you use sudo you'd have to make those files root owned (probaly something in ~/snap/$SNAP_NAME but I may be wrong)
[11:58] <gerry_> zyga: thank you for your help the app works when I run it without sudo it crashes when I use sudo with an exception
[11:58] <zyga> do you need to run it with sudo?
[11:59] <zyga> ogra_: I just requested a manual build
[11:59] <zyga> ogra_: if all goes well it will end up in edge :)
[11:59] <zyga> ogra_: and if not we can work with mvo on store side permission
[11:59] <gerry_> yes because when I upload it to the ubuntu store it does not get loaded into software
[11:59] <zyga> gerry_: what do you mean by "it does not get loaded into software"
[11:59] <ogra_> zyga, i could add you if i could reach the store ... seems it isnt liking me today ... getting 504s
[12:00] <zyga> ogra_: yeah, the store has hicckups today
[12:00] <zyga> hic-hic-hic-hic
[12:00] <zyga> or more rather
[12:00] <zyga> hic-hic-504-hic
[12:00] <ogra_> heh, it seems to be one very looong hick .... and no "up" at all for me
[12:01] <zyga> sergiusens: hey, can you suggest how we can use the dump plugin for this: ?
[12:01] <zyga> sergiusens: https://github.com/snapcore/pi2/blob/master/snapcraft.yaml#L15
[12:01] <gerry_> zyga : the gnome-software library I can see it when it is listed in the installed apps but does not get listed in the "wild"
[12:01] <zyga> gerry_: ah, I think this is a separate bug
[12:01] <zyga> gerry_: how does using sudo helps?
[12:02] <gerry_> zyga: I was told it had to work with sudo to be accepted
[12:02] <zyga> gerry_: who told you that?
[12:02] <gerry_> somebody on here didrocks
[12:03] <zyga> didrocks: can you tell me more about this please?
[12:06] <zyga> ogra_, mvo: can you guys please add me to the pi2 gadget snap in the store, if you can?
[12:06] <ogra_> if i could :P
[12:07] <ogra_> i cant even get the front page of myapps.d.u.c
[12:07] <ogra_> 504 Gateway Time-out
[12:07] <ogra_> The server didn't respond in time.
[12:07] <ogra_> ...
[12:08] <ogra_> oh, a new message !
[12:08] <ogra_> We're currently experiencing some difficulties
[12:08] <ogra_> Sorry, it looks like we're experiencing a problem with this service. We'll be investigating shortly.
[12:08] <ogra_> ... so that i dont get bored :P
[12:09] <zyga> thanks for checking
[12:10] <didrocks> hum? I didn't say to use sudo AFAIK
[12:10] <didrocks> gerry_: not sure where this is coming from, are you mixing with the permissions issues you had? ^
[12:10] <didrocks> zyga: ^
[12:11] <didrocks> scrolling back -> gnome software
[12:11] <didrocks> yeah, I did tell you that for now, you will only see snaps in gnome software if you use sudo AFAIK
[12:11] <didrocks> sudo to start gnome software
[12:11] <didrocks> nothing to do with your snaps
[12:11] <didrocks> (there is a permission mismatch in snapd/gnome-software)
[12:12] <zyga> gerry_: please don't worry about this, it will get fixed in gnome-software
[12:12] <didrocks> yeah, but gerry_ wanted to see his snap right now, hence this solution
[12:12] <zyga> gerry_: you should be able to just find the launcher of your app from dash/gnome-shell
[12:12] <zyga> gerry_: and it should run when started from that location
[12:13] <gerry_> zyga: yes I can run it locally but my ultimate aim was to have it included in gnome-software
[12:15] <zyga> ogra_: https://github.com/snapcore/pi3/pull/1
[12:15] <mup> PR pi3#1: Improve the README file <Created by zyga> <https://github.com/snapcore/pi3/pull/1>
[12:19] <ogra_> oh, hello store !
[12:20] <zyga> ogra_: https://github.com/snapcore/pi3/pull/2 :)
[12:20] <mup> PR pi3#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pi3/pull/2>
[12:22] <ogra_> zyga, you should have three invite mails from the store...
[12:23] <gerry_> zyga, didrocks: sorry I am a little confused now have I still to continue looking for an answer to my sudo problem?
[12:23] <zyga> ogra_: thank you
[12:23] <zyga> gerry_: no, unless you expect your users to use sudo on a daily basis
[12:24] <zyga> ogra_: you should have invites to the repos
[12:24] <ogra_> two for now, yeah
[12:25] <gerry_> zyga: so now I just need to find out why it has not been included in gnome-software? thank you very much and sorry I am such a pain
[12:25] <didrocks> gerry_: it does show up in snap find, correct?
[12:25] <didrocks> your snap
[12:26] <zyga> gerry_: does it show up in the dash when you search for it?
[12:26] <zyga> gerry_: is the desktop file in /var/lib/snapd/desktop/applications/ what you'd expect?
[12:26] <zyga> gerry_: if so, you are good
[12:27] <zyga> ogra_: ok, got it, I'll triggere another build of pi2 so that it can get published
[12:28] <zyga> ogra_: let's do dragon next, it doesn't have the PC problem
[12:28] <gerry_> I am using gnome desktop where it shows up as a menu selection and it shows up in gnome-software as an installed app
[12:28] <ogra_> oh, dragon ...
[12:29] <ogra_> forgot that one ... invite sent
[12:29] <gerry_> just when I search for it under "all" it is not there
[12:32] <zyga> ogra_: https://github.com/snapcore/dragonboard/pull/1
[12:32] <mup> PR dragonboard#1: Improve the README <Created by zyga> <https://github.com/snapcore/dragonboard/pull/1>
[12:32] <zyga> ogra_: got the invite, thanks
[12:36] <zyga> ogra_: so I see revision 30 in the store but it's not published automatically
[12:36] <zyga> looks like a launchpad bug?
[12:36] <zyga> https://myapps.developer.ubuntu.com/dev/click-apps/2436/rev/30/
[12:37] <zyga> cjwatson: should a snap built according to this recipe auto-publish to edge? https://code.launchpad.net/%7Ezyga/+snap/pi2
[12:37] <ogra_> zyga, yes
[12:38] <ogra_> note that it takes a while for the last step in the store
[12:38] <ogra_> (thats a cronned publisher i think)
[12:39] <ogra_> and there it published ;)
[12:40] <zyga> woooooot!
[12:40] <zyga> great
[12:41] <renato__> zyga, hey I am getting this error: http://paste.ubuntu.com/23554713/, while trying to test my new interface. What I am missing?
[12:41] <zyga> ogra_: https://github.com/snapcore/dragonboard/pull/2
[12:41] <mup> PR dragonboard#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/dragonboard/pull/2>
[12:41] <zyga> renato__: looking
[12:44] <zyga> renato__: you probably how to edit the base declaration assertion
[12:44] <zyga> renato__: look at ...
[12:45] <zyga> ah, sorry afk
[12:47] <renato__> let me check
[12:49] <renato__> zyga, http://paste.ubuntu.com/23557921/
[12:49] <sergiusens> didrocks mind helping me with `snapcraft define preload`?
[12:50] <gerry_> hi guys sorry I have another question had a look in ubuntu one and my app has the entry Tue 22 Nov. 2016 Approved. Automated review found no issue how long until it gets in gnome-software ?
[12:59] <zyga> gerry_: it's automatic it if is published into the stable channel
[13:00] <mup> PR snapd#2388 opened: make snap install/refresh/etc abort if the service does not stay active, unless --devmode is given <Created by chipaca> <https://github.com/snapcore/snapd/pull/2388>
[13:00] <gerry_> zyga: thank you nothing yet just found the little "release" button though
[13:13] <zyga> ogra_: pi3 build in progress, dragon is next but I'm waiting for the initial launchpad mirror
[13:14] <ogra_> cool
[13:15] <zzarr> hello! I'm trying to install snapd on a machine running 16.04.1, but get this error http://pastebin.com/QxCLfWE4 how do I solve it?
[13:15] <zzarr> are there a problem with the repository?
[13:15] <zzarr> I could install other packages
[13:16] <zyga> zzarr: there's a conflict there, you need to remove the snap package
[13:18] <zzarr> thanks zyga, I will do
[13:18] <zzarr> it worked, once more, thanks zyga
[13:20] <zzarr> if I install the nexctcloud snap, would that break my apache setup?
[13:21] <zyga> ogra_: dragonboard build triggered
[13:21] <ogra_> great
[13:22] <zyga> ogra_: now for pc
[13:22] <zyga> I wonder if I can cheat
[13:22] <ogra_> yay
[13:22] <zyga> merge both generic- repos into one
[13:22] <zyga> and use snapcraft.yaml to build it
[13:22] <zyga> so that there's one project that gives two working gadget snaps for both arches
[13:22] <zyga> hmmm - perhaps that's the way
[13:28] <ogra_> yeah
[13:30] <zyga> ogra_: pi2, pi3 and dragonboard are now auto-published :)
[13:30] <ogra_> yay
[13:35] <zyga> sergiusens: question about gadget.yaml
[13:36] <zyga> sergiusens: looking at amd64 and i386 gadget snaps I see differences in their gadget.yaml files
[13:36] <zyga> sergiusens: do you think we can build both snaps from one tree somehow?
[13:36] <zyga> sergiusens: or is this futile
[13:36] <zyga> zyga@xenial-server:~/snappy-hub$ diff -u generic-amd64/meta/gadget.yaml generic-i386/meta/gadget.yaml  | pastebinit
[13:36] <zyga> http://paste.ubuntu.com/23558061/
[13:38] <zyga> ogra_, slangasek ^^
[13:38] <ogra_> zyga, the diff looks right
[13:39] <ogra_> i386 doesnt have secure boot
[13:39] <ogra_> not sure how you would get that into a single snapcraft.yaml though
[13:39] <zyga> yeah, that's what I'm thinking about
[13:39] <ogra_> or rather gadget.yaml
[13:39] <zyga> if there's no way we can just accept two repos/snapcraft.yamls for now
[13:42] <gerry_> hi finally got my app uploaded to gnome-software thank for the zyga and didrocks
[13:42] <gerry_> *help
[13:43] <zyga> gerry_: that's great! glad to see your snap in the store
[13:44] <gerry_> I have another problem now when I want to remove it via the gnome-software it keeps asking me for my ubuntu one  email and password ?
[13:44] <zyga> gerry_: I think you have to login at least once to do that
[13:45] <gerry_> zyga: oh ok thanks trying that now :)
[13:59] <gerry_> zyga: I try to enter my email and password and it just says one of them is false even though I have checked it out in my browser and it logs in ok on that?
[14:06] <mhall119> does /w 79
[14:06] <gerry_> found a way started gnome-software as sudo
[14:16] <gerry_> I have another question why in gnome-software is my app have non-free written on it?
[14:16] <gerry_> *does
[14:23] <kalikiana> gerry_: non-free means nobody vetted the source code - so for a snap that's by design the case, nobody can know how it was built, as opposed to packages from the Ubuntu archive
[14:23] <kalikiana> I'll agree, though it looks ugly, it's just a technical stupidity
[14:24] <gerry_> Kalikianna: thanks for you help just one more question it does not seem to use screenshots either?
[14:32] <mup> Bug #1632390 changed: "snap find" return unrelative snap <Snappy:Opinion> <https://launchpad.net/bugs/1632390>
[14:32] <kalikiana> gerry_: It doesn't seem to be implemented yet. Not sure if there's a bug yet
[14:32] <mhall119> sergiusens: does snapcraft support ./setup/hooks/ yet? Or do you still have to put them into ./prime/meta/hook/ before the final snap step?
[14:34] <mhall119> niemeyer: zyga: related to that, has the change to run the configure hook on install & upgrade landed in the snapd archive packages?
[14:36] <didrocks> sergiusens: sorry, didn't see your ping, sure, what about it?
[14:37] <zyga> mhall119: I think we're still waiting for some stuff to get the next SRU out, mvo knows details
[14:41] <jdstrand> morphis, joc_ (cc niemeyer): hey, I was refamiliarizing myself with how serial-port, gpio, i2c and hidraw work in practice (due to responding to bug #1645445) and realized that https://github.com/snapcore/snapd/wiki/Interfaces was a bit lacking
[14:41] <mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1645445>
[14:41] <jdstrand> morphis, joc_ (cc niemeyer): so I fixed that: https://github.com/snapcore/snapd/wiki/Interfaces/_compare/0c2b18b9a98ce1a5e45d4392c05023a505072c2e...e514578237da8a4d00b38a0f6db6c1053448f764
[14:41] <jdstrand> morphis, joc_ (cc niemeyer): please let me know if I should change something
[14:43] <jdstrand> mvo: regarding 1645445, I responded. need feedback from the dev and then I can talk to Gustavo on how to advise on the next steps
[14:43] <zyga> jdstrand: o/
[14:43] <jdstrand> zyga: hey
[14:43] <zyga> jdstrand: I created a Content-Interface wiki page
[14:43] <zyga> jdstrand: I'd like to move all the interesting interfaces to sub-pages with details and link to them from the Interfaces page
[14:43] <mvo> jdstrand: thank you
[14:44] <zyga> jdstrand: thanks for your XDG_RUNTIME_DIR review, I will adjust the code as suggested
[14:44] <zyga> jdstrand: I proposed https://github.com/snapcore/snap-confine/pull/189 as a follow-up to what tyler reviewed yesterday
[14:44] <mup> PR snap-confine#189: Use apparmor-support module <Created by zyga> <https://github.com/snapcore/snap-confine/pull/189>
[14:45] <jdstrand> zyga: re Interfaces page, sounds good to me
[14:45] <jdstrand> zyga: re 189, yep saw that. re xdg, thanks!
[14:46] <abeato> sergiusens, maybe you know, how can add a user to a group in ubuntu core? --extrausers seems to be not magical enough
[14:47] <zyga> jdstrand: there was one interesting bug in i2c that was found recently
[14:47] <zyga> jdstrand: we used = instead of == in the udev rule
[14:47] <jdstrand> eek
[14:47] <zyga> jdstrand: I didn't do a pass over all of those but it feels like it slipped through review and is not CId yet
[14:47] <zyga> jdstrand: one interesting development today: look at github.com/snapcore
[14:47] <zyga> jdstrand: look for pi2, pi3 and dragonboard :)
[14:48] <zyga> jdstrand: I plan to hack on the wiki extensively tomorrow-ish
[14:49]  * ogra_ wonders why the snapcraft@ suddenly is hit by so much spam stuff 
[14:49] <ogra_> is that only me ?
[14:49] <abeato> not only you, not
[14:50] <zyga> ogra_: we've noticed, taking action
[14:50] <ogra_> thx
[14:50] <zyga> my inbox was beeping like a timer ;)
[14:50] <jdstrand> zyga: oh, that is handy. cool :)
[14:50] <zyga> jdstrand: PC is the last to go because of two arches sharing snap name but I'll get it supported if I can
[14:51] <jdstrand> ogra_: you may have an answer for abeato ^
[14:51] <zyga> jdstrand: also a place to report bugs (on the LP mirror projects)
[14:51]  * ogra_ reads backlog
[14:51] <jdstrand> interestingly, I *just* made a comment about group membership in bug #1645445
[14:51] <mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1645445>
[14:51] <abeato> ogra_, about adding a user to a group :)
[14:51] <ogra_> abeato, hmm, addgroup with --extrausers doesnt work ?
[14:51] <ogra_> err
[14:51] <ogra_> adduser
[14:52] <ogra_> adduser --extrausers ogra newgroup
[14:52] <ogra_> something like that
[14:52] <abeato> ogra_, http://paste.ubuntu.com/23558361/
[14:52] <ogra_> (newgroup being the name of the group)
[14:52] <ogra_> hmm, that should work
[14:53] <ogra_> abeato, oh
[14:53] <ogra_> you are trying to add the user to a group that lives in /etc/group
[14:53] <ogra_> so that cant work
[14:54] <abeato> ogra_, :(
[14:54] <abeato> ogra_, should not that be possible? is this a bug?
[14:54] <ogra_> we'd have to move that group to /var/lib/extrausers ... though the audio group is deprecated since half a decade now
[14:55] <jdstrand> ogra_: dialout came up in 1645445
[14:55] <abeato> ogra_, /dev/snd/ stuff has that group
[14:55] <ogra_> jdstrand, well, we cant really make these system groups dnyamic ... that will break the filesystems badly
[14:55] <mup> PR snapd#2364 closed: overlord: increase test timeout and improve failure message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2364>
[14:56] <jdstrand> ogra_: we need a solution for device permissions and users. maybe it is simply that we have snap.dialout and snap.audio and snapd's udev rules does that instead
[14:56] <ogra_> abeato, yes, but you should only access it through a sound daemon
[14:57] <jdstrand> ogra_: I think groups are still useful on all snaps, but it needs design
[14:57] <ogra_> jdstrand, that might work ... the prob is that the GIDs are immovable due to readonly/readwrite merges
[14:58] <rvr> Spam on snapcraft mailing list :(
[14:58] <jdstrand> ogra_: I was thinking snapd.dialout is an extrausers group. that suffers from the merge problem?
[14:58] <ogra_> which is why the system groups are all sitting in /etc/group
[14:58] <ogra_> jdstrand, the issue is the GID ... would an additional rgoup help at all ?
[14:59] <ogra_> the device node would still be owned by audio ... and potential homedirs of a daemon too ...
[14:59] <jdstrand> well, that is tricky. we don't want to change all dialout to snap.dialout cause that might break core
[14:59] <ogra_> if you now change GIDs the filesystem ownership breaks
[14:59] <jdstrand> yeah
[14:59] <jdstrand> hrm
[14:59] <ogra_> you would have to update the GID ownership on every boot ...
[14:59] <zyga> ogra_: https://github.com/snapcore/generic-amd64/pull/1/files
[14:59] <mup> PR generic-amd64#1: Add initial README.md file <Created by zyga> <https://github.com/snapcore/generic-amd64/pull/1>
[14:59] <ogra_> walking the whole fs
[14:59] <zyga> ogra_: I will do two github repos but one launchpad project with two git mirrors there
[15:00] <zyga> ogra_: and they will both build to the "pc" snap
[15:00] <ogra_> zyga, sounds good ... i'd still prefer pc and pc-i386 as names though :)
[15:00] <zyga> ogra_: yeah, maybe once we implement generic rename support we can do that
[15:00] <zyga> ogra_: do you want to rename the repos?
[15:00] <zyga> ogra_: this is free now
[15:00] <ogra_> generic is a 15.04 name we forcefully dropped everywhere (except in that branch because nobody cared)
[15:00] <zyga> ok
[15:00] <zyga> I'll do that
[15:00] <zyga> pc-$ARCH
[15:01] <niemeyer> jdstrand: Thanks for the wiki improvements
[15:01] <ogra_> thanks:)
[15:02] <abeato> ownership stuff can get tricky, what I am doing is playing with a confined aplayer, in the end I have to do: "sudo alsa-utils.aplay /root/enter.wav" when I have alsa and home interfaces connected... you have to do sudo *and have a file in /root/ folder* to play something
[15:02] <jdstrand> ogra_: it seems extrausers and the system group issue is that what we have isn't smart enough. it seems like an artificial limitation of the implementation that an extrauser can't be added to a system group. perhaps snappy needs an updated nss module that can handle that
[15:02] <abeato> addinng my user to the audio group would help a bit
[15:02] <ogra_> jdstrand, well, i wont hold you back :P
[15:03] <ogra_> abeato, device ownerships should be handled by udev ACLs nowadays
[15:03] <ogra_> (since years actually)
[15:03] <jdstrand> hrm
[15:03] <zyga> ogra_: https://github.com/snapcore/pc-amd64 and https://github.com/snapcore/pc-i386
[15:03] <jdstrand> it needs design
[15:03] <jdstrand> but seems possible
[15:03] <jdstrand> it also needs someone assigned to it
[15:03] <ogra_> jdstrand, and you think we cant do it via ACLs like we do oon the desktop since ages ?
[15:04] <abeato> ogra_, ok, I will try with an ACL, is that possible in ubuntu core?
[15:04] <ogra_> iirc we dropped the audio group membership for default users in 10.04 or 12.04 in favour of ACLs
[15:04] <zyga> ogra_: how does it work with ACLs?
[15:05] <ogra_> abeato, perhaps not without changes to core ... but i think if possible we should use them
[15:05] <zyga> ogra_: and wich users should get access? (if the ACLs relate to users, I don't know)
[15:05] <ogra_> zyga, now i'd say thats a pitti question ... but i guess we need to start getting along alone ... (he implemented that IIRC)
[15:05] <zyga> ogra_: is that documented anywhere?
[15:05] <ogra_> zyga, logind manages the access
[15:06] <zyga> ogra_: (and let's land https://github.com/snapcore/pc-amd64/pull/1/files unless you want to tweak wording)
[15:06] <mup> PR pc-amd64#1: Add initial README.md file <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/1>
[15:08] <ogra_> abeato, "getfacl /dev/snd/controlC0 | grep -Eo "user:.+:" | cut -d: -f2" ...
[15:08] <ogra_> that should return your username if you have acl access to the sound device ... independent from the audio group
[15:08] <zyga> ogra_: so for services (root) this is irrelevant but fro users that log in we could useit
[15:08] <jdstrand> ogra_: maybe. I see only one setfacl in /lib/udev/rules.d
[15:09] <ogra_> the above command clearly retuns ogra on all my desktop installs
[15:09] <ogra_> so we should make sure this works on core as well
[15:09] <zyga> ogra_: does logind manage ssh logins and console logins?
[15:10] <ogra_> and at the same time:
[15:10] <ogra_> ogra@styx:~$ groups|grep audio
[15:10] <ogra_> ogra@styx:~$
[15:10] <abeato> ogra_, same for me, it shows my user, but no getfacl in core, certainly
[15:10] <ogra_> ok, file a bug ... lets first get the tools in and then see if we can make them work ;)
[15:10] <abeato> ogra_, alright, in snappy I guess?
[15:10] <ogra_> yeah
[15:11] <jdstrand> ogra_: this seems like a plausible way to handle it. yes, abeato, please file a bug
[15:11] <abeato> cool
[15:11] <ogra_> if you can ... assign to me
[15:11] <abeato> sure :)
[15:11] <jdstrand> I'm curious about the mechanism used to setfacl
[15:12] <ogra_> i think there is some buuiltin setfacl in udev somehow
[15:12] <ogra_> but pitti only explained it once to me and that was several years ago
[15:13] <ogra_> (i have forgotten most of it and need to dig into it again)
[15:13] <mup> PR snapd#2388 closed: make snap install/refresh/etc abort if the service does not stay active, unless --devmode is given <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2388>
[15:14] <ogra_> aha
[15:14] <ogra_> jdstrand, https://wiki.ubuntu.com/Audio/TheAudioGroup
[15:14] <ogra_> a little sparse but it at least explains the high level to endusers
[15:14] <pitti> ogra_: right, /lib/udev/rules.d/70-uaccess.rules tags such devices as "uaccess" and 73-seat-late.rules calsl the "uaccess" builtin
[15:15] <jdstrand> ogra_: it looks like it should be systemd these days instead of consolekit, but yeah
[15:15] <ogra_> yeah, that was it ... uaccess
[15:15] <mup> PR snapd#2382 closed: snap: Improve `snap --help` output as designed by Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2382>
[15:15] <mup> PR snapd#2383 closed: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2383>
[15:16] <ogra_> i guess fort thing is to seed acl on core :)
[15:16] <ogra_> nice .... not really a dependency chain ... thats easy
[15:17] <ogra_> s/fort/first/
[15:17] <zyga> ogra_: https://github.com/snapcore/pc-amd64/pull/2
[15:17] <mup> PR pc-amd64#2: Add naive snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/2>
[15:17] <zyga> ogra_: it feels like licenses are missing
[15:17] <ogra_> zyga, what licenses ?
[15:18] <zyga> ogra_: and it would bew nice to have some gardening of the wording in snapcraft.yaml
[15:18] <jdstrand> ogra_: huh. with all the uaccess rules already there and systemd already in place, I'm curious if that is all you have to do...
[15:18] <zyga> well, for those binaries we are shipping now :)
[15:18] <ogra_> jdstrand, probably ... lets see :)
[15:18] <ogra_> zyga, well, they are built from ubuntu archive source for these arches
[15:18] <jdstrand> ogra_: that would literally be the best outcome imaginable :)
[15:18] <ogra_> yeah :)
[15:19] <ogra_> zyga, the licenses in the pi and dragonboard gadgets are only for the binary blobs we can not control and come as-is from upstream ...
[15:20] <ogra_> we ship a copy of the GPL in core ... so thats all fine for the gadgets that come completely from source
[15:21] <abeato> ogra_, https://bugs.launchpad.net/snappy/+bug/1646144 . I cannot assign, so feel free to auto-assign ;)
[15:21] <mup> Bug #1646144: ACLs to devices need to be supported in core  <Snappy:New> <https://launchpad.net/bugs/1646144>
[15:21] <ogra_> merci !
[15:22] <abeato> np
[15:23] <mup> Bug #1646144 opened: ACLs to devices need to be supported in core  <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1646144>
[15:25] <mup> PR snapcraft#936 opened: nodejs: install during pull to support npm run <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/936>
[15:29] <mup> PR snapd#2375 closed: store: retry tweaks and logging <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2375>
[15:29] <zyga> cjwatson: hey, can you please suggest some lp-shell operation that would un-set the default repo from https://code.launchpad.net/snap-pc
[15:30] <zyga> cjwatson: so that it shows github-mirror-{i386,amd64} explicitly
[15:35] <zyga> ogra_: https://github.com/snapcore/pc-amd64/pull/3 and https://github.com/snapcore/pc-i386/pull/1
[15:35] <mup> PR pc-amd64#3: Correct repo URL <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/3>
[15:35] <mup> PR pc-i386#1: Add initial README.md <Created by zyga> <https://github.com/snapcore/pc-i386/pull/1>
[15:36] <zyga> thanks!
[15:36] <ogra_> np
[15:38] <zyga> ogra_: https://github.com/snapcore/pc-i386/pull/2
[15:38] <mup> PR pc-i386#2: Add simple snapcraft.yaml <Created by zyga> <https://github.com/snapcore/pc-i386/pull/2>
[15:39] <ogra_> not naive this time ? :)
[15:39] <zyga> cjwatson: no worries, I figured it out :)
[15:39] <zyga> ogra_: haha, I saw your comment :D
[15:39] <ogra_> :)
[15:40] <zyga> ogra_: so all the base four are done
[15:40] <ogra_> yay
[15:40] <zyga> ogra_: once the mirror is refreshed I'll add snapcraft recipes
[15:40] <ogra_> cool
[15:40] <zyga> ogra_: and I should give slangasek admin rights over this
[15:40] <ogra_> yeah
[15:40] <ogra_> he has all the store submission rights already
[15:41] <zyga> ogra_: right, I want to give him github and launchpad project ownership
[15:41] <ogra_> the question is ... as what user does the LP build run ?
[15:41] <ogra_> you might need to re-own the snaps to snappy-dev (and just add steve to that team)
[15:41] <ogra_> else the store submissions will be as zygoon
[15:41] <jdstrand> ogra_: https://bugs.launchpad.net/snappy/+bug/1646144/comments/2
[15:41] <mup> Bug #1646144: ACLs to devices need to be supported in core  <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1646144>
[15:42] <jdstrand> ogra_: I have an idea :)
[15:42] <jdstrand> ogra_: I need to step away for a bit, but this chat of ours today I think may get us somewhere good :)
[15:42] <ogra_> :D
[15:43] <ogra_> the idea sounds good !
[15:43] <zyga> jdstrand: I'm curious too :)
[15:43] <mup> PR snapcraft#923 closed: pluginhandler: source management moved to the core <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/923>
[15:43] <ogra_> zyga, see the bug comment
[15:43] <zyga> ogra_: I think those are as me
[15:44] <zyga> ogra_: but I updated my boards, let me check
[15:44] <ogra_> essentially, we use ACLs but for additional groups in extrausers
[15:44] <zyga> ogra_: show up as canonical: http://pastebin.ubuntu.com/23558568/
[15:44] <ogra_> i,e, snap-dialout ...
[15:44] <ogra_> zyga, thats irrelevant ... i mean the sotre
[15:45] <ogra_> **store
[15:45] <zyga> ogra_: store says the published is canonical
[15:45] <ogra_> who is the uploader
[15:46] <zyga> ogra_: you cannot see that via snap info I suspect ( Chipaca << )
[15:46] <ogra_> (the sotre will always say canonical is the publisher ... thats the output side ... i'm concerned about the input side here)
[15:46] <zyga> ogra_: but my point is that it may not matter if it works
[15:46] <Chipaca> what can't you see?
[15:46] <ogra_> no, you can see it in the sotre page
[15:46] <zyga> ah, from the store page
[15:46] <zyga> Chipaca: uploader vs publisher on a snap
[15:47] <Chipaca> yeah, that doesn't reach the client yet
[15:47] <ogra_> zyga, it matters as soon as you resign, your account gets closed and alll builds under that account immediately stop
[15:47]  * zyga nod
[15:47] <ogra_> sadly i get 504 errors again :/
[15:47] <zyga> nods even
[15:47] <ogra_> so i cant really check
[15:47] <zyga> yeah, same here
[15:48] <zyga> ogra_: if that's "Submitted by" then it is indeed me
[15:48] <ogra_> right ... i wonder if we can get that team owned
[15:49] <ogra_> afaik it is the user who triggered the LP build
[15:49] <zyga> I suppose so, it probably depends on the recipe
[15:49] <zyga> right
[15:49] <ogra_> so if your tree is owned by snappy-dev on LP everyone from the tam can be the owner
[15:49] <ogra_> *team
[15:50] <ogra_> that at least gives the opportunity to have some other account take over instead of having everything killed once an account is closed on LP
[15:53] <zyga> ogra_: we could have a project group for all the canonical snaps on launchpad
[15:53] <zyga> ogra_: as a way to find them more easily
[15:59] <zyga> slangasek: around?
[15:59] <slangasek> zyga: hi
[16:00] <ogra_> zyga, well, thats snappy-dev for all others today
[16:00] <zyga> slangasek: hey, I wanted to give you and update on where we are for the transition we talked about yesterday
[16:00]  * slangasek nods
[16:00] <zyga> slangasek: all the official gadgets are on https://github.com/snapcore/ already
[16:00] <zyga> slangasek: we will probably tweak repository names later but they are all there and have the relevant history
[16:01] <slangasek> and do I have admin / commit privs on them?
[16:01] <zyga> slangasek: they have all been updated with nicer radmes and snapcraft.yamls that work
[16:01] <zyga> slangasek: not yet, I need your github handle for that
[16:01] <slangasek> zyga: vorlonofportland
[16:01] <zyga> slangasek: all but pc are also built all the way to the store already (just waiting for the mirror to enable the last two)
[16:01] <slangasek> zyga: did you end up using the pc snapcraft.yaml that sergiusens did?
[16:01] <zyga> slangasek: not yet but I plan to next
[16:02] <zyga> slangasek: all of the current ones are just dump plugins
[16:02] <slangasek> ok
[16:02] <ogra_> it think tehy are currently all just "dump"
[16:02] <slangasek> wfm
[16:02] <ogra_> yeah, we'll sort that over time
[16:02] <zyga> slangasek: there are also four new launchpad projects, snap-{pi2,pi3,dragonboard,pc}
[16:02] <zyga> slangasek: those host mirrors and do the package builds
[16:02] <slangasek> only pc, not pc-i386 vs. pc-amd64?
[16:02] <ogra_> nope
[16:02] <zyga> slangasek: I need to give you admin access over those so that you can tweak the rest (ownership etc)
[16:02] <ogra_> pc can handle both arches
[16:03] <ogra_> store side
[16:03] <ogra_> LP is where they get merged
[16:03] <zyga> slangasek: only one because pc can handle both (on launchpad), it does have two repositories
[16:03] <slangasek> but the gadget contents are different
[16:03] <zyga> slangasek: but that can change over time
[16:03] <ogra_> yeah, the github trees are too
[16:03] <zyga> slangasek: the idea was that those map to snap names exactly with "snap-$SNAP_NAME"
[16:03] <zyga> slangasek: github repos for pc were renamed from generic-* to pc-*
[16:03] <zyga> slangasek: ogra reviewed all the pull requests sofar
[16:03] <longsleep> zyga: its nice to have all the example/reference gadget stuff in one place - i will update my stuff on https://github.com/longsleep/build-pine64-image/tree/snappy/snappy accordingly.
[16:04] <zyga> slangasek: and that's about it
[16:04] <zyga> longsleep: woot! thank you!
[16:04] <ogra_> nobody tested them though ... :)
[16:04] <ogra_> or did you zyga ?
[16:04] <zyga> ogra_: I switched my boards to them but I dind't build images, the content is the same as before thoughj (looking at prime/)
[16:04] <slangasek> ok, so because the actual snap is named 'pc' this works - yes, understood
[16:04] <ogra_> well, then we're fine
[16:05] <zyga> slangasek: there are some low hanging fruit that I'll do a pass on also before finishing with this
[16:05] <zyga> slangasek: I want to improve snapcraft.yaml's wrt consistency and wording
[16:05] <zyga> (summary and description)
[16:05] <slangasek> ok
[16:05] <zyga> slangasek: so that's it :)
[16:05] <longsleep> zyga: the only thing which prevents me from releasing snappy stuff for pine64 is the issue that i cannot register my key with snapcraft and that the kernel fails with some aparmor thing which we debugged yesterday. Do you have an ETA when to expect a release of that branch of yours? Or would it be better to search for a fix on the current core release?
[16:06] <slangasek> zyga: who will review those snapcraft.yaml changes ? since you don't own these snaps :)
[16:06] <zyga> longsleep: ETA 2-3 days to the image PPA from which it gets to edge instantly
[16:06] <ogra_> slangasek, well, i handled them in the past, i will go on doing that
[16:06] <zyga> slangasek: you and gora
[16:06] <zyga> ogra
[16:06] <zyga> slangasek: those are regular pull requests
[16:06] <zyga> slangasek: I plan to add CI for snapcraft but maybe not tonight, I have a few other things to look at
[16:06] <longsleep> zyga: ah ok thats good, so i might be able to build a edge image on the weekend or next week
[16:07] <zyga> slangasek: let me add you as admin to the repos now
[16:08] <zyga> oh, bugget
[16:08] <zyga> bugger :P
[16:09] <zyga> launchpad cannot build two recipes from one account to the same snap name
[16:09] <zyga> "There is already a snap package owned by Zygmunt Krynicki with this name.
[16:09] <zyga> cjwatson: ^^
[16:09] <zyga> https://code.launchpad.net/~zyga/+snap/pc
[16:09] <longsleep> zyga: https://github.com/snapcore/sample-kernels/commits/stable-3.10.y should work yes? So if i would compare whatever was merged into that tree my kernel should work with snappy too?
[16:10] <zyga> longsleep: I don't know for sure, perhaps you should ask in #ubuntu-kernel
[16:10] <zyga> slangasek, ogra_: have a look at https://code.launchpad.net/~zyga/+snap/pc
[16:10] <longsleep> zyga: ok cool thanks
[16:10] <zyga> is the name under "registered store package name" the only relevant thing
[16:10] <zyga> and I can rename this to pc-i386?
[16:11]  * zyga tries
[16:11] <ogra_> i think thats the only relevant thing, yeah ... but you cant change it if you want to have it be the same thing in the sotre
[16:11] <ogra_> (same thing as amd64)
[16:12] <zyga> ogra_: compare https://code.launchpad.net/~zyga/+snap/pc-amd64 and https://code.launchpad.net/~zyga/+snap/pc-i386 please
[16:12] <zyga> IMHO looks good but ... we'll know when this is done
[16:12] <ogra_> ah, yeah, that looks correct
[16:13] <ogra_> the name in snapcraft,yaml is also pc for both ?
[16:13] <zyga> yes
[16:13] <mup> PR snapd#2381 closed: image: drop support for UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2381>
[16:13] <zyga> you reviwed that :)
[16:13] <ogra_> then we should be good
[16:14] <mup> PR snapd#2371 closed: daemon, store: let snap info find things in any channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2371>
[16:14] <zyga> niemeyer: can you please add vorlonofportland to the ubuntu-foundations team on https://github.com/orgs/snapcore/teams/ubuntu-foundations as the team maintainer
[16:15] <zyga> slangasek: this will then give you control over https://github.com/orgs/snapcore/teams/ubuntu-foundations/repositories
[16:15] <zyga> slangasek: let's talk about launchpad projects, who should own them?
[16:16]  * ogra_ would keep them at snappy-dev and add people as needed to the snappy-dev team 
[16:16]  * zyga nods
[16:16] <ogra_> that worked in the past and all other automatic snaps use it
[16:17] <ogra_> (core and kernels at least)
[16:17] <ogra_> (though the kernel bit might move with the kernel team taking over)
[16:20] <zyga> ogra_: pc-* builds completed
[16:20] <ogra_> yep, i saw
[16:20] <ogra_> failed the store review though
[16:20] <zyga> ogra_: yeah, I'm seeing the same thing
[16:21] <ogra_> Could not find compiled binaries for architecture 'i386' lint-snap-v2_architecture_specified_needed (i386)
[16:21] <zyga> ogra_: interesting: Could not find compiled binaries for architecture 'i386'
[16:21] <zyga> tyhicks: do you know where to report issues on store review tools?
[16:22] <ogra_> well, it worked before ... something is wrong
[16:22] <ogra_> bah
[16:22] <ogra_> sigh
[16:22] <zyga> store review tools may have gotten stronger, dunno
[16:22] <zyga> can you look at the snap to triple check it is sane?
[16:22] <ogra_> the new store policy will now stop all uploads for pc
[16:22] <ogra_> so amd64 wont even go inot testing so we could compare
[16:22] <zyga> I see
[16:22] <zyga> that's unfortunate, indeed
[16:22] <ogra_> yeah, thats a silly policy
[16:23] <zyga> ogra_: do you want me to push the bbb gadget snap anywhere? I did transition it as well
[16:23] <ogra_> push to a bzr branch
[16:24] <zyga> ogra_: sorry, that was all in git after the repo split :/
[16:24] <zyga> ogra_: one thing in bzr that we have to do is to remove those old versions from snappy-hub
[16:24] <tyhicks> zyga: https://bugs.launchpad.net/click-reviewers-tools/+filebug
[16:24] <zyga> tyhicks: thank you!
[16:24] <tyhicks> np!
[16:24] <ogra_> the i386 content looks fine to me
[16:25] <ogra_> i see pc-boot.img and pc-core.img as well as grub.cfg
[16:25] <ogra_> as it should be
[16:26] <ogra_> i dont understand why the check tools would compplain here
[16:27] <zyga> ogra_: reported as https://bugs.launchpad.net/click-reviewers-tools/+bug/1646176
[16:27] <mup> Bug #1646176: pc gadget snap blocked because it doesn't have i386 executables <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1646176>
[16:27] <zyga> ogra_: I suspect they look for elf files
[16:27] <ogra_> zyga, well, it looks identical to the former pc i396 gadget
[16:27] <ogra_> **i386
[16:27] <zyga> ogra_: as I said earlier I suspect the review tools have chanced since it was last uploaded but that's just a theory
[16:27] <ogra_> so why would this one fail while the other one went through
[16:28] <ogra_> i dont think they changed much in the last three/four weeks
[16:28] <zyga> slangasek: I didn't see your response for who should own launchpad objects
[16:29] <zyga> ok, I need a break, it's gotten very cold up here, time to get some warm tea made
[16:29] <zyga> ogra_: let me know if I can convince you of a nice shiny git repository
[16:30] <ogra_> do it ... :P
[16:30] <zyga> ogra_: I'd love to help as I want to support beagle boards for my ow needs
[16:30] <zyga> ogra_: ! :)
[16:30] <zyga> ogra_: where should we put the repo?
[16:30] <zyga> ogra_: is there a bbb community that we could use to host this?
[16:30] <zyga> ogra_: (nice to play in an exisiting playground :)
[16:30] <ogra_> i dont think so ... or i dont know about one on github at least
[16:31] <zyga> ogra_: ok, I'll get that tea and look around
[16:31] <zyga> ogra_: it would be nice if we could support variou TI boards this way, as long as they have a nice kernel and support ARMv7
[16:31] <zyga> ogra_: I bet you have more than I do :)"
[16:31] <ogra_> but i dont think it is bad if either you or me own it
[16:31] <zyga> ogra_: we could create a small organization and keep those projects there, it's a nice way to attract attention as it's not under anyone's name
[16:31] <zyga> ogra_: e.g. "beagleboard.org" or something
[16:31] <ogra_> we already can support multiple TI boards ... the generic kernel has a bunch of dtb's
[16:32] <ogra_> but each would need its own gadget anyway
[16:32] <zyga> but I bet there's some organization on github already, we just need to find it
[16:32] <zyga> ogra_: yes but that's an org, repos are under an owner (org or person)
[16:32] <ogra_> and the bbb community wont use our kernel anyway
[16:32] <ogra_> we're missing all the rcn-ee patches
[16:32] <ogra_> so that gadget isnt really for them
[16:32] <zyga> ogra_: so could be github.com/beagleboard.org/{beagle,beagleboardblack,...}
[16:33] <zyga> ogra_: one step at a time :)
[16:33] <ogra_> well
[16:33] <ogra_> the bbb gadget as is is far from being done
[16:34] <ogra_> it is supposed to use raw imgs, not a vfat for uboot ...
[16:34] <zyga> ogra_: sure, but it doesn't need to be perfect, it's important to find people that are willing to improve it and let them do it
[16:34] <ogra_> i had to cripple it due to an ubuntu-image bg
[16:34] <ogra_> **bug
[16:34] <ogra_> until it is ready for consumption i'd really prefer to not submit it anywhere
[16:34] <zyga> ogra_: what is the bug?
[16:35] <ogra_> a limitation in the sdgisk handling
[16:35] <ogra_> it is fixed now
[16:35] <ogra_> (you had to assign a partition per raw blob ... that moved the partition numbering and broke uboot... )
[16:35] <kalikiana> Is there any way to shadow /usr/bin/ locally from the point of view of a snap? I'm wondering if I can deal with a hard-coded /usr/bin/ without modifying the source
[16:36] <ogra_> it needs love (essentially a re-write of the gadget.yaml) that i didnt get to yet
[16:36] <slangasek> zyga: I disagree, the launchpad projects should be clearly owned by the foundations team not just snappy-dev
[16:36] <zyga> kalikiana: yes but it's not supported yet, we plan to support that
[16:36] <zyga> slangasek: fine, just give me the team name :)
[16:36] <ogra_> slangasek, is there a LP team for foundations used to own branches etc ?
[16:36] <slangasek> zyga: canonical-foundations
[16:36] <zyga> kalikiana: I think it will come to my todo list in Jan next year
[16:36] <zyga> slangasek: thank you :)
[16:36] <ogra_> (i only know cnaonical-foundations but thought thats organisational)
[16:37] <zyga> kalikiana: in a release Feb perhaps
[16:37] <slangasek> (there is a community ubuntu-foundations team but I'd rather just keep canonical-foundations for now)
[16:37] <kalikiana> zyga: Okay, I suppose hacking the source it is then. Waiting two months is not an option, but thanks anyway :-D
[16:37] <zyga> kalikiana: contributions are welcome, if you want to help we could get it in earlier
[16:37] <zyga> kalikiana: I can work with you and guide you through the code
[16:37] <zyga> kalikiana: we have machinery for that
[16:38] <zyga> slangasek: can you go to https://launchpad.net/snap-pi2 and edit all the other objects to be owned by that team
[16:38] <zyga> slangasek: I can no longer do it
[16:39] <zyga> slangasek: please also edit git mirror owner
[16:39] <kalikiana> zyga: I'd be interested in having a look. I don't know at what end that would be tackled at all, though - I have written some snapd code but no clue about other related bits
[16:39] <zyga> slangasek: or add me to that team for a moment
[16:39] <zyga> slangasek: I think that might be faster
[16:39] <zyga> kalikiana: you can hack a prototyle locally
[16:39] <slangasek> zyga: on a call, I will look at this shortly
[16:39] <zyga> slangasek: thank you
[16:40] <zyga> kalikiana: you can edit the mount profile that looks like an fstab, it is in /var/lib/snapd/mount/profiles AFAIR
[16:40] <zyga> kalikiana: (it might be gone if you don't have one for a snap but it's easy to create
[16:40] <zyga> kalikiana: the contents are exactly like an /etc/fstab
[16:41] <zyga> kalikiana: if you describe a bind mount operation there you can bind mount, e,g. /snap/yoursnapname/revision/bin to /bin
[16:41] <zyga> kalikiana: you will have to patch snap confine (perhaps) to allow this via an apparmor profile but you can do that live on a running system without rebuilding anything
[16:41] <zyga> kalikiana: by editing /etc/apparmor.d/usr.lib.snapd.snap-confine
[16:41] <zyga> kalikiana: (I can show you how)
[16:42] <zyga> kalikiana: and re-compiling the profile with apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine
[16:42] <zyga> kalikiana: if that all works the rest is to make that nicer and exposed through snapcraft.yaml
[16:42] <zyga> kalikiana: from there to snapd
[16:42] <zyga> kalikiana: and to that file
[16:42] <zyga> kalikiana: should be very easy to do a quick check if this works for you
[16:43] <zyga> kalikiana: and if it does I can help you make the contirbutions to snapd and eventually to snapcraft
[16:43] <kalikiana> Hmmm that sounds simpler than I might've expected
[16:43] <zyga> kalikiana: the fstab file is named snap.$SNAP_NAME.$APP_NAME AFAIR
[16:43] <zyga> kalikiana: you can run your program with SNAP_CONFINE_DEBUG=yes in the environment
[16:44] <zyga> kalikiana: it is pretty useful to see what's going on
[16:44] <zyga> kalikiana: one important note!
[16:44] <zyga> kalikiana: you need to run sudo /usr/lib/snapd/snap-discard-ns $SNAP_NAME
[16:44] <zyga> kalikiana: after every change to the mount profile and invocation of snap-confine
[16:44] <zyga> kalikiana: we don't have live modification of the mount namespace yet, that's something high on my todo list but it's not done yet
[16:45] <zyga> kalikiana: try it and ask if you get stuck on anything
[16:45] <zyga> :-)
[16:45] <zyga> kalikiana: and you can look at a snap using the content interface (connected) to see how this file usually looks like and how it is named
[16:53] <zyga> slangasek: I'm EODing, please add me to canonical-foundations so that I can complete the move
[16:53] <zyga> slangasek: ttyl :)
[16:53] <slangasek> zyga: ... no, but I will move over anything you want moved over :)
[16:54] <zyga> slangasek: can you move the git repos as well?
[16:54] <slangasek> yes, sure
[16:54] <zyga> slangasek: unless you have lp superpowerers you may not be able to
[16:54] <zyga> slangasek: if you can just go for it :)
[16:54] <slangasek> zyga: "git clone" "git push"
[16:54] <zyga> slangasek: no.. don't do that
[16:54] <zyga> slangasek: those are git mirrors
[16:54] <slangasek> heh ok
[16:54] <zyga> slangasek: also snap build recipes from those
[16:54] <zyga> slangasek: perhaps you can just ask lp admins to change those
[16:55] <slangasek> zyga: or should I not just recreate them?
[16:55] <zyga> slangasek: in the end you will also have to change all the README.md files as the owner is encoded in the URL
[16:55] <zyga> slangasek: well, that'd just duplicate all the work I did, I think it's faster to change the owner
[16:55] <ogra_> recreate sounds sanest
[16:55] <zyga> ogra_: why? this is all checked already
[16:55] <ogra_> but that would need super powers
[16:55] <zyga> slangasek: wait
[16:56] <zyga> slangasek: I can move this to canonical (group)
[16:56] <zyga> slangasek: you can move it then to the foundations team
[16:56] <zyga> slangasek: ok?
[16:56] <ogra_> heh
[16:56] <slangasek> zyga: which bit are you moving?
[16:56] <ogra_> canonical proxy
[16:56] <zyga> https://code.launchpad.net/~zyga/snap-pi2/+git/github-mirror/+edit
[16:56] <slangasek> ok
[16:56] <zyga> slangasek: try now
[16:57] <zyga> oh boy, the snap owenr edit has broken UI :)
[16:58] <ogra_> https://code.launchpad.net/~canonical/snap-pi2/+git/github-mirror/+edit seems to offer swithing owners though
[16:58] <zyga> slangasek: also https://launchpad.net/~canonical/+snap/pi2
[16:59] <zyga> repo chown'ed
[17:00] <zyga> nice!
[17:00] <ogra_> yay
[17:00] <zyga> now just the package
[17:00] <slangasek> zyga: done and done
[17:00] <zyga> slangasek: great, I'll move pi3 and the rest next
[17:02] <zyga> slangasek: https://code.launchpad.net/snap-pi3 all yours now
[17:05] <zyga> slangasek: snap-pc ready for you
[17:15] <zyga> slangasek, ogra_: https://github.com/snapcore/pi2/pull/5 https://github.com/snapcore/pi3/pull/3 https://github.com/snapcore/dragonboard/pull/3 https://github.com/snapcore/pc-i386/pull/3 https://github.com/snapcore/pc-amd64/pull/4
[17:15] <mup> PR pi2#5: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pi2/pull/5>
[17:15] <mup> PR pi3#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pi3/pull/3>
[17:15] <mup> PR dragonboard#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/dragonboard/pull/3>
[17:15] <mup> PR pc-i386#3: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pc-i386/pull/3>
[17:15] <mup> PR pc-amd64#4: Move snap build URL to canonical-foundations <Created by zyga> <https://github.com/snapcore/pc-amd64/pull/4>
[17:16] <ogra_> all approved
[17:16] <zyga> ogra_: merge them
[17:16] <zyga> ogra_: you should have the green button :)
[17:18] <ogra_> done
[17:18] <zyga> ogra_: thanks!
[17:18] <zyga> :)
[17:18] <ogra_> awful clickery
[17:19] <zyga> slangasek: snap-pc doesn't have the nice summary as other snaps do
[17:19] <zyga> slangasek: sorry, I didn't notice this earlier when creating the project
[17:20] <zyga> compare https://launchpad.net/snap-dragonboard and https://launchpad.net/snap-pc
[17:23]  * zyga EODs
[17:23]  * ogra_ too
[17:23] <zyga> ogra_: thanks for your help, that was well worth it IMHO :)
[17:23] <zyga> ogra_: let's talk tomorrow about bbb
[17:24] <zyga> ogra_: enjoy your evening :)
[17:24] <ogra_> i will !
[17:24] <ogra_> you too !
[17:26] <mup> PR snapd#2299 closed: overlord, daemon, progress: enable building snapd without CGO <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2299>
[17:31] <slangasek> zyga: branches and snap recipes transferred, thanks!
[17:34] <zyga> slangasek: I think you missed https://code.launchpad.net/~canonical/+snap/dragonboard
[17:34] <slangasek> zyga: race condition ;) done now
[17:35] <zyga> slangasek: confirmed! all the links from github work as well
[17:35] <zyga> nice :)
[17:35] <zyga> thank you for the help
[17:36] <zyga> slangasek: you may want to look at https://bugs.launchpad.net/click-reviewers-tools/+bug/1646176 though
[17:36] <mup> Bug #1646176: pc gadget snap blocked because it doesn't have i386 executables <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1646176>
[17:36] <zyga> slangasek: it cripples i386 / amd64 gadgets today
[17:36] <mup> PR snapd#2389 opened: daemon: close the dup()ed file descriptor to not leak it <Created by chipaca> <https://github.com/snapcore/snapd/pull/2389>
[17:37] <slangasek> zyga: by "cripples" you just mean that it prevents auto-publishing to edge, correct?
[17:37] <zyga> slangasek: yes
[17:37] <zyga> slangasek: they are stale
[17:38]  * slangasek nods
[17:38] <slangasek> though if any of your PRs changed the binary contents of the gadget... :)
[17:39] <zyga> slangasek: I'm running those gadgets on my boards / pc's but I didn't try to re-flash
[17:39] <zyga> slangasek: I think you should work with QA to propmote some edge revisions to beta to get them tested
[17:39] <zyga> slangasek: or candidate before the next release
[17:39] <zyga> slangasek: I'll propose some improvements to snapcraft.yaml's because they are ugly-ish and were done in a hurry
[17:39] <zyga> slangasek: but those are now normal reviews :)
[17:40] <zyga> slangasek: when gustavo adds you to the team on github you will have admin power over all those repos
[17:41] <slangasek> zyga: also, I saw your autobuild recipes use xenial. Any reason not to track devel?
[17:41] <zyga> slangasek: no opinion on that, right now it doens't matter (IMHO) but perhaps I'm wrong
[17:41] <slangasek> I don't think we want to build edge only from binaries that have cleared SRU queue
[17:41] <zyga> slangasek: also those are for 16 series which is xenial-ish so ... there
[17:42] <zyga> slangasek: but feel free to change those if you think it should be something else
[17:42] <slangasek> it's edge; we should take edge bootloader contents
[17:42] <slangasek> (switching now)
[17:42] <zyga> slangasek: one detail, can you updatet https://launchpad.net/snap-pc to have nicer summary
[17:42] <zyga> slangasek: e.g. " The gadget snap for Personal Computers using Intel or AMD processors"
[17:43]  * zyga nod
[17:43]  * zyga nods
[17:43] <zyga> (and s is stuck)
[17:43] <ogra_> time for a new keyboard ;)
[17:44] <zyga> nah, I'll just spray some air into it, it's not that old
[17:44] <zyga> ssss
[17:44] <slangasek> zyga: I'm unclear what you're wanting changed on https://launchpad.net/snap-pc, I already see a description much like the one for https://launchpad.net/snap-dragonboard
[17:44] <zyga> slangasek: the big bold "snap-pc"
[17:44] <slangasek> ah
[17:44] <zyga> slangasek: compare to https://launchpad.net/snap-pi2
[17:44] <slangasek> done
[17:45] <zyga> slangasek: so that it feels uniform among snap-{pi2,pi3,dragonboard,pc}
[17:45] <zyga> thanks!
[17:45]  * zyga really EODs now :-)
[17:46] <attente> sergiusens: hi, for some reason i keep getting "fatal: unable to access 'https://git.gnome.org/browse/jhbuild/': Failed to connect to git.gnome.org port 443: Connection timed out" from the integration test on github c-i
[17:48] <sergiusens> elopio can you check on attente's problem?
[17:57] <mup> PR snapd#2390 opened: tests: do not use external snaps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2390>
[18:10] <zyga> slangasek: I've added -gadget suffix to all the repos on github per niemeyer's request, can you please edit the correspodning github/launchpad links. I believe there are some redirects but it is more confusing if we have to rely on those
[18:25] <slangasek> zyga: ack, will do shortly
[18:42] <slangasek> zyga: I can't find an option to change the git branch that's the target for mirroring
[18:42] <cwayne> zyga: hey, sorry to bother you -- any eta on 'snaps calling other snaps' fix?
[19:19] <mup> PR snapcraft#933 closed: _filedir takes an extension, not a glob <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/933>
[19:23] <pedronis> cwayne: we don't have a design, either way last I heard it needs to be expressed as some kind of interface (it's setting up a dependency in practice so it needs to be mediated that way to fit)
[20:09] <zyga> cwayne: progressing, still not done, still pending for .45
[20:11] <zyga> slangasek: you mean source, right?
[20:11] <zyga> slangasek: I think that's fine, github does the aliases internally
[20:11] <slangasek> zyga: ok, then what was it you wanted updated?
[20:13] <zyga> slangasek: URLs in in README.md's and on launchpad itself in project description
[20:13] <slangasek> ah
[20:13] <mhall119> jdstrand: has https://issues.apache.org/jira/browse/COUCHDB-3226 been fixed in the mount-observe interface now?
[20:22] <robert_ancell> jdstrand, regarding your PR for D-Bus addresses. The first interface I am thinking of is the LigthDM D-Bus service. It seems to me this doesn't make sense as a built-in interface in snapd.
[21:10] <ssweeny> I currently use systemd mount dependencies to keep my media server software from starting until the external drive with the media on it is mounted. Is there a way to do that in a snap or do I have to write a startup script that waits on the mount to happen?
[21:14] <jdstrand> mhall119: it is in trunk. It should be in 2.18
[21:15] <jdstrand> robert_ancell: hmm, it seems to me like it *would* be an interface
[21:16] <robert_ancell> jdstrand, but it only applies to that one snap, and if I changed it in the future it would require modifying snapd...
[21:17] <mhall119> jdstrand: I thought 2.18 was released, is it waiting to be SRU'd into 16.04?
[21:19] <mup> PR snapcraft#936 closed: nodejs plugin: install during pull to support npm run <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/936>
[22:03] <jdstrand> robert_ancell: that could be said of the network-manager interface as well. that is the nature of interfaces. Interfaces are contracts between consumers and providers. if lightdm is going to be shipped as a snap and going to provide a service, it needs an interface
[22:04] <jdstrand> robert_ancell: the interface can be forward thinking and written in a way to minimize future changes
[22:05] <robert_ancell> jdstrand, it just seems like this is not going to scale for the hudreds of other interfaces that need to exist
[22:07] <jdstrand> robert_ancell: again, interfaces are contracts between snaps that may not be coordinating. if lightdm changes in an incompatible way with other snaps, then that needs to be coordinated via snappy such that a new lightdm doesn't break a consuming snap
[22:07] <jdstrand> robert_ancell: if lightdm isn't changing in incompatible ways like that then there is no maintenance issue because snapd shouldn't have to change
[22:09] <jdstrand> robert_ancell: some day the dbus interface might grow to a point that you wouldn't need a separate interface beyond it. however, system services, bus policy, policykit, etc, it isn't there yet
[22:17] <mup> PR snapd#2389 closed: daemon: close the dup()ed file descriptor to not leak it <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2389>
[22:40] <mup> PR snapcraft#934 closed: deltas: migrate from xdelta to xdelta3 <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/934>
[22:52] <mup> PR snapcraft#935 closed: cmake plugin: utilize MakePlugin build logic within CMakePlugin <Created by larryprice> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/935>