[06:14] morning [06:49] PR snapd#11000 closed: snapstate: add debug message where a snap is mounted [07:03] good morning, o [07:28] zyga-mbp: hey [07:29] hey mborzecki [07:29] hi mborzecki, zyga-mbp [07:30] * zyga-mbp waits for covid results :/ [07:31] meanwhile, I'm learning about testing.T and things it has to offer in latest Go [07:32] I've been using check.v1 since I learned Go but perhaps it's time to get back to the roots, at least partially [07:37] zyga-mbp: did you fall sick, or is it just a test? [07:38] mardy I feel totally sick [07:38] mardy no smell, no taste, some fever, etc [08:04] zyga-mbp: hm t.Parallel() and then before check I used to use https://github.com/stretchr/testify [08:05] PR snapd#10999 closed: cmd/snap-confine: lazy set up of device cgroup, only when devices were assigned (2.53) [08:07] morning [08:15] PR snapd#11004 opened: tests: give interfaces-udisks2 more time for the loop device to appear [08:20] PR snapd#11002 closed: tests: increase timeout/add debug around nbd0 mounting [08:40] Hello everyone o/ So William pointed out to me LP: #1948838 [08:40] Bug #1948838: Snapd can no longer be imported as a Go module [08:52] anyone know how I can run one spread test (ubuntu-core-18-64:tests/core/snapd-refresh-vs-services-reboots) using a custom UC18 image (https://people.ubuntu.com/~slyon/uc18/)? [08:59] mardy: you can use qemu backend (see our hacking.md and https://github.com/snapcore/spread); then you can pass the individual test name to spread [09:00] pstolowski: hi! Yes, but it still will load the ubuntu-16.04 image, and install the core as a snap [09:01] ah hmm [09:04] mvo: hi, see the issue sil2100 reported ^, not sure what was the state of things re go mod in 2.53 [09:30] jamesh: hi, re https://github.com/snapcore/snapd/pull/10867#discussion_r732705276 should we just not support notifications on 16.04 given that it probably isn't an interesting desktop environment anymore (but maybe this is a wrong assumption)? [09:30] PR #10867: desktop, usersession: observe notifications [09:35] pstolowski: it should still usually work on 16.04. The problem is that we can't use dependencies to ensure it works. [09:36] since one service is started by systemd and the other by Upstart [09:37] jamesh: hmm i see. i'm hoping for your suggestion on what to do with that, i'm afraid my understanding of the desktop is limited [09:43] pstolowski: when you log into a desktop session on 16.04, both a user mode systemd and upstart instance will be run. The D-Bus session bus is managed by upstart [09:44] pstolowski: the snap session agent is started on demand via socket activation. If it is started after the session bus has been started, then we can use the session bus. If it starts afterwards, then not. [09:45] s/afterwards/before/ at the end there [10:07] jamesh: got it. can we get session bus by other means in the latter case (possibly by retrying), or is it game over if DBUS_SESSION_BUS_ADDRESS is not set? [10:08] pstolowski: upstart's dbus job writes out the session bus address to a file in $XDG_RUNTIME_DIR. And godbus already had code to check that file (that I didn't even have to write). [10:09] https://github.com/godbus/dbus/blob/d379abe190d5ca3715642acec248498637629d53/conn_other.go#L51 [10:09] miguelpires: hi, can you assing https://bugs.launchpad.net/snapd/+bug/1943987 to self (I couldn't find your LP id) [10:09] Bug #1943987: snap disconnect : prints a confusing error [10:10] jamesh: that looks nice, sounds like a retry around that would do? [10:11] pstolowski: what's currently in master can potentially crash if (a) session agent gets started before dbus, and (b) the notification REST API gets called [10:11] with your changes, it'd crash with only (a) [10:12] pstolowski: Yes, thanks for reminding me [10:12] i.e. there's already the chance of a problem, but it'd be nice to avoid making it bigger. [10:12] jamesh: yes [10:13] jamesh: how about I guard it so it not going to crash, and then propose something around tryDiscoverDbusSessionBusAddress() as a new PR? [10:13] pstolowski: my suggestion would be (1) don't create the notification manager if s.bus is nil, and (2) have the REST API return an error if s.notificationMgr is nil [10:14] jamesh: yes, makes sense [10:14] miguelpires: what's your LP id btw, i already needed it before and couldn't find it ;) [10:15] pstolowski: Note that that tryDiscoverDbusSessionBusAddress() function is private. But it's already being used in the code to open a session bus connection. [10:16] pstolowski: miguelpires1 [10:16] miguelpires: thanks [10:17] jamesh: indeed, i need to see how it's used [10:17] with the session agent's exit on idle behaviour, I don't think it's a big deal if we've got a race where notifications might fail for the first 30 seconds of the session. It's just 16.04 after all... [10:18] pstolowski: here's the code calling tryDiscover...(): https://github.com/godbus/dbus/blob/master/conn.go#L76-L98 [10:18] jamesh: agreed [10:22] jamesh: thanks for the pointers [10:30] jamesh: actually, we are already guarding this with if c.s.bus == nil .. in postPendingRefreshNotification(), and return "cannot connect to the session bus (500) [10:31] pstolowski: right. The problem is that you're introducing code that assumes s.bus is non-nil in SessionAgent.Init() [10:31] that's the bit that's the problem. [10:33] jamesh: good point [10:55] pstolowski: so, my problem is that I don't understand how these ubuntu-core-* tests are run: in the spread they are declared with a classic distro as base (like ubuntu-16.04), and then somehow the core image is lanched from it. Maybe you know why it is like this? [10:56] mardy: whcih tests? [11:01] mardy: see prepare_ubuntu_core() and setup_reflash_magic() in tests/lib/prepare.sh [11:02] in essence it uses a classic Ubuntu system to build an Ubuntu Core image, writes it to /dev/sda, and reboots [11:21] jamesh: i've updated https://github.com/snapcore/snapd/pull/10867 [11:21] PR #10867: desktop, usersession: observe notifications [11:22] pstolowski: looking [11:27] pstolowski: looks good to me [11:30] jamesh: thank you! [11:43] mardy probably if you were given a uc18 image and you want to run spread tests on that image specifically, you should launch that image as a VM, then use the external backend to run the spread test you care about against your VM [11:43] mardy Sergio (who doesn't seem to be on IRC ATM) can help you with that, or I can show you in a bit, i don't have all the instructions in front of me right now [11:44] mborzecki: the test is ubuntu-core-18-64:tests/core/snapd-refresh-vs-services-reboots, more info in LP#1949089 [11:45] jamesh, ijohnson[m]: thanks, I'll give it a try [11:46] mardy for that rest specifically, i assume foundations built you a custom core18 snap to test, you could hack up the prepare.sh script to download that core18 snap instead of whatever one we normally download [11:47] *test [11:47] I still think external backend is simplest though [11:58] ijohnson[m]: I'm trying with the external backend, if it works I'll submit a PR to make the tests/externa-backend.md document mention this use-case too [12:01] PR snapd#9839 closed: tests: spread log analyzer that could be used for re execute failed tests <â›” Blocked> [12:05] ijohnson[m]: so, I think I'm quite close, but the test's prepare is failing: https://paste.ubuntu.com/p/TzjFRwNCGg/ (I started my UC image with the same command given in https://ubuntu.com/core/docs/testing-with-qemu) [12:36] PR snapd#10241 closed: tests: set memory limit for snapd [12:46] PR snapd#11004 closed: tests: give interfaces-udisks2 more time for the loop device to appear [12:46] PR snapd#11005 opened: tests: initialize CHANGE_ID in _wait_autorefresh [12:51] PR snapd#11001 closed: spread.yaml: show `journalctl -e` for all suites on debug [13:11] PR snapd#10706 closed: tests: clean up test tools [14:21] PR core20#120 opened: spread: add spread testing for the core20 repository [15:17] I noticed that snapd has a Recommends on gnupg, what does it use that for? [15:18] would it be fine with gpg; or optimally, gpgv? [15:25] * juliank is still in progress of reducing duplicate binaries :D [15:57] PR snapd#11006 opened: sandbox/cgroup: freeze and thaw cgroups related to services and scopes only [15:57] * mvo hugs mborzecki [16:27] PR snapd#10850 closed: o/snapstate: improve install/update tests [17:37] PR snapd#11007 opened: o/snapstate: test relink remodel helpers do a proper subset of doInstall and rework the verify*Tasks helpers [19:43] PR snapd#11008 opened: tests: some improvements for the spread log parser