[00:21]  * cmatsuoka EODs
[00:21] <cmatsuoka> good night everyone!
[07:23] <zyga> o/
[09:41] <mborzecki> morning
[10:07] <zyga> mborzecki: hey
[10:07] <mborzecki> zyga: hey, any clue why fedora 30 fails in https://github.com/snapcore/snapd/pull/8588 ?
[10:07] <mup> PR #8588: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8588>
[10:09] <zyga> Failed to connect to bus: No such file or directory
[10:09] <zyga> hmmmm
[10:09] <zyga> mborzecki: what's the likelikhood that magic prepare/restore handling tarballs /run? :D
[10:09] <mborzecki> maybe that's dbus-monitor?
[10:09] <zyga> mborzecki: I don't know
[10:10] <zyga> I mean, session-tool requires system bus
[10:10] <mborzecki> zyga: iirc it only tarballs the test directory and some bits of /var/lib/snapd/
[10:11] <zyga> does it happen each time?
[10:11] <zyga> there's one more possible aspect
[10:11] <mborzecki> yeah, for each test i believe
[10:11] <zyga> can you run it with debug as a single test and see it fail?
[10:11] <zyga> ah
[10:11] <zyga> sorry
[10:11] <zyga> I was talking about the failure
[10:11] <zyga> so, before we land all the fixes
[10:12] <zyga> we still have user.sh and rather brute force operations it does
[10:12] <zyga> it's likely something nuked /run/user/12345 "harder"
[10:12] <zyga> dunno
[10:13] <mborzecki> ok, let me try to run this test on f30 only
[10:13] <mborzecki> i mean locally
[10:13] <zyga> once mvo is around it would be good to get some 2nd reviews for the many branches from yesterday
[10:13] <zyga> and just land things
[10:13] <zyga> I suspect that once we land them all the number of random failures will dramatically drop
[10:14] <mborzecki> he'll probably be online around 13
[10:14] <zyga> ok
[10:14] <zyga> https://github.com/snapcore/snapd/pull/8590 was fun
[10:14] <mup> PR #8590: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
[10:15] <zyga> it passed on all fedora/centos systmes :)
[10:15] <zyga> https://www.irccloud.com/pastebin/2VA6WffF/
[10:15] <zyga> ha
[10:15] <zyga> this is fun
[10:16] <zyga> if this fails then something is nuking dbus.socket and not bringing it back
[10:16] <zyga> I bet it's one of the tests that installs/removes it unconditionally
[10:17] <zyga> could you grep for dbus-user-session and make sure we don't install/remove it blindly
[10:18] <zyga> maybe send a patch to add a debug: | section to this test, to dpkg --get-selections | grep dbus-user-session on apt-able systems
[10:26] <mborzecki> zyga: funny, the test passed in isolation
[10:26] <zyga> yeah
[10:27] <zyga> I bet there's some test that somehow breaks user sessions
[10:27] <zyga> what is curious
[10:27] <zyga> is that it happens this way for fedora
[10:27] <zyga> IIRC we routinely install debian packages
[10:27] <zyga> but not fedora
[10:27] <zyga> do you think anything in user.sh could be responsible
[10:27] <zyga> I strongly believe we leak dbus-daemon's lurking
[10:27] <zyga> because nobody is managing that unless used via systemd --user
[10:28] <zyga> maybe it binds to abstract socket
[10:28] <zyga> and newly started daemons cannot start
[10:28] <zyga> dunno :/
[10:29] <mborzecki> idk, there's only 2 tests that use as_user now
[10:29] <zyga> could be something eles
[10:29] <mborzecki> one of those is the pulseaudio test which iirc has a PR porting it to session-tool
[10:29] <zyga> one other idea is to change the main/session-tool-support test
[10:29] <zyga> to have a up-front check
[10:29] <zyga> for dbus-daemon running as test user
[10:29] <zyga> if so that means something broke before us
[10:29] <zyga> yeah
[10:29] <zyga> I think we are close
[10:29] <zyga> we just need to land the lot
[10:30] <zyga> and see what remains
[10:30] <zyga> I think it's going to be much less unpredictable
[11:19] <zyga> mvo: o/
[11:19] <zyga> mvo: when you have a moment, it would be good to merge some of the branches that are red and have two reviews
[11:20] <zyga> mvo: things are a bit unstable because each branch changes one or at most a few tests and we can estimate what's left only after they all land
[11:23] <mvo> zyga: sure, in a meeting righ tnow
[11:23] <mvo> zyga: but if you point me to things I can merge when I have some minutes
[11:23] <zyga> mvo: sure
[11:23] <zyga> mvo: I'm not working today, just cleaning the office
[11:24] <zyga> mvo: perhaps mborzecki can point you to things as well
[11:24] <zyga> (tough I understand you both share meetings)
[11:24] <mborzecki> mh
[11:24] <mborzecki> mhm
[11:26] <zyga> small scary blurb from the release page
[11:26] <zyga>  New bugfix release 2.44.5
[11:26] <zyga> @mvo5 mvo5 released this yesterday · 1628 commits to master since this release
[11:34] <mvo> zyga: aha, right. enjoy your day off
[11:37] <mborzecki> we should print out instructions about a day off for zyga :P
[11:37] <zyga> mborzecki: I'm cleaning the office
[11:37] <zyga> so many little things to tidy here
[11:37] <mborzecki> haha
[12:16] <roadmr> hey folks who know about spread:
[12:16] <roadmr> Cannot allocate lxd:ubuntu-18.04: cannot list lxd remotes: exec: "lxc": executable file not found in $PATH
[12:16] <zyga> roadmr: spread as a snap cannot invoke lxd
[12:16] <roadmr> what's going on? lxc *is* installed and working. spread was installed from snap.
[12:16] <zyga> roadmr: it's not coded to use the LXD API
[12:17] <zyga> roadmr: you need to use a hand-built version
[12:17] <roadmr> oh... zyga can I get non-snapped spread? and/or how do I get this to work?
[12:17] <roadmr> oh... argh.
[12:17]  * roadmr rolls up sleeves
[12:17] <zyga> roadmr: go get github.com/snapcore/spread/...
[12:18] <zyga> and you will find it in ~/go/bin
[12:18] <zyga> (assuming defaults)
[12:18] <roadmr> yay :)
[12:18] <roadmr> thanks zyga !! that sets me on the right path
[12:18]  * roadmr sadly deletes the spread snap
[12:19] <zyga> roadmr: I have several patches that greatly expand spread's support for lxd
[12:19] <roadmr> \o/
[12:42] <mup> PR core#113 closed: Makefile: conditionally use the "edge" PPA in live-build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/113>
[12:44] <mup> PR snapcraft#3101 opened: package repositories: avoid setting up on host when not the target <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3101>
[12:47] <ogra> zyga, it is super interesting how you manage to produce proper sentences on IRC by just cleaning your keyboard ! :)
[13:18] <zyga> ogra: years of experience
[15:30] <mup> PR snapcraft#3100 closed: Removed ``key`` from ``progressive`` dict following changes in the server API <Created by nessita> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3100>
[15:54] <mup> PR snapd#8588 closed: tests: port portals test to session-tool, fix portal tests on sid <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8588>
[15:54] <mborzecki> yay, thanks!
[15:55] <zyga> oh
[15:55] <zyga> mvo: merge https://github.com/snapcore/snapd/pull/8590 as well please
[15:55] <mup> PR #8590: tests: port selinux-clean to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8590>
[15:56] <zyga> mvo: I'll dig what's left to make master green
[15:56] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8587 needs a 2nd review
[15:56] <mup> PR #8587: tests: session-tool allows preparing/restoring for many users <Created by zyga> <https://github.com/snapcore/snapd/pull/8587>
[15:56] <zyga> (super trivial)
[15:56] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8589 also but is less trivial
[15:56] <mup> PR #8589: tests: port user-session-env to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8589>
[15:57] <mvo> zyga: thanks, looking
[15:57] <zyga> thanks!
[15:57] <zyga> I'm outside soldering GPIO headers
[15:57] <mvo> zyga: haha
[15:57] <zyga> just came to the office to print the pinout
[15:57]  * mvo hugs zyga
[15:57] <zyga> seriously ;D
[15:58] <mup> PR snapd#8590 closed: tests: port selinux-clean to session-tool <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8590>
[15:58] <mvo> zyga: I know, just find it funny that it's so opposite what I'm doing right now
[15:58] <zyga> you are unsoldering GPIO headers in the sun? :D
[15:59] <zyga> https://github.com/snapcore/snapd/pull/8583 is also +2 and simple (just debug code)
[15:59] <mup> PR #8583: tests: add debug to core-persistent-journal test <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8583>
[15:59] <zyga> mvo: I did the early github action matchers but it doesn't seem to work :(
[16:00] <mvo> zyga: meh, that's sad
[16:24] <mup> PR snapcraft#3099 closed: repo: always refresh cache when build packages are required <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3099>
[16:51] <mup> PR snapcraft#3074 closed: package-repositories: draft spec and cleanup <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3074>
[18:15] <mup> PR snapd#8583 closed: tests: add debug to core-persistent-journal test <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8583>
[18:18] <mup> PR snapd#8582 closed: github: register matchers before running spread <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8582>
[18:21] <mup> PR snapcraft#3102 opened: build providers: prevent snap refreshing in build environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3102>
[19:03] <mup> PR snapcraft#3103 opened: python v2 plugin: set path to the interpreter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3103>
[19:28] <cjp256> How should one hold a refresh on a base other than 'core'? `snap set core20 refresh.hold=2020-05-02T19:01:49.211053Z  -- error: cannot configure snap "core20" because it is of type 'base'`
[19:28] <cjp256> would setting than on `core` affect all core images?
[19:29] <mborzecki> cjp256: it's a system wide setting, not per snap
[19:29] <cjp256> oh :facepalming:
[19:30] <cjp256> thank you :D
[19:30] <mborzecki> cjp256: aiui the `core` bit in `snap set core` is legacy, we've support for using system in place of core to make things more clear, so you shoudl be doing `snap set system foo.bar=..`
[19:30] <cjp256> will do that, thanks!
[19:31] <mborzecki> bits inside snapd are still called configcore tho :P
[19:46] <cmatsuoka> ijohnson: interesting, the ubuntu-seed problem is more and more frequent now
[19:46] <ijohnson> cmatsuoka: yes it happens a lot which is annoying
[19:46] <ijohnson> cmatsuoka: my MP to fix it however has not landed :-(
[19:47] <cmatsuoka> a few days ago I tried many times and wasn't able to reproduce it, now it happens in almost every image build
[20:28] <ijohnson> cmatsuoka: yes needs that MP to merged ASAP, but I also don't want to bother folks over the weekend, so let's see how annoying it is on Monday