[06:15] morning [06:30] mvo: hey [06:30] good morning mborzecki ! [07:06] o/ [07:06] good morning [07:08] * zyga starts the day with https://github.com/snapcore/snapd/pull/9446 [07:08] PR #9446: overlord,usersession: initial notifications of pending refreshes [07:13] mornings [07:15] :-) [07:20] zyga: pstolowski: hey [07:21] o/ [07:39] pedronis: hi, shall we have a chat at 10? [07:39] mborzecki: I have the desktop meeting at 10 [07:39] pedronis: i can do now if you're not busy :) [07:39] I can I suppose [07:39] ok, heading to standup HO [08:38] mvo, https://forum.snapcraft.io/t/snapd-localisation/20696 (via jamesh) [08:42] zyga: thank you! yeah, we should totally tackle this one [08:42] zyga: and when I say we I should probably say I [08:42] zyga: added to trello, have some things now but will look at it soon [08:51] jamesh, building now, I'll just test it quickly on my system [08:55] zyga: awesome! [09:03] very tentative https://github.com/snapcore/snapd/compare/master...zyga:feature/share-x11-sockets?expand=1 [09:13] hi everyone [09:19] jamesh, 9530 tested locally [09:19] no tests or anything [09:23] PR snapd#9530 opened: interfaces: x11 shares hosts /tmp/.X11-unix/ [09:28] PR snapd#9531 opened: tests: add a unit test for UpdateMany where a single snap fails [09:29] jamesh, asked amurray for review [09:35] pstolowski: comment in 9531, thanks for it [09:38] pedronis: sure, thanks for the comment [09:40] zyga: I've left some initial comments. [09:41] thx [09:42] jamesh, yeah, I agree with all that you said [09:42] jamesh, note that the mount point cannot be removed or renamed so at least that part should be safe [09:42] zyga: hmm. I thought I remembered being able to move a bind mountpoint in the past [09:44] Is snapcraft's “build” parameter currently unsupported with the multipass build provider? When I shell into the VM and run `snapcraft build my-part` it works; the same command from the macOS host results in a complete build. [09:55] jamesh, I think you can move with MS_MOVE but not otherwise [09:57] mvo: do you think any of the helpers from https://github.com/snapcore/snapd/pull/9457 makessense? if not, i'll close it. they are a bit heavy [09:57] PR #9457: [RFC] o/snapshotstate: test for roundtrip with corrupted zip file inside exported snapshot [10:00] zyga: ah. It's the source directory you're free to move [10:11] zyga: One more question on the PR, about what happens when the slot snap's private tmp directory doesn't exist [10:12] jamesh, snap-update-ns will create it [10:12] zyga: sure, but will it create it correctly? [10:12] jamesh, there's some logic around this but it can be done [10:13] there are differences between source/destination [10:13] (for good reason) [10:13] but it can be done [10:16] jamesh, the only gotcha is https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/change.go#L209 [10:17] this needs adjusting [10:17] to take Assumptions into account [10:17] so that if we can write to a location, we can just do it [10:18] zyga: one last horrible case: what if an x11 plug is connected to an x11 slot of the same snap? [10:18] jamesh, that's also ok [10:18] jamesh, it will mount /tmp/.X11-unix over itself [10:18] jamesh, createPath used there takes assumptions alreadyu [10:18] zyga: how urgent is 9530? [10:19] zyga: and maybe make it read only [10:19] jamesh, and /tmp is whitelisted [10:19] amurray, I defer to jamesh [10:19] I realise X11 snaps are broken on wayland on groovy so I am guessing urgent-ish but since this is now a 0day SRU for snapd can it wait till next week? [10:20] amurray, I think so [10:20] jamesh: https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/change.go#L112 is the relevant point [10:20] we use assumptions object to compute the restrictions for the path we are about to create (/tmp/.X11-unix) [10:20] and then pass the restrictions to MkdirAll [10:21] ok let me know if it gets more urgent otherwise I'll take a look on Monday (or perhaps we'll be lucky and I'll get some time tomorrow) [10:21] amurray, +1 [10:21] amurray, it's not for this release [10:21] amurray: I've got an upstream PR to fix Mutter 3.38. If that patch is accepted and pushed out to existing distros with Gnome 3.38.x (currently Ubuntu 20.10 and beta Fedora?), then it is "in the next 6 months" priority. If we can't get the patch rolled out, then fairly soon [10:21] jamesh: yeah I saw that (and it seems upstream is not super motivated?) [10:22] jamesh, finally restrictions get passed to MpPrefix and MkDir in which both check if creating the directory is allowed (e.g. https://github.com/snapcore/snapd/blob/b2e238d229b8f4a686122ec6543842c97b8b25c3/cmd/snap-update-ns/utils.go#L175) [10:22] amurray: I think there's a very good chance that it'll make it into the 3.38.x branch [10:22] oh nice [10:22] amurray: there's some people who'd prefer the abstract sockets didn't exist period, but it hasn't just broken snaps [10:24] amurray: I think they'll consider removing them as a conscious choice in Gnome 4.0 [10:55] * pstolowski lunch [11:00] brb [11:00] PR snapcraft#3331 closed: spread tests: move package-repositories test snaps into own dir [11:01] PR snapcraft#3332 opened: storeapi: remove bindings for history [11:14] pstolowski: was in various meeting, I have a look later today/tomorrow [11:21] ijohnson: I reviewed 9489, the last small changes seem a bit off to me, also seems tests never started [11:23] re [11:45] pedronis: I'll have a look after our meeting, /me is still having breakfast [11:54] pstolowski: did a pas on #9527, some questions there [11:54] PR #9527: o/snapstate: implement undo handler for unlink-snap [11:59] PR snapd#9532 opened: tests: clean systems.sh helper and migrate last set of tests [12:07] pedronis: thanks [12:56] mvo_, I've updated https://github.com/snapcore/snapd/pull/9446 with lots of tests [12:56] PR #9446: overlord,usersession: initial notifications of pending refreshes [12:57] mvo_, I think it needs a second review now [12:57] mvo_, and I can follow-up with removal of warnings [12:58] mvo_, I'd also like to add very basic persistency [12:59] mvo_, so that old message, for a given snap, is updated instead of appended [12:59] mvo_, that will work fine for as long as you don't log out [12:59] PR snapd#9533 opened: tests: new systemd-state tool [12:59] and notifications are not persistent across logout, so that seems perfect to me [12:59] mvo_, we can also discard the notification when the snap does refresh [13:06] PR snapcraft#3321 closed: meta: add error check for "command not found" [13:16] PR snapcraft#3333 opened: specifications: finalization of package repositories spec [13:59] errands time [14:12] zyga, hey, could you please take a quick look to #9414 [14:12] PR #9414: tests: new nested tool [14:12] I update based on your comments [14:40] back from lunch [14:40] cachio, sure [14:40] zyga, tx [14:44] small errand, need to order some lights [14:44] then back to reviews [14:51] cachio, https://github.com/snapcore/snapd/pull/9414#pullrequestreview-514814755 [14:51] PR #9414: tests: new nested tool [15:30] mvo, I have two follow-up branches that remove warnings on inhibited refreshes [15:31] zyga: \o/ [15:31] mvo, and re-factor inhibitRefresh itself, to remove some duplication and explain the flow better [15:31] zyga: I guess you just need a second review for the initial one [15:31] https://github.com/snapcore/snapd/pull/9446 needs the 2nd review [15:31] PR #9446: overlord,usersession: initial notifications of pending refreshes [15:31] exactly so [15:32] perhaps jamesh could do a review of that branch? [15:33] or ian, not sure if anyone has time [15:39] * zyga EODs [15:40] I think jamesh reviewing #9446 if he can would be great [15:40] PR #9446: overlord,usersession: initial notifications of pending refreshes [15:40] yeah [15:40] definitely the best person with the right insight [15:44] zyga: you can request a review from me, I need to be doing more reviews really :-) [15:44] pedronis: I updated #9489 is ready for a re-review [15:44] PR #9489: daemon,client: write and read a maintenance.json file for when snapd is shut down [15:44] still no idea why the tests never started there but they are running now so /shrugs [15:48] pedronis: also is this TODO:UC20: 1.0 material ? https://github.com/snapcore/snapd/blob/master/cmd/snap-bootstrap/cmd_initramfs_mounts.go#L497 [15:48] or is that todo immaterial now that we seal against the model ? [15:51] because we measure the model is indeed not super relevant [15:51] with ARM we'll need to do something about that though but probably before we get there anyway [15:54] pedronis: so not for 1.0 then ? [15:54] indeed [15:54] ok [15:54] thanks for confirming [16:00] ijohnson: I re-reviewed #9489, thanks for the fixes there [16:00] PR #9489: daemon,client: write and read a maintenance.json file for when snapd is shut down [16:00] some small things [16:00] thanks I'll take a look in a second, working on 9418 right now [16:01] thx [16:05] Hello! [16:05] For some reason, `snap-store` isn't creating a window [16:07] When I installed it, I got: INFO snap "snap-store" has bad plugs or slots: appstream-metadata (unknown interface "appstream-metadata"); packagekit-control (unknown interface "packagekit-control") [16:07] whats the full output of "snap version" ? [16:08] snap 2.45, snapd 2.45, series 16, debian 10, kernel 4.19.0-10-amd64 [16:09] wait, i ran that command in an ssh [16:09] on this laptop snap and snapd are 2.37.4-1+b1 [16:09] oh and i just got a gui from snap-store [16:09] like, 15 minutes to half an hour after i started it [16:10] i think it pulls all metadata from some remote location on first run or some such [16:10] okay [16:10] 2.37 is rather old, is that also debian ? [16:11] yeah, i'll do a sudo apt upgrade [16:11] so the whole point of me installing snap-store was I was hoping there'd be some permission sliders [16:11] but i'm not seeing any for solarus [16:11] (it is likely correct that these interfaces do not exist in that old snapd, that probably also has some effect on the startup speed) [16:12] i want to enable permissions for joystick detection for the package solarus [16:12] snap connections solarus [16:12] that should output all interaes that snap has enabled [16:12] and show if they are connected [16:12] i did, nothing's connected [16:12] *interfaces [16:13] so use "snap connect sloarus:" to connect it [16:13] i.e.: snap connect solarus:joystick [16:13] error: cannot resolve connection, slot snap name is empty [16:14] hmm, you shouldnt need to define a slot name for jyostick normally [16:15] is it possible to update snap with snap? [16:15] i just quickly installed solarus here and the above command definitely works for me [16:16] $ snap connect solarus:joystick [16:16] $ [16:16] this is interesting, on my other laptop where snap version says 2.45, I have snap 2.37 installed with apt [16:16] $ snap connections solarus|grep joy [16:16] joystick solarus:joystick :joystick manual [16:16] and it shows as manually connected [16:16] yeah, snapd can update itself from the snapd snap [16:17] (and will re-execute itself into the snap version on startup) [16:17] error: snap "snap" not found [16:18] what did you try ß [16:18] ? [16:18] oh snapd [16:18] not snap [16:18] yeah [16:19] error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet [16:20] try: snap install core18 snapd [16:21] (core18, core and cor20 are base snaps) [16:21] snap list shoes core18 is already installed [16:21] oh, then i dont know [16:22] what if i install core instead of core18? [16:22] * ogra is a spoiled ubuntu user ... doesnt have to jump through such hoops here 🙂 [16:22] try it, yeah [16:23] are there snap repos other than canonical's repo? [16:23] nope [16:23] so flatpak is more decentralized? [16:24] dunno, i'd call it fragmented 🙂 [16:25] well it's fine until canonical starts pushing developers around by threatening to take apps of the snap repo [16:25] that's what apple does [16:26] well, apple has a business model around selling single apps ... canonical doesnt [16:27] (canonical sells sub-stores to business customers ... i doubt the apple model will ever be interesting for the global store) [16:28] though there is https://forum.snapcraft.io/t/apps-that-promote-hate-speech-and-violence-dissenter-browser/19537 ... [16:29] in which case i think it is a really good thing that there is a central store to avoid spreading of such software [16:42] What does "Waiting for server to restart" mean? Do I have to restart my computer now? [16:43] oh nvm [16:45] Alright, let's see if my xbox controller will work on zelda mystery of solarus now [16:47] It works!!! [17:16] Copenhagen_Bram, congrats [17:28] re\ [17:29] ijohnson: if you want to then https://github.com/snapcore/snapd/pull/9446 is ready, but I think we would still like a review fro jamesh for the desktop elements [17:29] PR #9446: overlord,usersession: initial notifications of pending refreshes [17:45] zyga: ack maybe I will look then tomorrow [17:45] ah that's the one I've looked at already [19:12] PR snapcraft#3332 closed: storeapi: remove bindings for history [19:22] PR snapcraft#3334 opened: package repositories: improve error handling [21:11] * ijohnson EODs [21:39] Does the latest version of snappy resume downloads if interrupted? [21:40] I have slow internet right now, and I had to run `until sudo snap install solarus; do sleep 1; done` to get solarus installed. It still filled my screen with many 'connection reset by peer' errors, until it finally was lucky enough to finish the download without an error [21:41] I wish developers wouldn't assume everybody has at least 1MB/s speed [22:04] Copenhagen_Bram: snapd should auto-retry refreshes, I don't know if we have the same logic for installs, could file a bug on launchpad ?