[05:27] morning [06:39] mborzecki: hi, I would appreciate reviews for #8907 and #8984 [06:39] PR #8907: asserts: implement Database.FindSequence [06:39] PR #8984: asserts: integer headers: disallow prefix zeros and make parsing more uniform [06:40] pedronis: hi, will do [06:42] thx [07:03] morning [07:11] mvo: pedronis: sent out the tiny spec for uc20 recovery on rpi, please take a look [07:12] pedronis: mvo: i'll write down something similar about grub.cfg command line and share it with you guys [07:15] mborzecki: ok, I'll see when I can look at it [07:15] pstolowski: hi, #8907 needs a review, I also made #8984 [07:15] PR #8907: asserts: implement Database.FindSequence [07:15] PR #8984: asserts: integer headers: disallow prefix zeros and make parsing more uniform [07:16] pedronis: hi, will review today [07:19] mborzecki: thank you === pedronis_ is now known as pedronis [07:51] good morning [07:52] sorry for starting late, I woke up very early due to pain and then tired to sleep again after taking painkillers [08:41] PR core18#159 closed: 030-fix-timedatectl.chroot: fix quoting issues [09:31] drat, lucy just walked over the keyboard and sigquit spread [09:52] zyga: haha [09:54] what are the chances... [09:57] * zyga is debugging some weird failures [10:06] mborzecki: something weird is going on in feature/track-launched-apps on tumbleweed [10:07] on master that test passes [10:07] on the feature branch it fails [10:07] as if making the transient scope actually affected the existing tracking using the pid cgroup [10:07] but why only on tumbleweed? [10:07] * zyga investigates [10:08] maybe they moved to cgroupv2? [10:08] notably the test does not fail in the big branch where we use the new information for the same decision [10:08] so maybe ...? [10:25] baaah [10:25] and now it passes [10:25] what the heck?! [10:26] * zyga thinks and tries to drink coffee [10:34] ok, docs updated, now onto the reviews [10:35] * sdhd-sascha Ooh, too much beer yesterday [10:36] mborzecki: thanks [11:01] zyga: can you review https://github.com/snapcore/snapd/pull/8883 ? [11:01] PR #8883: packaging: stop snapd early on purge [11:07] mborzecki: after the call [11:22] mborzecki: https://github.com/snapcore/snapd/pull/8883/checks?check_run_id=845292346 fails [11:22] PR #8883: packaging: stop snapd early on purge [11:23] uh, 14.40 [11:23] pff fun [12:02] re [12:02] mborzecki: ping me when ready [12:02] I'm debugging something related to old tracking [12:03] mborzecki: took a real quick look at your doc [12:13] ijohnson|sprint: hey, thanks [12:31] eh, I add logging and now it passes [12:31] there must be something racy there [12:32] all right, it failed now [12:34] ahh, I have a feeling I know what's wrong [12:57] mborzecki: heh, start transient scope keeps on giving [12:57] * zyga thinks [12:58] thinks it's time to join the call [12:58] heh ;) [13:03] PR snapd#8986 opened: tests: new snaps-state command - part1 [13:13] zyga: I managed to fix my layout verification PR, it was as expected to use Layout.Path instead of the key in the map [13:13] thanks! [13:42] ondra: hey, I played with the latest go which has some linker improvements - the snap-bootstrap binary is down from 11mb stripped to 7.7mb stripped. so low mem snapd looks more feasible [13:59] * zyga break for meds and some rest [15:37] * cachio lunch [15:55] cachio: +1 for your 'run nested' pr, please ping someone for 2nd review [16:38] Psi-Jack, thanks [16:38] What? [16:55] just take the credit, don't complain ... [16:55] Psi-Jack, sorry, was pstolowski but he quited [16:56] lol [16:56] Psi-Jack, I think it is the seconds time I do the same [16:56] hehe [16:57] Yep! [17:16] * zyga tested 16.04 and 18.04 and systemd is not racy there [17:16] trying 20.04 and adding workaround in software on our side [17:28] 20.04 also passes, trying 20.10 which should be close to sid [17:28] but this suggests either a regression in systemd [17:28] or a "feature" [17:44] 20.10 testing now.. [17:44] amd it seems to pass [17:44] maybe we have patches in systemd [17:44] jdstrand: ^ more tracking mystery [17:47] going to test debian-9 vs sid [17:53] hey people, i really regret my level of alcohol, yesterday ;-) sorry ;-) [17:54] it was rather obvious 🙂 [17:57] ogra: thank you ;-) i try to go another way in future ;-) [18:01] did anybody mention the birds, and there song's? here in bavaria, they decrease volume. Then after lockdown they increase there songs... And now, they have learn both ;-) [18:08] hmm, debian, even sid does not fail, so it is really just tumbleweed or was my sample size too small [18:09] PR snapd#8907 closed: asserts: implement Database.FindSequence [18:09] ogra: i share your love for graph-algos . But didn't have a hint how to optimize it?! [18:10] zyga, hi [18:11] cachio: hi [18:11] I was checking and to run shellcheck on tools tests we need to install the shellcheck snap [18:11] but for that we need to have the snap command available [18:11] zyga, does it make sense? [18:12] cachio: yes, I ran into this myself, it's not fortunate but perhaps unavoidable [18:12] zyga, currently we prepare the suite with --prepare-suite-each-minimal-no-snaps [18:12] cachio: alternatively, don't install it [18:12] cachio: but install it only on one system [18:12] cachio: and run shellcheck e.g. only on ubuntu 20.04 [18:12] this way we test on more systems [18:12] and shellcheck at least once [18:12] note that that suite does not have full snapd ready [18:13] so it may not be possible to install snaps [18:13] but then we also need to have snap to test the snaps tool that I just created [18:13] ooh, just a "deb" problem ? or others have that too? [18:13] zyga, but for that I could install snapd and then purge [18:14] cachio: hmmm [18:14] cachio: perhaps the snap helper needs different strategy [18:14] cachio: for generic helpers I would not install snapd [18:14] cachio: perhaps the snap helper needs to live in main [18:14] (as in tests) [18:14] PR snapd#8984 closed: asserts: integer headers: disallow prefix zeros and make parsing more uniform [18:14] zyga, you need the test [18:14] cachio: i love purge... But there was a AI, which should sort a list. The AI has won, with purging the complete list ;-) [18:15] zyga, so I'll move the test to main in that case [18:15] cachio: I think that's better [18:15] zyga, good [18:16] thanks! [18:16] what's the name of the tool btw? [18:17] snaps-state [18:18] schnaps-state ... [18:18] zyga, but it could change [18:18] cachio: do you want it to be on PATH? [18:18] cachio: note that the naming rules differ between the two [18:18] zyga, no [18:18] just to be on path when we debug [18:18] ok [18:18] hmm? [18:18] how would that work? [18:19] I'll use it like $TESTSTOOLS"/snap-state [18:19] so it should be fine [18:19] I see [18:20] if you want it on path it could be called tests.snap or something like that [18:20] I think that's okay too [18:20] no strong opinion either way [18:24] ok, so far it is ok [18:24] having this "$TESTSTOOLS"/snap-state is it ok [18:30] zyga, also we could have a test targeted to ubuntu-18.04 which runs shellcheck for all the bash files in tools [18:31] cachio: I think we kind of do that already (perhaps) via run-checks but yeah [18:31] but I really prefer each tool test to check itself [18:31] then it's obvious [18:31] ok [18:31] zyga: cachio: hey, at high-level language, it's possible to write once, and work everywhere ;-) [18:33] * sdhd-sascha short afk [18:56] PR snapcraft#3205 opened: spread tests: higher timeout for extension tests [19:15] jdstrand: o/ [19:15] jdstrand: some weird news [19:15] https://github.com/snapcore/snapd/pull/8977#issuecomment-655057400 [19:15] PR #8977: cmd/snap: track started apps and hooks [19:16] at this rate systemd will remove the API before it becomes reliable and we can merge it [19:25] PR snapd#8957 closed: tests: improve nested tests flexibility [19:32] jdstrand: FYI https://github.com/snapcore/snapd/pull/8977/commits/e2a21fbb16000ec87632f7f34a860d121933e1e9 [19:32] PR #8977: cmd/snap: track started apps and hooks [19:51] PR snapcraft#3206 opened: tests: add missing asserts to python unit tests [19:54] jdstrand: if you are keeping track, the patch to read is https://github.com/snapcore/snapd/pull/8977/commits/ee673c8a06c7f57e3a030bcf721c6d340e987303 [19:54] PR #8977: cmd/snap: track started apps and hooks [19:58] zyga, updated #8949, #8950 and #8973 [19:58] PR #8949: tests: new fs-state which replaces the files.sh helper [19:58] PR #8950: tests: new str-tool which replaces the strings.sh helper [19:58] PR #8973: tests: moving journalctl.sh to a new journal-state tool [19:59] hey, i'm trying to debug what i think is a race condition in snapd/ the pulseaudio snap-policy module. rebuilding a package with debug code everytime would be incredibly annoying though. So what i'm trying now is to start my app and then enter the sandbox with `nsenter` to give myself a shell in the snap application namespaces. [19:59] However when I run `pacmd` i get `No PulseAudio daemon running, or not running as session daemon.`, any ideas how to better debug this/provide a simple repro? [19:59] lawl: note that this is isufficient [19:59] the namespace is not the whole sandbox [19:59] if you want to be in the sandbox use snap run --shell [19:59] in addition, many wrappers "patch" the environment for things that are in different location [19:59] one such thing is the location of the pulse socket [20:00] there's a bug tracking that [20:00] in practice the socket is in $XDG_RUNTIME_DIR/.. [20:00] hope that hepls [20:00] *helps [20:00] yeah, XDG_RUNTIME_DIR was empty, i checked, i'll try `snap run --shell`, thanks