=== jamesh_ is now known as jamesh | ||
mborzecki | morning | 05:04 |
---|---|---|
zyga | good morning | 05:21 |
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:30 |
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:42 |
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 | 05:50 |
mborzecki | zyga: updated #6874 | 06:05 |
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 | 06:06 |
=== pstolowski|afk is now known as pstolowski | ||
pstolowski | morning | 07:02 |
mborzecki | pstolowski: hey | 07:04 |
mborzecki | pstolowski: https://news.ycombinator.com/item?id=19929986 | 07:05 |
jamesh | zyga: hi. Do you know if anything came of the "desktop session agent" idea we brainstormed at the last engineering sprint? | 07:07 |
jamesh | zyga: and if the answer is nothing, would it be something worth while for me to work on? | 07:08 |
pstolowski | mborzecki: uhmmm | 07:16 |
pstolowski | mborzecki: they even mention xplane, wow | 07:17 |
mborzecki | pstolowski: so you know, when you put that antenna on your balcony ;) | 07:25 |
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:32 |
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:36 |
zyga | Chipaca: thank you, queued | 08:37 |
jamesh | zyga: this was the idea of having a unix socket activated service in the user session that snapd could talk to | 08:39 |
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 | 08:40 |
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:39 |
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:41 |
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:42 |
zyga | jamesh: I would refrain from proposing thnigs that need design review before there's written agreement on what it is | 09:43 |
jamesh | zyga: okay. Would the forum be the best place to do that? | 09:44 |
zyga | jamesh: yes, and a call as well | 10:29 |
Girtablulu | Chipaca: are you around? | 11:00 |
Chipaca | Girtablulu: yes | 11:00 |
Girtablulu | remember my issue on solus with snapd 2.39 and creating the snapshot by removal? | 11:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
cachio | I'll try to have it working before standup | 11:07 |
Chipaca | cachio: do systems start with numbers in testflinger? | 11:08 |
cachio | Chipaca, no | 11:09 |
cachio | names are alphanumeric | 11:09 |
Chipaca | cachio: the change to validSystem seems bogus then | 11:09 |
cachio | Chipaca, yes, you are right | 11:10 |
cachio | should be something like [a-z]+[0-9]+ | 11:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:18 |
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:19 |
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:20 |
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:21 |
niemeyer | cachio: I'm pretty sure snapd tests depends on this | 11:22 |
Chipaca | of course that means you couldn't say rpi* | 11:22 |
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:23 |
niemeyer | cachio: No, that uses ... because wildcards are special for shells | 11:24 |
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:25 |
cachio | niemeyer, ok, thanks for the explanation | 11:26 |
Chipaca | niemeyer: ditto, thanks | 11:27 |
niemeyer | nps! | 11:27 |
cachio | Chipaca, right, pushing | 11:27 |
cachio | Chipaca, pushed | 11:32 |
pstolowski | cachio: ack, thanks for update! | 11:35 |
cachio | pstolowski, I just pushed the new models I am trygin to make that work | 11:43 |
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 | 11:44 |
mborzecki | off to pick up the kids | 12:03 |
* Chipaca lunches | 12:04 | |
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:13 |
popey_ | Consider re-refresh of "core" is all it says in the terminal where I am refreshing core | 12:14 |
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:19 |
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:20 |
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:23 |
popey_ | \o/ finished | 12:24 |
popey_ | that was about 20 mins. not bad for 260 snaps :D | 12:24 |
pstolowski | popey_: i agree, no feedback is problematic | 12:26 |
pstolowski | something worth exploring/imrpoving | 12:27 |
pstolowski | bbiab | 12:28 |
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:54 |
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:55 |
=== ricab is now known as ricab|lunch | ||
popey_ | \o/ | 12:56 |
popey_ | https://www.youtube.com/watch?v=ZtAzeoA0UgE | 12:56 |
popey_ | </spam> | 12:56 |
Chipaca | pstolowski: mborzecki: cachio: standup? | 13:01 |
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:05 |
Chipaca | mborzecki: i thought for mkfs.extN you could avoid the root/non-root weirdness via root_user | 13:07 |
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:08 |
Chipaca | mborzecki: yes | 13:09 |
Chipaca | mborzecki: under extended options | 13:09 |
mborzecki | Chipaca: isn't that the owner of / only? | 13:09 |
Chipaca | mborzecki: what else does it do that needs fakeroot? | 13:11 |
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/ | 13:12 |
=== ricab|lunch is now known as ricab | ||
* cachio lunch | 15:31 | |
mup | Bug #1829558 opened: Unable to install fwupd <Snappy:New> <https://launchpad.net/bugs/1829558> | 16:08 |
=== pstolowski is now known as pstolowski|afk | ||
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:31 |
Chipaca | zyga: 29, or 39? | 16:36 |
kenvandine | i'm sure it had to be 39 | 16:36 |
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:41 |
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:42 |
kenvandine | i'll talk to him on monday | 16:43 |
Chipaca | EOW, ttfn | 17:01 |
cachio | pstolowski|afk, I pushed the change in the model to make the nested vms start correctly | 17:53 |
cachio | and other changes | 17:53 |
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:54 |
cachio | pstolowski|afk, but first I want to make it pass :) | 17:55 |
pstolowski|afk | cachio: thanks, I’ll check it, the symptoms are as if my fix isn’t present or was not sufficient | 18:17 |
cachio | pstolowski|afk, when was it merged? | 18:18 |
cachio | it should be on edge | 18:18 |
* cachio afk | 19:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!