[01:07] PR snapd#8837 opened: Add an activates-on property to apps to support D-Bus activation [03:33] PR snapd#8838 opened: tests: fix the basic20 test for uc20 on external backend === KindTwo is now known as KindOne [05:21] morning [06:09] PR snapd#8833 closed: sandbox/cgroup: remove redundant pathOfProcPidCgroup [06:09] PR snapd#8836 closed: sandbox/cgroup: add tests for ParsePids [06:09] PR snapd#8838 closed: tests: fix the basic20 test for uc20 on external backend [06:18] mvo: hey [06:19] PR snapd#8828 closed: tests: clean up up the use of configcoreSuite in the configcore tests [06:19] good morning mborzecki [06:19] mvo: can you cherry pick https://github.com/snapcore/snapd/pull/8827 to 2.45? [06:19] PR #8827: interfaces/builtin/time-control: allow POSIX clock API [06:22] mborzecki: sure thing [06:22] mvo: and we can probably land https://github.com/snapcore/snapd/pull/8822 the tests failed with `error: cannot get snap sections: cannot sections: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"` [06:22] PR #8822: release: 2.45.1 [06:24] mborzecki: cherry-picked, thank you [06:24] mvo: thanks! [06:26] zyga: re the "too early for operation" error, I seem to only see this in the uc20 prepare, did you see tihs on other suites as well? [06:28] Yes, i saw it in Ubuntu 20.04 as well [06:28] Good morning [06:29] PR snapd#8822 closed: release: 2.45.1 [06:29] zyga: hey [06:30] Hey, sorry to be up so late. A bit sleepy still. I could not sleep well [06:32] heh, funny, spread discards the node that failed suite level prepare? [06:35] it's day two but my little daughter is still very reluctant to approach me [06:36] I guess I need to find a xmas beard and glue it first :) [06:40] oh, and it's not possible to restart old gh action jobs [06:40] there's no restart workflow button for the cla check job in https://github.com/snapcore/snapd/pull/8620 [06:40] zyga: anything other than 20.04? core20 is also 20.04 based, I wonder if it's only a 20.04 issue for some strnage reason [06:40] PR #8620: spdx: add GPL-3.0-or-later license <⛔ Blocked> [06:40] (it las ran more than a month ago tho) [06:44] mvo: no, nothing apart from 20.04 or core20 [06:44] mvo: it is weird, because we *wait* for seeding [06:44] so what could it be? [06:44] perhaps seeding "succeeds" with an error [06:44] and then we carry on and hit this [06:44] could we fail seeding due to incorrect time somehow? (but I strongly doubt this) [06:45] mvo: since it always fails on that line [06:45] mvo: perhaps we should add a patch that shows snap changes and other stuff [06:45] mvo: I will send a patch for that shortly [06:47] jamesh: thanks for splitting out https://github.com/snapcore/snapd/pull/8837 [06:47] PR #8837: snap: add an activates-on property to apps for D-Bus activation [06:48] zyga: no problem. I think there's more that can be split out on top of that. [06:48] zyga: mvo: what if there's a problem talking to the store, does this require poking the store to get some serial number? [06:48] yes, I think this is a good approach to landing large branches, as there's realistically much more review for small branches than there is for large ones [06:49] mborzecki: I don't know what would happen, my expectation is that when wait seed returns you are good to go [06:49] mborzecki: and we don't block installing snaps when you are not registered [06:49] detecting existing ActivatesOn conflicts with existing snaps could probably be done on top of this PR [06:50] jamesh: small comment https://github.com/snapcore/snapd/pull/8837/files#r437174750 [06:50] PR #8837: snap: add an activates-on property to apps for D-Bus activation [06:57] zyga: I like the idea of showing snap changes and snap tasks --last=seeding [06:57] zyga: I'm looking at the code right now, trying to understand this [06:58] zyga: I will try to write a small reproducer [06:58] mvo: do you want me to send patches or will you? [06:59] zyga: if you have it ready please do, otherwise I can do it. but I try to write a reproducer first I think [06:59] not ready yet, I'll defer to you then [06:59] zyga: ta [06:59] * zyga tries to drink coffee then [07:01] mvo: hi, the strange failures logs in #8832 doesn't seem to tell much, it doesn't seem to trigger debug logs? we need to add more logging, I started at the code some more yesterday and still unsure what is happening, it seems 20.04 only [07:01] PR #8832: travis.yml: removed, all our checks run in GH actions now [07:01] s/started/stared/ [07:02] mvo: also afaict this started appearing only last week? I wonder what changed [07:02] pedronis: yeah, it's pretty new [07:03] morning [07:05] good morning pedronis, pstolowski [07:05] pedronis: I think it started more than a week ago [07:05] pedronis: at least ~ 2 weeks to be safe [07:05] maybe it increased in frequency, maybe just bad luck [07:05] or !luck :P [07:06] I think we all agree we need more data [07:08] back in 15 min [07:18] hrm, hrm, I wrote a script that does what prepare.sh is doing in a loop and of course it is not failing. depressing [07:20] mvo: are you testing locally? [07:23] zyga: in qemu [07:24] zyga: but yeah, "locally" [07:24] zyga: from my desktop machine [07:24] PR snapd#8839 opened: tests: add debug for 20.04 prepare failure [07:25] zyga: do you happen to have an example failure on a 20.04 sytem (not core20)? if not, no problem, I will go over the existing failure [07:25] let me look quickly... [07:26] pedronis: are you happy with 8808 in principle (i.e. making the settle timeout a function etc)? if so I can help dimitri to land it (unless it requires design changes) [07:28] mvo: let me make a precise suggestion [07:28] pedronis: \o/ [07:28] pedronis: thank you [07:30] mvo: https://github.com/snapcore/snapd/pull/8808#issuecomment-641090791 [07:30] PR #8808: riscv64: bump timeouts [07:30] ta [07:32] mvo: and https://github.com/snapcore/snapd/pull/8808#issuecomment-641092197 [07:32] PR #8808: riscv64: bump timeouts [07:34] mborzecki: hi, +1 to #8830 with some final suggestions [07:34] PR #8830: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker [07:34] pedronis: thanks [07:34] PR snapd#8832 closed: travis.yml: removed, all our checks run in GH actions now [08:31] quick errand, back in 30 [08:39] PR snapd#8840 opened: tests: move try-related tests to snapstate_try_test.go [08:49] PR snapd#8839 closed: tests: add debug for 20.04 prepare failure [09:13] re [09:33] pedronis: i'm working on addressing comments to #8812; moving all this to servicestate means no backend abstraction layer for services and calling wrappers directly, makes sense? [09:33] PR #8812: o/snapstate: service-control task handler (4/N) [09:35] pstolowski: yes correct, then in the tests in snapstate if needed you do the same thing we do for ifacestate stuff [09:35] or at least something similar as needed [09:35] but not sure this will be used immediately in snapstate? [09:36] pedronis: i think the tests i've in this PR need to be moved entirely to servicestate [09:37] yea, I think my comment is relevant only for when we'll move start/stop-snap-services but that's not an immediate issue [09:37] pedronis: and changed, because i cannot use fakebackend anymore [09:38] pstolowski: I really don't have a strong opinion, you an use whatever work best for the tests [09:40] pedronis: ok, thanks [10:09] * pstolowski lunch [10:13] hi, any idea why snap is reporting error: cannot install "q": invalid instance name: invalid snap name: "q" if I "snap install q" ? [10:13] does anyon know if /dev/shm/snap.$SNAP_NAME/foo can be the endpoint of a content interface (for sharing a crypto function between two snaps) [10:14] (also "snap info q" doesn't find anything) [10:17] ackk: we don't support single letter snap names [10:17] pedronis, yet the store has them? [10:17] pedronis, (and command-not-found tells you to "snap install q") [10:17] https://snapcraft.io/q [10:17] you'll need to talk to the store afaik they shouldn't be supported in the store either [10:18] snapd will never install them [10:18] pedronis, I see, thanks [10:32] ogra: can you explain in more detail please [10:35] zyga, a customer has a snap with a crypto tool that creates /dev/shm/atpkcs11 and puts a mutex inside ... they want to be able to use this from a second snap [10:36] I see [10:36] let me think [10:36] (with snapcraft-prleoad they can indeed re-locate to /dev/shm/snap.$SNAP_NAME ... but i dont know if sharing that location would work) [10:40] PR snapd#8840 closed: tests: move try-related tests to snapstate_try_test.go [10:42] * zyga break to rest [10:45] PR snapd#8841 opened: gadget: drop dead code, hide exports that are not used externally [10:45] pedronis: ^^ [10:45] was able to hide/remove a bit more [10:46] heh 17 files changed, 147 insertions(+), 1414 deletions(-) [10:48] heh, hit that too early for operation thing again [10:56] mborzecki: oh [10:56] do you have more logs? [10:56] mvo added debug bits [10:57] nope [10:57] you had older masteR? [10:59] yeah [11:00] but i have another new PR running, let me check whetherh it has the right changes [11:00] ehh nope [11:10] xnox: I pushed a small tweak to 8808, should be ok to re-review [11:17] pedronis: hm, I'm testing the uc20 beta right now and there are a bunch of updates since. I get a reboot in the middle of console-conf. I guess we need to think about the user experience for this :/ [11:18] mvo: yes, but it would be the same with uc18 I suppose [11:18] pedronis: yeah, new kernel and snapd while I was in console-conf tryint go set this up [11:18] pedronis: yeah, not a regression [11:18] pedronis: mostly idle wondering [11:18] mvo: it's ok, it probably relates to trying to control our reboots more [11:19] morning folks [11:19] mvo: pedronis: also I filed https://bugs.launchpad.net/subiquity/+bug/1880156 about precisely the problem you are mentioning [11:19] Bug #1880156: console-conf when run with auto-refresh of core20 will crash and become non-responsive [11:19] hey ijohnson [11:19] apparently I should respond there [11:19] ijohnson: ha! one step ahead :) [11:19] ijohnson: thank you! [11:54] * ijohnson -> afk [11:55] PR snapd#8842 opened: tests: fix bug waiting for snap command to be ready [11:59] mvo: lmao [11:59] was that the bug?! [12:00] zyga: yes, well one bug :) [12:04] mvo: do you mean there are more? [12:06] https://forum.snapcraft.io/t/snaps-show-squares-instead-of-fonts/18073 hmm does pop os have a different fontconfig version too? [12:07] mvo: hmm funny, shellcheck could warn about that [12:08] mvo, hey [12:08] mborzecki: it's based on ubuntu so... unlikely [12:08] but ... dunno, install and check :) [12:08] snapd-vendor-sync running [12:13] if i had a penny for every linux distro i ever installed... :) [12:18] stgraber, are there any lxd images anywhere that do not waste the first 5min running cloud-init (read: do we have any minimal images that do not come with it) [12:21] ogra: all official Ubuntu images have it, but we have unofficial images that don't. [12:21] ogra: images:ubuntu/20.04 [12:21] (i'm running stuff immediately when the container comes up ... and cloud-init just changes the whole config underneah me) [12:22] stgraber, thanks ! [12:28] zyga: I reviewed #8829 [12:28] PR #8829: sandbox/cgroup: add tracking helpers [12:29] zyga: I also commented yesterday in #8573 as you asked [12:29] PR #8573: overlord/snapstate: inhibit startup while unlinked [12:29] thanks! [12:30] pedronis: the "fail" thing is a bit mysterious, thank you for pointing that out [12:30] IIRC nothing in systemd itself uses the other value [12:30] but it can be traced to the source and I think got documented [12:30] I'll go over the rest and adjust it today [12:31] pedronis: I can move the random uuid to randutil in the same branch as I need to make changes anyway [12:41] as you prefer [12:42] pedronis: I made some progress on the snap tooling fix, I will send a RFC today [12:50] zyga: there's now a random uuid function in randutil, see RandomKernelUUID [12:50] perhaps that was pedronis' comment [12:50] ah, I didn't know [12:50] perhaps that's all we need [12:50] thanks! [12:51] zyga: you might need to adjust it slightly and it's user in cmd_initramfs_mounts I think [12:51] but that should be fine [12:53] ah, I forgot, it's probably there because I made the same comment at the time [12:59] PR snapcraft#3166 opened: plugin handler: load legacy plugins prefixed with 'x-' === Eighth_Doctor is now known as Conan_Kudo === Conan_Kudo is now known as Eighth_Doctor === Eighth_Doctor is now known as Eleventh_Doctor === Eleventh_Doctor is now known as Eighth_Doctor [13:30] * zyga break from computer [13:39] mvo: gdbserver could use some reviews, maybe zyga, ijohnson or pstolowski can take a look there? [13:44] I will look [13:44] It tomorrow morning fine? [13:44] I’m a bit tired by holding my laptop [13:46] zyga, before you go, did you have any idea regarding the /dev/shm ssue above ? [13:46] *issue [13:46] ogra: yes, sorry, [13:47] ogra: /dev/ is shared from host [13:47] ogra: os if one snap puts stuf there and the other consumes they can see the same thing [13:47] right ... but /dev/shm isnt writable [13:47] you need an interface more than content [13:47] (from a snap) [13:47] the interface that will model the relationship [13:48] ogra: content sharing won't work as you cannot share stuff that is not "yours" [13:48] ogra: layouts cannot work either as they are private to a view of a given snap [13:48] well /dev/shm/snap.$SNAP_NAME is mine [13:49] ogra: yours as in $SNAP, $SNAP_DATA [13:49] and they want to share content from /dev/shm/snap.$SNAP_NAME to another snap [13:49] content cannot share anything else [13:49] sure I get that [13:49] ok [13:49] you saying /dev got me confides [13:49] *confused [13:49] * ogra glares at his fingers [13:50] content is not the way to share it IMO, please discuss this as a new interface [13:51] i know jdstrand ws looking at the possibility to have a pcscd (smartcard daemon) interface eventually ... i think that would allow such sharing ... but i dont think any work has happened in that area [13:51] ogra: if this is specific to a given daemon then I sugges pursuing that [13:51] zyga, not the way == impossible ? or just ugly ? [13:51] * zyga took the painkiller and tries to rest [13:52] ogra: hmm? [13:52] impossible [13:52] content cannot do that [13:52] ok [13:52] thanks ! [13:52] not yet, no. if someone else wants to pick it up, that's fine [13:52] zyga: ouch I hope you get better soon [13:52] (re pcsd) [13:52] roadmr: I hope so too [13:56] mborzecki: i can take a look [13:58] ijohnson: re hotplug & greedy plugs, i think we discussed something a few weeks ago and i replied to a question you had there but i don't remember where.. was there a bug report? [13:58] pstolowski: do you remember what it was about [13:58] pstolowski: oh if it's about greedy plugs jdstrand fixed it [13:58] hotplug + greedy plugs works with the right declaration [13:59] ijohnson: right, i think i hinted at declaration being na issue [14:00] there was a bug report [14:00] * jdstrand tries to find [14:01] mvo: snapd tools via export system https://www.irccloud.com/pastebin/ExcgIlg7/ [14:01] but yes, it was a bug in the snap decl [14:01] https://bugs.launchpad.net/snapd/+bug/1876356 [14:01] Bug #1876356: greedy auto-connect doesn't work with hotplug [14:01] jdstrand: right, that's the bug, thanks [14:02] pstolowski: did you see that I asked you about experimental? if you did and responded, I'll read email (just came online) [14:02] jdstrand: sorry i didn't reply to your question there, missed it [14:02] jdstrand: on the forum? yes, i replied [14:03] yes, thanks [14:09] pstolowski: ok, I asked Field to give you some feedback [14:10] jdstrand: great, thank you! [14:53] pedronis: I have end-to-end implementation of RFC for exporting snapd tools [14:53] pedronis: I'll send the RFC branch in a moment [14:53] pedronis: the changes are surprisingly short [15:00] zyga: this is without the snap-confine changes? [15:00] pedronis: with a tiny snap-confine change, snap-confine currently mounts the tools so I changed the path to use the exported tools instead [15:51] and back [15:59] refresh delta test failing? [16:00] 2020-06-09T13:24:50.3724981Z Jun 09 13:24:39 jun091254-105239 snapd[76428]: storehelpers.go:438: cannot refresh snap "test-snapd-delta-refresh": snap has no updates available [16:03] mborzecki: maybe store load? [16:04] mborzecki: I have something cool [16:04] zyga: what is that? [16:04] just running one more run of spread to see if I got a tweak right [16:04] mborzecki: exports [16:04] mborzecki: exporting stuff from snaps to host [16:05] mborzecki: use cases are numerous :) [16:05] mborzecki: but 1st use case is to fix this: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/5 [16:10] zyga: hm just a sec, bikeshedding on #8823, trying to make iteration smarter [16:10] PR #8823: asserts/internal: limit Grouping size switching to a bitset representation [16:10] mborzecki: heh sure :) [16:10] I was supposed to EOD anyway but I will be around for 15 more minutes [16:11] mborzecki: btw, do you remember this soundtrack? https://www.youtube.com/watch?v=Kf8j3FYxekk [16:12] zyga: staying a bit longer today, got some errands to run during the day tomorrow [16:12] yeah [16:12] my errand was to walk to the loo today :P [16:12] zyga: and ofc i remember this, it's even on spotify [16:12] mborzecki: I played some on x240 [16:13] wish I could go down to the office to play on a real computer [16:13] but the sound is great (on headphones, not on x240) [16:14] hm did some changes and it works, wonder if the test cases are enough [16:16] I have a "macro" ggg [16:17] mborzecki: what are you trying to do? [16:20] pedronis: checking whether i can further limit the number of iterations with bitset having counted leading & trailing zeros [16:21] mborzecki: are you using math/bits ? [16:21] pedronis: yeah [16:21] pedronis: does that pull in some crazy dep? [16:21] no, it's mostly table based [16:21] I'm not sure it would make me change my mind [16:21] about keeping the two impls tough [16:22] the other thing we care about is also Serialize size [16:23] pedronis: i was curious to try that out ;) [16:23] it's ok, I mean abour serialisation again we could be clever but at some point it all gets even more complicated to track [16:24] than two very distinct paths [16:31] mborzecki: the leading zero change should be relatively straighforward no? [16:31] pedronis: let me show you the diff [16:32] pedronis: https://paste.ubuntu.com/p/vxtcGMMRB5/ [16:33] I see [16:34] pedronis: trims the loop range a bit [16:34] pedronis: i'll post it in a comment === KindTwo is now known as KindOne [16:41] mborzecki: I didn't think of this, but we probably don't need to use both functions, instead of shifting bit, we could shift w until its 0 [16:42] pedronis: ha, yeah, nice idea === ijohnson is now known as ijohnson|lunch === msalvatore_ is now known as msalvatore [16:53] mvo: pstolowski left some comments under #8784, i'll address them [16:53] PR #8784: snap: add new `snap run --gdbserver` option [17:39] ok, did the change I wanted [17:39] it should now work on fedora as well [17:40] (and arch :) [17:56] doesn't look like we'll land anything today === ijohnson|lunch is now known as ijohnson [17:58] mborzecki: ? [17:58] the delta test is failing [17:59] ah [17:59] did you ask store devs? [17:59] actually wanted to run the test myself, but the logs say there's no update for the snap (which is weird i guess?) [18:00] hmm [18:00]