[05:05] morning [05:42] mvo: hi [05:43] good morning mborzecki [05:52] mborzecki: how are you? anything important that I missed in the morning so far :) ? [05:53] mvo: no, not really, some forum posts but nothing super interesting either [05:55] mborzecki: yeah, just looking over things, looks all pretty tame so far [06:06] Good morning. I woke up but please give me some time to come to senses and prepare for work. [06:08] zyga: good morning [06:08] zyga: no fires, take your time [06:23] zyga: hey [07:05] Had my coffee, did some basic unpacking of work stuff, just taking Bit for a short walk to buy bread. [07:06] I was home at around 11PM last night [07:07] zyga: take a day off [07:07] I plan to swap on Friday but I really want to write some reports before I forget [07:09] I also want to share what I know with everyone === chihchun_afk is now known as chihchun === pstolowski|afk is now known as pstolowski [07:16] Morning! [07:27] pstolowski: hey [07:44] ok [07:44] I think I'm "back" [07:44] now I have a huge pile of papers to go through [07:44] from the last two events [07:45] then email reporting and email catch-up [07:45] lastly some reviews I'd like to do [07:45] mvo: hey, any news from gustavo? [07:45] is the standup going to move to an earlier slot? === chihchun is now known as chihchun_afk [07:51] zyga: I have not heard from him yet [08:14] good morning Chipaca [08:14] zyga: greetings. You bring coffee? [08:15] Chipaca: now I feel uncomfortable because yes I do bring coffee, but I have no way to share [08:15] hey Chipaca ! good morning [08:15] Goooooood morning! [08:15] Chipaca: I'll bring you some next time we meet in person [08:15] niemeyer: wooot :) [08:15] hey niemeyer, welcome back! [08:15] zyga: :-) [08:15] niemeyer: hey, welcome, how was the hop across the pond? [08:15] niemeyer: welcome back! [08:15] Thanks! Very happy to be back [08:16] and now to get some coffee [08:16] niemeyer: do you plan to move the standup to an actual early morning stand up time? :-) [08:16] zyga: That'd be quite nice, but it also means we'd lose Sergio [08:17] indeed, that's not great :/ [08:20] we can move sergio [08:20] mborzecki: haha :D [08:20] we should ask him first though :) [08:21] morning [08:21] pedronis: hey [08:22] pstolowski: left some comments in https://github.com/snapcore/snapd/pull/5632 [08:25] mborzecki: thanks, looking [08:26] pedronis: Morning! [08:26] mvo, pedronis, mborzecki, good morning to you too [08:26] * Chipaca now has coffee and all is well [08:26] niemeyer: Chipaca: hey [08:27] Yo [08:27] niemeyer: welcome back [08:27] Given how chipper niemeyer is I can only assume he hasn't looked at his email yet (or he looked, selected all, and deleted) [08:27] hahaha [08:27] Chipaca: I have the same feeling [08:28] looking at my inbox now [08:28] hey pedronis, good morning :) [08:28] mvo: Chipaca: I see some PRs asking my review or that seems I should review, how urgent are they? [08:28] pedronis: if it's tagged 2.35, it's urgent [08:29] pedronis: if it isn't, probably not [08:29] Chipaca: mvo: can they wait the afternoon though or not? [08:29] * Chipaca defers to mvo on that [08:30] they are all marked 2.35 [08:30] ;) [08:31] pedronis: dangit [08:32] Chipaca: proxy reg is the large one [08:32] dangit² [08:33] pedronis: good morning, nice to have you back [08:33] pedronis: its not super urgent we have a bit of time for 2.35 in beta [08:33] pedronis: definitely can wait for the afternoon or tomorrow [08:33] ok, thank you, sounds reasonable [08:34] mvo: these should all be squash-merges at this point, right? [08:38] I see there's a bunch of PR for 2.35 [08:39] I mean, the ones waiting for me are not the only ones === chihchun_afk is now known as chihchun [08:45] pedronis: yeah, some need some high level input from niemeyer like 5340 and 5569, i.e. if the names and high level operations are ok [08:45] pedronis: the other ones are just work afaict [08:45] Ack [08:45] niemeyer: also not super urgent (just slightly urgent), I'm assuming you have tons of backlog from all directions [08:46] mvo: Yeah, it's been one of the most disconnected holidays I've had, so it's all a swamp now :) [08:47] niemeyer: hey o/ :) [08:47] mborzecki: replied, let me know if it makes sense [08:47] (re review comment) [08:48] pstolowski: o/ [08:57] pedronis: #5617 really starts with #5613 fwiw (but the latter landed already) [08:59] niemeyer: I can move the morning thing fwiw (even to the afternoon) [08:59] Chipaca: Which morning thing? [09:00] niemeyer: I saw you moving the standup around, and I've got an hour of my morning blocked off, but it's flexible [09:00] Chipaca: I see [09:01] I'll skim that too [09:01] Chipaca: Ah, thanks [09:01] Chipaca: I'm actually just trying to put our standup back into the usual time.. and having a hard time at it :) [09:01] Chipaca: I saw in the log you mentioned the autocontext, I suppose you find out that is not needed in the managers, it's mostly a thin wrapper for store around other helpers [09:01] niemeyer: hehe. It's there now :-) [09:02] pedronis: yeah, i chased it down until it disappeared :-) [09:02] I couldn't manage to get our old event to recur properly.. but I did manage to preserve our hangout by just copy & pasting the link into the location field [09:18] grrrr !!! [09:18] so the current images auto-refresh core in the middle of running console-conf [09:19] i thought we had a mechanism to prevent that [09:20] also ... snapd hangs on shutdown after an auto-refresh (1:30 timeout) is that known ? [09:32] ogra: We still have a mechanism to prevent that.. the mechanism is time-based, though [09:33] If it stays up for too long (2h?) it will attempt to refresh [09:33] well, it doesnt seem to use a very long timeout atm ... it happened a few mins after booting the VM [09:33] (initial boot that is) [09:33] ogra: it certainly not in the few minutes range [09:33] So something else is going on there [09:33] right, thats what i thought ... [09:34] (this is an older edge image from the 7th, might be an edge-only thing) [09:40] * ogra re-tries with the same image from scratch ... lets see if i can reproduce [09:41] yep [09:41] ogra: that is edge? stable? [09:41] reboots after about 2min [09:41] mvo, edge [09:42] ogra: uc16/amd64? i.e.. I just need to create an image and wait to reproduce? [09:42] mvo, see the other channel [09:43] ogra: thank you. to test on an stock image, will uc16/amd64 be okay? just to see if its already failing in the base images [09:43] ? [10:26] * Chipaca hugs kyrofa [10:27] * niemeyer hugs Chipaca and kyrofa with no context and shares the love [10:27] niemeyer: I -1'ed a PR of his [10:27] with a WAT [10:28] but he's still awesome [10:28] Damn.. I've mistaken a potential fight for love [10:28] love is full of fights, aint it ? [10:30] niemeyer: my hug was to emphasize that my criticism was with his work, not with himself [10:30] which is easy to forget [10:31] Chipaca: is command-chain supposed to support arguments at all ? [10:31] Chipaca: Ah, I thought maybe you were hugging him as a matter of self-protection [10:31] pedronis: well, in that implementation it does [10:31] ;P [10:31] niemeyer: I'm not scared of him, for two reasons [10:31] Chipaca: brokenly, though? [10:31] niemeyer: one, he's on the other side of the world [10:31] niemeyer: two, I can run longer [10:32] heh [10:33] pedronis, Chipaca: No, it shouldn't support arguments.. at least until we understand why [10:33] pedronis: if it's meant to replace a wrapper shell command, then it needs to be able to have spaces and stuff in it [10:33] niemeyer: that was my understanding as well [10:33] seems there is confusion around that though [10:33] The idea is to have the command able to be called as "foo bar baz actual-command -its -args" [10:34] If there are arguments, then we'll start to worry about ordering issues and whatnot [10:34] maybe is just a matter of missing validation [10:34] Chipaca I suppose knows more, he looked at the PR [10:34] heh [10:34] wait, if that _is_ what's wanted maybe the pr is ok === chihchun is now known as chihchun_afk [10:35] it does exec 'chain1 chain2 chain3 actualcmd arg arg arg' (except chainN can have args but let's ignore that bit for now) [10:35] given the feature is presented as a way to avoid having a wrapper, I thought this was not what was intended [10:36] IOW I thought what was wanted was 'chain1; chain2; actualcmd arg arg arg' [10:36] no, the former [10:36] because, you can _already_ have chain1 chain2 chain3 in cmd [10:36] but no args [10:36] Chipaca: yes, but then no --shell [10:36] etc [10:36] can you give me an example of what chains are, then? [10:37] I did read the forum post but it wasn't illuminating [10:37] Chipaca: first class (as in demarcated) wrappers [10:37] ? [10:38] niemeyer can probably say more [10:39] Chipaca: Sure, sorry for the lack of context [10:39] Chipaca: The idea is enabling wrappers to be dropped as they exist today [10:39] Chipaca: snapcraft today has to inject some logic via its plugins [10:39] Chipaca: The result is we get the messy shell script where "command" is just a line at the end of it [10:40] niemeyer: so the wrappers would still exist, they'd just be modified to take args like sudo & etc? [10:40] Chipaca: Instead, we want each plugin to generate its own content in its own script, and at the end call the rest of the chain [10:41] Chipaca: This enables the script to generate its environment, and have the rest of the chain within it [10:41] Chipaca: That also means it may be composed, seeing what's before and after it as a blackbox [10:42] Chipaca: and means we can have /bin/bash as the command and get the shell inside the tip, or after any of the commands really (we haven't designed UI for that latter part) [10:42] Chipaca: Right, they'd exist but be more isolated than they are today [10:43] Chipaca: Adding a wrapper just means adding the command to the end of the chain [10:44] This also makes templates work more easily [10:44] niemeyer: ok [10:45] niemeyer: I still fear tab completion might be too brittle to support this [10:45] niemeyer: but I'll leave it to implementers to figure out :-) [10:46] Chipaca: Not sure why? [10:46] Chipaca: I mean, the end result is effectively the same [10:47] Chipaca: I mean, today wrapped commands are already called inside a shell script, in a chain [10:48] niemeyer: right, but the completer wasn't wrapped [10:49] bah, as long as it all ends in an exec of what used to be exec'ed it'll be fine [10:52] Chipaca: Right, that's what I imagined [10:52] Chipaca: Or at least hoped.. :) [10:52] niemeyer: :-) [11:02] niemeyer, mvo, JamieBennett, popey: so I'm back home from Flock [11:02] I can honestly say that the talk was a great success [11:02] people were really interested (some difficult questions about store stuff aside) [11:03] and there's definitely interest in plugging in snap delivery into the Fedora pipeline [11:07] pstolowski: can we cherry-pick https://github.com/pilebones/go-udev/pull/14 into our tree without making later merges harder ? I'm not super familar with git subtree [11:08] Son_Goku: excellent, great to hear! Was it filmed? [11:08] yes, but probably poorly [11:08] hah [11:09] at least audio might be okay, but the hotel wanted to rip off the organizers on the A/V equipment, so last minute purchase of equipment happened [11:09] so you can guess it was kind of rickety [11:09] :/ [11:09] mvo: it should be fine, i did something similiar already (had local changes and later merged upstream, it just works out conflicts -if any- as you would expect from git, e.g. there'll be no conflicts unless you really touch same area) [11:11] mvo: can we just sync with upstream again whe your fix lands? there shouldn't be many changes, if any [11:13] pstolowski: yeah, no changes afaict, so that should be fine. I will propsoe the same pr against master now [11:14] mvo: ok. either way is fine [11:16] pstolowski: I did both now, pushed to upstream and also created one for us so we should be covered either way (ie. if upstream is slow) [11:16] mvo: great, ty! was it causing failures? [11:17] pstolowski: yes, build failure on powrpc [11:17] mvo: hmm, curious why didn't it fail when it landed earlier? [11:18] pstolowski: it probably did and it was lost in the noise [11:18] i see [11:18] ok, thanks for the fix! [11:18] pstolowski: but maybe not, might be worth investigating [11:18] pstolowski: do you remember when this landed? a while ago, right? [11:19] mvo: yes, at least 4-5 weeks ago [11:21] pstolowski: yeah, it looks like its failing since Jul 17 wich matches (roughly) the merge of go-udev stuff [11:25] mvo: and it's autopackage tests right? [11:25] pstolowski: yeah [11:26] mvo: right.. that's why it went under the radar [11:26] pstolowski: yeah, no biggie [11:26] pstolowski: but those small arches are always extra work [11:30] Son_Goku, a clever person would just have set up a mobile phone in each room to record videos ;) [11:30] you don't know how close you are to how the video was recorded [11:30] :D [11:33] ogra: dashcams are really cheap right now [11:39] * niemeyer steps out for lunch [11:42] Chipaca, +1 [11:46] jdstrand: did you get a chance to look at the hostnamectl denials? [11:55] yay, so after the updates to s-c and default apparmor profiles, the basic remapping/file-access tests is passing on ubuntu too [12:10] mvo: I reviewed #5611 [12:12] we lost mup? [12:13] pedronis: yes, it's been silent for the last 2+ weeks [12:23] Did mup go on holiday with niemeyer :) [12:26] pedronis: thank you! looking [12:27] pstolowski: pushed an update to https://github.com/snapcore/snapd/pull/5614 [12:28] mborzecki: thanks, will check in a moment [12:43] +1 [12:45] pstolowski: thanks [12:47] He broke down last Tuesday, apparently.. [12:47] mup: You okay now? [12:48] mup: no? [12:48] mup: echo foo [12:55] mup: How about now? [13:01] oh [13:01] standup! [13:02] Hmm.. I can't login [13:03] Is it just me? [13:04] niemeyer: we're all here [13:04] niemeyer: we [13:10] Chipaca: I reviewed a bit #5617 [13:12] pedronis: thanks [13:13] sparkiegeek: could you reply to pedronis' first comment on https://github.com/snapcore/snapd/pull/5617 ? (I could, but it'd be more authoritative from you) [13:20] mup: ping [13:26] Chipaca: I checked myself and it seems to be true but not sure it was ever tested [13:29] pedronis: i think it has unit tests, but i'm not sure that's what you mean :-) [13:30] Chipaca: I mean the proxying of registration [13:30] in the proxy [13:32] pedronis: yes, that's what i mean [13:33] pedronis: it didn't support custom serial vaults, but did support forwarding to the generic one [13:33] pedronis: and i think there are unit tests to that effect [13:45] pedronis: when you're done with higih priority stuff, I could use your one last look at https://github.com/snapcore/snapd/pull/5561 Chipaca and pstolowski went through it but as we know those changes may be a bit tricky [13:48] btw. 15th is a public holiday here (cc zyga pstolowski) [13:48] right, forgot about that [13:49] cachio: hey, you did some work around journalctl cursor in the spread test right [13:49] ? [13:49] yes [13:49] pstolowski, I implemented that in the tests [13:49] why? [13:50] cachio: good, so the problem i have is this - this is journalctl output I see when my test fails: https://paste.ubuntu.com/p/XH4ps65yQ3/ [13:50] cachio: note the " New test starts here " message [13:50] cachio: this is when the test thinks cursor starts [13:51] pstolowski, yes [13:51] cachio: so get_journalctl_log doesn't return the early snapd start messages (and i need to match those) [13:51] pstolowski, is there any problem there? [13:52] cachio: i wonder if that is intended or not; we seem to be preparing snapd after journcal curstor initialization, so it's not clear why it's like this [13:52] pstolowski, yes, it is intended [13:53] pstolowski, if we move the cursor initialization back, then we get a lot of messages from the previous test [13:53] pstolowski, and it was causing other issues [13:53] hmm allright [13:54] pstolowski, could you restart snapd as part of the test? [13:54] and check this initialization? [13:54] cachio: yes, that's what i was considering [13:54] just wanted to make sure it's intended [13:54] we are already doing that in one test [13:54] cachio: thanks [13:54] pstolowski, yaw [13:54] mup: You ok now? [13:55] pstolowski, check catalog-update teswt [13:55] pstolowski, I think this a similar test [14:01] mup: echo ok [14:01] niemeyer: ok [14:01] Yep.. nickserv registration issues, related to the spam measures recently adopted [14:01] popey: ^ [14:01] \o/ [14:03] mborzecki: yes, will look at parallel installs after I have unblocked other things [14:03] pedronis: thanks === Eleventh_Doctor is now known as Pharaoh_Atem [14:11] niemeyer: what's the plan to prevent snap (your QA systems?) from flooding https://errors.ubuntu.com/ ? [14:16] popey: afaik snapd QA is not reporting errors back to errors.ubuntu.com [14:17] popey: On a call [14:17] popey: Will ping a moment [14:17] in a [14:18] zyga, hey [14:18] I ran the fedora base test on core [14:18] yes? [14:18] and it is failing [14:18] https://paste.ubuntu.com/p/cGs978ZWqy/ [14:19] yes, it's expected until master hits edge but let me look at the failure [14:19] it is trying to get the snap.yaml from an incorrect path [14:19] yeah, that's exactly that [14:19] which version of snapd was that? [14:19] beta core [14:19] I am suing 2.34 [14:19] I am suing 2.35 [14:19] I will check if this is in master and in edge [14:19] popey: To make sure we're on the same page, what's the exact issue there? Do we have any open bugs or forum topics? [14:20] zyga, if it has been addresses it is ok [14:20] cachio: fetching now, I'll let you know in a moment [14:20] PR snapd#5638 opened: interfaces: basic spread test for udev monitor [14:20] cachio: but the same test I used passed when the branch was merged [14:20] cachio: so I believe it is fixed now, just out of sync in that channel [14:20] cachio: (we added a spread test for it) [14:20] zyga, well, this spread test is failing [14:21] Error executing external:ubuntu-core-16-64:tests/main/fedora-base-smoke [14:21] cachio: it _passed_ when it was merged into master so either the external target is older than master (which is IMO likely) or something broke since [14:21] one sec, almost done here [14:22] niemeyer: we discussed in one of the sprints months back. Basically errors.ubuntu.com seems to have a flood of crash reports from snap. They're coming from kvm based installs. I think m_vo and c_hipaca looked into it, and suggested it was from your build / testing systems [14:22] niemeyer: having the site flooded with snap crashes makes it less useful / usable. [14:23] cachio: reproduced in edge, so I suspect edge is just out of date [14:23] cachio: I will re-check with master [14:23] popey: I recall a related conversation back then, and I recall we actually landed changes to reduce how much we logged [14:24] popey: It'd be nice to have a proper forum topic so we can have more details about the problem and so people can follow through [14:26] niemeyer: I will start a new thread [14:26] popey: Thank you [14:36] Chipaca, I haven't looked at the review yet, but indeed, that chain args are intended (see the forum proposal as well as the enshrining spread test) [14:47] zyga, are yoiu planning to upload the fedora snapd for arm and other architectures? [14:48] zyga, it is failing on arm64 [14:48] zyga, or should I push the PR to skip it? [14:48] skip it please [14:49] it's hard to cross-build today [14:49] it will auto build later when it's done inside the fedora infra [14:49] zyga, sure, tx [14:49] thank you [14:49] kyrofa: psh, don't come here with your "facts" [14:51] Chipaca, heh. Find to get rid of them, but they're 1) easy to support, 2) requested by someone, and 3) have no clear downside [14:51] Fine* [14:53] I suspect this is simply an "easier to add functionality than remove it" argument, which is of course reasonable [14:53] kyrofa: you mean arguments in the chain? [14:53] kyrofa: yeah [14:53] Indeed [14:55] PR snapd#5639 opened: snapcraft: set version information for the snapd snap [14:56] kyrofa: I hope the review ended up making sense though [14:57] Chipaca, indeed. Does the functionality make sense, now? [14:57] kyrofa: silly question, when is the snapcraft version script run? after the build by any chance? [14:58] Chipaca, there are so many snaps out there where `snap run --shell` doesn't represent anything close to the real environment because of all these wrappers [14:59] mvo: +1 for #5611 with a nitpick [14:59] PR #5611: devicestate: only run device-hook when fully seeded [14:59] pedronis: thank you, checking [15:00] mvo, during the prime step [15:02] kyrofa: cool, thanks [15:02] Chipaca: added a question to #5617, I think the answer is no, but making sure [15:02] PR #5617: overlord/devicestate: DTRT w/a snap proxy to reach a serial vault [15:03] PR snapd#5640 opened: tests: skip unsupported architectures for fedora-base-smoke test [15:08] mvo: looked at #5631 as well, couple of comment/questions [15:08] PR #5631: snapstate: ensure normal snaps wait for the "snapd" snap on refresh [15:18] PR core18#63 opened: [RFC] snapcraft.yaml: add current date to core18 rev [15:20] pedronis: thanks for your comments on 5583 too! [15:23] mvo: since you reviewed some of my udev stuff last week, would you find a moment for https://github.com/snapcore/snapd/pull/5618 or https://github.com/snapcore/snapd/pull/5632 ? [15:23] PR #5618: overlord: instantiate UDevMonitor [15:23] PR #5632: overlord: integrate device enumeration with udev monitor [16:07] Chipaca, https://paste.ubuntu.com/p/FJVhj5H2H7/ see those permissions [16:07] I saw you changed install-sideload to check this [16:08] but in core it is failing [16:49] mvo you should switch to snapcraftctl set-version $(whatever) (last section of https://snapdocs.labix.org/extracting-information-from-sources-in-snapcraft-parts/4642) [16:49] cachio_: how are those files getting there? [16:51] PR snapcraft#2209 closed: tests: add spread suite for tar-content plugin [16:59] Chipaca, which ones?? [16:59] all of them? [16:59] I think those are downloaded during test executions [17:22] sergiusens, but set-version only works from an override or am i wrong ? [17:23] (i use it all the time btw, it is awesome ... but if you dont have overrides it is kind of forcing adding one on you) [17:28] ogra: so? snapcraftctl makes what you would otherwise override actually run [17:32] cachio_, spread from master can't seem to run with snapd's spread.yaml: preserve-size is an invalid size string? [17:32] Know anything about that? [17:33] kyrofa, you need to update spread [17:33] cachio_, I did [17:33] mmm [17:33] did you download a spread again? [17:34] I ran `go get` [17:34] curl -s -O https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz && tar xzvf spread-amd64.tar.gz [17:34] try that [17:34]