[05:10] <mborzecki> morning
[05:25] <zyga> Hey hey
[05:25] <zyga> Janek just got on the bus to school
[05:26] <zyga> His “first” rainy morning
[06:10] <zyga> bedna: hello
[06:10] <zyga> bedna: it may be possible to add support for snaps that don't use services
[06:11] <zyga> bedna: but I think services would be extremely difficult to support, in general
[06:23] <mborzecki> FYI seems like apparmor userspace will land in community arch repo, it's in community-testing atm
[06:24] <zyga> mborzecki: question about https://github.com/snapcore/snapd/pull/5378/files
[06:24] <mup> PR #5378: dirs: improve identification of Arch Linux like systems <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5378>
[06:24] <zyga> does arch set ID_LIKE=archlinux
[06:24] <mborzecki> zyga: yes
[06:24] <zyga> ah, ok
[06:25] <mborzecki> antergos was off on this
[06:25] <mborzecki> don't remember what manjaro does
[06:25] <mborzecki> or maybe we had explicit check for manjaro?
[06:27] <zyga> I don't know either
[06:27] <zyga> I wonder if anyone wants to review https://github.com/snapcore/snapd/pull/5802
[06:27] <mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
[06:28] <mborzecki> zyga: i did already :)
[06:28] <zyga> I know :)
[06:28] <zyga> thank you :)
[06:28] <mborzecki> mvo if off today
[06:29] <zyga> ooh right
[06:29] <mborzecki> maybe john/pawel
[06:29] <mborzecki> idk about pedronis, whether he's off too
[06:29] <zyga> I think chipaca should review it as we need to discuss how to merge it to osutils
[06:29] <zyga> I actually could get a day off too
[06:29] <zyga> to prepare for the trip,
[06:29] <mborzecki> ok
[06:29] <zyga> I need to buy a SSD
[06:29] <zyga> to fit into the bracket mvo is packing
[06:29] <zyga> ...
[06:30] <zyga> I will remind mvo just in case
[06:34] <mborzecki> i think i'll take a day or 2 swap days afer the trip to make up for the half-weekends, it's the only time you can actually do anything takign more than 1h
[06:34] <zyga> yeah
[06:34] <mborzecki> and there's a sports event at school on tue which i'll miss :/
[06:59] <mup> PR snapd#5830 opened: packaging/arch: sync packaging with AUR <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5830>
[06:59] <mborzecki> zyga ^^
[07:00] <zyga> thanks
[07:02] <mborzecki> hm we seem to have explicit checks for arch, manjaro and antergos https://github.com/snapcore/snapd/blob/master/dirs/dirs.go#L200
[07:02] <zyga> indeed
[07:02] <zyga> that's why I asked
[07:02] <zyga> because that code uses DistroLike
[07:02] <zyga> and the condition changed
[07:03] <mborzecki> zyga: but DistroLike looks at ID as well
[07:03] <zyga> mhm
[07:03] <mborzecki> iirc it's ID == this || in list of ID_LIKE
[07:04] <zyga> correct
[07:04] <mborzecki> yup, it's 	if ReleaseInfo.ID == distro || strutil.ListContains(ReleaseInfo.IDLike, distro)
[07:04] <mborzecki> arch works for us either way, and so does the rest
[07:05] <mborzecki> eli's PR has landed, so antergos in should end up with ID_LIKE=arch too
[07:06] <jamesh> zyga: I managed to get some spread tests for user mode systemd daemons that works on all but three distros under spread
[07:07] <zyga> jamesh: hey, that's great!
[07:07] <zyga> which three are problematic?
[07:07] <jamesh> zyga: it turns out "systemctl start user@$UID.service" does the trick provided you've got a new enough systemd
[07:07] <jamesh> to get the user instance running
[07:08] <mborzecki> heh nice
[07:08] <mborzecki> jamesh: and then systemctl --user for that user works?
[07:08] <jamesh> mborzecki: yes, provided you run it with the correct UID and have XDG_RUNTIME_DIR set
[07:09] <mborzecki> nice
[07:09] <jamesh> (the latter so it can find the user insrtance socket)
[07:09] <mborzecki> mhm
[07:09] <pstolowski> morning
[07:10] <zyga> good morning
[07:10] <zyga> all set for the trip?
[07:11]  * zyga afk for a sec
[07:12] <mborzecki> pstolowski: hey hey
[07:40] <pstolowski> Mount snap "test-snapd-control-consumer" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount failed
[07:40] <pstolowski> again in the spread tests, grr
[07:41] <mborzecki> heh
[07:41] <mborzecki> maybe we could do some brainstorming about that while at the sprint
[07:41] <pstolowski> i wish we had a short sprint focused on stabilization of the tests
[07:52] <zyga> I think we should land https://github.com/snapcore/snapd/pull/5807
[07:52] <mup> PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807>
[07:54] <mborzecki> yeah, good idea, touches many files, easy to get into conflicts with other code
[08:18] <mup> PR snapd#5830 closed: packaging/arch: sync packaging with AUR <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5830>
[08:52] <pedronis> I see, thre is some test(s) in cmd/snap tests that leaves behind ~/snap/snapname for real
[08:52] <pstolowski> zyga, mborzecki can you take a look at this trivial https://github.com/snapcore/snapd/pull/5829?
[08:52] <mup> PR #5829: tests: use lxd's waitready instead of polling lxd socket <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5829>
[08:52] <mborzecki> looking
[08:53] <pstolowski> zyga: thanks, will fix the newline
[08:53] <pstolowski> now
[08:59] <mborzecki> pstolowski: do you know if wait_ready is in lxd stable too?
[09:05] <pstolowski> mborzecki: i've just installed lxd on my 18.04, it's still a deb version and it has it if that means anything?
[09:05]  * zyga tries to recall how to use quilt 
[09:06] <zyga> I have a patch for qt for the statx issue
[09:06] <zyga> but man,... packaging
[09:06] <mborzecki> pstolowski: thanks, just curious, in case we use lxd from stable in some test and need it
[09:11] <Chipaca> zyga: whoa, qt easier to patch than the rest of it?
[09:11] <pstolowski> mborzecki: ah, i misunderstood your questions; you meant channels
[09:11] <pstolowski> mborzecki: let me check
[09:11] <zyga> Chipaca: yes
[09:11] <zyga> Chipaca: though we're progressing on the "rest of it" aspect
[09:11] <Chipaca> zyga: whoa
[09:12] <Chipaca> zyga: is this going to work for thresh, though? I thought they were using qt from a ppa
[09:12] <zyga> nope
[09:12] <zyga> but it's a low hanging fruit
[09:12] <Chipaca> one of your five-a-day!
[09:13] <pstolowski> mborzecki: yes, lxd from stable channel supports waitready
[09:14] <mborzecki> pstolowski: thx
[09:17] <thresh> :)
[09:24] <om26er> How do you "unrelease" a snap ? We have a snap whose "beta" channel have a very old version and we currently don't want to expose a new revision to the users in the beta channel. How do we remove that ?
[09:24] <zyga> close the channel
[09:25] <om26er> zyga: super, I was looking for `snapcraft unrelease`, didn't know there was a `close` command.
[09:26] <mborzecki> hm snapstate tests should be run with -count=10 and some random sleep between ootb
[09:26] <om26er> So now we need parallel installs because our crossbar snap has two variants (cpy3 vs pypy) and would be cool to have both installed at the same time, instead of having different snap names.
[09:26] <zyga> mborzecki: because raciness?
[09:26] <zyga> om26er: it's coming :)
[09:26] <mborzecki> zyga: or some crazy map iteration thing
[09:27] <zyga> hmmm
[09:27] <zyga> building qt on one core out of 8
[09:27] <zyga> :/
[09:27] <zyga> well
[09:27] <zyga> at less I'll get my debdiff
[09:28] <mborzecki> zyga: parallel builds explicitly disabled or you forgot a switch?
[09:28] <zyga> I don't know
[09:28] <zyga> it's not default
[09:28] <zyga> so maybe there's some switch
[09:28] <zyga> but meh :/
[09:28] <zyga> crappy defaults
[09:31] <zyga> mborzecki: ha
[09:32] <zyga> I was -j16
[09:32] <zyga> but I need more ram
[09:32] <zyga> c++
[09:32]  * zyga adds more ram to the VM
[09:32] <mborzecki> hahaha
[09:33] <pstolowski> noo i shouldn't have touched these newlines, now travis hates me again
[09:33] <zyga> the build process crashes because apparently 4GB is insufficient
[09:33] <mborzecki> zyga: can't you do that in systemd-nspawned chroot?
[09:33] <zyga> (for compiling, let alone linking)
[09:33] <zyga> mborzecki: the whole OS is a vm
[09:33] <zyga> I'm not running natively
[09:33] <mborzecki> aah you're on mac
[09:33] <zyga> yeah
[09:34] <zyga> ok, while this builds I can hack on a laptop
[09:38]  * Chipaca looks at what he's wrought so far, and goes for more coffee
[09:45]  * Chipaca pushes a PR before the coffee
[09:45] <mup> PR snapd#5831 opened: client, cmd/snap: on !linux, exit when the client tries to Do something <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5831>
[09:45] <Chipaca> ^^ if you could give it a look as my next pr would build on it ^^
[09:55] <zyga> sure
[09:55]  * zyga figured out a way to update seccomp filters on the fly
[09:57] <zyga> Chipaca: done
[09:59] <Chipaca> zyga: getting some good feedback from pedronis also
[09:59] <Chipaca> thank you
[10:09] <mup> PR snapd#5807 closed: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5807>
[10:10] <mup> PR snapd#5762 closed: ifacestate: don't initialize udev monitor until we have a system snap <Hotplug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5762>
[10:25] <Chipaca> zyga: pstolowski: (pedronis): I changed the approach in that simple PR; it's a lot nicer now
[10:25] <pstolowski> Chipaca: k, looking
[10:27] <pstolowski> Chipaca: ah, runtime check, that's much nicer indeed
[10:29] <pstolowski> +1 once again
[10:29] <Chipaca> pstolowski: thanks!
[10:32] <Chipaca> https://mobile.twitter.com/Caged/status/1039937162769096704
[10:40] <pstolowski> lol, so true
[10:40] <Chipaca> if you have a struct { client *client.Client }, that just holds the client and nothing else, what would you call it? clientHolder?
[10:40] <Chipaca> yeOldeClientBag?
[10:40] <Chipaca> clientHolder sounds like something that'd have a clientHold method
[10:41] <zyga> Chipaca: store
[10:41] <zyga> Chipaca: ;)
[10:41] <zyga> or guard
[10:41] <zyga> it just holds the client
[10:41] <pstolowski> clientContainer
[10:42] <zyga> Chipaca: maybe if you tell us why you want that
[10:42] <zyga> is it a proxy?
[10:42] <zyga> client future?
[10:42] <Chipaca> zyga: a mixin
[10:42] <Chipaca> to be embedded in any cmdFoo that needs a client
[10:42] <zyga> ClientIncluded5PercentOffBuyNow
[10:42]  * zyga stops being silly
[10:42]  * Chipaca throws plushies at zyga
[10:43] <pstolowski> clientWrapper
[10:43] <Chipaca> i like clientContainer best, so far
[10:43] <zyga> type interface Clienter { Client() *Client }
[10:44] <pstolowski> Chipaca: 5% interest rate if you make any profit of it
[10:44] <Chipaca> pstolowski: ok
[10:45] <zyga> Chipaca: how about just clientMixin?
[10:47] <Chipaca> zyga: that might be clearer overall
[10:47] <Chipaca> and cheaper also
[10:49] <pstolowski> #5829 anyone? trivial and needs 2nd review
[10:50] <mup> PR #5829: tests: use lxd's waitready instead of polling lxd socket <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5829>
[10:55] <zyga> me
[10:56] <zyga> +1
[10:56] <pstolowski> thx
[10:56] <mup> PR snapd#5829 closed: tests: use lxd's waitready instead of polling lxd socket <Simple> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5829>
[11:00] <zyga> Chipaca: do you think you will have time to look at the trespassing fix PR
[11:00] <Chipaca> zyga: I don't think I'll have time today unless it's urgent
[11:01] <Chipaca> zyga: which is the pr?
[11:01] <zyga> one sec
[11:01] <zyga> https://github.com/snapcore/snapd/pull/5802
[11:01] <mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
[11:03]  * zyga -> coffee
[11:17] <mup> PR snapd#5826 closed: tests: refactor for nested suite and tests fixed <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5826>
[11:17] <pstolowski> Chipaca: #5831 can old, or are you still tinkering with it?
[11:17] <mup> PR #5831: client, cmd/snap: on !linux, exit when the client tries to Do something <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5831>
[11:19] <Chipaca> green already?
[11:19] <Chipaca> greyback: purple now :-)
[11:19] <mup> PR snapd#5831 closed: client, cmd/snap: on !linux, exit when the client tries to Do something <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5831>
[11:20] <pstolowski> wow, the day of landings today
[11:20]  * Chipaca -> lunch and such
[11:28] <zyga> pstolowski: before a day of takeoffs :)
[11:29] <pstolowski> indeed ;)
[11:42] <mup> PR snapd#5832 opened: [RFC] overlord/{snapstate,assertstate}: parallel instances and refresh validation <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5832>
[11:43] <mborzecki> pedronis: ^^ i was totally unfamiliar with this area, hopefully didn't do anything stupid there
[11:46] <mup> PR snapcraft#2218 closed: yaml: replace yaml.safe_load() with CSafeLoader <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2218>
[11:50] <mborzecki> off to pick up the kids
[12:01] <mup> PR snapcraft#2271 closed: reporting: fail gracefully on submit errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2271>
[12:03] <mup> PR snapd#5833 opened: asserts,interfaces/policy: add support for on-store/on-brand/on-model plug/slut rule constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5833>
[12:04] <mup> PR snapcraft#2270 closed: catkin, rosdep: stop using FileNotFoundErrors <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2270>
[12:38] <mborzecki> re
[12:39] <mborzecki> opesuse mirrors returning empty responses again :/
[12:52] <Son_Goku> mborzecki, this is why I use the openSUSE metalink instead of the redirector URL
[12:52] <Son_Goku> unfortunately, I'm not sure how well zypper supports the metalink (I use dnf with openSUSE nowadays...)
[12:53] <zyga> I think we're just complaining when distribution archive is not working
[12:53] <zyga> regardless of why
[12:53] <Son_Goku> the redirector is kind of dumb
[12:53] <Son_Goku> and because it only passes one URL, the package manager can't fall back to another mirror easily
[12:54] <Son_Goku> whereas when using the metalink, it can actually do that
[12:54] <Son_Goku> I think I recently saw some commits go into libzypp about metadata download handling, which makes me think it might have been broken before :/
[12:54] <mborzecki> hm
[12:55] <mborzecki> hopefully it'll be fixed soon
[12:55] <mborzecki> and then we'll complain again in a month or so :)
[12:55] <Son_Goku> haha
[12:55] <mborzecki> didn't know dnf was supported in opensuse
[12:55] <Son_Goku> DNF is available in openSUSE since Leap 15.0
[12:56] <mborzecki> nice
[12:56] <mborzecki> Son_Goku: btw. do you remember that other package manager in fedora that happnend sort of between yum and dnf time wise, iirc it was written in c
[12:56] <pedronis> mborzecki: I saw your RFC PR, not sure I will get to it today
[12:57] <mborzecki> pedronis: no worries, we can do it next week
[12:57] <Son_Goku> mborzecki: you're talking about zif
[12:57] <Son_Goku> mborzecki: https://github.com/hughsie/zif
[12:57] <mborzecki> Son_Goku: ah zif right, is it dead?
[12:57] <Son_Goku> it became hawkey, which is now libdnf
[12:57] <mborzecki> oh it is
[12:58] <Son_Goku> microdnf is another lightweight C implementation of DNF: https://github.com/rpm-software-management/microdnf
[13:02] <Son_Goku> mborzecki, VMware wrote their own C implementation of DNF called "tdnf" for VMware Photon, but it's kind of broken :(
[13:02] <zyga> mborzecki: standup
[13:38] <pedronis> pstolowski: did you land your changes to NewConnectedPlug/Slot ?
[13:39] <mup> PR snapd#5834 opened: cmd/snap: commands no longer build their own client <Created by chipaca> <https://github.com/snapcore/snapd/pull/5834>
[13:39] <Chipaca> ^^ very long :-( but repetitive :-) pure refactor PR I'll be basing snap warnings on
[13:40] <pstolowski> pedronis: yes
[13:41] <pedronis> ok, makes sense, I need to fix my PR
[13:43] <zyga> man, that's really long
[13:58] <mup> PR snapcraft#2273 opened: build providers: use the best CPU configuration <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2273>
[14:52] <mup> PR snapcraft#2274 opened: snap: use a newer PyYAML and drop patches <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2274>
[14:55] <mup> PR snapcraft#2272 closed: meta: friendlier message for incorrect app command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2272>
[17:39] <kyrofa> Trevinho, you around?
[17:41] <mup> PR snapcraft#2275 opened: build providers: use the provider if exported <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2275>
[17:42] <kyrofa> kenvandine, Trevinho finally figured out how to reliably trigger that odd "firefox windows show up under slack icon" issue
[17:42] <kyrofa> kenvandine, Trevinho close Firefox. Open slack snap. Click a link in slack, which fires up Firefox. Notice Firefox now shows up under the slack icon, not Firefox
[17:42] <kenvandine> oh
[17:43] <kyrofa> Might be xdg-open-related
[17:48] <kyrofa> If firefox was already running before clicking the link in slack, it works as expected
[17:49] <kenvandine> kyrofa, maybe something leaking in the env?
[18:13] <kenvandine> jdstrand, could you please ack the dbus slot for gnome-calendar so I can get the strict snap into the edge channel?
[19:06] <jdstrand> kenvandine: I thought I did that before. I'll take a look
[19:06] <kenvandine> jdstrand, that was gnome-contacts :)
[19:06] <kenvandine> getting them both confined this week
[19:06] <kenvandine> jdstrand, and i just requested auto-connect for gnome-calendar as well
[19:40] <jdstrand> kenvandine: done. it's going through automated review now
[19:41] <kenvandine> jdstrand, thanks!