[00:22] <mup> PR snapcraft#1145 opened: tests: skip the tests that can't be run in arm64 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1145>
[03:04] <foobar_> hi
[03:04] <foobar_> i'm trying set up a typical unix environment on my raspberry pi
[03:05] <foobar_> i was wondering if there was a way to load the classic snap whenever I ssh'd in
[03:05] <foobar_> versus invoking it
[03:05] <foobar_> or if there was a way to install vim, git, etc via snaps
[04:53] <mup> PR snapd#2826 closed: overlord: optional device registration and gadget support on classic <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2826>
[07:17] <mup> PR snapd#2867 closed: screen-inhibit-control: add methods for delaying screensavers <Created by 3v1n0> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2867>
[07:18] <mup> PR snapd#2863 closed: cmd/snap-confine: ensure that hostfs is root owned <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2863>
[07:31] <Son_Goku> sergiusens: hey
[08:26] <mup> Bug #1652273 changed: Ubuntu Core 16.04 Docker Seg Faults 139 <Snappy:Fix Released> <https://launchpad.net/bugs/1652273>
[08:29] <mup> Bug #1665029 changed: snapweb needs a link for device when store selected <Snappy:Invalid> <snapweb:Triaged by dbarth> <https://launchpad.net/bugs/1665029>
[08:38] <mup> Bug #1655262 changed: Driver doesn't support ap mode <Snappy:Invalid> <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1655262>
[08:44] <mup> PR snapd#2876 opened: snap: error when `snap list foo` is run and no snap is installed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2876>
[09:06] <jamesh> mvo: hi.  Are you able to merge https://github.com/snapcore/snapd/pull/2783 for me?  It looks like jdstrand is happy with the changes I made w.r.t. his review.
[09:06] <mup> PR snapd#2783: interfaces: add an interface for use by thumbnailer <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/2783>
[09:07] <mup> PR snapd#2783 closed: interfaces: add an interface for use by thumbnailer <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2783>
[09:07] <mvo> jamesh: yes, looked at it this morning and looks fine, I was waiting for tests to go green (unrelated failure in there so I had to re-ruN)
[09:07] <jamesh> mvo: thanks!
[09:10] <mvo> yw
[09:11] <mup> PR snapd#2877 opened: interfaces: new chroot interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2877>
[09:25] <zyga> o/
[09:25] <zyga> Pharaoh_Atem: hey, thank you for the contributions and for accepting the CLA
[09:25] <zyga> Pharaoh_Atem: we're on the final 2 PRs for 2.23
[09:26] <zyga> Pharaoh_Atem: I think this one can go into fedora :)
[09:35] <hangun> zyga: hi
[09:36] <zyga> hangun: hey, did you have luck in getting that to work?
[09:36] <hangun> zyga:  following your blog, I am trying to build snapd from master branch
[09:36] <hangun> zyga:  my env: ubuntu 16.04
[09:37] <hangun> zyga: but got same errors http://pastebin.com/3ySFyvNX
[09:38] <mup> Bug #1665590 opened: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:New> <https://launchpad.net/bugs/1665590>
[09:38] <zyga> hangun: did you run ./get-deps.sh?
[09:39] <hangun> not yet
[09:39] <zyga> hangun: well, why not?
[09:39] <zyga> hangun: you have to run that to build the go parts
[09:39] <zyga> hangun: try that, it should build without issues afterwards
[09:50] <mup> Bug #1665592 opened: cannot bind mount nvidia driver /usr/lib/nvidia-367 <landscape> <Snappy:New> <https://launchpad.net/bugs/1665592>
[09:56] <hangun> zyga:  after running ./get-deps.sh , that error was fxed.
[09:56] <hangun> zyga:  sudo install -m 0755 -o root -g root -D $GOPATH/bin/snap-exec /usr/libexec/snapd/
[09:56] <hangun> zyga: install: target '/usr/libexec/snapd/' is not a directory: No such file or directory
[09:57] <zyga> hangun: that was for centos, on ubuntu you need to use /usr/lib/snapd/
[09:58] <zyga> hangun: (all of libexec becomes just lib)
[09:58] <hangun> zyga: thanks
[11:02] <hangun> zyga:  trouble you again.  when I run "snapcraft register-key " ,  got an error like this: Key registration failed: Failed to save account-key-request assertion for account_id
[11:02] <hangun> zyga: invalid revision: could not add assertion (revision 0 is already the current revision)
[11:03] <zyga> hangun: I'm not that familar with that part, kyrofa or sergiusens are the experts there
[11:04] <mup> PR snapd#2875 closed: mkversion.sh: Add support for taking the version as a parameter <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2875>
[11:05] <zyga> or perhaps pedronis ^^
[11:05] <zyga> pedronis: that assertion error looks weird
[11:05] <zyga> pedronis: this is master built locally
[11:05] <hangun> kyrofa:  when I run "snapcraft register-key " ,  got an error like this: Key registration failed: Failed to save account-key-request assertion for account_id
[11:06] <hangun> kyrofa: invalid revision: could not add assertion (revision 0 is already the current revision)
[11:07] <pedronis> hangun: it means you already registered that key
[11:08] <pedronis> or somebody did
[11:08] <pedronis> likeyly you though
[11:09] <hangun> pedronis:  can I delete the key by "snap delete-key"
[11:09] <hangun> pedronis:  re-register it
[11:10] <pedronis> no, revoke/expire key are not stil work in progress
[11:11] <pedronis> hangun: what does snapcraft list-keys shows ?
[11:11] <pedronis> s/are not stil/are still/
[11:14] <Son_Goku> mvo: so I'm working on preparing fedora packaging to merge into snapd git
[11:14] <Son_Goku> I'm hoping on having that ready to go today so it can go in with snapd 2.23
[11:15] <hangun_> pedronis:  is there any way to work it out ?
[11:15] <pedronis> hangun_: ?
[11:16] <mvo> Son_Goku: I'm about to wrap up 2.23 - but for that I would do a 2.23.1 :-D that is pretty cool
[11:17] <mvo> s/pretty/very very/
[11:17] <hangun_> pedronis:  the key in my machine have been registered.  snapcraft register-key always  dones't work
[11:18] <pedronis> hangun_: sorry I don't undersand what you are saying
[11:18] <pedronis> what does snapcraft list-keys says ?  is your key there?
[11:18] <pedronis> (there's no secret in that list, it's just public bits of the key )
[11:19] <hangun_> pedronis:  haha, no secret.
[11:19] <hangun_> pedronis: snapcraft list-keys
[11:19] <hangun_> pedronis: Name     SHA3-384 fingerprint
[11:20] <zyga> Son_Goku: fantastic
[11:20] <hangun_> pedronis: default  9rrxV3xRkNjih58E4_TVKIOZrZwX3VYySFzZx3qUveRf_7xkPSYpPQFTw6Y0JAaN  (not registered)
[11:20] <zyga> Son_Goku: I'm fighting autocraptools
[11:20] <Son_Goku> I mean... man, that was *your* fault
[11:20] <pedronis> hangun_: that's the key you are trying to register?
[11:20] <Son_Goku> cmake and meson both existed :)
[11:20] <hangun_> pedronis: yes, it is.
[11:20] <zyga> Son_Goku: meson maybe, cmake is yuck and I'd rather use bare make or ... you know
[11:20] <pedronis> hangun_: ok, I need to have lunch, then I can check about it in the store
[11:21] <hangun_> pedronis: thanks a lot
[11:22] <zyga> Son_Goku: how about merging the policy into snapd now?
[11:22] <Son_Goku> ....
[11:22] <zyga> Son_Goku: though up to you, I don't know if you had plans for that
[11:22] <Son_Goku> I thought about it
[11:22] <zyga> (to merge into the bigger policy package?
[11:23] <Son_Goku> well, keeping it as a module seems to make more sense than merging it back into selinux-policy
[11:23] <Son_Goku> especially since the scope of snapd increases with every release
[11:23] <zyga> Son_Goku: up to you
[11:23] <zyga> Son_Goku: I think it will make sense to keep it close over time
[11:23] <Son_Goku> mvo: what do you think?
[11:23] <zyga> Son_Goku: as we enable CI it would just be built and installed
[11:24] <Son_Goku> should I propose to merge the policy module into the snapd source tree?
[11:24] <zyga> Son_Goku: we could experiment, in one PR, with changes that change policy and fix something in the core
[11:24] <zyga> mvo: this is the selinux policy, about 5 files
[11:24] <Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-selinux
[11:25] <popey> anyone on the device enablement side able to help here? ogra_ ? :) http://askubuntu.com/questions/884346/creating-a-custom-ubuntu-core-image-for-intel-joule
[11:25] <mvo> zyga, Son_Goku my gut-feeling is that having that in the snapd git repo would be good
[11:25] <zyga> +1
[11:25] <Son_Goku> is there a way to preserve the commit history with doing that?
[11:25] <zyga> Son_Goku: absolutely
[11:25] <zyga> Son_Goku: just add it as a remote
[11:25] <zyga> Son_Goku: and merge
[11:25] <zyga> with --no-commit
[11:25] <zyga> then move them around and commit
[11:26] <zyga> I did that with snap-confine
[11:26] <Son_Goku> what were the exact steps?
[11:26] <zyga> git remote add policy /path/to/policy/repo
[11:26] <zyga> git merge --no-commit policy master
[11:26] <zyga> git mv ...
[11:26] <zyga> git commmit
[11:26] <zyga> then remove the remote
[11:26] <zyga> it's pretty neat as history is fully preserved this way
[11:26] <zyga> including before the merge
[11:31] <Son_Goku> merge: sepolicy - not something we can merge
[11:31] <Son_Goku> zyga: am I missing a step?
[11:31] <zyga> git fetch
[11:32] <zyga> I bet I forgot :)
[11:32] <zyga> sorry
[11:32] <zyga> (merge is local after all)
[11:32] <ogra_> popey, hanging directly after selecting the image in grub points to a kernel issue ...
[11:33] <Son_Goku> fatal: refusing to merge unrelated histories
[11:33] <Son_Goku> zyga: it doesn't like that much
[11:34] <zyga> mmm, let me think
[11:34] <zyga> I wonder if I still have that in bash history
[11:34] <ogra_> popey, i'd suggest to him to try each snap on its own ... i.e. build the gadget, build an image with the official pc kernel, see if that boots ... only then start plying with the kernel ... also, the gadget is at https://github.com/snapcore/pc-amd64-gadget
[11:35] <zyga> Son_Goku: --allow-unrelated-histories
[11:35] <zyga> Son_Goku: odd, maybe git updated since, I don't recall using it
[11:35] <zyga> Son_Goku: try it with that option
[11:36] <Son_Goku> yay, now conflicts with COPYING and README.md files
[11:36] <zyga> great!
[11:36] <zyga> Son_Goku: you should be good now :)
[11:36] <Son_Goku> mvo, zyga: what should the folder be?
[11:36] <popey> ogra_: any chance you can paste that in? :)
[11:36] <popey> for the karma
[11:37] <mvo> Son_Goku, zyga: maybe just data/selinux ?
[11:37] <zyga> mvo: sounds good to me
[11:37] <zyga> Son_Goku: unless you have a better idea
[11:37] <mvo> zyga, Son_Goku: or packaging/fedora/selinux if its specific to that (but it sounds like it is not)
[11:38] <Son_Goku> it's not
[11:38] <zyga> mvo: I think it is generic for many selinux systems
[11:38] <Son_Goku> I set it up to work on Fedora, Debian, and Arch/Gentoo hardened
[11:38] <Son_Goku> all systems that prefer selinux for hardened configurations
[11:40] <apeattack> Does anyone know if canocials landscape will support snappy in the future ?
[11:40] <Son_Goku> zyga: do you know how I can filter out a directory?
[11:41] <zyga> mmm, not sure, I bet there's a way
[11:41] <zyga> what do you want to do?
[11:41] <zyga> manybe for a one-off it is easier to just do it manuall
[11:41] <zyga> apeattack: it is plausible but I don't have anything to back this up
[11:42] <Son_Goku> zyga: I want to remove dist/ folder
[11:42] <apeattack> is there any other way to manage snaps instead ?
[11:42] <Son_Goku> snapd uses packaging/ as its equivalent
[11:43] <apeattack> Make sure that a certain snap is installed on a machine at acertain time ?
[11:43] <Son_Goku> and I'm not using the selinux module spec for this
[11:43] <zyga> Son_Goku: I think we can drop the .refresh timer + service now
[11:44] <zyga> Son_Goku: you can rm -rf it now
[11:44] <zyga> Son_Goku: becausethis is --no-commit you can still tweak it
[11:44] <zyga> Son_Goku: it will be in the history but that's okay
[11:44] <zyga> apeattack: mvo was working on  way to set the refresh schedule, there's a new way to control this
[11:45] <zyga> apeattack: but you cannot manage the device to tell it to install a specific snap remotely yet
[11:46] <apeattack> ok thanks
[11:50] <pedronis> hangun_: so in the store there's  a request to register that key, but not the key itself, I need to talk with the person responsible for that code to understand how that happened, but he is off today
[11:51] <hangun_> pedronis: thanks
[11:57] <pedronis> hangun_: for now I created a bug:  https://bugs.launchpad.net/snapstore/+bug/1665617
[11:57] <mup> Bug #1665617: user key with account-key-request present in the store but no matching account-key <Snap Store:Confirmed for cjwatson> <https://launchpad.net/bugs/1665617>
[11:59] <mup> PR snapd#2878 opened: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
[11:59] <Son_Goku> zyga, mvo ^
[12:03] <zyga> Son_Goku: commented already
[12:17] <Son_Goku> zyga: done
[12:20] <zyga> Son_Goku: I saw, thanks
[12:22] <Son_Goku> I don't know how to wire up the debian packaging to produce the selinux policy module
[12:22] <Son_Goku> so you're going to have to do that :)
[12:25] <mup> PR snapd#2879 opened: asserts: improved information about assertions format in the Decode doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/2879>
[12:54] <morphis> sergiusens, kyrofa: ping
[12:54] <mup> Bug #1665592 changed: cannot bind mount nvidia driver /usr/lib/nvidia-367 <landscape> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1665592>
[12:56] <sergiusens> morphis: pong?
[12:56] <morphis> sergiusens: not sure if I found a regression with snapcraft 2.27
[12:56] <sergiusens> Son_Goku: got delayed with the snapcraft release, starting the work on it today
[12:56] <morphis> sergiusens: but our network-manager builds are now failing with:
[12:56] <morphis> /usr/bin/ld: ./.libs/libNetworkManager.a(nm-vpn-editor-plugin.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
[12:56] <Son_Goku> sergiusens: fantastic!
[12:56] <morphis> see https://launchpadlibrarian.net/305337019/buildlog_snap_ubuntu_xenial_armhf_network-manager-daily_BUILDING.txt.gz for a build with snapcraft 2.26 and https://launchpadlibrarian.net/306823655/buildlog_snap_ubuntu_xenial_amd64_network-manager-daily_BUILDING.txt.gz for one with 2.27
[12:57] <morphis> there are no changes on the snap side
[12:57] <sergiusens> morphis: interesting; is that using classic confinement?
[12:57] <morphis> no
[12:57] <morphis> sergiusens: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snapcraft.yaml
[12:57] <sergiusens> hmm, we had no changes in this area iirc
[12:58] <morphis> hm
[12:58] <sergiusens> elopio: that needs to be added to the nightlies ^
[12:58] <morphis> sergiusens: trying to see if I get that locally too
[13:00] <sergiusens> morphis: k, this is xenial, right? I am going to clone your project and build here too
[13:00] <morphis> sergiusens: it is
[13:02] <sergiusens> morphis: can you create a bug on our lp tracker for us to add your projects to our nightly builds? List all the projects you care about not breaking and elopio will add them to our nightly check of snaps against snapcraft master
[13:02] <sergiusens> it is equivalent of "archive rebuild"
[13:08] <morphis> sergiusens: nice, will do that!
[13:16] <pmcgowan> ogra_, hi, I disabled snapd.refresh.timer but I still see it trying to refresh, do I need to disable the service as well?
[13:16] <ogra_> pmcgowan, oh, that might be
[13:16] <ogra_> i hought the timer is enough, but if it still runs then most likely not
[13:16] <pmcgowan> let me try
[13:17] <pmcgowan> ogra_, status doesnt indicate its disabled, unless I miss something
[13:19] <hangun> pedronis: thanks
[13:23] <ogra_> mvo, hmm, did we drop the snap refresh timer without having the core option for refresh.schedule in place ?
[13:23] <mvo> ogra_: yes
[13:23] <ogra_> mvo, i cant find the timer in systemctl anymore
[13:23] <ogra_> but also not the timer option
[13:23] <mvo> ogra_: in 2.23 it is now internal
[13:23] <mup> PR snapcraft#1144 closed: Trigger beta tests on travis every day <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1144>
[13:23] <mvo> ogra_: what do you need in particular?
[13:23] <ogra_> right, but no way to turn it off yetz
[13:24] <mvo> ogra_: no easy way, you can set "snap set core snapd.last" to something recent
[13:24] <ogra_> mvo, well,s ee the discussion on the ML ...
[13:24] <mvo> ogra_: let me check
[13:25] <ogra_> where max asks about a way to find if a refresh is due and then wants to do some testing first
[13:25] <ogra_> (the replies to "New stable "core" and "ubuntu-core" snaps released" )
[13:26] <mvo> ogra_: we have the store side validation mechanism for this
[13:27] <ogra_> ah
[13:32] <sergiusens> morphis: reproduced :-/
[13:33] <sergiusens> I think I know what it may be
[13:33] <pmcgowan> mvo, so is there no way to turn ff autoupdates atm?
[13:33] <pmcgowan> off
[13:33] <mvo> pmcgowan: unfortuantely not, if that is a blocker we need to talk and maybe delay the release
[13:34] <pmcgowan> mvo, my question is actually for a core system
[13:34] <pmcgowan> if that matters
[13:34] <ogra_> should be the same nowadays
[13:34] <mvo> pmcgowan: total disable is a much discussed topic
[13:35] <pmcgowan> mvo, my example use case is we staged a demo machine for next week and would like to keep it the same
[13:35] <pmcgowan> although real world examples probably meatier
[13:37] <mvo> pmcgowan: right, well, let me put it differently, we can trivialy add code for this (there is even code in snapd to disable refresh). we need to decide (at a level above me) if that is something we want or not :)
[13:37] <pmcgowan> mvo, understood
[13:38] <pmcgowan> mvo, I think with better use of tracks/channels for the snaps we could be fine
[13:40]  * mvo nods
[13:42] <mup> Bug #1663942 changed: snappy-debug suggests network-control, when network is enough <Snappy:Invalid> <https://launchpad.net/bugs/1663942>
[13:43] <sergiusens> morphis: kyrofa reverting https://github.com/snapcore/snapcraft/commit/3052b0f459ded440dad2e2362946ee37e09c8606 fixes it
[13:43] <sergiusens> so boo
[13:51] <mup> PR snapcraft#1146 opened: Revert "repo: remove symlinks to libc. (#1100)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1146>
[13:52] <morphis> sergiusens: ok, thanks
[13:57] <morphis> sergiusens: are you pushing a minor release out to fix this?
[13:57] <morphis> this will cause all our CI to break until this is fixed
[13:57] <sergiusens> morphis: yes
[13:59] <sergiusens> morphis: with luck it can be out on Monday, is that ok? https://bugs.launchpad.net/snapcraft/+milestone/2.27.1
[13:59] <morphis> sergiusens: yeah, that should be ok
[13:59] <sergiusens> I am thinking that this will hit most autotools/libtool projects though
[13:59] <morphis> sergiusens: you still want a bug report for this?
[13:59] <morphis> yeah
[13:59] <sergiusens> morphis: I think LP: #1665089 is related
[13:59] <mup> Bug #1665089: snapcraft 2.27 fails to build the mosh classic snap <classic> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1665089>
[14:00] <sergiusens> but the 'classic' misled the importance
[14:00] <morphis> sergiusens: ok
[14:01] <sergiusens> morphis: my guess is that `libtool` does some guessing and then hardcodes expected library paths depending on the libraries it finds; not entirely sure but the whole auto world is full of black magic
[14:01] <morphis> it is :-)
[14:02] <stokachu> what's the snap install syntax to install from a track/channel?
[14:03] <morphis> sergiusens: so Monday means in proposed for xenial?
[14:09] <mup> Bug #1650671 changed: Content sharing from snap common is broken <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1650671>
[14:12] <mup> PR snapcraft#1135 closed: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1135>
[14:13] <mup> PR snapd#2881 opened: cmd/snap-confine: don't crash if nvidia module is loaded but drivers are not available <Created by zyga> <https://github.com/snapcore/snapd/pull/2881>
[14:15] <mup> PR snapcraft#1134 closed: 2.26 dragonboard fixes <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1134>
[14:15] <mup> PR snapcraft#1136 closed: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1136>
[14:16] <zyga> Son_Goku: some build woes on rawhide with golang packages on ppc? I just got a bunch of bug reports about this
[14:16] <Son_Goku> we just did a mass rebuild
[14:16] <zyga> https://kojipkgs.fedoraproject.org//work/tasks/3376/17733376/build.log
[14:16] <Son_Goku> so it's possible
[14:16] <zyga> yeah, I saw that
[14:16] <Son_Goku> this is where you get to talk to the fedora golang guys :)
[14:18] <zyga> Son_Goku: ay, will do
[14:24] <mup> PR snapcraft#1147 opened: snapcraft.yaml: 96boards: minimal changes to get a working kernel snap <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1147>
[14:27] <mup> Bug #1604346 changed: snapd apparmor tests fail on ArchLinux <Snappy:Won't Fix by zyga> <https://launchpad.net/bugs/1604346>
[14:29] <stokachu> im having some issues trying ot get my systemd script to run on boot https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada
[14:29] <stokachu> zyga, ^ are you familiar with this at all?
[14:29] <stokachu> i need a custom bridge interface to come up on boot thats handled through this snap run mechanism
[14:29] <stokachu> https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L20-L24
[14:30] <stokachu> is my daemon config
[14:30] <stokachu> if i run the snap run command manually it works
[14:30] <zyga> stokachu: looking
[14:30] <ogra_> didrocks, have you heard about any Gtk theme errors when using the desktop launcher for ubuntu-app-platform ? i get:
[14:30] <ogra_> ogra@anubis:~/datengrab/devel/branches/rocket-client-webapp$ rocket-client-webapp.ogra-rocket-webapp
[14:30] <ogra_> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
[14:30] <ogra_> "file:///build/webbrowser-app-96smi5/webbrowser-app-0.23+16.04.20161028/src/app/webcontainer/webapp-container.qml:-1 File not found\n"
[14:30] <mup> Bug #1612909 changed: Unable to install snappy in Fedora <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1612909>
[14:31] <morphis> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1665658
[14:31] <mup> Bug #1665658: Add system enablement snaps to nightly build of snapcraft <Snapcraft:New> <https://launchpad.net/bugs/1665658>
[14:31] <didrocks> ogra_: could be. There are quite some warning when using Qt, but I don't think that one. Mirv is responsible for ubuntu-app-platform and manage it. It could be a missing dep
[14:31] <didrocks> the file not found with webapp-container.qml is more annoying
[14:32] <ogra_> oh, i thought thats just fallout of the first
[14:32] <mariogrip> Is it possible to use pkexec in a snap? (with --devmode)
[14:32] <didrocks> ogra_: I don't think it is
[14:32] <ogra_> yeah, now that you say it :P
[14:33] <ogra_> who maintains the webapp-helper remote part ?
[14:33] <mup> PR snapcraft#1148 opened: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1148>
[14:33] <mup> PR snapcraft#1149 opened: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1149>
[14:33] <ogra_> i guess the issue is in there
[14:34] <didrocks> ogra_: Alberto (from https://wiki.ubuntu.com/snapcraft/parts)
[14:34] <zyga> stokachu: sorry, I'm not sure what to look at
[14:34] <zyga> stokachu: what is the error specifically?
[14:34] <zyga> stokachu: I don't see any
[14:35] <stokachu> zyga, there are no errors, systemctl status show it applying the items in my bridge.start script
[14:35] <stokachu> but it doesn't actually do anything
[14:35] <ogra_> mardy, ^^^ seems the webapp-helper is broken
[14:35] <stokachu> there are some reexec commands in there
[14:35] <stokachu> snap rexec
[14:35]  * mardy reads...
[14:35] <Mirv> (s/Mirv/SDK team/, also t1_mp and kali_kiana can be pinged among else)
[14:36] <mardy> ogra_: oh, lool has met just the same issue :-)
[14:36] <mardy> ogra_: where are you building it? 16.04?
[14:36] <ogra_> yeah, we are brothers in spirit :)
[14:36] <ogra_> snapcraft cleanbuild on 16.04
[14:36] <zyga> stokachu: not sure if that's related
[14:36] <zyga> mvo: have a look at this vvvv
[14:36] <zyga> Feb 16 20:32:11 chonk /usr/bin/snap[1400]: cmd.go:105: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
[14:36] <zyga> Feb 16 20:32:11 chonk /usr/bin/snap[1400]: cmd.go:59: DEBUG: re-exec disabled by user
[14:36] <zyga> snap reexcs to say "nah disabled by the user"
[14:36] <zyga> stokachu: still, no idea what the problem is
[14:36] <zyga> stokachu: what does the wrapper do?
[14:37] <stokachu> zyga, https://github.com/conjure-up/conjure-up/blob/master/snap/wrappers/bridge.start
[14:37] <mardy> ogra_: you must enable the stable-phone-overlay PPA, as the webapp-container from xenial is too old
[14:37] <ogra_> eeek
[14:37] <ogra_> ok
[14:37] <stokachu> zyga, basically systemd loads this script file and i can see it running those commands, but then it never applies
[14:37] <zyga> stokachu: and what is the actual issue, that the network changes you did with iptables don't show up?
[14:37] <stokachu> zyga, yes
[14:38] <stokachu> and that network interface isn't brought up
[14:38] <zyga> stokachu: no idea, that's not related to snaps, is it?
[14:38] <zyga> stokachu: (with classic confinement)
[14:38] <stokachu> zyga, well it works with my debian package
[14:39] <stokachu> so not sure what the issue is
[14:39] <zyga> stokachu: can you provide a small test case, a oneshoot daemon does something in classic confinement
[14:39] <mup> PR snapcraft#1150 opened: kernel plugin: remove MAKEFLAGS from the environment <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1150>
[14:39] <zyga> stokachu: and that thing is not applied
[14:39] <stokachu> zyga, sudo snap install conjure-up --classic on xenial
[14:40] <stokachu> see ifconfig output to see interfaces
[14:40] <stokachu> reboot
[14:40] <stokachu> interfaces gone
[14:40] <stokachu> no errors in syslog
[14:40] <zyga> stokachu: I don't want to run that on my system
[14:41] <zyga> stokachu: a _small_ test case I can read and change would be better
[14:41] <zyga> stokachu: ah
[14:41] <zyga> stokachu: reboot
[14:41] <zyga> stokachu: after reboot is the job started?
[14:41] <stokachu> yes the job is started
[14:41] <zyga> stokachu: maybe it runs too early
[14:41] <zyga> stokachu: and there's no network or something like that yet
[14:41] <stokachu> i dont know how to set the targets in snapcraft.yaml
[14:41] <stokachu> to tell it to wait for network.target
[14:41] <zyga> stokachu: there's no way to do that
[14:42] <stokachu> zyga, https://github.com/conjure-up/conjure-up/blob/2.1.0-beta5/debian/conjure-up.service
[14:42] <stokachu> thats what the service should look like
[14:43] <zyga> stokachu: there's no way to express that in snapd
[14:43] <zyga> stokachu: partially by design
[14:43] <zyga> stokachu: please report an issue and discuss this with gustavo when he's back next week
[14:44] <zyga> stokachu: technically this is easy-ish to do but this is a design issue not a technical issue
[14:45] <stokachu> k
[14:45] <zyga> stokachu: technically we should model dependencies inside snap services and among a curated set of services like network
[14:45] <zyga> (targets)
[14:51] <stokachu> ok
[14:51] <stokachu> is there a plan to add an uninstall hook?
[14:51] <zyga> I don't know
[14:52] <zyga> stokachu: there's some chatter about install hooks
[14:52] <zyga> stokachu: (on the ML)
[14:53] <stokachu> yea i need them too
[14:53] <zyga> I really feel we need an RFC process or PEP-like process
[14:54] <ogra_> mardy, thanks that worked
[15:15] <mup> PR snapcraft#1151 opened: Remove 'Series' from channel maps.   <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1151>
[15:22] <mup> PR snapd#2882 opened: snapstate: ensure snapstate.CanAutoRefresh is nil in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2882>
[15:23] <mup> PR snapd#2883 opened: seccomp: added Specification for seccomp backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/2883>
[15:25] <gQuigs> is there a list of ports/servers snap needs to access to work?
[15:29] <lool> ogra_: also captured solution in https://bugs.launchpad.net/webapp-container/+bug/1651812
[15:29] <mup> Bug #1651812: snaps of webapps <webapp-container:Confirmed for mardy> <https://launchpad.net/bugs/1651812>
[15:30] <lool> also I hit this first https://lists.ubuntu.com/archives/snapcraft/2016-November/001735.html
[15:31] <ogra_> i didnt hit that one ... but my icon and .desktop file arent found by unity somehow
[15:31] <ogra_> it seems all correct but still
[15:49] <mup> Bug #1665683 opened: Strictly confined desktop applications snaps can't toggle Launch at Login  <Snappy:New for flexiondotorg> <https://launchpad.net/bugs/1665683>
[16:27] <kyrofa> sergiusens_, morphis that doesn't make sense. That lib should just be in the host machine now, still picked up
[16:29] <kyrofa> Hard-coded paths, then?
[16:29] <zyga> kyrofa: which lib?
[16:33] <morphis> kyrofa: I don't know, but I know it breaks all builds for some of our snaps like network-manager
[16:33] <morphis> and it doesn't with snapcraft 2.26
[16:34] <mup> Bug #1591148 changed: snap install fails with a kernel lacking apparmor support <security> <snapd:Confirmed> <https://launchpad.net/bugs/1591148>
[16:35] <kyrofa> That's unfortunate, we'll need to figure out another fix for bug #1658774
[16:35] <mup> Bug #1658774: Symlinks to libc left dangling <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1658774>
[17:04] <sergiusens_> kyrofa: the effects of pkg-config and libtool might be at play ;-)
[17:04] <kyrofa> sergiusens_, :(
[17:13] <mup> PR snapd#2884 opened: snapstate: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <https://github.com/snapcore/snapd/pull/2884>
[17:14] <mup> PR snapd#2885 opened: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <https://github.com/snapcore/snapd/pull/2885>
[17:40] <jdstrand> nessita, noise][: is something wrong with the store:
[17:40] <jdstrand> $ sudo snap install core
[17:40] <jdstrand> error: cannot perform the following tasks:
[17:40] <jdstrand> - Download snap "core" (1079) from channel "stable" (received an unexpected http response code (500) when trying to download https://public.apps.ubuntu.com/anon/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_1079.snap)
[17:40] <jdstrand> $ wget https://public.apps.ubuntu.com/anon/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_1079.snap
[17:40] <jdstrand> ...
[17:40] <jdstrand> HTTP request sent, awaiting response... 500 INTERNAL SERVER ERROR
[17:40] <jdstrand> 2017-02-17 11:39:55 ERROR 500: INTERNAL SERVER ERROR.
[17:41] <ogra_> jdstrand, stokachu just reported the same on rocket
[17:41] <nacc> seems like it (happens here too)
[17:41] <nessita> jdstrand, yes, we are getting sort of DoS by snapd itself
[17:41] <nessita> working on it
[17:41] <jdstrand> ok
[17:41] <stokachu> we just did a big release announcent
[17:41] <stokachu> fyi nessita
[17:41] <nacc> heh
[17:41] <jdstrand> I should be able to just sideload, so I'm not blocked
[17:41] <nacc> stokachu: use snaps! oh wait ... don't use them so hard! :)
[17:42] <stokachu> :D
[17:42] <nessita> stokachu, there is an issue with the transition from ubuntu-core -> core that's making snapd ask for package details in a loop
[17:42] <jdstrand> yikes
[17:42] <nessita> so is not strictly on amount of users, but on an loop of requests, still investigating
[17:43] <stokachu> nessita, ok people are actively trying to download conjure-up so it's giving them a bad first impression
[17:43] <nessita> cprov, see above %
[17:43] <stokachu> nessita, just letting you know the severity
[17:43] <nessita> stokachu, thank you
[17:45] <kyrofa> Hey ogra_, I tried comparing an amd64 ubuntu core image to an amd64 cloud image (the disk1.img), and Ubuntu Core is larger, which surprised me. Any idea why?
[17:45] <cprov> right, we are actively working on it with the snapd team.
[17:45] <mup> PR snapd#2882 closed: snapstate: ensure snapstate.CanAutoRefresh is nil in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2882>
[17:45] <ogra_> kyrofa, i have never seen one fo the cloud images ... so i cant really tell
[17:46] <kyrofa> ogra_, ah darn
[17:46] <ogra_> not even sure who produces them
[17:46] <ogra_> but i guess they dont have a kernel :)
[17:47] <kyrofa> ogra_, well, I know the rootfs ones don't, but I thought the disk1.img was flashable
[17:50] <stokachu> nessita, i think it's working for now
[17:50] <kyrofa> ogra_, if I wanted to say "this is how stripped down ubuntu core is" what would you recommend I compare to?
[17:50] <nessita> stokachu, I was about to say downloading should work now
[17:50] <stokachu> nessita, thank you!
[17:51] <nessita> hehe still more to do! but you are welcome
[17:54] <ogra_> kyrofa, ubuntu-server vs the core snap
[17:54] <kyrofa> ogra_, ubuntu-server what, though? Not the ISO, for example
[18:00] <noise][> FYI, snap download issue is resolved
[18:30] <mup> PR snapd#2879 closed: asserts: improved information about assertions format in the Decode doc comment <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2879>
[18:36] <lazyPower> is there a pattern for interfacing with man in snaps? Would I need to ship it as a part?
[18:37] <kyrofa> lazyPower, not yet, but that's something we're working on. bash-completion, too
[18:38] <lazyPower> ah ok, i found this - http://askubuntu.com/questions/764835/how-can-i-view-man-pages-for-apps-installed-via-snaps
[18:38] <kyrofa> lazyPower, yeah I suppose that works
[18:39] <lazyPower> seems like a big hack... not sure if we want to follow up there or not on that answer when the feature lands. Is there a bug i can subscribe to and track this?
[18:39] <kyrofa> lazyPower, indeed, definitely a hack
[18:40] <kyrofa> lazyPower, I think this is it: https://bugs.launchpad.net/snappy/+bug/1575593
[18:40] <mup> Bug #1575593: Snappy installed manpages aren't accessible through man <Snappy:Triaged> <https://launchpad.net/bugs/1575593>
[18:41] <lazyPower> Thank you kyrofa, my launchpad-fu failed me
[18:41] <lazyPower> ta :)
[18:41] <kyrofa> lazyPower, hardly-- snappy bugs are spread all over the place :P
[18:41] <kyrofa> lazyPower, we're trying to make that better as well
[18:42] <lazyPower> is there a way to fix this in the short term? if it were a classic snap would that make a consistent work-around fix until this gets bumped from low priority?
[18:42] <lazyPower> s/would that/ would that help/
[18:44] <lazyPower> i guess it would work like this: and i think it would work fine in strict mode too: set that manpath  env, and i would have to include man as a part, and then make petname call petname.man which would fix petname -h complaining it cant find man...  thoughts on this approach?
[18:45] <kyrofa> lazyPower, mvo or zyga might have some thoughts on that
[18:45] <lazyPower> ok just sounding out a work-around out loud :) thanks kyrofa
[18:50] <lazyPower> yeah my thought was outlined in that bug pretty well too by paelzer already.
[18:50] <lazyPower> nice, thanks again.
[18:51] <kyrofa> lazyPower, make sure to mark "effects me too"
[18:52] <lazyPower> Just did :)
[18:54] <mup> PR snapd#2885 closed: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2885>
[19:15] <mup> PR snapd#2886 opened: releasing package snapd version 2.22.3 <Created by zyga> <https://github.com/snapcore/snapd/pull/2886>
[19:45] <mup> Bug #1665756 opened: environment variable setting issue <Snappy:New> <https://launchpad.net/bugs/1665756>
[19:54] <mup> PR snapcraft#1146 closed: Revert "repo: remove symlinks to libc. (#1100)" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1146>
[19:58] <noonien> Hello folks!
[19:58] <noonien> Does snappy have repositories?
[19:58] <noonien> Can I host my own snap repo?
[19:59] <nacc> noonien: i believe you'd need your own store
[20:00] <noonien> How can I store private snaps then?
[20:01] <nacc> https://insights.ubuntu.com/2016/06/24/howto-host-your-own-snap-store/ ... but i'm not sure that is official
[20:01] <nacc> noonien: i think this is an open feature, but i'd wait to see if someone can respond officially
[20:02] <noonien> Cool, I'll look into it! Thanks! ^_^
[20:03] <mup> PR snapcraft#1152 opened: Changelog for 2.27.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1152>
[20:04] <noonien> From what I undestand from that blogpost, snapd doesn't support multiple stores.
[20:05] <kyrofa> noonien, indeed, you understand correctly
[20:06] <noonien> Well, that's kind of a bummer :(
[20:06] <kyrofa> noonien, the goal as I understand it is for snapd to have one authoritative source, instead of essentially duplicating PPAs
[20:06] <kyrofa> noonien, whether that's the Ubuntu store, or someone else's. Still one source
[20:07] <noonien> I see, don't really understand the reasoning for such a limitation though.
[20:08] <kyrofa> noonien, I for one never liked adding PPA from <random person> to my system
[20:09] <noonien> Well, as long as the store is public(as is the ubuntu store), I don't see how anything is improved
[20:10] <kyrofa> noonien, public i.e. anyone can put anything in there?
[20:10] <noonien> Yes, is that not the case with the ubuntu snappy store?
[20:11] <kyrofa> noonien, indeed it is, but there are two things. 1) snaps are typically confined, and 2) in the case where they're not, they undergo manual review by the store/security team. In the case of Ubuntu, I trust them. I don't place that trust easily
[20:11] <ogra_> yes, and thats the reason for the "one store" policy ... since that one store has certain policies and security checks in place so poeple can not upload malicious stuff
[20:11] <kyrofa> noonien, indeed, as ogra mentioned, there are a lot of automated checks done on the store as well
[20:12] <noonien> So I cannot upload any packages I like under my developer namespace?
[20:12] <ogra_> (or rather ... people can uploads anything malicious they want but it will be harmless on the endusers machine)
[20:12] <kyrofa> noonien, you'd have none of those guarantees if anyone could use any store
[20:12] <ogra_> yo can upload anything you like
[20:12] <ogra_> under your namespace
[20:13] <ogra_> evil things will hit the wall and get stuck in "manual review" though
[20:13] <noonien> So what's the difference between installing from a PPA or a developers namespace?
[20:13] <ogra_> compliant things will just go through
[20:13] <noonien> Ugh, so everything under my dev namespace needs to get reviewed?
[20:13] <ogra_> you dont define the namespace as the enduser
[20:13] <kyrofa> noonien, only if it doesn't pass automated review
[20:14] <ogra_> why would it get reviewed ?
[20:14] <noonien> hmm, is there anywhere where I can read about the process?
[20:14] <kyrofa> noonien, which process, uploading snaps? Installing them?
[20:14] <ogra_> https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
[20:14] <noonien> I'm trying to create an automated build bot that packages and publishes snaps of the apps I need. It would be a major PITA and waste of time if ubuntu decides my packages don't belong in their store.
[20:15] <ogra_> noonien, well, as long as they comply with the security policies of snaps they will just go through
[20:15] <kyrofa> noonien, Ubuntu doesn't care as long as the snap is safe. I also use CI to push snaps
[20:15] <ogra_> they need to properly use interfaces to talk to the system etc
[20:16] <noonien> I see, that's a relief. I'll look into the whitepaper
[20:16] <ogra_> if thats given then yoou can just upload ... or even use launchpad pointing to your git/bzr/wahatever trees to have that auto-build and upload for you
[20:16] <kyrofa> noonien, check out snapcraft.io as well, it'll walk you through how snaps are put together, including walking you through interfaces
[20:16] <ogra_> (for all the arches launchpad supports)
[20:17] <noonien> kyrofa: thanks, will do!
[20:17] <ogra_> noonien, i'd also recommend http://snapcraft.io and https://docs.ubuntu.com/core/en/
[20:18] <noonien> I'd prefer to avoid launchpad as much as I can.
[20:18] <ogra_> well, it gives you arch builders for free and is fully integrated with all the snap tools ... so it saves a lot of work
[20:18] <ogra_> but up to you indeed :)
[20:18] <kyrofa> noonien, note that you don't have to host your code there, FYI
[20:18] <ogra_> whats the reason you dont like it though ?
[20:19] <noonien> I've had some issues with it in the past, a long time ago, when I tried to contribute to some projects, it's probably a lot better now
[20:20] <noonien> The applications I'd like to packages already have git repos, I'm trying to create a build bot that updates the snaps when the developers push to their repos and deploy them using my snapcraft manifests, as long as they don't wish to support snappy.
[20:20] <ogra_> it can easily build github trees for example ... no need that you move your whole project over just to use the snap build mechanism
[20:21] <noonien> And from the brief look I took over snapcraft.io some time ago, snappy seems like a pretty decent alternative to debs.
[20:21] <ogra_> it totally is !
[20:21] <noonien> Hopefully less work needs to be put into building a snap than a deb.
[20:22] <ogra_> yeah
[20:22] <ogra_> all you eed is the snapcraft.yaml file ... try out the hello-world example on snapcraft.io
[20:23] <ogra_> that yaml file can even point to some remote source ... so it doesnt necessary need to live inside your upstream branch (though that is indeed the best) snapcraft gives you all the freedom you can imagine
[20:23] <noonien> I have, sadly the packages I want to build are a bit more complex, they have lib dependencies, need to access X, etc. AFAIR some time ago snappy hardly had any support for such stuff. However, from what I gather it's pretty easy to setup now.
[20:24]  * ogra_ has some snaps that he re-packs from proprietary deb binaries for personal use ... there are pretty much no restrictions what you package or how 
[20:24] <ogra_> yeah
[20:24] <ogra_> well, read up on it, tinker with it, and if you have questions, we are here :)
[20:24] <mup> PR snapcraft#1153 opened: contribution guide: add commit message template <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1153>
[20:24] <noonien> https://github.com/jaagr/polybar is one such package
[20:25] <noonien> I'll try to get it running first. Will check in if there's anything i'm struggling with
[20:25] <noonien> You guys have been of great help! Thank you! ^_^
[20:25] <ogra_> :)
[20:46] <jdstrand> davidcalle: hey, I just noticed https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ still says ~rc5. the pdf is correct
[20:47] <jdstrand> noonien: fyi, if reading the whitepaper, get the pdf ^
[21:13] <kyrofa> ogra_, why does the core manifest include apt?
[21:13] <ogra_> because it is taken before we remove packages
[21:14] <kyrofa> Oh, you strip from there? Of course, you use this to create classic huh
[21:14] <kyrofa> (classic mode, that is)
[21:14] <ogra_> right
[21:14] <kyrofa> ogra_, FYI, you might be not stripping libapt, I think sergiusens hit that
[21:15] <ogra_> we do ... but only in edge
[21:15] <kyrofa> ogra_, ah
[21:15] <ogra_> stable is usually 300 revs behind edge ... the fun is in the edge ;)
[21:15] <kyrofa> ogra_, I don't suppose you generate a manifest of everything that actually ends up in the core snap? i.e. excluding stripped items?
[21:15] <ogra_> (sounds like a 70s song title)
[21:15] <ogra_> nope
[21:16] <ogra_> that would be hard to obtain since the package info is gone then
[21:17] <kyrofa> Yeah... I figured. Haha, I really have no information to put on this "Ubuntu Core is a flavor of Ubuntu with a minimal footprint" slide
[21:30] <mup> PR snapcraft#1152 closed: Changelog for 2.27.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1152>
[21:34] <kyrofa> Hey jdstrand, remember that weird DNS-not-working-from-within-the-snap issue I mentioned the other day?
[21:34] <kyrofa> jdstrand, after some more investigation, the only thing that seemed different on his setup than mine was that his /etc/resolv.conf points to 127.0.0.53
[21:34] <kyrofa> Whereas mine is 127.0.1.1
[21:35] <kyrofa> jdstrand, any chance this could have something to do with systemd-resolved?
[21:36] <jdstrand> kyrofa: maybe? you might ask foundations. I'm not using systemd-resolved...
[21:36] <kyrofa> jdstrand, yeah me neither
[21:37] <jdstrand> kyrofa: I can say I've heard of people having dns issues when using systemd-resolved with snappy. I didn't help debug it (ie, I heard it in passing)
[21:37] <kyrofa> jdstrand, any chance you remember who was discussing it?
[21:38] <jdstrand> it might've been Zygmunt
[21:38] <kyrofa> zyga, do you remember any issues with systemd-resolved related to snappy?
[21:38] <zyga> kyrofa: yes
[21:39] <zyga> kyrofa: but ask me some other time, this is not the best moment
[21:39] <zyga> kyrofa: tired and fire-fighting
[21:39] <zyga> jdstrand: hey :)
[21:39] <zyga> jdstrand: how are you?
[21:39] <zyga> (no reviews)
[21:39] <jdstrand> zyga: hi :)
[21:39] <zyga> heh
[21:39] <jdstrand> zyga: I see that! unfortunately, I know why :\
[21:39] <zyga> no I mean I don't want a review :)
[21:39]  * jdstrand nods
[21:39] <zyga> jdstrand: I'll catch you next week, I'm about to sign off soon
[21:39] <jdstrand> zyga: you've been busy today
[21:40] <jdstrand> ok
[21:40] <jdstrand> zyga: you probably know this, but fyi, Monday is national holiday for US
[21:41] <zyga> jdstrand: ah, enjoy then
[21:41] <zyga> jdstrand: man that's not good tho :D
[21:44] <kyrofa> zyga, okay... any chance you know of a bug, or someone else familiar with the issue?
[21:45]  * ogra_ wonders if the US had these many free days last year too ... 
[21:45] <kyrofa> ogra_, hahaha
[21:45] <ogra_> or is that a trump bonus ?
[21:45] <mup> PR snapd#2887 opened: merge release/2.22 branch into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2887>
[21:45] <zyga> kyrofa: no idea
[21:45] <ogra_> suffer more but get more free days
[21:45] <kyrofa> zyga, alright I'll ask next week, thanks
[21:50] <mup> PR snapd#2886 closed: releasing package snapd version 2.22.3 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2886>
[21:56] <kyrofa> ogra_, this coming from the guy who gets three months of paternity leave?
[21:57] <ogra_> paternity ?
[21:57] <kyrofa> Well, not you personally
[21:57] <ogra_> :)
[21:57] <ogra_> heh, indeed
[21:57] <ogra_> france is worse than germany though
[21:58] <kyrofa> What is it in france?
[21:58] <ogra_> more paternity leave i mean
[21:58] <ogra_> what do you celebrate on monday ?
[22:00] <kyrofa> Washington's birthday
[22:00] <kyrofa> Otherwise known as President's Day
[22:00] <ogra_> ah ...
[22:01]  * ogra_ holds back on the trump jokes :)
[23:05] <mup> PR snapd#2888 opened: many: display kernel version in 'snap version' <Created by zyga> <https://github.com/snapcore/snapd/pull/2888>
[23:43] <mup> PR snapd#2887 closed: merge release/2.22 branch into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2887>
[23:55] <mup> Bug #1665808 opened: Unable to install core snap in an ephemeral boot: cannot create namespace group directory /run/snapd/ns: Bad file descriptor <Snappy:New> <https://launchpad.net/bugs/1665808>