[05:01] morning [05:54] mvo: hey [05:56] mborzecki: hey, good morning [05:56] mvo: found a bug in snap info, try `snap install hello-world hello-world_foo`, then compare `snap info hello-world` and `snap info hello-world_foo` [06:01] mvo: the fix is super simple so no big deal [06:01] nice [06:02] mvo: also this request sounds sane https://forum.snapcraft.io/t/feature-request-link-to-store-page-in-snap-info/12838 [06:04] indeed [06:07] i'll open PRs for both in a bit [06:08] ta [06:16] PR snapd#7274 closed: tests: change cgroups so that LXD doesn't have to [06:38] PR snapd#7257 closed: packaging: fix symlink for snapd.session-agent.socket [06:51] surprisingly the hardest part of the fix is figuring out the whitspace in channel output and disabling whitespace-cleanup :/ [06:53] PR snapd#7275 opened: cmd/snap: fix remote snap info for parallel installed snaps [06:54] mvo: ^^ [06:56] mborzecki: thanks, looking [06:56] PR snapd#7124 closed: many: create system-usernames user/group if both don't exist [07:01] I just branched 2.41 locally === pstolowski|afk is now known as pstolowski [07:03] morning [07:03] pstolowski: hey [07:13] hey pstolowski [07:19] good morning [07:19] sorry for being late, Lucy is very active today and I had to help more [07:19] o/ [07:19] hey :) [07:20] * zyga runs TW updates [07:20] hey zyga [07:20] good morning, how are you doing todayt? [07:21] zyga: good, a bit sleepy but good, today is 2.41~pre1 day! [07:21] excellent, time to roll those releases :) [07:36] zyga: hey [07:36] :) [07:36] * zyga fights gnome-shell [07:37] zyga: the year of linux desktop [07:37] I can either get 100% scaling and background or 200% scaling and solid white background [07:37] in x mode, in wayland the resolution is stuck but I have background [07:37] zyga: ui scaling? [07:37] yeah [07:38] heh [07:39] hey pedronis, good morning [07:39] zyga: fwiw, who needs to look at the background ;) all my windows are full screen [07:39] mborzecki: white BG at 500 nits can hurt [07:40] zyga: it's called front camera flash in smartphones :) [07:41] pedronis: hi, opened the PR with renames yday, https://github.com/snapcore/snapd/pull/7273 in case you want to look, or i can poke others for reviews [07:41] PR #7273: gadget, overlord/devicestate: rename Position/Layout [07:43] mborzecki: I'll do a quick scan [07:44] pedronis: thanks! === pedronis_ is now known as pedronis [07:49] mborzecki: made a couple of remarks, about fields [07:49] let me know if they make sense [07:50] or not [07:55] pedronis: s/StructureLayout/Layout/ sounds fine, but s/ContentLayout/Content/ is tricky, VoluemContent already has a field named Content, maybe RawContentLayout/RawLayout would work? [07:56] mborzecki: why is tricky? [07:56] (I'm missing something here) [07:59] mborzecki: what is your worry? [07:59] pedronis: LaidOutStructure embeds *VolumeStructure which alreay has a field named Content (that describes all content, raw and filesystem), thus suggestion to use Raw(Content,Layout) which is only present for raw content anyway [08:01] mborzecki: no, then the boring LaidOutContent is probably my preference [08:02] pedronis: haha, boring works for me too :) [08:11] PR snapd#7276 opened: cmd/snap: include snapcraft.io page URL in snap info output [08:12] zyga: https://lists.opensuse.org/opensuse-project/2019-08/msg00011.html [08:12] yeah, I saw that earlier [08:17] brb [08:20] geez, my son is still sleeping [08:41] Chipaca: thanks for the reviews, is default store check only possible within snapd? [08:42] mborzecki: needs a device auth context i think [08:46] mborzecki: meaning, yeah [08:46] Chipaca: ok, then the store-url could be added to the snapd api on /v2/snaps/ [08:46] mborzecki: yes [08:46] mborzecki: would be even nicer if it came from remote [08:47] * zyga quick breakfast [08:49] Chipaca: heh ;) [08:50] PR snapd#7275 closed: cmd/snap: fix remote snap info for parallel installed snaps [08:51] re [08:59] mborzecki: #1840751 FWIW [09:00] Bug #1840751: Please include store-url when it exists [09:00] Chipaca: thank you! [09:17] yay, I think I'm down to 0 leaks on all classic systems [09:17] core seems to leak something odd [09:17] not snaps visible in snap list [09:17] but actual mounted squashes and loopback devices [09:17] I have three cleanup patches upcoming, just let the classic run finish again [09:17] and looking at core, core tests don't overlap with classic fully so I bet there are some I just didn't look at [09:22] mvo: I hope I fixed 7135, not quite sure what happened with that assertion [09:30] PR snapcraft#2671 opened: docker: remove snapcraft-wrapper [09:32] pedronis: thanks [09:39] PR snapcraft#2672 opened: docker: use apt-get to avoid warnings [09:41] re [09:42] PR snapd#7277 opened: [RFC] overlord/snapstate: fix undo on firstboot seeding [09:44] pedronis: ^ a high-level ack/nack on the apporach would be great [09:45] *approach [09:49] zyga: sorry for pestering... #7081 waves at you ;) [09:49] PR #7081: ifacestate: optimize auto-connect by setting profiles once after all connects [09:49] indeed, after this call I'll jump right in [09:51] PR snapcraft#2673 opened: Single dockerfile [10:05] pstolowski: btw, there are still a couple of things to do here: https://trello.com/c/yxC3omC9/245-snap-snapctl-unset-support [10:05] pedronis: yes, i saw your comment, thanks, i'm on it [10:17] Chipaca: https://paste.ubuntu.com/p/sFtP2kQ5M6/ not sure about the part that finds whether it's a custom store or not [10:23] mborzecki: I think we shouldn't do anything until we have store support [10:26] PR snapd#7031 closed: debian: re-enable systemd environment generator [10:28] pedronis: yeah, you're probably right, i'll keep the branch so that the client bits are ready when store updates the api [10:28] PR snapd#7278 opened: tests: unmount fusectl after testing [10:29] PR snapd#7279 opened: tests: restore nsdelegate clobbered by LXD [10:30] PR snapd#7276 closed: cmd/snap: include snapcraft.io page URL in snap info output [10:47] PR snapd#7264 closed: packaging/fedora: build on RHEL8 (2.40) [10:52] PR snapd#7280 opened: debian: re-enable systemd environment generator (2.41) [10:55] * zyga coffee [11:05] jdstrand, zyga, mvo, fun coffee read: https://lwn.net/Articles/796687/ [11:07] Chipaca: I take that and raise https://lwn.net/Articles/796641/ [11:09] PR snapd#7281 opened: cmd/snap: fix snap unset help string [11:09] Chipaca: nice, that was on my reading list [11:09] zyga: fuse tangled into the package manager [11:09] Chipaca: nice to hear that its apparently worth it :) [11:10] zyga: what could go wrong? [11:10] mvo: :) [11:10] Chipaca: squashfs :) [11:11] zyga: fuse pinning a core, but everywhere all the time [11:11] and that's when it's working :) [11:11] anyway, will read more [11:15] mvo: when was core 4486 from? [11:16] never mind, over a year old [11:16] * Chipaca used 'git log' to get a good enough guess [11:25] ok i'm off to look lunch in the face [12:51] PR snapd#7247 closed: interfaces/mount: forward SNAPD_DEBUG to ns tools [12:51] PR snapd#7282 opened: asserts: move Model to its own model.go [12:59] seems futexes are blocked but silently... https://www.irccloud.com/pastebin/rolINucz/ [12:59] I can't find any mention of seccomp blocking the syscall in /var/log === ricab is now known as ricab|lunch [13:04] PR snapcraft#2664 closed: cli: handle exception when cleaning a part with a fresh project [13:04] PR snapcraft#2666 closed: tests: move meta testing to its own package [13:04] PR snapcraft#2667 closed: yaml utils: move OctInt from meta [13:06] mvo: https://irclogs.ubuntu.com/2019/08/19/%23snappy.html#t15:08 [13:19] PR snapd#7283 opened: tests: unmount binfmt_misc on cleanup [13:26] PR snapd#7278 closed: tests: unmount fusectl after testing [13:41] mvo: is this what you mentioned a moment ago? [13:41] https://www.irccloud.com/pastebin/e89eTfcR/ [13:47] zyga: what was this about snap info of files? [13:47] something to do with The Pope(y) [13:48] Chipaca: I think we might check if a dir exist before doing anything else, that does unexpected/expected things if you happen to be sitting somewhere with a dir foo which contains snap foo [13:49] hmm, i thought i'd checked for that, but … maybe? is there a concrete bad case? [13:50] Chipaca: it's not a priority either way, please queue it [13:50] there is some weird behaviour if you have a directory foo and do 'snap info foo' and foo is an installed snap that the store knows about and the foo directory does not contain a snap [13:51] e.g., snap install http go; cd /snap/go/current/src/net; snap info http β†’ no channel map; weird [13:51] Chipaca: re lwn> on the agenda for lunch :) [13:51] jdstrand: :) [13:52] PR snapcraft#2659 closed: Add support for building inside podman containers [13:52] but, i'd like to know if that is the strangeness or if there's something worse [13:52] popey: ^ [13:52] zyga: yes [14:15] jdstrand: I presume futex is being blocked somewhere but I can't find any log: https://www.irccloud.com/pastebin/rolINucz/ [14:22] PR snapd#7284 opened: tests: clean user and group for test system-usernames-install-twice === ricab|lunch is now known as ricab [14:23] diddledan: the futex syscall is allowed by default. the man page for futex has some things to say about EPERM. specifically: "(FUTEX_UNLOCK_PI) The caller does not own the lock represented by the futex word" and "(FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI) The caller is not allowed to attach itself to the futex at uaddr". you may want to see the man page for more context [14:23] hmm [14:24] for the last point, it also says "(This may be caused by a state corruption in user space.) [14:24] I wonder what mycroft is doing that it is failing [14:24] " [14:25] something in the voice/speech part of mycroft is reporting this https://www.irccloud.com/pastebin/crszJzeL/ [14:25] so in response I did an strace which only shows futex failing [14:27] hmm [14:27] I'm not sure where that error lies in the mycroft code though, because it's huge :-) [14:28] mycroft itself is python but it has a few C-like libraries that it calls - I did a bit of research and found references to C++ [14:29] research on the specific error message, I mean [14:29] PR snapd#7285 opened: httputil: improve http2 PROTOCOL_ERROR detection [14:31] diddledan: does it use the preload for the semaphore? it is python multithreading that needs that.... I would've expected a denial. it is possible the kernel is rate limiting it. you could: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.mycroft.* ; sudo journalctl --output=short --follow --all | sudo snappy-debug [14:31] I do launch it with the snapcraft-preload, yes [14:32] diddledan: then try again. the reload will cause denials that are being rate limited to show (until they are rate limited again) and the snappy-debug turns off general kernel rate limiting [14:32] diddledan: the above might make a denial pop out that was rate limited, so still worth a try [14:33] Chipaca: afk [14:34] zyga: ? [14:35] thanks Chipaca! [14:36] Chipaca: also do you think the unit tests I have there are sufficient or do I need to add more, etc. ? [14:36] PR snapd#7286 opened: tests: use images:ubuntu/ in lxd tests [14:37] (in #7149 that is) [14:37] PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs [14:44] ijohnson: hmm, i didn't look at coverage [14:44] ijohnson: will do in a bit [14:44] okay, sounds good [14:45] PR snapd#7287 opened: hookstate/ctlcmd: snap unset command [14:47] hmm [14:50] zyga: fwiw, I think I know why the system-users test is failing, fixing now [14:57] Oh? I’m eager to know [15:01] ijohnson: maybe i'm not spotting it: what would cause jsonResult to be true? [15:02] ijohnson: in model and serial queries i mean [15:02] specifying ?json=true in a REST API call (i.e. not using the CLI) [15:02] zyga: PR will be up in some minutes but its boring :) [15:03] ijohnson: thought so. Commented, wrt coverage and other bits and bobs [15:03] got it, thanks [15:03] ijohnson: I'd accept these to be in a followup fwiw, if it makes this easier to land [15:04] it's already quite big [15:04] I dunno, what does mvo think? [15:04] re [15:04] Chipaca: sorry, I noticed the message and replied from my phone [15:04] Chipaca, popey: you guys should talk about snap info :) [15:05] ijohnson: I miss some context I think but followup sounds good especially if the pr is already big [15:05] 2.41 is branched so having it in a not 100% state for a tiny bit is not too terrible [15:06] mvo: it's PR #7149, not sure if you wanted to make a review pass on that [15:06] PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs [15:06] IIRC, this wasn't needed for 2.41 [15:07] ijohnson: yeah, its fine for .42 [15:07] .42 is the answer ! [15:09] is .41 out yet? *ducks the swinging punches* [15:09] mvo: so do you want to review that PR as well before landing for 2.42? or am I good to merge once tests are green? [15:10] ijohnson: needs two approvals to merge tho [15:10] ah I guess Graham only reviewed the help message, I forgot that [15:15] ijohnson: yeah, what john said, needs two +1 :) [15:27] PR snapd#7288 opened: tests: cleanup "snap_daemon" user in system-usernames-install-twice [15:29] mvo: did you see https://github.com/snapcore/snapd/pull/7284 [15:29] PR #7284: tests: clean user and group for test system-usernames-install-twice [15:29] zyga: meh, I did not [15:30] your PR looks more comprehensive :) [15:30] but I didn't look deeper yet [15:30] zyga: yeah, the extrausers bit [15:31] PR snapcraft#2669 closed: Plugin catkin: forward parallel build count [15:36] * cachio lΓ±unch [15:42] PR snapd#7281 closed: cmd/snap: fix snap unset help string [15:43] PR snapd#7280 closed: debian: re-enable systemd environment generator (2.41) [15:50] * zyga takes a break [15:50] I added service leak detector [15:51] checking for stuff that affects systemd serrvices [15:51] *services [15:51] so looking forward to what the outcome will be [15:51] I'll grab coffee and be back to check === pstolowski is now known as pstolowski|afk [16:31] pstolowski|afk, #7110 updated [16:31] thanks [16:31] PR #7110: tests: new test to check the output after refreshing/reverting core [16:35] PR snapd#7289 opened: tests: ubuntu 18.10 removed from the google-sru backend on the spread.yaml [16:49] re [16:50] PR snapd#7279 closed: tests: restore nsdelegate clobbered by LXD [18:59] PR snapd#7290 opened: tests: allow test user XDG_RUNTIME_DIR to phase out [19:03] * cachio afk [19:07] PR snapd#7283 closed: tests: unmount binfmt_misc on cleanup [19:27] Zyga Chipaca can we talk about snap info over mail or a bug? Been on a plane for 11 hours [19:30] where you at this week, popey ? [19:30] Arizona [19:30] \o/ [19:30] It am hot [19:31] boo [19:31] I saw your post earlier about 40degrees [19:43] PR snapd#7291 opened: Add new cases into arch_test [23:07] PR snapd#7292 opened: interfaces: k8s worker node updates [23:11] PR snapd#7293 opened: interfaces: k8s worker node updates - 2.41