=== jamesh_ is now known as jamesh [05:04] morning [05:21] good morning [05:30] mborzecki: will you be reworking https://github.com/snapcore/snapd/pull/6874/files? [05:30] PR #6874: cmd/snap-confine: do not mount over non files/directories [05:30] zyga: hey, yes [05:30] cool, thanks! [05:42] mborzecki: https://github.com/snapcore/snapd/pull/6873/reviews [05:42] PR #6873: gadget: improve device lookup, add helper for mount point lookup [05:42] zyga: thanks [05:50] mborzecki: I just pushed https://github.com/zyga/snapd/tree/wip/lp-1828354 (diff https://github.com/snapcore/snapd/compare/master...zyga:wip/lp-1828354?expand=1 ) [05:50] it doesn't nearly pass tests [05:50] I'm trying to understand which of the fragments of mimic construction breaks sharing [06:05] zyga: updated #6874 [06:06] PR #6874: cmd/snap-confine: do not mount over non files/directories [06:06] zyga: tagged it for .39.1 too === pstolowski|afk is now known as pstolowski [07:02] morning [07:04] pstolowski: hey [07:05] pstolowski: https://news.ycombinator.com/item?id=19929986 [07:07] zyga: hi. Do you know if anything came of the "desktop session agent" idea we brainstormed at the last engineering sprint? [07:08] zyga: and if the answer is nothing, would it be something worth while for me to work on? [07:16] mborzecki: uhmmm [07:17] mborzecki: they even mention xplane, wow [07:25] pstolowski: so you know, when you put that antenna on your balcony ;) [08:32] interesting read, if you're into that sort of thing: https://songlh.github.io/paper/go-study.pdf [08:32] zyga: i know you probably are ^ [08:36] PR snapd#6873 closed: gadget: improve device lookup, add helper for mount point lookup [08:36] jamesh: hey, not 100% sure if that's the topic but I think we agreed to use snap userd a lot more; having said that we're not doing anything towards that [08:37] Chipaca: thank you, queued [08:39] zyga: this was the idea of having a unix socket activated service in the user session that snapd could talk to [08:40] zyga: this could either be userd, but wouldn't necessarily be the same thing. [08:40] jamesh: note, I'm at a sprint now, partial focus [08:40] zyga: ah. [08:40] jamesh: I think that's the agreement [09:39] jamesh: I don't think we've ageed on anything byeond the general idea that there's a two way communication between system-wide snapd and per-user "aid" [09:41] zyga: okay. Would it be useful to start adding the infrastructure for the user agent? From my memory, we discussed socket activated user session service speaking an HTTP API similar to snapd [09:41] mborzecki: so because that wip branch I posted is arguably huge and the test there is hard to follow, I'm making a standalone shell script that illustrates the issue so that we can discuss this properly next week [09:42] jamesh: I think you need to get an ack from pedronis before you do that [09:42] zyga: ack [09:42] jamesh: explain that this is going towards bi-directional communication and this is the protocol idea and if you get an ack, work on it [09:43] jamesh: I would refrain from proposing thnigs that need design review before there's written agreement on what it is [09:44] zyga: okay. Would the forum be the best place to do that? [10:29] jamesh: yes, and a call as well [11:00] Chipaca: are you around? [11:00] Girtablulu: yes [11:01] remember my issue on solus with snapd 2.39 and creating the snapshot by removal? [11:02] Girtablulu: yes [11:02] well, no, but yes [11:02] i didn't remember it was you :-) [11:02] but i remember the issue [11:02] mborzecki: is --prune in 2.39.1? [11:02] Chipaca, hey, if you want to enjoy a bit you can take alook to https://github.com/snapcore/spread/pull/77 [11:02] PR spread#77: Add testflinger backend [11:02] cachio: sure! [11:03] cachio: and i get the impression you asked me to do something last night and i never did :-/ [11:03] well talked to JoshStrobl and he had a look and made this patch https://dev.getsol.us/source/snapd/browse/master/files/0001-Force-usage-of-sudo-over-runuser-on-Solus.patch, and he said we have to look into the util-linux if it's setup wrong on Solus [11:03] Chipaca, hehehe, it is ok [11:03] no hurry [11:03] Chipaca: isn't that wip still? pstolowski will know [11:03] mborzecki: i meant purge, and it's not even in master, so yeah [11:03] Chipaca, I need a final review for #6618 [11:03] PR #6618: tests: validates snapd from ppa [11:04] Girtablulu: wow [11:04] mborzecki, Chipaca: yes, not even in master, needs Samuele's review [11:04] Girtablulu: thanks for the update! that's very interesting [11:04] pstolowski: yep yep [11:05] Chipaca: np you said I should come back if a solution is found :) [11:05] Girtablulu: it does sound like something's awry in solus's plumbing, but glad that's getting sorted one way or another [11:05] pstolowski, hey, yesterday I could make work the user my keys to sing the models [11:06] but then testing I realized I need to make some changes for core18 [11:06] because the vms are not starting with the user1 [11:07] I'll try to have it working before standup [11:08] cachio: do systems start with numbers in testflinger? [11:09] Chipaca, no [11:09] names are alphanumeric [11:09] cachio: the change to validSystem seems bogus then [11:10] Chipaca, yes, you are right [11:10] should be something like [a-z]+[0-9]+ [11:11] cachio: the * seems intentional also [11:11] which you removed [11:11] but dunno [11:11] Chipaca, no, because the name enforced has a - between [11:12] ? [11:12] ah [11:12] you mean in testflinger systems can't have -s? [11:12] I need [a-z]+[0-9]+-[a-z0-9*] [11:12] no you don't :-) [11:12] Chipaca, the name enforced by default is like [11:12] cachio: what do you actually need? give me examples please [11:13] rpi-3-64 [11:13] and we need rpi3-64 [11:13] because then we use the rpi3 as name for testflinger [11:14] ah [11:14] Chipaca, rpi3 is the device name on tf [11:14] cachio: and do you know what systems have an '*' in them? [11:14] wondering what that was there for [11:14] Chipaca, no idea, I never seen one with * [11:15] let's ask gustavo :) [11:15] Chipaca, yes :) [11:15] niemeyer: in spread, why does the validSystem regexp allow explicit asterisks in the system name? "^[a-z*]+-[a-z0-9*]+(?:[-.][a-z0-9*]+)*$" [11:15] niemeyer: what's the use case for this? (examples? tests?) [11:18] cachio: in any case what you want is probably "^[a-z][a-z0-9]*-[a-z0-9]+(?:[-.][a-z0-9]+)*$" [11:18] cachio: modulo *s inside the []s pending gustavo's reply [11:18] cachio: that is, changing the [a-z]+ to a [a-z][a-z0-9]* [11:18] meaning there can be numbers in the first chunk as long as it doesn't start with numbers [11:19] perfect [11:19] cachio: simplest way forwards is to assume the *s are there for a reason, and replacing the [a-z*]+ with [a-z*][a-z0-9*]* [11:19] change done :) [11:20] Chipaca: Might be a bug depending on where this is used, but systems filtering allows wildcards [11:20] ah! +ubuntu-* etc? [11:20] cachio: there you go :) [11:20] Chipaca, niemeyer nice [11:21] cachio: so [11:21] I never tried it :) [11:21] cachio: ^[a-z*][a-z0-9]* instead of ^[a-z*]* and the rest stays the same [11:22] cachio: I'm pretty sure snapd tests depends on this [11:22] of course that means you couldn't say rpi* [11:23] e.g. tests/main/xdg-open/task.yaml:systems: [-ubuntu-core-*] [11:23] cachio: ^ [11:23] niemeyer, we run snapd tests like doing google: that should use the * as wildcard right? [11:23] cachio: it's for the filtering in tasks [11:24] cachio: No, that uses ... because wildcards are special for shells [11:25] cachio: I suspect you forgot to push to snapd#6618 [11:25] PR #6618: tests: validates snapd from ppa [11:26] niemeyer, ok, thanks for the explanation [11:27] niemeyer: ditto, thanks [11:27] nps! [11:27] Chipaca, right, pushing [11:32] Chipaca, pushed [11:35] cachio: ack, thanks for update! [11:43] pstolowski, I just pushed the new models I am trygin to make that work [11:44] pstolowski, to run the test you need to set the variable SPREAD_NEW_CORE_CHANNEL to edge [11:44] cachio: ack, ty, i'll try that [12:03] off to pick up the kids [12:04] * Chipaca lunches [12:13] how long should a refresh from of core from stable to candidate (2.39) take? It's taking forever here. [12:13] "snap changes" hasn't returned anything at all. [12:14] Consider re-refresh of "core" is all it says in the terminal where I am refreshing core [12:19] perhaps it's regenerating all apparmor profiles or something? [12:19] (yes, looks like that's what it's doing, incredibly slowly) [12:20] popey_: possible, ps aux and check for apparmor parser? i just checked and it was almost instant, but i have very few snaps [12:23] pstolowski: yes, i see a lot of apparmor parser in syslog. i have 260 snaps and this is taking an age and I'm not getting any feedback from the "snap refresh core --candidate" about what's happening [12:23] if I was a normal person, I would likely have turned my computer off right now [12:23] (not that a normal person has 260 snaps ofc) :D [12:24] \o/ finished [12:24] that was about 20 mins. not bad for 260 snaps :D [12:26] popey_: i agree, no feedback is problematic [12:27] something worth exploring/imrpoving [12:28] bbiab [12:54] popey_: this gets precisely to the snapd team's roadmap item to make this faster (cc zyga). snapd is calling apparmor_parser for *every* interface connect in every snap command rather than once per snap command [12:55] popey_: which makes it particularly terrible for you and as snaps get more popular [12:55] popey_: but, it's known and understood and now marked as a deliverable for the next cycle (last I saw) === ricab is now known as ricab|lunch [12:56] \o/ [12:56] https://www.youtube.com/watch?v=ZtAzeoA0UgE [12:56] [13:01] pstolowski: mborzecki: cachio: standup? [13:05] zyga: is bug 1825883 fixed in 2.39 or is there still some work to do? [13:05] Bug #1825883: stale copy of plug and slot attributes is kept in connection state [13:07] mborzecki: i thought for mkfs.extN you could avoid the root/non-root weirdness via root_user [13:08] PR snapcraft#2537 closed: dotnet plugin: fix parsing of newer sdk releases [13:08] Chipaca: is that an option for mkfs? [13:09] mborzecki: yes [13:09] mborzecki: under extended options [13:09] Chipaca: isn't that the owner of / only? [13:11] mborzecki: what else does it do that needs fakeroot? [13:12] Chipaca: ownership of all entries dropped into the fs, it's basically doing `mkfs.ext.4 -d ` [13:12] s/ext.4/ext4/ === ricab|lunch is now known as ricab [15:31] * cachio lunch [16:08] Bug #1829558 opened: Unable to install fwupd === pstolowski is now known as pstolowski|afk [16:31] kenvandine: pstolowski|afk did the fix in reduced capacity for 2.29 but I don’t remember if that is .0 or .1 [16:36] zyga: 29, or 39? [16:36] i'm sure it had to be 39 [16:41] kenvandine: I _think_ it's e4c706fb7bf9f19279d54f1ce610ef2bbfaae8b1/b2c48938155f8e05f53843fe718e6f326c0362ec but I can't see that in any tag [16:41] kenvandine: mvo will know for sure [16:42] if i'm right, then not in any tag → not in 2.39; hopefully 2.39.1 [16:42] but if you need certainty (heh) ask mvo [16:43] i'll talk to him on monday [17:01] EOW, ttfn [17:53] pstolowski|afk, I pushed the change in the model to make the nested vms start correctly [17:53] and other changes [17:54] the problem is that the qemu is not appearing when doing snap connections system [17:54] pstolowski|afk, it is easy to reproduce by running: SPREAD_NEW_CORE_CHANNEL=edge spread -debug google-nested:ubuntu-18.04-64:tests/nested/core/hotplug [17:54] still missing the change to reuse the test script [17:55] pstolowski|afk, but first I want to make it pass :) [18:17] cachio: thanks, I’ll check it, the symptoms are as if my fix isn’t present or was not sufficient [18:18] pstolowski|afk, when was it merged? [18:18] it should be on edge [19:03] * cachio afk