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