[05:09] <mborzecki> morning
[05:18] <mvo> hey mborzecki
[05:19] <mborzecki> mvo: hey
[05:20] <mup> PR snapd#8777 closed: packaging: disable buildmode=pie for riscv64 <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8777>
[05:22] <mborzecki> mvo: there is no docs for the snapd API besides the code, right? i recall we discussed tools to use for documenting it nicely, but i don't recall seeing any readmes or whatnot
[06:19] <mvo> mborzecki: sorry for the delay, did not see the msg - here are the docs https://github.com/snapcore/snapd/wiki/REST-API
[06:20] <mvo> mborzecki: but very outdated
[06:23] <mborzecki> mvo: thanks!
[06:24] <mborzecki> mvo: hm maybe we should move that to the forum
[06:35] <mborzecki> mvo: added the snapd REST API docs page in the forum  https://forum.snapcraft.io/t/snapd-rest-api/17954 we'll need to update it though
[06:37] <mvo> mborzecki: oh, nice
[06:38] <mvo> mborzecki: yes, it needs updating but having it here is a good step, I wonder if we can delete the wiki version or if we can redirect it or something
[06:38] <mborzecki> funny, i've never looked in the wiki section in the snapd repo, immediately assumed that forums is where it would live since we have all the docs there
[06:39] <mborzecki> mvo: perhaps we can discuss that quickly during the standup?
[06:40] <mvo> mborzecki: +1
[06:41] <mvo> mborzecki: yeah, the issue was that we always wanted to move it but there was never time and the perfect was (maybe) the enemey of the good
[06:41] <mvo> mborzecki: i.e. just moving it to the forum as is not that much work and beneficial but we always wanted to do more (like auto-generating it) hence the delay :/
[06:41] <mvo> mborzecki: anyway, thanks for doing this!
[06:42] <mborzecki> mvo: with gh actions, maybe we could update the forum doc automatically? :)
[06:42] <mvo> mborzecki: heh - nice idea!
[06:58] <zyga> o/
[06:58] <mvo> good morning zyga
[06:58] <zyga> mborzecki: actions can trigger on directories
[06:58] <zyga> good morning
[06:59] <zyga> though it's bad, I can barely stand :/
[06:59] <mvo> zyga: oh no :(
[07:00] <mborzecki> zyga: nice, so we'd need to agree on a format of the doc, swagger or maybe just plain markdown, and then push that to the forum automatically from master?
[07:01] <mborzecki> same markdown should work on github wiki if we want to keep maintaining that
[07:02] <pstolowski> morning
[07:12] <zyga> eh, thinkpad died on the spot again
[07:13] <pedronis> mvo: mborzecki: what is this https://forum.snapcraft.io/t/snapd-rest-api/17954 ?
[07:16] <mborzecki> pedronis: tried moving the snapd api docs from github wiki to the forum where they can be found, quick HO to discuss what to do with this?
[07:16] <mvo> pedronis: it's the old rest API from the wiki, mborzecki  moved it over to the forum this morning
[07:16] <pedronis> I would really like to involved in this kind of things
[07:17] <pedronis> mvo: there are bit that we probably don't want to document anymore at all
[07:17] <mborzecki> pedronis: sorry, maybe i was a bit quick to move that
[07:19] <mvo> pedronis: sure, what do you recommend? hiding the post? or "fixing", i.e. marking the bits we don't want as obsolete or removing them?
[07:19] <pedronis> mvo: did we plan to work on this right now?
[07:20] <pedronis> but yes, moving it over without a plan of how to improve it doesn't seem a great idea to me, but my 2cts
[07:20] <mvo> pedronis: we did not plan this
[07:21] <mup> PR snapd#8520 closed: data: fix shellcheck warnings in snapd.sh.in <Simple 😃> <Created by jelovac> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8520>
[07:21] <mvo> pedronis: if you think it's a net-negative we can just hide/remove it again
[07:21] <pedronis> mvo: did you at least talk with Graham?
[07:22] <mborzecki> pedronis: i'm happy to have a chat about that, the reason i moved it was that it was not easy to find them, so if they're in the forum could start updating them incrementally
[07:23] <pedronis> mborzecki: the problem is, we should discuss what to simply scrub before moving it over at least
[07:23] <mvo> pedronis: I did not, this happend this morning. but I think the intention is good and give us a chance to improve things. I understand your concerns though, maybe we can hide it and tweak it with the help of graham and then add it back? how does that sound?
[07:24] <pedronis> mvo: it should have been put in some place easier to edit at least initially
[07:25] <mborzecki> pedronis: ok, let me find out where degville keeps the pages for editing, move it to that location and we can take it from ther, wdyt?
[07:26] <mup> PR snapd#8767 closed: snap: (small) refactor of `snap download` code for testing/extending <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8767>
[07:33] <mborzecki> mvo: small tweak https://github.com/snapcore/snapd/pull/8722#discussion_r434363214
[07:33] <mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
[07:36] <mvo> mborzecki: let's do that then, move into degville queue and hide until it's a bit nicer (we need to remove some bits like "buy")
[07:36] <mborzecki> ack
[07:37] <zyga> mvo: https://github.com/snapcore/snapd/pull/8722#pullrequestreview-423293055
[07:37] <mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
[07:46] <degville> mborzecki / mvo / pedronis: (morning!) it's great we're updating those API docs (thanks mborzecki!) - they've been on my mind for a long time. I think it's ok marking them WIP on the forum for now until we can go over them. They won't be published outside the forum until we add the page to the whitelist. They're currently only as broken as the GH wiki version :)
[07:49] <mborzecki> degville: hi, thanks for the tip, was about to add the header you have in other docs but i see you're already editing the page
[07:50] <degville> mborzecki: yeah, I just expanded on your note a little.
[07:51] <mborzecki> degville: great, thank you
[07:54] <pedronis> degville: there are really some things that we want to stop documenting, that's the part I'm unhappy about
[07:55] <pedronis> becaue they are again in fron of people
[07:56] <degville> pedronis: ok. would you rather I unlist the page? or would you simply prefer us to move it to a google doc for now?
[07:57] <pedronis> degville: well unlist for now and we talk in the standup about what needs removing and we decide how to proceed?
[07:57] <degville> pedronis: yep, np.
[07:57] <degville> done
[07:59] <mborzecki> pedronis: should we unlist the wiki page too? https://github.com/snapcore/snapd/wiki/REST-API
[08:03] <mborzecki> mvo: playing with your gdbserver branch, i think i've hit: https://sourceware.org/bugzilla/show_bug.cgi?id=18945
[08:05] <mborzecki> mvo: maybe it'd also be nice to pass a port number in --gdbserver[=<port>], otherwise the gdb command is different for each invocation
[08:08] <mvo> mborzecki: looking, sorry
[08:09] <pedronis> mborzecki: we can do that once we have decided what to do with the moving to the forum
[08:09] <mborzecki> pedronis: ok
[08:16] <mup> PR snapd#8773 closed: overlord/configstate: add sysctl option <Created by EthanHsieh> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8773>
[08:18] <mvo> mborzecki: reading this bug makes me wonder if the approach is doomed
[08:18] <mvo> mborzecki: actually, hm
[08:18] <mvo> mborzecki: maybe a quick ho?
[08:18] <mborzecki> mvo: ok
[08:18] <mborzecki> standup?
[08:19] <mvo> mborzecki: yeah, 1min
[08:19] <mvo> mborzecki: ready when you are
[09:48] <zyga> pedronis: can you look at https://github.com/snapcore/snapd/pull/8778 again please
[09:48] <mup> PR #8778: tests: modernize and use snapd.tool <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
[09:48] <pedronis> zyga: not now, just mark it unblocked I suppose
[09:48] <zyga> ok
[09:48] <zyga> I put it on PATH
[09:48] <zyga> I guess that's okay
[09:55] <mborzecki> mvo: pushed some tweaks to https://github.com/snapcore/snapd/pull/8784 please take a look when you have a slot
[09:55] <mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
[09:57] <mvo> mborzecki: \o/ thank you, looking
[09:58] <mvo> mborzecki: thanks for https://github.com/snapcore/snapd/pull/8784#discussion_r434384356 - I like this idea a lot
[09:58] <mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
[10:00] <mvo> mborzecki: I really like your idea of breaking at exec and avoid the raise(SIGTRAP) but that's for later I guess :)
[10:30] <mborzecki> hmm actually surprised, i'm looking at the backtrace from a segfault in snap-store
[10:31] <mborzecki> target:/snap/snap-store/467/gnome-platform/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 gtk3 in gnome platform snap are built with symbols?
[10:31] <mborzecki> the entries in backtrace are pretty detailed, eg `#5  0x00007f473cedab04 in gtk_label_get_preferred_layout_size (label=0x5612253d4ef0, smallest=0x7ffcf00c89b0, widest=0x7ffcf00c89a0) at ../gtk/gtklabel.c:3725`
[10:32] <mborzecki> heh, info sharedlibrary definitely lists some of the libraries in snap-store & gnome snaps are cotnainig debug symbols
[10:42] <zyga> pedronis: do you have a moment to summarize what you want to do about snapd tools?
[10:43] <zyga> pedronis: you said you want them to behave more like in classic
[10:43] <zyga> are you thinking about making whatever tools we have available in the initial mount ns and then just inheriting all of that (and change propagation) into snap namespaces?
[10:44] <pedronis> zyga: probably better to chat tomorrow
[10:44] <zyga> pedronis: I may be off tomorrow for a medical visit, if you have the time just summarize this in an email and share that when you have the time
[10:44] <zyga> pedronis: but that's fine, I have things to do
[10:44] <zyga> just wanted to understand your ideas better
[10:46] <mup> PR snapd#8796 opened: tests: modernize retry tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8796>
[10:48] <mborzecki> zyga: https://forum.snapcraft.io/t/gimp-broken/17958
[10:49] <zyga> hmm
[10:49]  * zyga tries
[10:50] <zyga> mborzecki: I wonder if we released robust mount namespace updates?
[10:51] <mborzecki> wasn't that in 2.44 already?
[10:52] <mborzecki> ah no, it was but disabled, 2.45 made it default in https://github.com/snapcore/snapd/commit/716ec3de3526e7c6eb1b22e3d077b4fc48d69a6e
[10:54] <zyga> mborzecki: works on my machine :/
[10:56] <mborzecki> heh ;)
[10:56] <mborzecki> quick errand, back in 30
[11:29] <mborzecki> re
[11:45] <zyga> pstolowski: follow up from the parsed security tag branch https://github.com/snapcore/snapd/pull/8797
[11:45] <mup> PR #8797: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>
[11:46] <pstolowski> zyga: ty!
[11:47] <mup> PR snapd#8797 opened: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>
[11:51] <mborzecki> zyga: something is wrong with the spread jobs, ther's a bunch of queued jobs, some from 15h ago
[11:52] <zyga> mborzecki: checking
[11:53] <zyga> hmmm
[11:53] <zyga> odd
[11:53] <mborzecki> zyga: https://github.com/snapcore/snapd/actions?query=workflow%3ATests
[11:53] <zyga> yeah, I looked
[11:53] <zyga> I saw something similar yesterda
[11:53] <zyga> when after a unit test job was finished
[11:53] <zyga> all of a sudden *all* the spread jobs started
[11:54] <zyga> maybe it's somehow related to slot allocation
[11:56] <pedronis> mborzecki: I did a pass on #8775, it's a bit unclear what should happen with the recovery partition scripts
[11:56] <mup> PR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
[11:56] <pedronis> it seems to support updates but not installing
[11:56] <pedronis> but then updates are called install
[11:57] <zyga> mborzecki: ha, it just happened
[11:57] <zyga> brb
[12:03] <mborzecki> pedronis: thanks, will check the comments
[12:03] <mborzecki> zyga: anything interesting there? did the spread jobs start?
[12:04] <jdstrand> mvo, pstolowski: is tests/lib/nested.sh supposed to be shellcheck clean on bionic?
[12:05] <pstolowski> jdstrand: it should be clean everywhere, yes
[12:06] <jdstrand> let me get you a paste
[12:06] <jdstrand> (me dev container is still bionic)
[12:07] <jdstrand> my*
[12:07] <jdstrand> pstolowski: https://paste.ubuntu.com/p/wPYVVt4VdX/
[12:08] <jdstrand> pstolowski: you did touch that line recently, but if I change it back, more errors are unconvered
[12:10] <pstolowski> jdstrand: that's unexpected, should have been caught on travis; thanks, i'll check it
[12:11] <jdstrand> pstolowski: thank you. note, it had been a while (weeks?) since I last ran run-checks (tasked with work that didn't involve submitting PRs), so not sure when it was introduced
[12:14] <zyga> hmmm
[12:14] <zyga> mborzecki: lxd refreshed and we ran out of memory
[12:14] <zyga> we allocated all the memory and the system was in limbo state after oom killer went hunting
[12:15] <pstolowski> jdstrand: ok,  weird.. even recently i had a shellcheck error there and it was preventing merging. very weird it get through
[12:15] <pstolowski> *got
[12:15] <mborzecki> zyga: hm, w8, how much mem does this system have?
[12:15] <zyga> I'm looking though the logs now
[12:15] <zyga> 8GB
[12:15] <zyga> mborzecki: but it's not usually staturated, it's happened the moment lxd refresh ran
[12:16] <zyga> https://usercontent.irccloud-cdn.com/file/DTVVZl9c/overnight%20lxd%20refresh%20crash
[12:16] <zyga> load average approaching 1K?
[12:17] <mborzecki> hmm auto update ;)
[12:17] <zyga> maybe I should configure lxd with memory limits
[12:17] <mborzecki> zyga: can you see what got killed by oom?
[12:18] <zyga> https://usercontent.irccloud-cdn.com/file/j5i39wAk/dashboard%20over%20last%20two%20weeks
[12:27] <jdstrand> pstolowski: I noticed that shellcheck is only conditionally run on if it is installed. not sure if that helps track things down for you...
[12:28] <pstolowski> jdstrand: interesting.. thanks!
[12:34] <pedronis> pstolowski: should we re-run things to land #8567? or do you want to see #8780 green first?
[12:34] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[12:34] <mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
[12:36] <pstolowski> pedronis: restarted. i don't think it needs to wait for 8780
[12:36] <pedronis> ok
[12:37] <mup> PR snapd#8798 opened: data/selinux: allow checking /var/cache/app-info <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
[12:37] <mup> PR snapd#8799 opened: interfaces/system-packages-doc: fix typo in variable names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8799>
[12:46] <pedronis> jdstrand: I tried to answer your questions in a couple of open PRs
[12:47] <xnox> mvo:  what needs to happen to have https://github.com/snapcore/bolt/pull/1 merged & then vendorized version updated?
[12:47] <mup> PR bolt#1: Enable riscv64 build <Created by xnox> <https://github.com/snapcore/bolt/pull/1>
[12:47] <xnox> given it is #1 i fear this has never been excercised =)
[12:50] <zyga> pedronis: updated the parsed tag PR
[12:50] <zyga> I need to reboot, my thinkpad is acting up again, x input broke
[12:50] <zyga> eh
[12:51] <jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/8398#issuecomment-638175977 (I deconflicted but there are cla-check issues still)
[12:51] <mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
[12:54] <zyga> jdstrand: o/ 8788 is not more strict (the hwcaps PR)
[12:54] <zyga> is *now* more strict
[12:59] <jdstrand> pe
[12:59] <mvo> xnox: merged now, now it just needs an update to the vendor.json in snapd, I can do that after the meeting
[13:00] <jdstrand> pedronis: thanks! I responded to PR 8789 (note, that isn't urgent so if you're busy, feel free to circle back)
[13:00] <mup> PR #8789: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8789>
[13:00] <zyga> mvo: I don't really feel able to attend the meeting today
[13:00] <xnox> mvo:  tah. I don't know how to correctly do govendor stuff. and plus then the ci will run against this bolt change for the first time.
[13:00] <xnox> it better not regress anything on non-riscv64!
[13:01] <mborzecki> pstolowski: https://github.com/snapcore/snapd/blob/master/.github/workflows/test.yaml#L74-L78
[13:02] <mborzecki> maybe we should use --edge there
[13:02] <mvo> zyga: no worries, get well!
[13:02] <mvo> xnox: no worries
[13:03] <pstolowski> mborzecki: thanks, is it run only on 16.04 or am I reading it wrong?
[13:08] <pstolowski> jdstrand: turns out we run shellcheck from a snap (which is shellcheck 0.7.0). bionic has shellcheck 0.4.6
[13:10] <pstolowski> jdstrand: can you try with the version from snap?
[13:17] <jdstrand> oh!
[13:17] <mup> PR snapd#8800 opened: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8800>
[13:18] <jdstrand> pstolowski: absolutely yes. I was thinking I needed to backport shellcheck from focal, but then when you said it was supposed to work everywhere, I stopped
[13:20] <jdstrand> mvo: ok, sorry to keep pinging you. as mentioned, I deconflicted PR 8398. The submitter signed the cla (see my PR comment) but cla-check is still failing. so I milestoned that to 2.46 and then created PR 8800 for 2.45 with 'Original-Author: troyready <troy@troyready.com>'
[13:20] <mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
[13:20] <mup> PR #8800: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8800>
[13:20] <jdstrand> mvo: but it failed with: 'troy@troyready.com (https://api.launchpad.net/1.0/~troyready) has NOT signed the CLA'
[13:20] <pstolowski> jdstrand: ok, good; so for clarity, we only care about latest shellcheck
[13:21] <jdstrand> mvo: oh, actually, I see troyready signed the code of conduct, I don't know about the cla, but he has a screenshot in the original PR
[13:21] <jdstrand> mvo: so, yeah, I'll defer to you on how to proceed
[13:27] <jdstrand> pstolowski: yep, understood
[13:35] <zyga> gah, another sudden power off
[14:01] <mvo> xnox: I pushed 8801 with the bolt update
[14:02] <mvo> jdstrand: thanks, I have a look why the cla is acting up, it's unfortunately a constant hassle :(
[14:02] <mup> PR snapd#8801 opened: vendor: update to latest github.com/snapcore/bolt for riscv64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8801>
[14:05] <jdstrand> mvo: :\
[14:20]  * cachio afk
[14:41] <zyga> cmatsuoka: when would be a good time to update spread?
[14:41] <zyga> do you need the new master deployed?
[14:42] <cmatsuoka> zyga: let me update the yaml and prepare a PR to update the secure-boot attribute
[14:42] <zyga> cmatsuoka: I think we should burn through the current queue first
[14:43] <zyga> cmatsuoka: can we agree on a a time, perhaps tonight when europe stops working
[14:43] <cmatsuoka> zyga: sounds good, I'll leave the PR ready and then we can switch at any convenient time
[14:43] <zyga> ok
[14:51] <cmatsuoka> zyga: https://github.com/snapcore/snapd/pull/8802
[14:51] <mup> PR #8802: spread.yaml: update secure boot attribute name <Simple 😃> <Skip spread> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>
[14:52] <zyga> hmm perhaps skip spread is undesired :)
[14:52] <zyga> but I think we can close and reopen without it
[14:52] <zyga> that's fine, I'll do this late at night when there is less activity
[14:52] <mup> PR snapd#8802 opened: spread.yaml: update secure boot attribute name <Simple 😃> <Skip spread> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>
[14:53] <cmatsuoka> zyga: it will fail with the current spread, but we can remove the skip tag after spread is updated
[14:53] <zyga> ok
[14:53] <zyga> yeah, we learned that the tags tend to stick though :)
[14:53] <zyga> that's fine
[14:53] <zyga> we can use the close / open trick
[14:53] <cmatsuoka> oh really? well ok then
[14:53]  * zyga breaks for some time to just rest and avoid pain 
[14:53] <zyga> yeah, we noticed when the tag was first used in actions but perhaps this was not common knowledge in the team yet
[14:56] <cmatsuoka> if everything else fails we can close it and open another PR :)
[14:57] <zyga> or run it manually and land :)
[15:10] <pstolowski> cachio: could you take a look at the new spread test in https://github.com/snapcore/snapd/pull/8780  ?
[15:10] <mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
[15:13] <mup> PR snapcraft#3154 opened: cmake v2 plugin: take source-subdir into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3154>
[15:46] <pedronis> ijohnson: you froze for me
[15:47] <ijohnson> yes rejoingin one moemnt sorry
[15:50]  * cjp256 laughed at`Download snap "snapcraft" (4852) from channel "latest/edge"  0%  0B/s ages!` 
[15:51] <cjp256> Specifically at the 'ages!', not the fact it's not downloading anything :)
[15:53] <mup> PR snapd#8803 opened: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8803>
[16:03] <cachio> pstolowski, sorry, I was with the doctor
[16:03] <cachio> pstolowski, I'll check it now
[16:06] <cmatsuoka> cjp256: at 0B/s it should really be never, not ages
[16:06] <pstolowski> cjp256: haha, i've never seen this; interestingly i've just checked, and we have a TODO there saying "// TODO: figure out exactly what overflow causes the ==0"
[16:07] <cjp256> cmatsuoka: I think it is being optimistic ;)
[16:07] <cjp256> hah
[16:07] <pstolowski> yeah, it wants to give hope
[16:17] <cachio> pstolowski, review done
[16:17] <cachio> just minor changes required.
[16:17] <pstolowski> cachio: thanks!
[16:17] <cachio> pstolowski, yaw
[16:43] <zyga> the day of constant pain is not a good day
[16:52] <zyga> hrm
[16:52] <zyga> I have a patch I cannot find
[16:52] <zyga> where did I put it
[16:53] <mup> PR snapd#8804 opened: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>
[16:56] <zyga> I'll make some coffee and get painkillers
[16:56] <zyga> and then do one more PR
[16:56] <zyga> and maybe help drain the queue by running more workers
[16:56] <zyga> afk
[17:11] <zyga> re
[17:13] <pstolowski> cachio: hey, re your comment for " 2 functions: 1 for unsign and 1 for sign "
[17:14] <pstolowski> cachio: do you think just one function that does sbattach --remove & sbsign would be ok? i'm not sure we need more granularity
[17:15] <cachio> pstolowski, yes
[17:15] <pstolowski> ok
[17:15] <cachio> the idea is to have that as a function so the tests are more easy to read / understand
[17:15] <cachio> in the future
[17:15] <cachio> thanks
[17:28] <zyga> https://github.com/snapcore/snapd/pull/8805 is the last one :)
[17:28] <mup> PR #8805: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>
[17:28] <mup> PR snapd#8805 opened: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>
[17:28] <zyga> please look at the two "test robustness" PRs
[17:28] <zyga> no more leaking dbus
[17:30] <om26er> Is there a place to track progress of UbuntuCore 20, its "what's new" and an expected timeline for its release ?
[17:32] <zyga> om26er: good question
[17:32] <zyga> om26er: it's a bit hazy, apart from what's in the PRs that are landing
[17:33] <zyga> om26er: I heard that beta is coming soon but there are still some TODOs in the code
[17:34] <om26er> maybe there is a public kanban I could look at ?
[17:35] <zyga> nope
[17:35] <zyga> I wish we used github projects for the public side but that didn't go far
[17:35] <zyga> you can expect ongoing releases to broaden core20 support
[17:43] <mup> PR snapd#8806 opened: tests: install/run the lzo test snap too <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8806>
[17:48]  * cachio -> app with doctor part 2
[17:50] <pstolowski> cachio: updated #8780
[17:50] <mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
[18:13] <zyga> hmm
[18:13] <zyga> I will fight the pain and go and turn on some extra workers
[18:13] <zyga> this queue is not shrinking fast enough
[18:45] <cmatsuoka> hmm, tests stalled again
[18:47] <zyga> sorry, I was not able to go down
[18:48] <zyga> back hurts badly and affects leg
[18:49] <cmatsuoka> ah ugh, yeah, don't do anything that could make it worse
[19:34] <mup> PR snapcraft#3155 opened: storeapi: specify Content-Type for icon <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3155>
[19:44] <mup> PR snapcraft#3156 opened: log: trace HTTP connections with developer debug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3156>
[19:53] <cachio> zyga, any idea why jobs for #8790 are queued?
[19:53] <mup> PR #8790: tests: update the file used to detect the boot path on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8790>
[19:53] <zyga> because we are burning through this backlog: https://github.com/snapcore/snapd/actions?query=is%3Aqueued
[19:56] <cachio> zyga, I see
[20:19] <jdstrand> degville (cc emitorino): hi! is https://github.com/snapcore/snapd/wiki/REST-API the right place to look at the rest api of /run/snapd.socket? I expected something more like https://api.snapcraft.io/docs/info.html but for snapd's socket (also, what about a similar page for snapctl?)
[20:21] <degville> jdstrand: unfortunately, yes, right now. Moving it to somewhere more appropriate is on our immediate to do list, and we're meeting this week to discuss it.
[20:21] <degville> And of course updating it and the process to keep it updated.
[20:22] <jdstrand> degville: oh, heh. nice. AIUI, the snapctl api could probably live on the same page since it will largely be a subset of the snapd api
[20:23] <emitorino> ack jdstrand
[20:23] <jdstrand> degville: but emitorino and I were talking about how there is a lack of documentation on the security properties of /run/snapd.socket (snap) vs /run/snapd-snap.socket (snapctl), so perhaps some verbiage on that could be included? 2 cents
[20:26] <jdstrand> degville: thanks for all your doc work btw :)
[20:26] <degville> jdstrand / emitorino: yes, definitely. after we've sorted its location and how we'll keep it updated, maybe i could ping you for your thoughts. Also, thanks for the snapctl api (oh, thanks :) still lots to do!)
[20:29] <jdstrand> degville: perhaps add userd's DBus API to the list as well (along with its security properties, if it makes sense there)? (sorry, that is the last one I had in my mind)
[20:29] <jdstrand> degville: and yes, emitorino and I would be happy to chat about the security aspects whenever it makes sense for you
[20:30] <degville> jdstrand: ok. Thank you!
[20:58] <zyga> I managed to get downstaris and I lit up 32 more nodes
[20:58] <zyga> we should eat the rest of the queue quickly now
[20:58] <cachio> zyga, awesome, thaks a lot
[21:01] <cmatsuoka> zyga: thanks, but be careful, the impact will be much larger if you get worse
[21:01] <zyga> cmatsuoka: thank you, I really want to get better
[21:01]  * cmatsuoka just ordered a new NAS
[21:02] <zyga> neat :)
[21:02] <zyga> degville: I bought SC-D70 earlier today
[21:02] <zyga> cmatsuoka: I joined the midi party
[21:03] <cmatsuoka> zyga: oh haha, what did you get there?
[21:03] <zyga> cmatsuoka: a vintage roland midi module
[21:03] <cmatsuoka> the canvas? or mt?
[21:03] <zyga> the canvas
[21:03] <zyga> canvas D70
[21:03] <cmatsuoka> oh nice!
[21:04] <zyga> it's the most modern of the pack
[21:04] <cmatsuoka> haha, that's great
[21:04] <zyga> and does a bit more than the older guys
[21:04] <degville> zyga: awesome!
[21:09] <zyga> all the workers are lit up but they are not receiving jobs from github
[21:10] <cmatsuoka> humm, that's odd
[23:00] <mup> PR snapd#8807 opened: Revert "Enable riscv64 builds in the edge PPA without PIE" <Created by xnox> <https://github.com/snapcore/snapd/pull/8807>
[23:45] <mup> PR snapd#8808 opened: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>