[03:39] PR snapd#8429 opened: github: port CLA check to Github Actions [05:40] morning [06:20] mvo: hey [06:21] Hey [06:21] Please merge my last PR into master and merge master into your branches. [06:21] zyga: hey [06:22] zyga: here's a simple one porting another job off Travis: https://github.com/snapcore/snapd/pull/8429 [06:22] PR #8429: github: port CLA check to Github Actions [06:22] zyga: which one is that? this one https://github.com/snapcore/snapd/pull/8428 [06:22] PR #8428: tests/session-tool: stop cron/anacron from meddling [06:22] jamesh: thanks! [06:23] zyga: also, I'm not convinced that the use of actions/cache@v1 for the apt cache actually works [06:23] (the way it is written, I don't think it will ever get a cache hit) [06:23] That one [06:24] jamesh: I noticed [06:24] Something is off [06:24] Do you know what the issue is? [06:24] hey mborzecki, good morning [06:25] jamesh: quick question about gtk2, we have gtk2-common-themes snap, but one would still need the right theme engine to render those, isn't that right? [06:26] jamesh: asking in the context of https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3 which looks like the snap plugs gtk2-common-themes, but when starting there's a log about missing pixbuf engine to render the adwaita-like theme with gtk2 [06:28] zyga: ah. you're doing the chown on /var/cache/apt after calling actions/cache, so the action does not have permission to write to that location [06:29] Mmmmm [06:30] So we need two chowns [06:30] zyga: It's not obvious that it is a good use of caching anyway: the cache key you're using doesn't specify exact revisions of packages, so each user could be testing against a different set of packages [06:30] Or update the action to a version that fixed this and uses sudo [06:30] We rarely rev our dependencies [06:31] mborzecki: gtk2-common-themes only contains theme engines. We left the actual theme data files in gtk-common-themes, since most GTK 2 themes are distributed beside their GTK 3 counterpart these days [06:31] So it is not a perfect set but a sufficient set [06:31] jamesh: so gtk2-common-themes is effectively dead? [06:32] mborzecki: no. You need theme data files plus any engines the theme uses [06:32] mborzecki: this is also a split between platform independent data files (gtk-common-themes), and platform dependent engines (gtk2-common-themes) [06:33] maybe we should have named the second package gtk2-common-engines [06:39] zyga: It might also be a good idea to combine some of the spread tests back into fewer jobs: it's nice not having mingled output, but we're obviously hitting Github's runner limits now [06:40] jamesh: I will surely consider that but over weekend we also hit limits on our account in GCE [06:40] now that we actually run spread when we push stuff [06:40] we run out of capacity quickly [06:40] we need to measure and count and decide [06:41] jamesh: hmm so the gtk2-common-themes engines part content is connected, the snap sets GTK_PATH in meta/snap.yaml, but once the process runs GTK_PATH is set to a different path :/ looks like it's coming from desktop-launch [06:45] * zyga breakfast [06:48] jamesh: looks like GTK_PATH ends up without the location where the engines from gtk2-common-themes snap are, i added a note under https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3 [06:56] zyga: when you have a moment, a look/merge of https://salsa.debian.org/debian/snapd/-/merge_requests/5 would be great [06:58] ehh 1080p is such a downgrade from 4k [06:58] o/ [06:58] at my desk [06:58] mvo: looking [06:59] mborzecki: display change? [06:59] morning [06:59] zyga: yeah, had to rma the 4k one, so i'm using my old 1080p display now [07:00] zyga: not ugent but it will bring the packaging git trees in sync again [07:00] pstolowski: hey [07:00] ta [07:00] good morning pawel [07:00] zyga: which is ironic, since it's also lg, 10+ years and not a single bad pixel [07:00] hmm, salsa doesn't load for me, feels like none of the JS bits are getting loaded [07:03] mvo: commits 8482? is this bundled with development history? [07:04] (this explains why js is slow to load) [07:05] zyga: yes, I think that's how we setup our branch [07:05] zyga: it contains all the history [07:05] ta [07:06] zyga: TBH i have no idea why this style is popular, I think it's kinda useless [07:07] maybe easier for cherry picking patches [07:07] libzt uses separate history [07:07] anyway [07:07] approved [07:07] PR snapd#8430 opened: packaging: use debian/not-installed to ignore snap-preseed [07:08] mvo: I see you have two more extra PRs there [07:08] but I guess they are obsolete now [07:09] mvo: closed both, please shout at me if I was meant to land them instead [07:10] zyga: probably fine, I forgot those [07:10] zyga: that was when we were not directly involved I think [07:10] aha [07:10] looking at 8430 [07:10] do you know what's broken in our sid tests? [07:11] mvo: can you review and land https://github.com/snapcore/snapd/pull/8428 please [07:11] PR #8428: tests/session-tool: stop cron/anacron from meddling [07:11] it will prevent random failures on centos 7 [07:11] looking at this branch I also wonder if we should do a pass and review the timers and background services in our images [07:11] who knows what else is randomly running [07:12] zyga: yeah, I have a look soon, just need to finish my current task [07:12] thanks [07:13] zyga: is there anything like "skip-spread" in the new gh-actions world? just an idle thought [07:13] mvo: not yet, we can certainly code it [07:13] actions has enough logic for it [07:14] https://github.community/t5/GitHub-Actions/Labeled-action-on-pull-request/m-p/37839#M3093 has some ideas [07:14] we can just get the context as a json object, select the labels and skip the whole spread part if a particular one is set [07:14] mvo: if it's not urgent I'll do it in the evening [07:15] actually [07:15] zyga: nice, not urgent at all [07:15] https://stackoverflow.com/questions/59588605/how-to-check-for-a-label-in-a-github-action-condition [07:15] is even easier [07:15] if: contains( github.event.pull_request.labels.*.name, 'My Label') [07:15] we could just do [07:15] if: !contains( github.event.pull_request.labels.*.name, 'Skip Spread') [07:16] PR snapd#8428 closed: tests/session-tool: stop cron/anacron from meddling [07:16] thanks for that mvo ^ ! [07:17] pstolowski, jamesh, mborzecki, mvo: gentle reminder to merge master into any branches you push or iterate on [07:17] mainly to get the fail-fast: false part [07:17] ack [07:17] I will share details at the standup [07:22] mvo: pstolowski: hi, I would appreciate reviews for https://github.com/snapcore/snapd/pull/8427 it's huge but is splitting files up basically, except for reorganizing things such that we can have mutiple store* test suites [07:22] PR #8427: store: start splitting store.go and store_test.go into subtopic files [07:23] over weekend I noticed the ubuntu archive was failing again, I reported this to IS but they asked for more details. If this happens frequently we should cook a patch that prints the IP address of the node in case "apt-get *" fails [07:23] pedronis: sure, will do [07:38] pedronis: ok, thanks, I have a look. so this is no code change, just reorg? [07:38] mvo: yes [07:40] mvo: description and commit summary should hopefully be understandable [07:40] ta [07:42] mvo: can you take another look at https://github.com/snapcore/snapd/pull/8415 ? [07:42] PR #8415: cmd/snap-recovery-chooser: tweaks [07:43] mborzecki: sure thing! [07:43] mvo: thanks! [07:48] hehe firefox chokes on the full diff in #8427 [07:48] PR #8427: store: start splitting store.go and store_test.go into subtopic files [07:51] brb [07:55] fwiw, I updated the branch protection rules for master so that all stable gh actions need to be successful [08:31] The GH Actions workflow should probably also be updated to run on pushes to master and release branches. At present, only the unit tests are being run for pushes to master [08:48] re [08:48] jamesh: we had something similar but I agree, we wanted not to test a push and a PR at the same time [08:48] jamesh: but I think we should do tests on PRs for both master and release branches [08:53] PR snapd#8431 opened: github: give jobs shorter names [09:04] PR snapd#8427 closed: store: start splitting store.go and store_test.go into subtopic files [09:08] mvo: mborzecki: thanks [09:14] PR snapd#8218 closed: [RFC] cmd/snapd, daemon/snapd: use multi call binary <⛔ Blocked> [09:16] Bug #1871058 opened: Tell how many bytes "install" will take [09:19] Bug #1871060 opened: Don't hide each step after it completes [09:28] PR snapd#8432 opened: travis.yml: disable unit tests on travis [09:32] #8411 needs 2nd reviews [09:32] PR #8411: boot: cleanup more things, simplify code [09:33] jamesh: https://github.com/snapcore/snapd/pull/8429#issuecomment-609683448 [09:33] PR #8429: github: port CLA check to Github Actions [09:34] mvo: https://github.com/snapcore/snapd/pull/8432#pullrequestreview-388082166 [09:34] PR #8432: travis.yml: disable unit tests on travis [09:36] hmm seems like ijohnson's standup notes were cut short or he didn't manage to publish the snapd branch of grub.cfg on friday [09:38] zyga: thanks, replied [09:39] mvo: I replied twice there, weird stuff [09:42] I think we are leaking session from tests/main/snap-session-agent-service-control [09:43] they break tests/main/snap-confine-undesired-mode-group [09:47] pedronis: mvo: looking into adding 'recover' and 'run' modes into system actions, and actually i'm wondering a bit about run, it doesn't make sense to have run for other system than current, does it? [09:49] mborzecki: no, it's only for current [09:50] we discussed that in Frankfurt [09:50] pedronis: ok, let me check the notes [09:50] mborzecki: +1 - nly relevent for current [10:05] mvo: pedronis: doesn't look like we put that down in the notes, nevertheless i take that recover applies to the current system only too [10:11] zyga: that seems like a good idea, especially since we can't use the job as a prereq for jobs that should run on pushes [10:11] +1 [10:12] zyga: the macos test should be fairly easy to move over to GH Actions too. At that point, the main thing the Travis job is doing is coverage [10:12] yeah [10:13] the test coverage provider we use has a dedicated action IIRC - we could adopt it [10:19] and codecov's first party action also downloads and executes a shell script... [10:19] of course it does :) [10:26] brb [10:55] re [11:17] zyga: hm that centos7 session-tool restore is still failing [11:17] and travis is green fwiw [11:18] mborzecki: same was as you showed me? [11:18] yeah [11:18] session that was running before the test closes during the test [11:18] ok, I'll switch gears to that in a moment [11:18] ta [11:18] tbh making gh actions spread jobs as require feels a bit premature [11:19] why? [11:19] note that travis doesn't run spread anymore [11:20] zyga: bc we cannot restart just one job [11:20] I see [11:20] I disagree but I wanted to understand [11:20] note that we can collapse all spread runs into one big run [11:20] and have that instea [11:20] *instead [11:23] zyga: that'd make it the same as it is now [11:24] we've traded ability to restart half the workers for being able to get tests started faster [11:24] (and having control over how many workers we can run) [11:25] mvo: hey! do you guys saw issues with a not existing /run/snapd-snap.socket on configure hook execution recently? Running quite frequently into https://paste.ubuntu.com/p/qQGSQjRjM7/ with snapd 2.44.1 [11:27] to be precise, snapd isn't restart and was active all time. [11:27] morphis: what is the status of the socket? [11:27] I suspect it's in CI but perhaps you know [11:28] I have a shell active so happy to debug [11:28] please start with systemctl status snapd.socket [11:28] zyga: socket is active and happy for >1h [11:28] morphis: both? [11:29] Listen: /run/snapd.socket (Stream) [11:29] /run/snapd-snap.socket (Stream) [11:29] ^ that's what I get on my box [11:29] https://paste.ubuntu.com/p/phZ4H7SGXb/ [11:29] jepp, same here [11:29] ok [11:29] and is /run/snapd-snap.socket really there on disk? [11:29] yes, touched an hour ago [11:29] ok [11:29] can you jump into the mount namespace of lxd [11:29] and then check if the socket is there [11:30] sudo nsenter -m/run/snapd/ns/lxd.mnt [11:30] this will give you a shell in the mount namespace of lxd [11:30] just check if the sockets are there as well [11:31] yes, exists there too [11:31] can you CURL to it? [11:31] or maybe instead [11:31] can you snapctl to it? [11:33] ah, I think I know what happens here [11:34] it's a race between `snap install lxd` and `snap set ..` [11:34] something we should prevent from the charm side [11:35] that matches with the dates the socket within the lxd ns is created and the snap got installed and the last time the error occurred in the juju output [11:37] morphis: cool [11:37] morphis: are you saying lxd doesn't really work after snap install lxd [11:37] in the sense that snap set is invoked too early? [11:37] PR snapd#8433 opened: overlord/devicestate: support for recover and run modes [11:38] it looks like we invoke `snap set` while performing `snap install` [11:38] as in during? [11:38] yeah that would not work [11:38] jepp [11:38] makes sense that it doesn't work [11:40] zyga: is there a simple `snap wait-until-install lxd` thing? [11:40] I don't think there is [11:41] ok [11:42] well, the configure hook runs after install [11:42] perhaps move your stuff over to it ? [11:42] morphis: hmm snap watch --last=install? could work [11:42] mborzecki: interesting [11:44] morphis: though it's still racy, since you'd expect the install to be started already to watch it [11:44] morphis: may I ask how do you run the two operations concurrenctly? [11:48] zyga: it's a problem in our charms I can fix on that level, was just looking for a hotfix [11:48] I see [11:48] ok [11:54] mborzecki: testing a fix for what you found now [11:54] zyga: cool thanks [11:55] cachio: hey [11:55] cachio: are you around? [11:55] zyga, yes [11:55] hi [11:55] hey [11:57] hey mborzecki sorry I didn't finish putting the snapd branch for grub.cfg things in the SU doc [11:57] I just put it in there if you wanted to take a look, it's quite simple [12:05] ijohnson: no biggie, i worked on adding the recovery/run modes to devicemgr [12:08] PR snapd#8431 closed: github: give jobs shorter names [12:10] * zyga breaks for a moment, [12:11] mborzecki: I've started reviewing 8433 [12:15] zyga: thanks [12:16] hi pedronis did you have a chance to look at how I organized things in #8424 at all ? [12:16] PR #8424: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting [12:17] PR snapd#8434 opened: systemd: move the doc comments to the interface so their are visible [12:17] pstolowski_: ^ [12:20] ijohnson: I skimmed it, I didn't see anything unreasonable... but there's some comments about details from others [12:21] pedronis: ok, sure I will continue on with it [12:21] pedronis: I just didn't know if you would have opinions on having stuff in the boot package vs in the partition package of snap-bootstrap, etc. [12:21] pedronis: I assume you will have opinions on the names of things and that's fine to rename later :-) [12:28] * zyga breaks for lunch, see you soon [12:29] PR snapcraft#3013 closed: plugins: use v1 import path for all plugins [12:38] PR snapcraft#3014 opened: meta: migrate get_build_base to Snap [12:50] hey ogra, is your zoom-client snap supposed to work with nvidia drivers? I tried it with 440 drivers on Sunday and it crashed on me [12:51] PR snapd#8430 closed: packaging: use debian/not-installed to ignore snap-preseed [12:51] PR snapd#8432 closed: travis.yml: disable unit tests on travis [13:34] ijohnson, works gret with everything but nvidia-440 [13:34] *great even [13:35] ijohnson, https://github.com/ogra1/zoom-snap/issues/2 [13:36] is this an issue with the 440 drivers in general with snaps? [13:37] due to the awful nature of the zoom binary (forcefully setting LD_LIBRARY_PATH to ./zoom (and ./zoom only) on app startup) i actually need to LD_PRELOAD the drivers ... and -440 somehow refuses to load libOpenGL.so for no apparent reason [13:37] diddledan, there used to be one but zyga has fixed that ... i asked people to try snapd from edge but that didnt help [13:37] ogra: ack I can try with 390 or 435 then instead [13:37] -400 has a new directory structure and seemingly the linkage between the libs is differet [13:38] err [13:38] -440 indeed [13:39] aah, yeah, I see that message now on https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/15 - I must have overlooked it [13:39] right ... but that is supposed to be fixed [13:39] gotcha :-) [13:39] * diddledan goes snooping to see what the fix was [13:39] and according to the logs users actually have the proper content in /var/lib/snapd/lib/gl ... [13:40] so it is something with the LD_PRELOAD load order that i need to research to get t going (but for that i need a system that runs -440 ... my nvidia equipped desktop is still on 16.04 for which that driver doesnt exist) [13:41] I just took my nvidia card out to move it into my plex server [13:41] I now have reasonable transcoding on the fly for plex though, so WINNING [13:42] but you cant use zoom-client on it ! [13:42] :D [13:42] I had to install the deb variant of plex though. something in the snap config is unable to do hardware transcoding [13:43] mvo: so I guess this means you approve of my incoming valve index :D [13:43] and on the upside - everyone can then test on their nvidia GPUs [13:43] zyga: haha [13:43] man, we will catch all the bugs this way [13:43] the quality of nvidia support will skyrocket after this happens [13:43] snapd: add half life alyx support [13:43] snapd: fix level 3, achievement #42 [13:44] I vote for leaving a few gotchas to keep the users on their toes [13:44] snapd: fix 2nd playthrough ... [13:44] ;-) [13:44] PR #42: rework filelock to make it less surprising wrt flock(2) semantics [13:53] PR core20#35 opened: run-snapd-from-snap: log first snap watch better [13:55] Issue core20#36 opened: SSH login shell says the system was minimized and to run "unminimize", but should not [13:56] PR pc-amd64-gadget#38 closed: grub.cfg-recovery: fix typo, filter vars when loading them [14:00] jdstrand: where's the trello card for the appstream-metadata inteface fixes? I want to link it to mine card, but must be looking at the wrong board [14:24] Issue pc-amd64-gadget#41 opened: Hide the menu by default [14:30] mborzecki: https://github.com/snapcore/snapd/pull/8433#pullrequestreview-388194361 [14:30] PR #8433: overlord/devicestate: support for recover and run modes [14:39] mvo: I wonder if we should add some of my hosted workers to the pool [14:39] to spread the load [14:40] spread the spread ? [14:40] exactly [14:50] kenvandine: hey, I privmsg'd you [14:57] jdstrand: hello :) [14:57] jdstrand: thank you for the review from Friday [14:57] sure, I need to finish and followup [14:57] jdstrand: the tracking PR will be ready soon, there's a core20 issue still, where some packages related to dbus are missing, but it should be ready soon [14:57] and hi [14:57] ok [14:57] jdstrand: not end of the story but looking like something we could look at merging soon [14:58] jdstrand: I'll spend some more time on your feedback tomorrow, today I'm trying to wrap up that core20 problem first [14:59] great! :) [15:02] * cachio lunch [15:06] PR snapd#8435 opened: configcore,tests: fix setting watchdog options on UC18/20 [15:13] mvo: hey, so it sounds like you will roll another 2.44 point release for some policy updates? [15:14] jdstrand: if it's just safe policy updates I can do that [15:14] jdstrand: at this point I want to keep the risk minimal [15:14] mvo: is later today ok? [15:14] jdstrand: yeah [15:15] ok, I'll do a couple low risk PRs then [15:15] I'll target 2.44, 2.45 and master [15:15] jdstrand: or in my morning tomorrow [15:15] jdstrand: ok [15:15] jdstrand: 2.44 and master is fine, 2.45 is not branched yet [15:22] mvo: ah, ok, thanks [15:35] * zyga runs an errand in the office [15:36]