[05:09] <zyga> Hello
[05:09] <zyga> I will start later today. My son is going for a weekly school trip. Need to see him off
[05:12] <mborzecki> morning
[05:57] <zyga> Hey hey
[05:57] <zyga> 07:09 <zyga> I will start later today. My son is going for a weekly school trip. Need to see him off
[06:26] <mborzecki> zyga: hey
[06:41] <zyga> Still waiting for the coach to pick the kids up
[06:42] <zyga> Lots of traffic in Waw this morning, could be a while
[07:05] <pstolowski> mornings
[07:10] <mup> PR snapd#6875 opened: store,daemon: add client-user-agent support to store.SnapInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/6875>
[07:25] <zyga> Hej Paweł
[07:32] <zyga> Hey pedronis, how are you doing?
[07:33] <zyga> I will be starting in about an hour
[07:33] <zyga> Bus is packed and ready to go (school trip)
[07:36] <mup> PR snapd#6876 opened: Optical-drive Interface: Add scsi-generic support <Created by diddledan> <https://github.com/snapcore/snapd/pull/6876>
[07:37] <diddledan> morning :-)
[07:41] <mborzecki> pstolowski: hey
[07:42] <pstolowski> o/
[07:49] <mborzecki> mvo taking a day off today?
[07:51] <mvo> mborzecki: I'm here
[07:51] <mborzecki> mvo: hi, didn't notice
[07:51] <mvo> mborzecki: doing silly admin stuff right now :)
[07:51] <mvo> mborzecki: yeah, mostly silent
[07:51] <mborzecki> mvo: #6872 needs a glimpse from you
[07:51] <mup> PR #6872: many: backport fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6872>
[07:52] <mvo> mborzecki: sure, will do !
[07:54] <pedronis> I'm around too, will swap Fri
[07:55] <zyga> re
[08:05]  * Chipaca thinks things are too quiet and goes to check his email
[08:08] <zyga> Chipaca: hey :)
[08:08] <zyga> how was last week
[08:08] <zyga> man, it's good to be home with all the peace and quiet here!
[08:09] <Chipaca> zyga: :)
[08:09] <Chipaca> last week was a'ight
[08:09] <zyga> and *plenty* of updates after last week's CPU bugs
[08:09]  * zyga reboots 
[08:11] <mvo> hey Chipaca and pstolowski !
[08:12] <pstolowski> hey o/
[08:13] <Chipaca> mvo: o/
[08:16] <Chipaca> mborzecki: with parallel installs, hooks don't run with remapped names, right? ie a hook can't do "snapctl restart foo.bar", they need to do "snapctl restart $SNAP.bar"?
[08:16] <mborzecki> Chipaca: the forum topic?
[08:16] <Chipaca> mborzecki: yes
[08:17] <Chipaca> mborzecki: just checking before telling them they're holding it wrong
[08:17] <mborzecki> Chipaca: wanted to sync with pedronis/mvo first, but I believe, all the commands should use $SNAP_INSTANCE_NAME & $SNAP_NAME instead of hardcoding nextcloud
[08:17] <mvo> yeah, hardcoding sounds bad(tm)
[08:17] <mborzecki> Chipaca: in that case, SNAP_INSTANCE_NAME == nextcloud_1
[08:17]  * Chipaca always hardcodes nextcloud even if the snap is called something else
[08:17] <Chipaca> mborzecki: good :)
[08:18] <Chipaca> bah, i can see the dev's perspecive on this, seems weird, but yeh
[08:18] <pedronis> yes, I'm not sure we can reasonably ask them that
[08:18] <mborzecki> doing magic could work, but i sense possible problems when we have cross snap ordering and whatnot
[08:19] <pedronis> why?
[08:19] <pedronis> by definition we will not let snap refer to other snaps by name
[08:19] <zyga> I think snapctl driven requests could easily be remapped
[08:20] <mborzecki> hmm if there's no chance they'd attempt to refer to other snap by name, then we can do it
[08:21] <pedronis> mborzecki: we really don't want snap to talk about other snap by name,  default-provider are the only exception, for sure not at runtime
[08:21] <pedronis> anyway I fear that the all set of service commands were a bit under thought out, as we know
[08:21] <pedronis> anyway it's fine to suggest a workaround, I don't see us jumping on changing this now either
[08:22] <mborzecki> i can put it my todo queue and take a look after gadget updates
[08:23] <pedronis> mborzecki: ok, maybe,  let's discuss when we get there
[08:23] <mborzecki> pedronis: sgtm :)
[08:25] <mborzecki> zyga: can you take a look at #6874 later on?
[08:25] <pedronis> pstolowski: hi, do you have something blocked on me?  what's the status of auto snapshot docs?
[08:25] <mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
[08:25] <zyga> mborzecki: will do
[08:26] <mborzecki> zyga: pinged jdstrand and pedronis for reviews on this one too
[08:28] <pstolowski> pedronis: hi, not really, you can take a look at the snap remove --purge PR, but it's not blocking antyhing. i've send the auto snapshot doc change to degville a few days ago
[08:29] <degville> pstolowski / pedronis: morning! I updated the docs with the auto snapshot details pstolowski sent over - on the getting started page, system options page and on the snapshots page.
[08:30] <pstolowski> degville: i think i forgot to clarify the time duration format ("d" for "days"), or did you sort that out yourself?
[08:31] <degville> pstolowski: I removed the day example (just used the hours example) until we had some clarification, so it still makes sense.
[08:32] <pstolowski> degville: k, thanks
[08:34] <zyga> mborzecki: reviewed
[08:41] <Chipaca> xnox: i'd like to know more about #1829510
[08:41] <mup> Bug #1829510: snapd connectivity check did not change fastly cdn <subiquity:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1829510>
[08:41] <Chipaca> xnox: istm there's more going on and you might've jumped to conclusions somewhere
[08:43] <mvo> pstolowski: was "Infrastructure to measure subtimings for operations" done for 2.39 or for 2.40 (iirc the later but not quite sure)
[08:45] <mvo> Chipaca: "snap download and related changes for snapcraft" is done, right? iirc it was 2.39 or is there something missing
[08:45] <Chipaca> mvo: no not done yet
[08:45] <mvo> Chipaca: oh, ok
[08:45] <Chipaca> mvo: it has two parts, one part is done, the other isn't
[08:45] <mvo> Chipaca: aha, ok - the --output part is missing?
[08:46] <mup> PR snapd#6877 opened: overlord/configstate: don't panic on invalid configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/6877>
[08:46] <pstolowski> mvo: let me check that
[08:46] <Chipaca> mvo: yes
[08:46] <mvo> Chipaca: ta!
[08:55] <pstolowski> mvo: yes, timings are 2.40; 2.39 is missing some important commits. and i've one more PR and a bug to fix there too
[08:56] <mvo> pstolowski: sure thing, thank you!
[08:56] <mvo> pstolowski: I will update trello
[08:56] <pstolowski> ty
[09:04] <zyga> brb
[09:16] <mvo> Chipaca: do you have a few min for a quick HO on the Snap-Client-User-Agent feature? just need someone to bounce ideas off :)
[09:17] <Chipaca> mvo: in 5?
[09:17] <Chipaca> got a bit of context right now
[09:20] <pedronis> mvo: I suspect  you maybe should leave that to Chipaca at this point, I fear I'll have opinions on details and will drag a bit
[09:20] <mvo> Chipaca: sure, or in 10 if you prefer
[09:21] <mvo> pedronis: ok, I hope this won't change to radically from what we have right now up for review
[09:21] <pedronis> probably not, but we are adding context everywhere, we should try to do it right, given now is in the new cycle work
[09:21] <mvo> pedronis: do you already have a sense of how to transmit the client-user-agent from a "snap install"? I mean, have you looked at this yet? it seems we need to put it on the download task
[09:22] <pedronis> have we agreed to need it on download?
[09:23] <Chipaca> I thought it was only needed in the synchronous part
[09:23] <Chipaca> i.e. in what we call the info and refresh endpoints
[09:23] <mvo> pedronis, Chipaca we can do it either way, I think doing it in the task is more realistic but either way will work
[09:23] <Chipaca> (refresh being what we hit for install/download/refresh)
[09:23] <mvo> (this is mostly why I wanted to talk :)
[09:23] <Chipaca> ok
[09:24] <Chipaca> i'll just finish wrapping up this (more PRs for reviewage) and then will be free for y'awl
[09:24] <pedronis> we can ask the store what they prefer, not needing it in download would slightly better for us
[09:24] <mvo> pedronis: ok, I can kick this off and then we can decide based on their reply
[09:25] <mvo> pedronis: out of curiosity, is your current thinking to add a context to "snapstate.Install" ?
[09:25] <pedronis> yes
[09:26] <pedronis> in theory anything that we would like to interrupt should take it
[09:26] <pedronis> unrelatedly of this precise task
[09:26] <mvo> pedronis: all right! I think thats all I wanted to know, so no need for further discussion with Chipaca  I think. and its easy to extend to download if we have to
[09:26] <mvo> pedronis: thank you!
[09:26] <mup> PR snapd#6878 opened: cmd/snap, etc: add health to 'snap list' and 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/6878>
[09:27] <Chipaca> mvo: pedronis: ok i'm ready, am i needed?
[09:27] <pedronis> Chipaca: I don't know
[09:27]  * Chipaca weeps
[09:27] <Chipaca> :-p
[09:30] <mup> PR snapd#6653 closed: tests: try to be a little bit invariant <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6653>
[09:31] <mvo> Chipaca: I think pedronis already answerd all my questions :)
[09:32] <mvo> Chipaca: sorry, we can still chat if you want
[09:32] <Chipaca> mvo: nah :)
[09:32] <mvo> heh :)
[09:57] <mvo> thanks degville for updating trello :)
[09:58] <degville> oh, no problem mvo - sorry I left the card there so long.
[09:58] <mvo> degville: no worries
[10:12] <mup> PR snapd#6879 opened: [RFC] overlord: add context.Context to snapstate.Install() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6879>
[10:21]  * Chipaca takes a break
[10:28] <mup> PR snapd#6877 closed: overlord/configstate: don't panic on invalid configuration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6877>
[10:36] <pstolowski> cac:
[10:38] <pstolowski> ups
[10:44] <mborzecki> zyga: about nsswitch, it doesn't happen in our spread setup bc it's modified in our image
[10:44] <zyga> ahhh
[10:44] <zyga> do you know why it was modified?
[10:44] <zyga> mborzecki: https://github.com/zyga/mimic-bug offtopic
[10:45] <zyga> mborzecki: this illustrates the issue I was fighting last week
[10:45] <mborzecki> zyga: no clue, i don't see anything in our test setup or spread
[10:45] <zyga> mborzecki: probably the image was "cured"
[10:45] <zyga> mborzecki: if you have a moment please have a look at bug.sh
[10:45] <zyga> I would love to have a call and discuss options
[10:45] <zyga> I feel a bit stuck now :/
[10:46] <zyga> just need to grab a coffee
[10:46] <zyga> still overdosed from last week :)
[10:56] <xnox> Chipaca:  re connectivity check => so snapd found new subiquity snap (visibile with like $ snap info SNAPNAME) but $ snap download SNAPNAME was stalling, ie. zero progress because connectivity to fastly requires proxy.
[10:56] <xnox> Chipaca:  what logs / details do you need from me? i can try to recreate that network setup and gather things for you.
[10:56] <zyga> mborzecki: ok
[10:56] <Chipaca> xnox: but "snap download" and "snap refresh" are very different paths wrt proxies
[10:57] <Chipaca> xnox: which one was it? because the bug mentions refresh
[10:57] <xnox> Chipaca:  it was both.
[10:57] <Chipaca> xnox: and the connectivity check reflects what happens on refresh, not download
[10:58] <xnox> Chipaca:  both refresh, and download stalling, despite info showing that new stuff is available.
[10:58] <xnox> Chipaca:  i believe subiqutiy queries snapd's connectivity check before showing the "new installer is available screen"
[10:59] <zyga> mborzecki: do you have some time for interactive debugging?
[10:59] <Chipaca> xnox: if you could turn set SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=7 in /etc/environment that might give us an insight into what's going on
[10:59] <mborzecki> zyga: need ~15 minutes
[10:59] <zyga> sure
[10:59] <zyga> thank you!
[10:59] <xnox> Chipaca:  ack.
[10:59] <Chipaca> xnox: (snapd would have to restart to pick those up)
[11:00] <xnox> sure.
[11:00] <Chipaca> xnox: if the connectivity check is not picking up on the problem, something's wrong and needs fixing
[11:00] <Chipaca> xnox: otoh i don't know where these things run, maybe cloud-init needs tweaking?
[11:01] <Chipaca> its configuration i mean
[11:01] <Chipaca> i honestly don't know
[11:01] <Chipaca> here's hoping for logs :)
[11:02] <xnox> well, i care about this in the context of subiquity server live image.... and I know how to hack that to do what I want =) so we are all good.
[11:04] <xnox> mvo:  vorlon: i still think i want to pre-built correct initrds for all arches, and publish them into the snapstore. Only for the snapcraft kernel plugin to consume them as staging those snaps..... Not for them to be installed on target devices directly.
[11:05] <xnox> Kind of like "shipping a snapcraft build-dependency as a snap in the store"
[11:05] <xnox> cause i am being asked for a FDE embedable initrd, for uc16 and uc18 as well as uc20
[11:09] <zyga> mborzecki: https://meet.google.com/bpg-rxba-igg?ijlm=1558350555676&hs=125&adhoc=1&authuser=0 when ready
[11:13] <mup> PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[11:18] <pedronis> Chipaca: connectivity-check tries a download but yes snap download will use different configs all together atm
[11:18] <Chipaca> pedronis: yes as i said
[11:19] <Chipaca> pedronis: but the bug talked about 'refresh', not download, otherwise i would've brought that up earlier
[11:19] <Chipaca> pedronis: but it turns out connectivity-check works, but neither refresh nor download do
[11:19] <Chipaca> pedronis: hence, gimme logs
[11:19] <pedronis> yea, that's unexpected
[11:31] <Chipaca> lunch is calling
[11:38]  * Chipaca obeys
[11:48] <cachio> pstolowski, hey
[11:48] <pstolowski> cachio: hey! i've been debugging the test issue
[11:48] <cachio> pstolowski, nice
[11:48] <cachio> pstolowski, is it a test issue?
[11:49] <cachio> or is it a problem in the code?
[11:49] <pstolowski> cachio: so, first of, the test is incorrect
[11:49] <pstolowski> cachio: after fixing it passed on 16.04
[11:49] <cachio> nice
[11:50] <cachio> pstolowski, and on core18?
[11:50] <pstolowski> cachio: it sill fails on core 18 and i'm trying to find out why. fwtw i've flashed my pi3 with core18 from edge this morning and hotplug worked with real device, so i suspect it is still something with the est
[11:50] <pstolowski> *test
[11:50] <cachio> pstolowski, yes, probably, it is the first time we run this test on core
[11:51] <pstolowski> cachio: also, not sure if you noticed, it's probably not affecting this test directly, but in both cases the "initialize device" change fails repeatedely and is retried
[11:52] <pstolowski> cachio: https://paste.ubuntu.com/p/YRWth9FdjM/
[11:52] <pstolowski> cachio: it's device serial to be exact
[11:52] <cachio> pstolowski, yes
[11:53] <cachio> I knew that
[11:53] <pstolowski> ah ok
[11:53] <cachio> pstolowski, but it shouldn't affect
[12:00] <pstolowski> cachio: indeed, seems to be irrelevant
[12:25] <pstolowski> cachio: re core18 test failure i think it's not using the latest versions?
[12:25] <pstolowski> cachio: https://paste.ubuntu.com/p/67fJ4k8Mvw/
[12:26] <cachio> pstolowski, snanpd is still on stable
[12:27] <cachio> could you push the change you did to fix core16?
[12:27] <pstolowski> cachio: right, that's the issue
[12:27] <cachio> so then I'll push the fix fot that with other stuff that I also fixed today
[12:29] <pstolowski> cachio: ok, will do in a while, trying to run everything from this test now
[12:30] <cachio> pstolowski, nice
[12:59] <pstolowski> cachio: here is the diff https://pastebin.ubuntu.com/p/c3kMDWhzzM/
[12:59] <pstolowski> cachio: it passed for me on core16
[13:00] <cachio> pstolowski, nice, I'll add it to the next commit
[13:00] <cachio> thanks
[13:01] <zyga> mborzecki: dziala!
[13:53]  * zyga goes for lunch
[13:54] <cachio> pstolowski, so, could you please paste the whole test
[13:54] <pstolowski> sure
[13:54] <cachio> thanks
[13:55] <pstolowski> cachio: https://paste.ubuntu.com/p/mKryYZNtHK/
[13:55] <cachio> pstolowski, with this change in ubuntu-image I'll create a new PR after this one
[13:55] <cachio> so, the idea is to pre-generate the image witt the desired core/snapd and avoid the refresh which takes time
[13:55] <pstolowski> cachio: it's basically the original test from classic, minus the -writing bits for serial port that required dialout to work
[13:56] <cachio> pstolowski, nice, thanks
[13:56] <mup> PR snapd#6869 closed: daemon: only allow `users`/`create-users` when not on classic* <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6869>
[14:19] <pedronis> mborzecki: mvo: I gave my +1 to #6872
[14:19] <mup> PR #6872: many: backport fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6872>
[14:19] <mvo> pedronis: thank you
[14:20] <mup> PR snapd#6872 closed: many: backport fixes to 2.39 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6872>
[14:31] <pedronis> pstolowski: degville: auto snapshots docs don't seem to mention that atm they are off by default on core
[14:34] <mborzecki> off taking the kids to the troop meeting
[14:34] <degville> pedronis: thanks for checking - that's important - I'll add it now.
[14:36] <mup> PR snapd#6880 opened: daemon: refactor user ops to api_users <Created by chipaca> <https://github.com/snapcore/snapd/pull/6880>
[14:50] <Chipaca> pedronis: I addressed the concerned you'd raised in #6564 fwiw (other than two that're better left for a later pr)
[14:50] <mup> PR #6564: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/6564>
[14:52] <pstolowski> pedronis, degville to clarify - no snapshots for core snaps are created, only for app snaps; yes
[14:52] <pedronis> pstolowski: ?
[14:52] <degville> pstolowski: thank you!
[14:53] <pedronis> degville: pstolowski: I think we are talking about different things
[14:54] <pedronis> degville: pstolowski: I'm talking about this: https://github.com/snapcore/snapd/blob/master/overlord/snapshotstate/snapshotstate.go#L103
[14:55] <degville> pedronis/pstolowski: I'll mention both cases.
[14:55] <pedronis> on core we default to no
[14:58] <pstolowski> pedronis: ah, this landed while i was away beginning of May. i see, makes sense, thanks
[15:15] <pedronis> pstolowski: likely, we did this to be more conservative with disk space on core
[15:30]  * cachio lunch
[15:51] <pedronis> pstolowski: Chipaca: I did a pass on #6870
[15:51] <mup> PR #6870: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
[15:52] <pstolowski> pedronis: ty
[16:06] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[16:06] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[16:06] <mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
[16:07] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[16:07] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[16:07] <mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
[16:58] <cachio> pstolowski|afk, hey, I pushed the hotplug test working on both cores
[16:58] <cachio> pstolowski|afk, in a following PR I'll add the new improvemente to avoid test code duplication
[16:59] <cachio> pstolowski|afk, but I prefer keep it as it is to simplify the change and start running this new change as part of the nightly suite
[17:59] <mup> PR snapd#6618 closed: tests: validates snapd from ppa <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
[18:11]  * cachio afk
[20:49] <mup> PR snapd#6874 closed: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6874>