[00:03] <mwhudson> Chipaca: did you get anywhere with dhcp fun?
[00:04] <kyrofa> mwhudson, it's probably well past his EOD
[02:04] <ahoneybun> cwayne: I think my issue was my wifi card
[02:04] <ahoneybun> using a wire seems to be getting more success
[02:12] <ahoneybun> built
[02:12] <ahoneybun> but it is not intergating with Unity AppMenu
[02:12] <ahoneybun> I did install with --devmode
[02:22] <ahoneybun> nevermind you updated it
[02:24] <mwhudson> where is the vcs for ubuntu-core-config?
[04:19] <ahoneybun> jdstrand: any info on LP: #1590679
[04:19] <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>
[07:04] <dholbach> hey hey
[07:06] <didrocks> good morning dholbach!
[07:06] <dholbach> salut didrocks
[07:41] <dorche> hi
[07:53] <Odd_Bloke> kyrofa: This is QT5, yeah. I tried using the desktop/qt5 part, but I get a Python encoding error (for which a bug is already filed).
[08:24] <seb128> oh, mvo is back
[08:24] <seb128> mvo, hey :-)
[08:31] <mwhudson> good morning europe
[08:33] <mvo> hey seb128
[08:33] <mvo> hey mwhudson, good morning!
[08:33] <seb128> hey mwhudson
[08:33] <seb128> mvo, howa re you?
[08:34] <mvo> seb128: thanks, good, how are you? a gazillon of mail and tasks :)
[08:34] <seb128> mvo, can you have a look to https://code.launchpad.net/~seb128/livecd-rootfs/snap-hooks-tweaks/+merge/301881 ? I think the duplicated <<EOF was a mistake you added it with a string change and copied over
[08:34] <seb128> mvo, I'm good thanks :-)
[08:35] <mvo> seb128: nice catch, thank you!
[08:35] <seb128> mvo, yw!
[08:36] <seb128> mvo, do you have any idea when we are going to get an ubuntu-core update in the stable channel? the current version still doesn't have the xdg-open script
[08:37] <mvo> seb128: it is planed for this week, we are waiting for 2.11 in xenial-updates before we do the update but that is in propsoed now, so it can go to updates today or tomorrow and then we create a image with that
[08:37] <mvo> eh
[08:37] <mvo> a core snap :)
[08:37] <seb128> mvo, also I think your update-desktop-database fix doesn't work, did you test it?
[08:38] <seb128> oh, I didn't notice we had 2.11 landed in proposed
[08:38] <seb128> going to install and test
[08:39] <mvo> seb128: it does not work in what way?
[08:39] <seb128> but reading the commit I think it's not working, calling update-desktop-database without argument seems to not update /var/lib/snap/...
[08:39] <seb128> I think you need to call it with that dir as arg
[08:39] <seb128> at least if I do sudo update-desktop-database I don't get the cache generated
[08:39] <mvo> seb128: oh, hrm, ok. happy to fix that
[08:40] <seb128> I can do a PR if you want
[08:40] <seb128> let me install 2.11 and test
[08:40] <seb128> do I need to reboot to load the new version?
[08:40] <seb128> or can I systemctl restart somethin?
[08:41] <mvo> seb128: it should get restart ed automatically iirc
[08:41] <seb128> k, let's see
[08:41] <seb128> mvo, danke
[08:41] <mvo> seb128: its really only doing that, update-desktop-database, if it needs more, a PR is most welcome
[09:09] <mwhudson> Chipaca, ogra_: fwiw i installed a hacked snappy into an image and confirmed that nothing matches /sys/class/net/eth* when snap firstboot runs for me
[09:10] <mwhudson> lool: hey i just sent you a mail, i'll be around for the next 30 mins or so if by any chance you want to chat about it
[09:10] <lool> mwhudson: seen it
[09:10] <lool> mwhudson: did you want to chat about it?  :)
[09:10] <mwhudson> lool: well only if your answer is something other than "everything you say sounds fantastic" :-)
[09:11] <lool> mwhudson: from what I've read so far it is  ;-)
[09:13] <mwhudson> lool: excellent
[09:45] <mwhudson> lool: all good then?
[09:45] <mwhudson> oh heh you replied
[09:47] <ogra_> mwhudson, well, like i said yesterday, i think that bit related to module loading
[09:47] <mwhudson> ogra_: probably
[09:47] <mwhudson> ogra_: i should file a bug and let someone who knows what they are doing tackle it i guess...
[09:48] <ogra_> /sys is definitely there since the initrd ... but the subdir comes from the driver
[09:49] <ogra_> mwhudson, do you see the module loaded at all on a failed boot ?
[09:49] <mup> PR snapd#1620 opened: give a directory argument to update-desktop-database because the script <Created by seb128> <https://github.com/snapcore/snapd/pull/1620>
[09:49] <ogra_> (i think kvm uses e1000)
[09:49] <seb128> mvo, ^
[09:49] <mwhudson> ogra_: well "dhclient eth0" works fine once booted, so yes?
[09:49] <ogra_> hmm
[09:50] <ogra_> and i guess the dir exists too at the time you run dhclient
[09:50] <mvo> seb128: thanks, I have a look
[09:50] <mwhudson> ogra_: yeah
[09:52] <seb128> mvo, is replacing the /usr/lib/snapd/snapd binary enough for testing (and restarting the service)?
[09:52] <mvo> seb128: yes
[09:53] <mup> Bug #1609322 opened: snap firstboot can run before /sys/class/net/ is populated <Snappy:New> <https://launchpad.net/bugs/1609322>
[09:54] <seb128> mvo, so hold on, seems not work at runtime, looking a bit more
[09:56] <mvo> ok
[10:02] <ogra_> mwhudson, how did you find that /sys/class/net/eth* isnt there ? i assume you have some ls sprinkled over some start scripts ? if so, could you do the same with lsmod instead ?
[10:02] <ogra_> so we see when the modules get loaded
[10:02] <mwhudson> ogra_: i added code to snapd/firstboot/firstboot.go
[10:03] <mwhudson> ogra_: i can try games with lsmod too (tomorrow)
[10:03] <ogra_> cool ... (in case i get to it before you i'll note it on the bug)
[10:07] <seb128> mvo, is there a trick like compiled binaries or a cache or something? I don't understand my snapd log has a string which isn't in the binary even after being restarted
[10:08] <seb128> mvo, snapd[8273]: desktop.go:177: DEBUG: update-desktop-database successful
[10:08] <seb128> but
[10:08] <seb128> $ strings /usr/lib/snapd/snapd | grep successful
[10:08] <seb128> update-desktop-database successful on %s
[10:10] <seb128> I added the parameter for debugging but my code doesn't seem to be used?!
[10:19] <ogra_> mvo, can you share the kernel packages with me in the store ?
[10:20] <ogra_> also u-d-f doesnt like the dragoboard gadget it seems
[10:20] <ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo ./ubuntu-device-flash core 16 --channel=edge --os=ubuntu-core --kernel=dragonboard-kernel --gadget=dragonboard -o test-dragon.img
[10:20] <ogra_> cannot use "dragonboard", must be one of: ["canonical-i386" "pc" "canonical-pc" "canonical-pi2" "canonical-dragon" "beagleblack"]
[10:23] <timothy> hi, are zyga on vacation this week?
[10:25] <mvo> seb128: oh, it may restart itself from the core snap, SNAP_REEXEC=0 is the trick, easiest for testing is probably to follow the README.md (there is a subsection on testing)
[10:25] <mvo> ogra_: please check the latest u-d-f from the all-snaps/16 subdir
[10:25] <mvo> ogra_: what kernel packages are missing, happy to share them with you
[10:26] <mvo> ogra_: also, how can I get a serial console for the pi2? I get to starting kernel and then nothing, iirc you menitoned some dtb issues?
[10:26] <mvo> ogra_: this blocks me right now because I can not debug the early boot on my pi2 with the latest pi2 test image
[10:27] <mvo> ogra_: see also telegram, there are some fixes (and questions). sideload should work again
[10:28] <seb128> mvo, even after a reboot still the same, I don't understand what's going on...
[10:28] <seb128> I did string on the different binary on disk and they have the updated string
[10:28] <seb128> how can the debug output have the old one?
[10:28] <ogra_> mvo, i dont have any access to the new -kernel ones only to the old canonical- ones
[10:29] <ogra_> mvo, i can dig up a uboot.bin that has serial for you ... gimme a bit
[10:30] <mvo> seb128: its re-execing to ubuntu-core
[10:30] <mvo> seb128: its a "feature" but I can see that its confusing
[10:31] <mvo> ogra_: great, thank you
[10:31] <seb128> mvo, meaning?
[10:31] <mvo> ogra_: I add you to all the kernels now
[10:31] <seb128> mvo, what file/version do I need to update and how?
[10:31] <ogra_> mvo, and if you want my attention on telegram, please ping directly, i dont get any access to super-groups from the ubuntu phone client (which is the only thing permananently on telegram i have)
[10:31] <mvo> seb128: there is a snapd in /snap/ubuntu-core/current/usr/lib/snapd/snapd which will be used if its there (and has a higher version)
[10:31] <seb128> oh
[10:31] <mvo> seb128: the easiest way to test your change is to follow the readme in the github repo
[10:31] <seb128> lol
[10:31] <seb128> mvo, thanks
[10:31] <mvo> seb128: it should be short and sweet (the testing section)
[10:32] <ogra_> mvo, also, there is still a base package (from a failed and overzealous renaming attempt) in the store that needs unpublishing
[10:32] <ogra_> seemes we have at least one bug where people installed it :P
[10:32] <mvo> ogra_: uff, I renamed it to base-delete-me
[10:33] <ogra_> thanks :)
[10:33] <mvo> ogra_: hm, so you don't see anything in the group at all? meeh, good to know
[10:33] <ogra_> we really need an easy way for package owners to wipe their packages in the store ... my packagelist is so full of unpublished crap now
[10:34] <mvo> ogra_: +100
[10:35] <ogra_> (and owning 60 click packages in the store really doesnt help to keep the overview ... everything is on one page)
[10:35] <seb128> mvo, k, going to teach me to read the README upfront next time ;-)
[10:35] <seb128> mvo, thanks!
[10:35] <seb128> mvo, change works btw, good to land ;-)
[10:37] <mvo> seb128: !!! thank you
[10:37] <seb128> yw!
[10:50] <mup> PR snapd#1621 opened: store: fix buy method after some refactoring broke it <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1621>
[10:52] <mup> PR snapd#1553 closed: cmd: support defaulting to the user's preferred payment method <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/1553>
[10:54] <Cavan> My snap is running in devmode but not confiened anyway to check whats stopping it?
[10:55] <qengho> Cavan: it will still log many messages if it tries to do too much. Check "dmesg" output.
[10:56] <qengho> Cavan: Then install in confined mode, and try to run it. When it crashes, you find out why. If there's a seccomp abortion, "scmp_sys_resolver NNN" on the signal number you see in the log.
[10:56] <qengho> Cavan: It's basically, "run it and see how it crashes."
[11:00] <Cavan> quengho, do I literally type "dmesg" after trying to run the snap to trace the crash? Or in the directory?
[11:17] <Chipaca> mwhudson, I didn't do anything with dhcp (not looking into this atm)
[11:17] <Chipaca> mwhudson, did updating the before/after work in the end?
[11:22] <mup> PR snapd#1622 opened: client, cmd/snap: use the new multi-refresh endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/1622>
[11:30] <popey> I have a VPS I am using to build "in the cloud" and when I spin it up I only have a root account, no user. For speed, I just snapcraft as root. I know under normal circumstances "building as root" is ill advised, is that still the case with snapcraft, given confinement?
[11:30] <popey> i.e. can I be lazy and build as root and be okay?
[11:32] <ogra_> popey, the danger is that you mess up the host, from a snap POV it shouldnt matter if you run as root or not
[11:32] <popey> i dont care about the host, i provisioned it just to build the snap
[11:32] <ogra_> i thought so :)
[11:32] <popey> and will destroy it afterwards :)
[11:33] <ogra_> i.e. if you do a snapcraft build on LP it always runs as root
[11:34] <popey> oh, well that's interesting data point :)
[12:37] <Chipaca> is launchpad timing out (when commenting on a bug) for anybody else, or does it hate me in particular?
[12:38] <mup> PR snapd#1596 closed: osutil: support both "nobody" and "nogroup" for grpnam tests <lp> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1596>
[12:39] <mup> PR snapd#1590 closed: interfaces: add process-control interface (LP: #1598225) <lp> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1590>
[12:40] <mup> PR snapd#1589 closed: interfaces: miscelleneous policy updates for default, log-observe, mount-observe, opengl, pulseaudio, system-observe and unity7 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1589>
[12:42] <mup> PR snapd#1562 closed: many: cleanup/update rest.md; improve auth errors <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1562>
[12:43] <mup> PR snapd#1586 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1586>
[12:43] <mup> PR snapd#1602 closed: interfaces: add kernel-module interface for module insertion <Created by arges> <Conflict> <https://github.com/snapcore/snapd/pull/1602>
[12:44] <mup> PR snapd#1620 closed: give a directory argument to update-desktop-database because the script <Created by seb128> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1620>
[12:46] <mup> PR snapd#1570 closed: snapstate: remove artifacts from a snap try dir that vanished <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1570>
[12:50] <mup> PR snapd#1565 closed: interfaces: also allow rfkill in network_control <Created by lpotter> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1565>
[12:51] <mup> PR snapd#1566 closed: interfaces/builtin: read perms for network devices in network-observe <Created by jaymell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1566>
[13:33] <seb128> is snappy giving access to the dbus session bus by default?
[13:33] <seb128> or is there an interface needed for that? (which one?)
[13:39] <kyrofa> seb128, I think parts of it, depending on interfaces used (e.g. unity7)
[13:40] <seb128> kyrofa, that user on the list gets a "Failed to open connection to "session" message bus: Failed to connect to socket /tmp/dbus-OQWDAcdbVG: Permission denied "
[13:40] <seb128> I wonder if that's just a missing interface, he doesn't use any
[13:40] <seb128> but also unsure which one to recommend
[13:40] <seb128> unity7 is not very restrictive and not needed there
[13:41] <kyrofa> seb128, indeed. Hold on, the mailing lists changed again so my filters are garbage. I'm redoing them now then I can see what you're talking about
[13:43] <kyrofa> seb128, ah, the xdg one?
[13:44] <seb128> yes
[13:44] <kyrofa> seb128, xgd-open is used for links, right? Click a link within the snap, want firefox to open?
[13:45] <seb128> correct
[13:45] <seb128> but the dbus question is orthogonal
[13:45] <seb128> he did a minimal part to test
[13:45] <seb128> kyrofa, but yeah, basically the command he uses does "dbus-send  --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1" "
[13:45] <kyrofa> Indeed, just making sure I'm clear on what's happening here
[13:46] <seb128> and he got an access denied to the session bus
[13:46] <kyrofa> Yeah I don't think there are any interfaces which grant generic access to the session bus
[13:47] <seb128> k, I replied suggesting that he tries unity7
[13:47] <seb128> thanks
[13:49] <kyrofa> Yeah that should definitely cover it. However, does the SRU of xdg-open solve this issue for him? He'd still need that interface, no?
[13:49] <kyrofa> seb128, also, while I understand he was just testing it out, would xdg-open ever be utilized from a non-gui application?
[13:50] <seb128> yes
[13:50] <seb128> it's a shell script and is used in random places
[13:50] <seb128> including small sysadmin scripts and command lines tools
[13:50] <kyrofa> Can you give me an example? I wonder if we need a simpler interface that includes it
[13:52] <seb128> kyrofa, http://sources.debian.net/src/mc/3:4.8.17-1/misc/ext.d/image.sh/?hl=9#L9
[13:52] <seb128> kyrofa, from a random search on codesearch.debian.net
[13:52] <kyrofa> Huh, interesting
[13:53] <seb128> debian reportbug is in the list
[13:54] <seb128> kyrofa, http://sources.debian.net/src/lptools/0.2.0-2/bin/lp-review-notifier/?hl=160#L160
[13:54] <kyrofa> mvo, what do you think about that? Should we be recommending cli applications that utilize xdg-open to use the unity7 interface, or would it be better to have a more fine-grained interface?
[13:55] <kyrofa> (I ask you since you were the last person I talked to about xdg-open, but jdstrand may be better)
[13:56] <seb128> could make sense to have an "url-handler" interface
[13:56] <seb128> xdg-open does mailto: also
[13:56] <jacekn> I am trying to snap python project and I need to get config.yml from the source repo to parts/<part>/install (python setup tools don't put it there). How can it be done? I can add filesets in "stage" and "snap" but not "build" phases
[13:58] <Spads> jacekn: organise?
[13:58] <jacekn> Spads: explain?
[13:59] <Spads> jacekn: it's a stanza that lets you shuffle file locations around, but it may be the wrong part of the process for this
[14:00] <Spads> http://snapcraft.io/docs/build-snaps/parts
[14:00] <Spads> there's filesets and organize(sic)
[14:01] <jacekn> Spads: I'l have a look but it's not that simple. The file is in the source dir but setuptools don't copy it to parts/<part>/install
[14:01] <Spads> right
[14:01] <Spads> and really this is a problem I've had a few times
[14:01] <Spads> where the install step wasn't fully automated
[14:02] <kyrofa> Spads, if the build system doesn't install it really the only way to do it is to have another part that uses the copy plugin and the same source and places the config where it needs to go
[14:02] <Spads> and I could set up a second part to go through the whole build process a second time
[14:02] <Spads> which seems pointless
[14:02] <Spads> when really what we usually need is "build system X, plus a copy"
[14:05] <kyrofa> Spads, something like this: http://pastebin.ubuntu.com/22031026/
[14:05] <jacekn> kyrofa: ok that will work for me I think. It's suboptimal but will do the job
[14:06] <mvo> kyrofa: jdstrand is probably better
[14:06] <Spads> yeah
[14:06]  * jacekn thinks "ship that sample config file with my build" will be pretty common use case
[14:06] <Spads> The other common use case I'm still trying to work out is the "copy this example config file to $SNAP_USER_DATA before first run"
[14:06] <kyrofa> jacekn, indeed, which is why build systems typically take care of that
[14:07] <jdstrand> kyrofa: how safe is xdg-open? I mean, if everything is expected to be able to use it and it is safe, could just add it to the default template
[14:07] <Spads> jacekn: so one of the things about snappy is that the real goal is to get upstreams to adopt it, so if we can add that file to the build system and get the snapcraft.yaml merged in, that's better
[14:07] <kyrofa> jdstrand, seb128 or attente can probably answer that better than me
[14:08] <jacekn> Spads: kyrofa: ok thanks, I'll use the workaround and try to improve upstream
[14:09] <kyrofa> jdstrand, but it causes browsers or mailers to open... so off the cuff I'd say that doesn't sound like a great thing for everything to have blanket access to
[14:10] <jdstrand> kyrofa, seb128: there is also the question of if xdg-open is in all snaps images
[14:10] <kyrofa> Indeed, good question
[14:10] <mup> PR snapd#1621 closed: store: fix buy method after some refactoring broke it <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1621>
[14:10] <seb128> jdstrand, kyrofa, we need to MIR it so I guess it's going to go through a security review, but it's basically an hundred line of C and small service getting on the bus and calling g_app_info_launch_default_for_uri() on the uri you gave to it
[14:10] <jdstrand> kyrofa: well, that is the safety question. the one on touch was safe and we had it in the default policy
[14:11] <seb128> jdstrand, kyrofa, the script in the ubuntu-core image is just calling "dbus-send  --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1""
[14:11] <seb128> then the small service is on the system side
[14:12] <seb128> which get the message and call the glib function to open the uri provided in the default handler
[14:12] <jdstrand> if it makes sense for all snaps and iot, I would suggest adding it to the default template. if it does not, I think I would suggest adding a new interface: 'url-handle' (not 'handler')
[14:13] <jdstrand> if someone submits a PR, then the interfaces team can discuss
[14:13] <seb128> k
[14:13] <seb128> unsure if it makes sense for iot
[14:14] <seb128> but it's used by sysadmin in scripts and in command line tools
[14:14] <jdstrand> if it can be used in a cli environment, then it might make sense. if not, I would say no
[14:15] <seb128> it can, it only calls to your default handler
[14:15] <seb128> that could be links
[14:16] <mup> PR snapd#1612 closed: interfaces: add /proc/version_signature to appamor template <Created by arges> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1612>
[14:16] <mup> PR snapd#1617 closed: many: move to purely hash based key lookup and to new key/signature format (v1) <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1617>
[14:16] <jdstrand> I suggest submitting a PR with it in the default template then (that will be easier to implement), then if the fuller interfaces team wants it in a separate interface, then moving it out is easy
[14:19] <mup> PR snapd#1611 closed: tests: add locale-control write spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1611>
[14:27] <mup> PR snapd#1607 closed: changed snapd to snap <Created by liu-xiao-guo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1607>
[14:29] <mup> PR snapd#1608 closed: tests: add snapd-control interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1608>
[14:30] <mup> PR snapd#1601 closed: partition: clear snap_try_{kernel,core} on success <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1601>
[14:30] <mup> PR snapcraft#708 opened: Add support for use of pip constraints <Created by javacruft> <https://github.com/snapcore/snapcraft/pull/708>
[14:44] <seb128> jdstrand, thanks, going to do that
[14:46] <mup> PR snapd#1623 opened: interfaces: udev: avoid doubled rules and put all in a per snap file <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
[14:46] <morphis> zyga: ^^
[14:46] <morphis> zyga: took the time and implemented that now
[14:47] <morphis> joc_: ^^
[15:02] <arges> jdstrand: hey for https://github.com/snapcore/snapd/pull/1618, adding this to the hardware-observe seems fine
[15:02] <mup> PR snapd#1618: interfaces: add lscpu to apparmor template <Created by arges> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1618>
[15:03] <arges> jdstrand: for https://github.com/snapcore/snapd/pull/1612 is there an existing interface i should add that to?
[15:03] <mup> PR snapd#1612: interfaces: add /proc/version_signature to appamor template <Created by arges> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1612>
[15:06] <jdstrand> arges: ./interfaces/apparmor/template.go has a typo using @{PROC}/@{pid}/version_signature and @{PROC}/@{pid}/version. clearly, no one has complained about the currect path in the default template, so how about remove from there and add to system-observe?
[15:07] <jdstrand> I commented in the 1612 PR
[15:07] <arges> jdstrand: i was wondering about that extra @{pid} in the path!
[15:07] <jdstrand> I half suspect it was a java app that was looking in the wrong place
[15:08] <arges> jdstrand: ack I can do that, and I'll just submit them as three separate patches into one pull-request
[15:08] <jdstrand> arges: sounds great
[15:08] <jdstrand> arges: feel free to ping me
[15:08] <seb128> mvo, if you have some review slots still, https://code.launchpad.net/~seb128/livecd-rootfs/snap-xdg-defaults/+merge/301917 ... that's creating a .desktop/mimetype registration so clicking on http/mailto/help urls in gnome software know what handle to use
[15:19] <imexil> Hi. I was wondering, are there any plans to make  snapd also available to older Ubuntu versions. Like 14.04 LTS or is this technically not possible?
[15:20] <mup> PR snapd#1624 opened: Use `cp -aLv` instead of `cp -a` (no symlinks on vfat) <Created by mvo5> <https://github.com/snapcore/snapd/pull/1624>
[15:22] <ogra_> imexil, not as long as there is a systemd requirement
[15:23] <mup> PR snapd#1610 closed: store: soft-refresh discharge macaroon from store when required <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1610>
[15:23] <imexil> ogra_: OK
[15:37] <mvo> seb128: oh, nice! thank you
[15:38] <seb128> mvo, yw!
[15:48] <mup> PR snapcraft#618 closed: parser - Support .snapcraft.yaml files <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/618>
[15:49] <Beret> any snappy folks around?
[15:51] <mup> PR snapcraft#662 closed: Update the Standards-Versions and the Vcs* tags in the debian/control file <Created by tsimonq2> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/662>
[15:53] <mup> PR snapd#1625 opened: asserts: make account-key's `until` optional to represent a never-expiring key <Created by emgee> <https://github.com/snapcore/snapd/pull/1625>
[16:00] <mup> PR snapcraft#688 closed: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/688>
[16:03] <mhall119> \o/
[16:14] <mup> PR snapd#1624 closed: boot: use `cp -aLv` instead of `cp -a` (no symlinks on vfat) <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1624>
[16:40] <Cavan> I can run my snap in devmode, but when confined im getting "[28234.099513] audit: type=1400 audit(1470242246.729:353): apparmor="DENIED" operation="exec" profile="snap.zeppelin.zeppelin" name="/usr/bin/nohup" pid=21467 comm="zeppelin-daemon" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0" through 'dmesg'
[16:40] <Spads> Cavan: does it need unity7?
[16:40] <Spads> some programs hit dbus walls just trying to tell the unity dock they're there and have an icon etc
[16:40] <Spads> I found adding the unity7 plug helped there
[16:40] <Spads> oh it's a daemon
[16:41] <Spads> as you were!
[16:42] <Cavan> Spads, aha thanks anyway!
[16:45] <mup> PR snapcraft#669 closed: Add detection for an existing `.snapcraft.yaml` file before running `snapcraft init` <Created by tsimonq2> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/669>
[16:47] <Odd_Bloke> At the sprint last week, oneshots were mentioned as being supported; snapcraft rejects "daemon: oneshot".  Is there something else I should be doing?
[16:47] <jdstrand> Cavan: that came up yesterday. please file a bug at https://bugs.launchpad.net/snappy/+filebug and add the 'snapd-interface' tag and we'll allow calling nohup
[16:51] <sergiusens> Odd_Bloke in is in master, no as a deb yet
[16:51] <sergiusens> *not
[16:51] <Odd_Bloke> sergiusens: OK, cool, so long as I'm not remembering things that aren't true. :p
[16:52] <Cavan> jdstrand, is there anything I can do in the meantime to make it work?
[16:52] <sergiusens> Odd_Bloke in case you want to git clone and just run from master https://github.com/snapcore/snapcraft/blob/master/HACKING.md#project-layout
[16:53] <sergiusens> just use the snapcraft in that bin
[16:53] <sergiusens> and yes, it was added for lxd
[16:53] <sergiusens> now adding timers and socket activation
[16:53] <Odd_Bloke> Cool!
[16:53] <Odd_Bloke> I'll probably have a few more (non-lxd) things incoming at some point.#
[17:02] <Odd_Bloke> We build Ubuntu cloud images using a chroot.  This chroot (obviously) does not have snapd running in it, which means that running 'chroot foo snap install ...' produces a "dial unix /run/snapd.socket: connect: no such file or directory" error.  How can we go about installing snaps within a chroot?
[17:03] <Odd_Bloke> slangasek: Have you done any relevant thinking around this for doing things in livecd-rootfs/buildds?
[17:04] <Cavan> jdstrand, is there anything I can do in the meantime to make it work? (Sorry if I already sent this I disconnected)
[17:06] <sergiusens> Odd_Bloke preinstall snaps instead of fetching/caching them?
[17:06] <Odd_Bloke> sergiusens: Yeah, this is looking at replacing deb packages that we ship installed in images with snaps.
[17:07] <Odd_Bloke> (So is separate from pre-caching snaps that users might want to install themselves)
[17:07] <sergiusens> ah, ic
[17:07] <sergiusens> Odd_Bloke so ogra_ is the image builder master hacker
[17:07] <sergiusens> he might have some insight
[17:08] <Odd_Bloke> OK, he's in my sort of timezone, so I can bug him in the morning.
[17:08] <Odd_Bloke> ogra_: In the meantime, if you want to bless me with some wisdom around the above, it would be much appreciated. ;)
[17:20] <mup> PR snapd#1626 opened: interfaces: add system-trace interface LP: #1600085 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1626>
[17:22] <sergiusens> elopio mind updating https://github.com/snapcore/snapcraft/pull/656/files ?
[17:22] <mup> PR snapcraft#656: Use requirements files in travis tests <Created by elopio> <Conflict> <https://github.com/snapcore/snapcraft/pull/656>
[17:23] <sergiusens> Odd_Bloke heh, ogra_ is awake at weird hours though ;)
[17:29] <mup> Bug #1609499 opened: move interface-specific OS mounts to interface.SecurityMounts <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1609499>
[17:32] <mup> Bug #1597842 changed: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <Snappy Launcher:In Progress by jdstrand> <Snappy:Invalid> <https://launchpad.net/bugs/1597842>
[17:34] <elopio> sergiusens: done. Let's see if travis is still happy.
[17:40] <TaleOfThor> Does anyone know when a snappy version for Raspberry pi 3 will be released?
[17:44] <kyrofa> TaleOfThor, ogra_ will know best, but I believe you can use the rpi2 image if you're okay with 32-bit
[17:44] <kyrofa> 64bit is harder since the firmware blobs are only 32 (right ogra_?)
[18:08] <mup> Bug #1609509 opened: No "slot" exists that allows read-only access to any file <Snappy:New> <https://launchpad.net/bugs/1609509>
[18:18] <niemeyer> morphis: You got some feedback on snapd#1623
[18:18] <mup> PR snapd#1623: interfaces: udev: avoid doubled rules and put all in a per snap file <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
[18:57] <morphis> niemeyer: thanks
[19:19] <mup> PR snapcraft#656 closed: Use requirements files in travis tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/656>
[19:19] <niemeyer> jdstrand: Heya
[19:19] <niemeyer> jdstrand: Long time no speak!
[19:19] <niemeyer> jdstrand: I'm sure we have a vast number of pending topics to talk about :)
[19:19] <niemeyer> jdstrand: But this ping is a minor one.. :)
[19:19] <niemeyer> jdstrand: snapd#1626 needs a go fmt
[19:19] <mup> PR snapd#1626: interfaces: add system-trace interface LP: #1600085 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1626>
[19:20] <jdstrand> niemeyer: hi!
[19:20] <jdstrand> niemeyer: whoops, let me fix that, sorry
[19:21] <niemeyer> jdstrand: Thanks!  Trying to cut down on that never ending list of PRs
[19:22] <jdstrand> niemeyer: yeah, lots of outcomes, bugs, etc, etc :) A lot of PRs is better than no PRs though :)
[19:23] <niemeyer> jdstrand: I should stop reviewing then!
[19:23] <jdstrand> lol
[19:23] <jdstrand> that's one way to look at it I guess :)
[19:24] <mup> PR snapd#1627 opened: squashfs: do not install a snap if its already exists and is valid <Created by mvo5> <https://github.com/snapcore/snapd/pull/1627>
[19:28] <tianon> kyrofa, TaleOfThor: proper 64bit rpi3 kernels are still scarse and WIP :)  if you want ubuntu classic, I've been using the one Ryan Finnie maintains linked from https://wiki.ubuntu.com/ARM/RaspberryPi on my pi3 with good success (including snap/snapcraft), but generally yeah, rpi2 images are the current "state of the art"
[19:34] <jdstrand> niemeyer: fyi, committed (it's going through the various tests now)
[19:45] <powersj> Going through the hello world tour and there is mention of a --broad flag, however when I use it with `snap find` I get unknown flag
[19:52] <mup> PR snapd#1627 closed: squashfs: do not install a snap if its already exists and is valid <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1627>
[19:56] <niemeyer> jdstrand: Thanks!
[20:25] <snappy_> Hi
[20:25] <snappy_> Can anyone help me with installing shout in snappy? I'm getting an error saying "unsupported protocol scheme"
[20:30] <sergiusens> snappy_ snap install shout
[20:33] <snappy_> it says snap command is not found
[20:33] <snappy_> we're using the 15.04 version
[20:59] <mup> PR snapd#1628 opened: store: refactor newRequest/doRequest to take requestOptions <Created by matiasb> <https://github.com/snapcore/snapd/pull/1628>
[21:09] <mwhudson> Chipaca: no, i didn't try your before= suggestion, maybe today :)
[21:42] <mup> PR snapd#1626 closed: interfaces: add system-trace interface LP: #1600085 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1626>
[21:43] <mup> PR snapd#1597 closed: tests: add hardware-observe spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1597>
[21:46] <bladernr> Hey, noob question... how do I install a snap locally?  I just built a snap following the Your First Snap walkthrough.
[21:46] <bladernr> Now how do I install it?
[21:46] <mup> PR snapd#1574 closed: tests: add network-control interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1574>
[21:50] <bladernr> webdm is up, I found something that hinted at scping my snap to ubuntu@webdm.local.  That fails on my system though :/
[21:53] <kyrofa> bladernr, webdm is a bit in flux. You should probably just use the device IP if you have it
[21:54] <bladernr> no device, it's localhost?
[21:54] <kyrofa> bladernr, but yeah, scp it to the device and just install it via snap install <local file>
[21:54] <bladernr> hrmmm... oh... ok
[21:54] <bladernr> doh
[21:54] <kyrofa> bladernr, oh well then, skip the scp step and just snap install it!
[21:54] <bladernr> hahaha...
[21:54] <bladernr> thanks, I was overthinking it
[21:55] <kyrofa> bladernr, I mean, you could scp if you wanted to. An encrypted-in-transit, slower cp
[21:55] <kyrofa> :P
[21:55] <bladernr> Hah!
[21:55] <kyrofa> But yeah, you got it
[21:56] <mup> PR snapd#1629 opened: daemon,docs: drop license docs and error kind <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1629>
[21:57] <mup> PR snapd#1569 closed: Drop license documentation and error kind - this has not been implemented <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1569>
[21:57] <mup> PR snapd#1628 closed: store: refactor newRequest/doRequest to take requestOptions <Created by matiasb> <https://github.com/snapcore/snapd/pull/1628>
[22:14] <sergiusens> elopio what is the story with https://github.com/snapcore/snapcraft/pull/593 ? I give the ball to you to say it is ready to merge ;-)
[22:14] <mup> PR snapcraft#593: git demo snap update - Bug 1595229 <Created by stub42> <Conflict> <https://github.com/snapcore/snapcraft/pull/593>
[22:14] <sergiusens> kyrofa do we still need this https://github.com/snapcore/snapcraft/pull/497 ?
[22:14] <mup> PR snapcraft#497: Catkin plugin: Enforce C.UTF-8 locale <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/497>
[22:15] <kyrofa> sergiusens, yes, that snapd bug is taking too long to fix and people are starting to ask questions
[22:15] <kyrofa> sergiusens, particularly because we're recommending people test on desktop now
[22:15] <sergiusens> kyrofa so why did the test fail? if due to nothing important let's just get it in
[22:15] <kyrofa> sergiusens, checking now
[22:16] <elopio> sergiusens: it's missing at least the removal of the other git test.
[22:17] <elopio> and well, it has a conflict.
[22:17] <sergiusens> elopio can you make the comment there please?
[22:18] <sergiusens> kyrofa also, is this one still relevant after your source management change https://github.com/snapcore/snapcraft/pull/645 ?
[22:18] <mup> PR snapcraft#645: If "source: .." do not copy the current directory into itself <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/645>
[22:18] <kyrofa> sergiusens, actually yeah, my change might have caused that :(
[22:19] <kyrofa> We need to have a test for that case
[22:19] <sergiusens> kyrofa well sheppard that in then ;-)
[22:19] <kyrofa> Okay
[22:22] <Pharaoh_Atem> does anyone know who created snap?
[22:23] <Pharaoh_Atem> like I know Alexander Larsson created flatpak/xdg-app, but who created snap?
[22:23] <sergiusens> kyrofa fwiw, I think it was broken before
[22:30] <kyrofa> elopio, is http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-snaps-cloud/201/console just an infrastructure failure?
[22:32] <elopio> kyrofa: yes, something weird happened during the reboot of the testbed.
[22:32] <kyrofa> elopio, did the tests all run, then? Or did it fail partway through and I should re-run them?
[22:33] <tsimonq2> sergiusens: I would much rather " instead of ' :P
[22:33] <tsimonq2> but yeah yeah I have to be consistent... :P
[22:33] <elopio> kyrofa: rerun. Only the unit tests during the package build ran.
[22:33] <kyrofa> tsimonq2, gotta stick with the standard established in the project :)
[22:33] <tsimonq2> kyrofa: :P
[22:34] <kyrofa> elopio, good deal, thank you
[22:36] <sergiusens> tsimonq2 consistency makes things easier to read
[22:44] <elopio> sergiusens: this one is up-to-date, and all tests are passing: https://github.com/snapcore/snapcraft/pull/687
[22:44] <mup> PR snapcraft#687: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
[22:44] <elopio> it will just need a change in the script to run the staging store tests. cprov: can you please take a look?
[22:45] <elopio> you'll have to add: TEST_STORE=staging.
[22:50] <sergiusens> elopio lgtm. I will wait for cprov
[22:50] <sergiusens> elopio nice cleanup!
[22:57] <mup> PR snapd#1630 opened: daemon: stop using group membership as succedaneous of running things with sudo <Created by chipaca> <https://github.com/snapcore/snapd/pull/1630>
[23:22] <mup> PR snapcraft#497 closed: Catkin plugin: Enforce C.UTF-8 locale <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/497>
[23:22] <sergiusens> kyrofa ^
[23:25] <kyrofa> sergiusens, thanks!
[23:28] <mup> PR snapcraft#703 closed: Update the completion list of commands <Created by seb128> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/703>
[23:28] <mup> PR snapcraft#703 closed: Update the completion list of commands <Created by seb128> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/703>
[23:31] <mup> PR snapcraft#686 closed: Add missing dependencies <Created by cholcombe973> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/686>