[00:24] ijohnson, hey [00:24] I left a comment in the PR [00:24] the issue can be reproduced [00:35] * cachio dinner [01:02] PR snapd#8150 closed: tests: ask tar to speak English [02:21] PR snapcraft#2951 opened: snap-packaging: remove broken host-compatibility check for runner [03:08] PR snapd#8173 opened: tests: adding arch-linux execution [06:19] morning [06:39] hm https://community.spotify.com/t5/Desktop-Linux/Spotify-Snap-randomly-stopped-working/td-p/4901987 [07:33] PR snapd#8172 closed: snapcraft.yaml: add python3-apt, tzdata as build-deps for the snapd snap [07:34] mvo: hi, can you review or get a review for #8130 ? [07:34] PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) [07:40] mborzecki: #8136 needs a 2nd review from you [07:40] PR #8136: boot: write current_kernels in bootstate20, makebootable [07:41] pedronis: hi, will do [07:41] mvo: morning, evdev sucks, golang-evdev and python-evdev are buggy ;) [07:42] i'm not sure how libinput author didn'g go crazy [07:46] pedronis: hey, good morning [07:46] pedronis: sure, let me review this [07:46] mborzecki: uh, oh no [07:47] mborzecki: even for our (relatively) simple use-case it sucks? [07:48] mvo: yeah, good to use different test systems, the laptop keybiard and VM input device behaves completely differntly than my other keyboard [07:48] mborzecki: oh, woah [07:49] mborzecki: I did test with vm and with my thinkpad keyboard and for the simple things I did it was ok but sad to hear that it's so annyoing [07:49] mvo: some devices emit repeated keys, some do not, so we need to sync the initial state, then we have to actually look at key up/down rather than repeating event [07:49] also, golang-evdev SetRepeatRate() is buggy and parameter meaning/order is swapped than what i see in the kernel code that interprets them ;) [07:50] (same for python-evdev) [07:50] nonetheless, SetRepeatRate() does nothing with my other keyboard, there's no repeat at all :P [07:50] mborzecki: does any of this correlate with reported capabilities or it's random? [07:51] I mean can we know from caps if it does repeat or not? [07:51] pedronis: no, there's no capability that states that you get repeat events [07:51] ok [07:51] oh, and libinput ignores kernel autorepat events [07:51] like totally [07:52] yesterady I was reading something and it sounded like there are hardware auto-repeat, and some at higher levels [07:52] https://gitlab.freedesktop.org/libinput/libinput/blob/master/src/evdev-fallback.c#L537 afaict they synthesize their own events [07:52] and they might even interfere [07:53] e->value corrsponds to our KeyHold [07:53] good morning [07:54] pedronis: so i'm refactoring this to get the initial state of the keys as libinput does it, and then observe the up event and look at the time key is held [07:54] zyga: hey [07:54] are we low level input engineers now too? :) [07:54] and, fwiw the golang-evdev does not include a wrapper to get the initial state of keys :P so had to pull out the ioctls and do it myself [07:54] mborzecki: hm, if we only get up/down reliable that would make the UX really not nice [07:55] mvo: right, thus it's check initial state, then observe down if it appears and see if it's down for amount of time [07:56] and the goroutine leaks, bc we have the same problem as with netlink socket [07:56] mborzecki: aha, nice [07:56] mborzecki: that makes sense [07:56] mborzecki: do you want my fix for that? [07:57] mborzecki: which reminds me, can you review #8101 [07:57] zyga: it's not critical, it's a short lived process, but ultimately we'll need a fix, either yours or the Stopper thing [07:57] PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets [07:57] ack [07:58] oh, and will have to step out for a bit late to some blood tests [08:01] morning [08:02] * zyga recalls he has to do blood tests as well but needs to get an appointment first [08:02] hey pawel [08:05] mborzecki: what's the status of #8081 ? [08:05] PR #8081: tests/main/user-session-env: add test verifying environment variables inside the user session [08:07] pedronis: it should be good to go [08:07] let me merge master there [08:12] mborzecki: so it works in other distros but not ubuntu/debian ? [08:12] pedronis: zsh? yes, there's a lp bug i linked there [08:14] fwiw zsh has a sh compat mode for loading /etc/profile, it's used on fedora, arch and and probably suse too [08:15] the downside is that there's no standard way to do drop-in files for zsh like /etc/profile.d, otherwise we could fix it easily [08:15] yes, that bug doesn't seem to be going anywhere [08:16] and it's been there for a while now [08:21] hmm [08:21] mborzecki: I'm using zsh on my mac for a while [08:21] is there really not standard way? [08:21] * zyga looks at zsh in Ubuntu [08:22] mborzecki: can you please review https://github.com/snapcore/snapd/pull/8171 -- the failover test is still causing some pain [08:22] PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists [08:28] zyga: added a note https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1640514/comments/30 [08:28] Bug #1640514: /snap/bin is not added to the PATH when using zsh Xenial):Confirmed> [08:28] doubt this will help the bug move forward [08:29] mmm [08:30] yeah, I see [08:30] man, everything is hard [08:33] * mborzecki has 3 keyboards connected to his pc now [08:33] mvo: I reviewed #8142 [08:33] PR #8142: client: add support for "ResumeToken", "HeaderPeek" to download [08:33] PR snapd#8130 closed: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) [08:35] pedronis: nice, thank you [08:35] yay, thanks for reviews [08:36] pedronis: would you like to take a quick look at https://github.com/snapcore/snapd/pull/8120 or can I land (has +2 already) [08:36] ? [08:36] PR #8120: cmd/snap-preseed: snapd version check for the target [08:36] pstolowski: I did skim it [08:37] pstolowski: related to reviews, can you finish reviewing #8101 [08:37] PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets [08:38] pedronis: i made 2 or 3 comments there [08:40] pstolowski: I know, do you want to block it on them? [08:40] I need to fetch something, back in 30 [08:41] pedronis: no, it's fine as a potential followup (if the comments make sense at all) [08:41] pstolowski: I expect the gc test to be a bit of a pain to write tbh [08:45] pedronis: i've never played with this aspect in go... wouldn't runtime.GC() make it deterministic for the test? [08:45] pstolowski: possibly, somebody has to try [08:46] about the comment, I'm happy to mention the GC in a follow up, if there no more comments [08:46] I asked mborzecki to review #8101 [08:46] as well [08:46] PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets [08:49] pstolowski: is not just the GC, is also finalizers, I don't remember in which thread they are run [08:50] pstolowski: the docs have this to say: The finalizer is scheduled to run at some arbitrary time after the program can no longer reach the object to which obj points. [08:57] pedronis: i see, it's tricky, you probably looked at https://medium.com/a-journey-with-go/go-finalizers-786df8e17687 [08:58] pstolowski: I meand, maybe it's trivial, maybe not [09:04] mvo: you have a weird code typo in 8142 now, also made a nitpick suggestion given it needs at least another commit [09:06] pedronis: I just noticed and force pushed the typo thing, sorry for that [09:12] mvo: +1, it needs a 2nd review now, maybe pawel or zygmunt [09:16] hi, is the snapd version which supports default tracks targeted to be in focal? [09:22] pedronis: thank you [09:22] ackk: yes, we plan to go with 2.44 [09:22] mvo, nice, thanks [09:26] * zyga looks forward to end of winter holidays on Monday [09:26] mvo: which branch is that? [09:27] zyga: what branch? [09:27] to review [09:27] PR snapd#8154 closed: tests: reset PS1 before possibly interactive dash [09:27] zyga: 8142 [09:28] mvo, is there an ETA for that? asking since we'd like to have the maas transitional package point to the default track [09:29] hey ackk [09:29] hi zyga [09:29] I heard there is some progress on the issue you were long plagued by [09:29] I hope we can get to the bottom if ot [09:29] *of it [09:30] zyga, the snapfuse one? well I can't reproduce it on another machine with 20.04, I hope I can reinstall my laptop soon w/20.04 and test there [09:31] ackk: 4-5 weeks until it's in stable [09:31] otoh mvo sort of managed to reproduce it [09:31] mvo, will you also upload to focal? or will it just be in the snapd snap ? [09:33] ackk: we plan to upload to focal [09:35] mvo, awesome, thanks [09:40] mvo: done [09:41] zyga: thank you! [09:43] hmm so, the input seems ot be working [09:46] mborzecki: yay [09:47] PR snapd#8101 closed: netlink: fix/support stopping goroutines reading netlink raw sockets [09:49] mvo: heh, it's super ugly ;) [09:55] pstolowski: https://github.com/snapcore/snapd/pull/8170#discussion_r382491439 [09:55] PR #8170: snap-preseed: support for preseeding of snapd and core18 [09:57] zyga: ty [10:03] damn, i'm late for the blood tests, got to go [10:03] pushed the changes to #8156 [10:04] PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <⛔ Blocked> [10:16] pstolowski: I made a comment in 8170 [10:17] zyga: whats the status of 8133 ? [10:18] pedronis: I think it is non-essential but I want jamie to look at it first [10:18] pedronis: after 7614 lands it is no longer needed [10:18] pedronis: if it doesn't land it may be a factor for device assignment on arch [10:19] pedronis: but I didn't debug deeper to know [10:20] what's the highest priority of these: https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+review-requested%3Ajdstrand+author%3Azyga [10:21] pedronis: currently 8123 - jamie was looking at yesterday evening but said he will finish in the morning as priority request came in and he had to stop [10:21] then 7614 [10:21] apart from that last one I'm no longer blocked [10:22] I'm iterating on 7825 and it will be ready soon [10:22] I labeled the first and I'm tagging 7614 for 2.45 [10:22] thank you [10:22] that's great [10:23] https://www.irccloud.com/pastebin/eM7kmuRb/ [10:23] FAIL: overlord_test.go:694: overlordSuite.TestEnsureLoopPruneAbortsOld [10:23] ah fun [10:24] pstolowski: ^ [10:24] darn, my shell still sucks [10:24] brb, need to get coffee [10:24] pstolowski: the PR it failed on changes some C code, not related to any overlord bits [10:24] brb [10:25] pedronis,zyga : ah, overlordSuite.TestEnsureLoopPruneAbortsOld seems flaky, checking [10:26] pstolowski switching to take control over the ticker channel is probably the best way forward [10:26] if there's no easy fix [10:27] pedronis: i can prep a quick PR to bump sleep to 1500 (currently 1000) to match all other overlord tests. then will work on proper change in a followup? [10:28] pstolowski: if that helps [10:29] pstolowski: I made another comment in 8170 [10:29] unrelatedly [10:34] pstolowski: I made a nitpick comment in 8210, can be taken care in a follow up, I think it can be merged otherwise [10:35] back with coffee [10:35] pedronis: great, thanks, will do a followup [10:36] ok, let's fix that shell mistake [10:36] and land another big branch :) [10:49] PR snapd#8174 opened: tests: bump sleep time of the new overlord tests [10:51] pstolowski: looking at preseed.sh [10:51] pstolowski: umount_ubuntu_image can be simplified [10:51] pstolowski: you can just umount -l "$IMAGE_MOUNTPOINT/sys" [10:52] pstolowski: or better yet, use mount-tool to iterate over them [10:52] pstolowski: just nitpick on the code [10:52] the part about qemu-nbd is interesting [10:52] I need to look at it closer later today if I can [10:53] pstolowski: and in setup_preseeding, I would add head -n 1 to ensure that find only gives us one result [10:53] zyga: nice, thanks, i can address this when later (and i didn't forget about the other issue you found in error path of service wrapers, on my list) [10:54] s/when// [10:54] pstolowski: sure, just looking at it because it said mount :) [10:54] heh [10:54] and I'm waiting for spread to prepare to see if my new shell expression is better [10:55] PR snapd#8153 closed: [RFC] "snap run --explain" with different formating [10:56] mvo: hey, what's going on with explain there? [10:57] mvo: I should be able to help soon [10:59] mvo: this looks important https://bugs.launchpad.net/snapd/+bug/1864096 [10:59] Bug #1864096: Incomplete search path(s) for xdelta3 executable [10:59] mvo: we may be hitting the store for more downloads than necessary [10:59] pedronis: ^ [10:59] zyga: it's not clear to me how to push this forward or if the pr I just closed is even the right direction so I closed it to avoid wasting ppls time [11:00] zyga: let me look [11:00] mvo: can we chat about it (explain) later today [11:00] mvo: just pull me into a call if you have a moment and feel like it [11:00] zyga: ok [11:01] zyga: do you look into this xdelta thing or should I ? should be a simple fix but yeah, agreed that it's annoying [11:01] mvo: let me, I'm waiting for another cycle of spread [11:01] yeah [11:01] mvo: and something for 2.44 [11:01] to save on all the bits over all the fiber [11:01] mvo: zyga: there's little point discussion explain without me, I don't think mvo PR was too far off, but it's all in the details at this point [11:02] pedronis: aha [11:02] pedronis: is there something we can do to make it progress? [11:02] it's probably best to just sketch the api somewhere with usage examples [11:02] than modify the full PR [11:02] k [11:02] ok [11:04] my issue with the last iteration, is mostly how you had to use explain and start_section independently to into a section, even though conceptually is one thing [11:04] zyga: if you want you have a look at my latest code, maybe you have creative ideas, anyway, we can have a quick brainstorm to sketch some api [11:04] s/to into/to intro/ [11:05] pedronis: right, yeah, that's a problem [11:06] pedronis: there could be a _start_section(text) and "explain_indented()". but probaly needs a bit more time to sketch out something. anyway, having a brainstorm with zyga is probably a good idea and then we can get back to you [11:07] ok [11:09] mvo: also ideally there should be only one function to add a string entry and one for key: value. that probably needs some more state [11:09] zyga: can we close 8113 now that it looks like we go with 8123 ? [11:09] * zyga checks the numbers :) [11:09] I don't remember branch names that well [11:10] mvo: I think so but jamie said he will review both today morning [11:10] mvo: let's wait one more morning please [11:10] mvo: he was looking into it last night but something urgent pulled him [11:11] pedronis: yeah, the in-list could be part of the state, we will explore that [11:11] mvo: the point of that it should be hard to add a non "-" prefixed entry in the middle of a list, etc [11:11] pedronis: ok [11:12] pedronis: https://github.com/snapcore/snapd/pull/7728/files#diff-e4c8d0c72c7b412376e0a04e6ad4db41R37 is an example where this is mixed [11:12] PR #7728: cmd: implement snap run --explain [11:12] i.e. - Creating new per-snap mount namespace [11:12] desired mount profile: /var/lib/snapd/mount/snap.test-snapd-sh.fstab [11:12] pedronis: but maybe the output should change [11:12] but that's by design [11:13] that was what the output was meant to look like [11:13] mvo: I don't understand in which sense it's mixed [11:13] there's a list that containts k: v sections [11:14] these thing need to next to some extent [11:14] s/next/nest/ [11:16] pedronis: the list-item has a different indent than the following line, that's what I mean [11:17] mvo: I'm probably being obtuse, I still don't understand [11:18] pedronis: let me look at your suggestions with fresh eyes I'm probably just haven't thought it through yet [11:21] mvo: I can try to write down a strawman of api signatures, if that helps [11:30] mvo: https://paste.ubuntu.com/p/qRvD3thMdz/ [11:38] PR snapd#8120 closed: cmd/snap-preseed: snapd version check for the target [11:43] pedronis: thank you [11:51] re [11:54] hey maciek [11:57] hmm [11:58] errtracker tests are failing for me on 20.04 [11:58] * zyga looks [12:00] https://twitter.com/ubuntu/status/1230795310756245505 [12:02] brace yourselves, bug reports are coming? :) [12:04] brb, [12:09] hmm random unit test failure in overlord ensure loop? https://paste.ubuntu.com/p/3sxTTChNzh/ [12:14] hey :-) [12:14] Is there a way, to do something like that: [12:14] ``` [12:14] $ sudo snap install --dangerous --classic <(wget -q -O- https://github.com/sd-hd/runner-snap/releases/download/v2.165.2-19/runner-snap-v2.165.2-19) [12:14] error: cannot open: "/dev/fd/63" [12:14] ``` [12:14] The problem here seems to be `sudo` [12:14] With `root` it works. [12:17] mborzecki: Paweł sent a PR for that failure [12:18] ah, cool, my mind is still stuck with input and debuild/dpkg -i snapd & ubuntu-core-initramfs loop [12:25] I can't find a option for sudo, to preserve the file descriptors on fork :-( [12:28] Oh, i found it `sudo -C ` . Now i get `sudo: you are not permitted to use the -C option` [12:28] Thank you. I will figure it out now. [12:32] sdhd-sascha: either way, snap install takes only snap names or filenames, it doesn't install from stdin [12:32] haha, so got the chooser trigger and service into initramfs and in my vm, the initramfs pivots earlier than the trigger is fired ;) [12:32] pedronis the `<( ... )` inside bash, creates a file descriptor [12:33] pedronis: so it's like a local file. But wget is non `sudo/root` but `snap install` is uid=0... [12:34] pedronis if often do this: `diff <(grep ....) <(grep ...) [12:35] pedronis: this is nice: [12:35] ``` [12:35] $ ls -l <(echo "hello world") [12:35] lr-x------ 1 sascha sascha 64 Feb 21 13:34 /dev/fd/63 -> 'pipe:[22821730]' [12:35] ``` [12:35] hmm [12:35] anyone here using 20.04 [12:35] or otherwise, can anyone run errtracker tests? [12:35] they keep failing for me and I cannot see why [12:38] * zyga digs into that [12:41] bah, another spread wasted on prune failure [12:55] pedronis: i got it :-) [12:55] I added this line to /etc/sudoers: `Defaults closefrom_override` [12:55] Then this works: [12:55] `sudo -C 99999 snap install --dangerous --classic <(wget -q -O- https://github.com/sd-hd/runner-snap/releases/download/v2.165.2-19/runner-snap-v2.165.2-19)` [12:55] Thank you :-) [13:08] cachio: hi, have you enabled manual/preseed test in nightly? [13:11] gaah [13:11] I debugged it [13:11] missing mocking [13:17] PR snapcraft#2948 closed: Regenerate the GDK pixbuf loaders cache file if for whatever reason it isn't there (LP: #1863801) [13:19] lp times out [13:19] eh [13:19] ok [13:20] I'm parking this for now: https://bugs.launchpad.net/snapd/+bug/1864197 [13:20] Bug #1864197: errtracker unit tests interact with real whoopsie.service === pedronis_ is now known as pedronis [13:20] Can i give snapcraft a default configuration for a snap? Or better use hooks for setting them ? [13:22] Wait. I ask on #snapcraft. Sorry [13:23] sdhd-sascha: 1) no 2) it could [13:23] zyga: thank you :-) [13:28] PR snapd#8175 opened: store: rely on CommandFromSystem snap to find xdelta3 [13:29] mvo: I opened https://github.com/snapcore/snapd/pull/8175 as draft, I have a small second patch that improves CommandFromSystemSnap but it's not essential [13:29] PR #8175: store: rely on CommandFromSystemSnap to find xdelta3 [13:30] pstolowski: master is broken on TestEnsureLoopPruneAbortsOld [13:30] pstolowski: what's the state of your PR, I see it is yellow [13:30] zyga: PR is already up but fails on random stuff [13:30] which stuff? [13:31] zyga: timed out on prepare [13:31] aha [13:31] oh well :) [13:36] mvo: I did a pass on #8100, the main issue there is how we name things [13:36] PR #8100: httputil: add support for extra snapd certs [13:39] pstolowski: do you know why it got worse? [13:39] I see it now even in travis-ran quick run of tests [13:39] even before spread starts [13:40]