/srv/irclogs.ubuntu.com/2020/06/03/#snappy.txt

mborzeckimorning05:09
mvohey mborzecki05:18
mborzeckimvo: hey05:19
mupPR snapd#8777 closed: packaging: disable buildmode=pie for riscv64 <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8777>05:20
mborzeckimvo: 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 whatnot05:22
mvomborzecki: sorry for the delay, did not see the msg - here are the docs https://github.com/snapcore/snapd/wiki/REST-API06:19
mvomborzecki: but very outdated06:20
mborzeckimvo: thanks!06:23
mborzeckimvo: hm maybe we should move that to the forum06:24
mborzeckimvo: 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 though06:35
mvomborzecki: oh, nice06:37
mvomborzecki: 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 something06:38
mborzeckifunny, 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 there06:38
mborzeckimvo: perhaps we can discuss that quickly during the standup?06:39
mvomborzecki: +106:40
mvomborzecki: 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 good06:41
mvomborzecki: 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
mvomborzecki: anyway, thanks for doing this!06:41
mborzeckimvo: with gh actions, maybe we could update the forum doc automatically? :)06:42
mvomborzecki: heh - nice idea!06:42
zygao/06:58
mvogood morning zyga06:58
zygamborzecki: actions can trigger on directories06:58
zygagood morning06:58
zygathough it's bad, I can barely stand :/06:59
mvozyga: oh no :(06:59
mborzeckizyga: 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:00
mborzeckisame markdown should work on github wiki if we want to keep maintaining that07:01
pstolowskimorning07:02
zygaeh, thinkpad died on the spot again07:12
pedronismvo: mborzecki: what is this https://forum.snapcraft.io/t/snapd-rest-api/17954 ?07:13
mborzeckipedronis: 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
mvopedronis: it's the old rest API from the wiki, mborzecki  moved it over to the forum this morning07:16
pedronisI would really like to involved in this kind of things07:16
pedronismvo: there are bit that we probably don't want to document anymore at all07:17
mborzeckipedronis: sorry, maybe i was a bit quick to move that07:17
mvopedronis: 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
pedronismvo: did we plan to work on this right now?07:19
pedronisbut yes, moving it over without a plan of how to improve it doesn't seem a great idea to me, but my 2cts07:20
mvopedronis: we did not plan this07:20
mupPR 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
mvopedronis: if you think it's a net-negative we can just hide/remove it again07:21
pedronismvo: did you at least talk with Graham?07:21
mborzeckipedronis: 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 incrementally07:22
pedronismborzecki: the problem is, we should discuss what to simply scrub before moving it over at least07:23
mvopedronis: 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:23
pedronismvo: it should have been put in some place easier to edit at least initially07:24
mborzeckipedronis: 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:25
mupPR 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:26
mborzeckimvo: small tweak https://github.com/snapcore/snapd/pull/8722#discussion_r43436321407:33
mupPR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>07:33
mvomborzecki: 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
mborzeckiack07:36
zygamvo: https://github.com/snapcore/snapd/pull/8722#pullrequestreview-42329305507:37
mupPR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>07:37
degvillemborzecki / 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:46
mborzeckidegville: hi, thanks for the tip, was about to add the header you have in other docs but i see you're already editing the page07:49
degvillemborzecki: yeah, I just expanded on your note a little.07:50
mborzeckidegville: great, thank you07:51
pedronisdegville: there are really some things that we want to stop documenting, that's the part I'm unhappy about07:54
pedronisbecaue they are again in fron of people07:55
degvillepedronis: ok. would you rather I unlist the page? or would you simply prefer us to move it to a google doc for now?07:56
pedronisdegville: well unlist for now and we talk in the standup about what needs removing and we decide how to proceed?07:57
degvillepedronis: yep, np.07:57
degvilledone07:57
mborzeckipedronis: should we unlist the wiki page too? https://github.com/snapcore/snapd/wiki/REST-API07:59
mborzeckimvo: playing with your gdbserver branch, i think i've hit: https://sourceware.org/bugzilla/show_bug.cgi?id=1894508:03
mborzeckimvo: maybe it'd also be nice to pass a port number in --gdbserver[=<port>], otherwise the gdb command is different for each invocation08:05
mvomborzecki: looking, sorry08:08
pedronismborzecki: we can do that once we have decided what to do with the moving to the forum08:09
mborzeckipedronis: ok08:09
mupPR snapd#8773 closed: overlord/configstate: add sysctl option <Created by EthanHsieh> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8773>08:16
mvomborzecki: reading this bug makes me wonder if the approach is doomed08:18
mvomborzecki: actually, hm08:18
mvomborzecki: maybe a quick ho?08:18
mborzeckimvo: ok08:18
mborzeckistandup?08:18
mvomborzecki: yeah, 1min08:19
mvomborzecki: ready when you are08:19
=== ricab__ is now known as ricab
zygapedronis: can you look at https://github.com/snapcore/snapd/pull/8778 again please09:48
mupPR #8778: tests: modernize and use snapd.tool <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>09:48
pedroniszyga: not now, just mark it unblocked I suppose09:48
zygaok09:48
zygaI put it on PATH09:48
zygaI guess that's okay09:48
mborzeckimvo: pushed some tweaks to https://github.com/snapcore/snapd/pull/8784 please take a look when you have a slot09:55
mupPR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>09:55
mvomborzecki: \o/ thank you, looking09:57
mvomborzecki: thanks for https://github.com/snapcore/snapd/pull/8784#discussion_r434384356 - I like this idea a lot09:58
mupPR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>09:58
mvomborzecki: I really like your idea of breaking at exec and avoid the raise(SIGTRAP) but that's for later I guess :)10:00
mborzeckihmm actually surprised, i'm looking at the backtrace from a segfault in snap-store10:30
mborzeckitarget:/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
mborzeckithe 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:31
mborzeckiheh, info sharedlibrary definitely lists some of the libraries in snap-store & gnome snaps are cotnainig debug symbols10:32
zygapedronis: do you have a moment to summarize what you want to do about snapd tools?10:42
zygapedronis: you said you want them to behave more like in classic10:43
zygaare 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:43
pedroniszyga: probably better to chat tomorrow10:44
zygapedronis: 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 time10:44
zygapedronis: but that's fine, I have things to do10:44
zygajust wanted to understand your ideas better10:44
mupPR snapd#8796 opened: tests: modernize retry tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8796>10:46
mborzeckizyga: https://forum.snapcraft.io/t/gimp-broken/1795810:48
zygahmm10:49
* zyga tries10:49
zygamborzecki: I wonder if we released robust mount namespace updates?10:50
mborzeckiwasn't that in 2.44 already?10:51
mborzeckiah no, it was but disabled, 2.45 made it default in https://github.com/snapcore/snapd/commit/716ec3de3526e7c6eb1b22e3d077b4fc48d69a6e10:52
zygamborzecki: works on my machine :/10:54
mborzeckiheh ;)10:56
mborzeckiquick errand, back in 3010:56
=== facundo__ is now known as facubatista
mborzeckire11:29
zygapstolowski: follow up from the parsed security tag branch https://github.com/snapcore/snapd/pull/879711:45
mupPR #8797: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>11:45
pstolowskizyga: ty!11:46
mupPR 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:47
mborzeckizyga: something is wrong with the spread jobs, ther's a bunch of queued jobs, some from 15h ago11:51
zygamborzecki: checking11:52
zygahmmm11:53
zygaodd11:53
mborzeckizyga: https://github.com/snapcore/snapd/actions?query=workflow%3ATests11:53
zygayeah, I looked11:53
zygaI saw something similar yesterda11:53
zygawhen after a unit test job was finished11:53
zygaall of a sudden *all* the spread jobs started11:53
zygamaybe it's somehow related to slot allocation11:54
pedronismborzecki: I did a pass on #8775, it's a bit unclear what should happen with the recovery partition scripts11:56
mupPR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>11:56
pedronisit seems to support updates but not installing11:56
pedronisbut then updates are called install11:56
zygamborzecki: ha, it just happened11:57
zygabrb11:57
mborzeckipedronis: thanks, will check the comments12:03
mborzeckizyga: anything interesting there? did the spread jobs start?12:03
jdstrandmvo, pstolowski: is tests/lib/nested.sh supposed to be shellcheck clean on bionic?12:04
pstolowskijdstrand: it should be clean everywhere, yes12:05
jdstrandlet me get you a paste12:06
jdstrand(me dev container is still bionic)12:06
jdstrandmy*12:07
jdstrandpstolowski: https://paste.ubuntu.com/p/wPYVVt4VdX/12:07
jdstrandpstolowski: you did touch that line recently, but if I change it back, more errors are unconvered12:08
pstolowskijdstrand: that's unexpected, should have been caught on travis; thanks, i'll check it12:10
jdstrandpstolowski: 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 introduced12:11
zygahmmm12:14
zygamborzecki: lxd refreshed and we ran out of memory12:14
zygawe allocated all the memory and the system was in limbo state after oom killer went hunting12:14
pstolowskijdstrand: ok,  weird.. even recently i had a shellcheck error there and it was preventing merging. very weird it get through12:15
pstolowski*got12:15
mborzeckizyga: hm, w8, how much mem does this system have?12:15
zygaI'm looking though the logs now12:15
zyga8GB12:15
zygamborzecki: but it's not usually staturated, it's happened the moment lxd refresh ran12:15
zygahttps://usercontent.irccloud-cdn.com/file/DTVVZl9c/overnight%20lxd%20refresh%20crash12:16
zygaload average approaching 1K?12:16
mborzeckihmm auto update ;)12:17
zygamaybe I should configure lxd with memory limits12:17
mborzeckizyga: can you see what got killed by oom?12:17
zygahttps://usercontent.irccloud-cdn.com/file/j5i39wAk/dashboard%20over%20last%20two%20weeks12:18
jdstrandpstolowski: I noticed that shellcheck is only conditionally run on if it is installed. not sure if that helps track things down for you...12:27
pstolowskijdstrand: interesting.. thanks!12:28
pedronispstolowski: should we re-run things to land #8567? or do you want to see #8780 green first?12:34
mupPR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>12:34
mupPR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>12:34
pstolowskipedronis: restarted. i don't think it needs to wait for 878012:36
pedronisok12:36
mupPR snapd#8798 opened: data/selinux: allow checking /var/cache/app-info <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>12:37
mupPR snapd#8799 opened: interfaces/system-packages-doc: fix typo in variable names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8799>12:37
=== KindTwo is now known as KindOne
pedronisjdstrand: I tried to answer your questions in a couple of open PRs12:46
xnoxmvo:  what needs to happen to have https://github.com/snapcore/bolt/pull/1 merged & then vendorized version updated?12:47
mupPR bolt#1: Enable riscv64 build <Created by xnox> <https://github.com/snapcore/bolt/pull/1>12:47
xnoxgiven it is #1 i fear this has never been excercised =)12:47
zygapedronis: updated the parsed tag PR12:50
zygaI need to reboot, my thinkpad is acting up again, x input broke12:50
zygaeh12:50
jdstrandmvo: fyi, https://github.com/snapcore/snapd/pull/8398#issuecomment-638175977 (I deconflicted but there are cla-check issues still)12:51
mupPR #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:51
zygajdstrand: o/ 8788 is not more strict (the hwcaps PR)12:54
zygais *now* more strict12:54
jdstrandpe12:59
mvoxnox: merged now, now it just needs an update to the vendor.json in snapd, I can do that after the meeting12:59
jdstrandpedronis: thanks! I responded to PR 8789 (note, that isn't urgent so if you're busy, feel free to circle back)13:00
mupPR #8789: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8789>13:00
zygamvo: I don't really feel able to attend the meeting today13:00
xnoxmvo:  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
xnoxit better not regress anything on non-riscv64!13:00
mborzeckipstolowski: https://github.com/snapcore/snapd/blob/master/.github/workflows/test.yaml#L74-L7813:01
mborzeckimaybe we should use --edge there13:02
mvozyga: no worries, get well!13:02
mvoxnox: no worries13:02
pstolowskimborzecki: thanks, is it run only on 16.04 or am I reading it wrong?13:03
pstolowskijdstrand: turns out we run shellcheck from a snap (which is shellcheck 0.7.0). bionic has shellcheck 0.4.613:08
pstolowskijdstrand: can you try with the version from snap?13:10
jdstrandoh!13:17
mupPR 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:17
jdstrandpstolowski: absolutely yes. I was thinking I needed to backport shellcheck from focal, but then when you said it was supposed to work everywhere, I stopped13:18
jdstrandmvo: 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
mupPR #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
mupPR #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
jdstrandmvo: but it failed with: 'troy@troyready.com (https://api.launchpad.net/1.0/~troyready) has NOT signed the CLA'13:20
pstolowskijdstrand: ok, good; so for clarity, we only care about latest shellcheck13:20
jdstrandmvo: 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 PR13:21
jdstrandmvo: so, yeah, I'll defer to you on how to proceed13:21
jdstrandpstolowski: yep, understood13:27
=== facundo__ is now known as facubatista
zygagah, another sudden power off13:35
mvoxnox: I pushed 8801 with the bolt update14:01
mvojdstrand: thanks, I have a look why the cla is acting up, it's unfortunately a constant hassle :(14:02
mupPR snapd#8801 opened: vendor: update to latest github.com/snapcore/bolt for riscv64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8801>14:02
jdstrandmvo: :\14:05
* cachio afk14:20
zygacmatsuoka: when would be a good time to update spread?14:41
zygado you need the new master deployed?14:41
cmatsuokazyga: let me update the yaml and prepare a PR to update the secure-boot attribute14:42
zygacmatsuoka: I think we should burn through the current queue first14:42
zygacmatsuoka: can we agree on a a time, perhaps tonight when europe stops working14:43
cmatsuokazyga: sounds good, I'll leave the PR ready and then we can switch at any convenient time14:43
zygaok14:43
cmatsuokazyga: https://github.com/snapcore/snapd/pull/880214:51
mupPR #8802: spread.yaml: update secure boot attribute name <Simple 😃> <Skip spread> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>14:51
zygahmm perhaps skip spread is undesired :)14:52
zygabut I think we can close and reopen without it14:52
zygathat's fine, I'll do this late at night when there is less activity14:52
mupPR 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:52
cmatsuokazyga: it will fail with the current spread, but we can remove the skip tag after spread is updated14:53
zygaok14:53
zygayeah, we learned that the tags tend to stick though :)14:53
zygathat's fine14:53
zygawe can use the close / open trick14:53
cmatsuokaoh really? well ok then14:53
* zyga breaks for some time to just rest and avoid pain 14:53
zygayeah, we noticed when the tag was first used in actions but perhaps this was not common knowledge in the team yet14:53
cmatsuokaif everything else fails we can close it and open another PR :)14:56
zygaor run it manually and land :)14:57
pstolowskicachio: could you take a look at the new spread test in https://github.com/snapcore/snapd/pull/8780  ?15:10
mupPR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>15:10
mupPR snapcraft#3154 opened: cmake v2 plugin: take source-subdir into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3154>15:13
pedronisijohnson: you froze for me15:46
ijohnsonyes rejoingin one moemnt sorry15:47
* cjp256 laughed at`Download snap "snapcraft" (4852) from channel "latest/edge" 0% 0B/s ages!` 15:50
cjp256Specifically at the 'ages!', not the fact it's not downloading anything :)15:51
mupPR snapd#8803 opened: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8803>15:53
cachiopstolowski, sorry, I was with the doctor16:03
cachiopstolowski, I'll check it now16:03
cmatsuokacjp256: at 0B/s it should really be never, not ages16:06
pstolowskicjp256: 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:06
cjp256cmatsuoka: I think it is being optimistic ;)16:07
cjp256hah16:07
pstolowskiyeah, it wants to give hope16:07
cachiopstolowski, review done16:17
cachiojust minor changes required.16:17
pstolowskicachio: thanks!16:17
cachiopstolowski, yaw16:17
zygathe day of constant pain is not a good day16:43
zygahrm16:52
zygaI have a patch I cannot find16:52
zygawhere did I put it16:52
mupPR snapd#8804 opened: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>16:53
zygaI'll make some coffee and get painkillers16:56
zygaand then do one more PR16:56
zygaand maybe help drain the queue by running more workers16:56
zygaafk16:56
zygare17:11
pstolowskicachio: hey, re your comment for " 2 functions: 1 for unsign and 1 for sign "17:13
pstolowskicachio: do you think just one function that does sbattach --remove & sbsign would be ok? i'm not sure we need more granularity17:14
cachiopstolowski, yes17:15
pstolowskiok17:15
cachiothe idea is to have that as a function so the tests are more easy to read / understand17:15
cachioin the future17:15
cachiothanks17:15
zygahttps://github.com/snapcore/snapd/pull/8805 is the last one :)17:28
mupPR #8805: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>17:28
mupPR 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
zygaplease look at the two "test robustness" PRs17:28
zygano more leaking dbus17:28
om26erIs there a place to track progress of UbuntuCore 20, its "what's new" and an expected timeline for its release ?17:30
zygaom26er: good question17:32
zygaom26er: it's a bit hazy, apart from what's in the PRs that are landing17:32
zygaom26er: I heard that beta is coming soon but there are still some TODOs in the code17:33
om26ermaybe there is a public kanban I could look at ?17:34
zyganope17:35
zygaI wish we used github projects for the public side but that didn't go far17:35
zygayou can expect ongoing releases to broaden core20 support17:35
mupPR snapd#8806 opened: tests: install/run the lzo test snap too <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8806>17:43
* cachio -> app with doctor part 217:48
pstolowskicachio: updated #878017:50
mupPR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>17:50
zygahmm18:13
zygaI will fight the pain and go and turn on some extra workers18:13
zygathis queue is not shrinking fast enough18:13
cmatsuokahmm, tests stalled again18:45
zygasorry, I was not able to go down18:47
zygaback hurts badly and affects leg18:48
cmatsuokaah ugh, yeah, don't do anything that could make it worse18:49
mupPR snapcraft#3155 opened: storeapi: specify Content-Type for icon <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3155>19:34
mupPR snapcraft#3156 opened: log: trace HTTP connections with developer debug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3156>19:44
cachiozyga, any idea why jobs for #8790 are queued?19:53
mupPR #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
zygabecause we are burning through this backlog: https://github.com/snapcore/snapd/actions?query=is%3Aqueued19:53
cachiozyga, I see19:56
jdstranddegville (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:19
degvillejdstrand: 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
degvilleAnd of course updating it and the process to keep it updated.20:21
jdstranddegville: oh, heh. nice. AIUI, the snapctl api could probably live on the same page since it will largely be a subset of the snapd api20:22
emitorinoack jdstrand20:23
jdstranddegville: 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 cents20:23
jdstranddegville: thanks for all your doc work btw :)20:26
degvillejdstrand / 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:26
jdstranddegville: 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
jdstranddegville: and yes, emitorino and I would be happy to chat about the security aspects whenever it makes sense for you20:29
degvillejdstrand: ok. Thank you!20:30
zygaI managed to get downstaris and I lit up 32 more nodes20:58
zygawe should eat the rest of the queue quickly now20:58
cachiozyga, awesome, thaks a lot20:58
cmatsuokazyga: thanks, but be careful, the impact will be much larger if you get worse21:01
zygacmatsuoka: thank you, I really want to get better21:01
* cmatsuoka just ordered a new NAS21:01
zyganeat :)21:02
zygadegville: I bought SC-D70 earlier today21:02
zygacmatsuoka: I joined the midi party21:02
cmatsuokazyga: oh haha, what did you get there?21:03
zygacmatsuoka: a vintage roland midi module21:03
cmatsuokathe canvas? or mt?21:03
zygathe canvas21:03
zygacanvas D7021:03
cmatsuokaoh nice!21:03
zygait's the most modern of the pack21:04
cmatsuokahaha, that's great21:04
zygaand does a bit more than the older guys21:04
degvillezyga: awesome!21:04
zygaall the workers are lit up but they are not receiving jobs from github21:09
cmatsuokahumm, that's odd21:10
mupPR snapd#8807 opened: Revert "Enable riscv64 builds in the edge PPA without PIE" <Created by xnox> <https://github.com/snapcore/snapd/pull/8807>23:00
mupPR snapd#8808 opened: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>23:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!