[05:05] <mborzecki> morning
[05:42] <mborzecki> mvo: hi
[05:43] <mvo> good morning mborzecki
[05:52] <mvo> mborzecki: how are you? anything important that I missed in the morning so far :) ?
[05:53] <mborzecki> mvo: no, not really, some forum posts but nothing super interesting either
[05:55] <mvo> mborzecki: yeah, just looking over things, looks all pretty tame so far
[06:06] <zyga> Good morning. I woke up but please give me some time to come to senses and prepare for work.
[06:08] <mvo> zyga: good morning
[06:08] <mvo> zyga: no fires, take your time
[06:23] <mborzecki> zyga: hey
[07:05] <zyga> Had my coffee, did some basic unpacking of work stuff, just taking Bit for a short walk to buy bread.
[07:06] <zyga> I was home at around 11PM last night
[07:07] <mborzecki> zyga: take a day off
[07:07] <zyga> I plan to swap on Friday but I really want to write some reports before I forget
[07:09] <zyga> I also want to share what I know with everyone
[07:16] <pstolowski> Morning!
[07:27] <mborzecki> pstolowski: hey
[07:44] <zyga> ok
[07:44] <zyga> I think I'm "back"
[07:44] <zyga> now I have a huge pile of papers to go through
[07:44] <zyga> from the last two events
[07:45] <zyga> then email reporting and email catch-up
[07:45] <zyga> lastly some reviews I'd like to do
[07:45] <zyga> mvo: hey, any news from gustavo?
[07:45] <zyga> is the standup going to move to an earlier slot?
[07:51] <mvo> zyga: I have not heard from him yet
[08:14] <zyga> good morning Chipaca
[08:14] <Chipaca> zyga: greetings. You bring coffee?
[08:15] <zyga> Chipaca: now I feel uncomfortable because yes I do bring coffee, but I have no way to share
[08:15] <mvo> hey Chipaca ! good morning
[08:15] <niemeyer> Goooooood morning!
[08:15] <zyga> Chipaca: I'll bring you some next time we meet in person
[08:15] <zyga> niemeyer: wooot :)
[08:15] <mvo> hey niemeyer, welcome back!
[08:15] <Chipaca> zyga: :-)
[08:15] <zyga> niemeyer: hey, welcome, how was the hop across the pond?
[08:15] <Chipaca> niemeyer: welcome back!
[08:15] <niemeyer> Thanks! Very happy to be back
[08:16] <Chipaca> and now to get some coffee
[08:16] <zyga> niemeyer: do you plan to move the standup to an actual early morning stand up time? :-)
[08:16] <niemeyer> zyga: That'd be quite nice, but it also means we'd lose Sergio
[08:17] <zyga> indeed, that's not great :/
[08:20] <mborzecki> we can move sergio
[08:20] <zyga> mborzecki: haha :D
[08:20] <zyga> we should ask him first though :)
[08:21] <pedronis> morning
[08:21] <mborzecki> pedronis: hey
[08:22] <mborzecki> pstolowski: left some comments in https://github.com/snapcore/snapd/pull/5632
[08:25] <pstolowski> mborzecki: thanks, looking
[08:26] <niemeyer> pedronis: Morning!
[08:26] <Chipaca> mvo, pedronis, mborzecki, good morning to you too
[08:26]  * Chipaca now has coffee and all is well
[08:26] <mborzecki> niemeyer: Chipaca: hey
[08:27] <niemeyer> Yo
[08:27] <pedronis> niemeyer: welcome back
[08:27] <Chipaca> 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] <zyga> hahaha
[08:27] <zyga> Chipaca: I have the same feeling
[08:28] <zyga> looking at my inbox now
[08:28] <zyga> hey pedronis, good morning :)
[08:28] <pedronis> mvo: Chipaca: I see some PRs asking my review or that seems I should review, how urgent are they?
[08:28] <Chipaca> pedronis: if  it's tagged 2.35, it's urgent
[08:29] <Chipaca> pedronis: if it isn't, probably not
[08:29] <pedronis> Chipaca: mvo: can they wait the afternoon though or not?
[08:29]  * Chipaca defers to mvo on that
[08:30] <pedronis> they are all marked 2.35
[08:30] <pedronis> ;)
[08:31] <Chipaca> pedronis: dangit
[08:32] <pedronis> Chipaca: proxy reg is the large one
[08:32] <Chipaca> dangit²
[08:33] <mvo> pedronis: good morning, nice to have you back
[08:33] <mvo> pedronis: its not super urgent we have a bit of time for 2.35 in beta
[08:33] <mvo> pedronis: definitely can wait for the afternoon or tomorrow
[08:33] <pedronis> ok, thank you, sounds reasonable
[08:34] <Chipaca> mvo: these should all be squash-merges at this point, right?
[08:38] <pedronis> I see there's a bunch of PR for 2.35
[08:39] <pedronis> I mean, the ones waiting for me are not the only ones
[08:45] <mvo> 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] <mvo> pedronis: the other ones are just work afaict
[08:45] <niemeyer> Ack
[08:45] <mvo> niemeyer: also not super urgent (just slightly urgent), I'm assuming you have tons of backlog from all directions
[08:46] <niemeyer> mvo: Yeah, it's been one of the most disconnected holidays I've had, so it's all a swamp now :)
[08:47] <pstolowski> niemeyer: hey o/ :)
[08:47] <pstolowski> mborzecki: replied, let me know if it makes sense
[08:47] <pstolowski> (re review comment)
[08:48] <niemeyer> pstolowski: o/
[08:57] <Chipaca> pedronis: #5617 really starts with #5613 fwiw (but the latter landed already)
[08:59] <Chipaca> niemeyer: I can move the morning thing fwiw (even to the afternoon)
[08:59] <niemeyer> Chipaca: Which morning thing?
[09:00] <Chipaca> 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] <pedronis> Chipaca: I see
[09:01] <pedronis> I'll skim that too
[09:01] <niemeyer> Chipaca: Ah, thanks
[09:01] <niemeyer> Chipaca: I'm actually just trying to put our standup back into the usual time.. and having a hard time at it :)
[09:01] <pedronis> 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] <Chipaca> niemeyer: hehe. It's there now :-)
[09:02] <Chipaca> pedronis: yeah, i chased it down until it disappeared :-)
[09:02] <niemeyer> 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] <ogra> grrrr !!!
[09:18] <ogra> so the current images auto-refresh core in the middle of running console-conf
[09:19] <ogra> i thought we had a mechanism to prevent that
[09:20] <ogra> also ... snapd hangs on shutdown after an auto-refresh (1:30 timeout) is that known ?
[09:32] <niemeyer> ogra: We still have a mechanism to prevent that.. the mechanism is time-based, though
[09:33] <niemeyer> If it stays up for too long (2h?) it will attempt to refresh
[09:33] <ogra> well, it doesnt seem to use a very long timeout atm ... it happened a few mins after booting the VM
[09:33] <ogra> (initial boot that is)
[09:33] <niemeyer> ogra: it certainly not in the few minutes range
[09:33] <niemeyer> So something else is going on there
[09:33] <ogra> right, thats what i thought ...
[09:34] <ogra> (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] <ogra> yep
[09:41] <mvo> ogra: that is edge? stable?
[09:41] <ogra> reboots after about 2min
[09:41] <ogra> mvo, edge
[09:42] <mvo> ogra: uc16/amd64? i.e.. I just need to create an image and wait to reproduce?
[09:42] <ogra> mvo, see the other channel
[09:43] <mvo> 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] <mvo> ?
[10:26]  * Chipaca hugs kyrofa 
[10:27]  * niemeyer hugs Chipaca and kyrofa with no context and shares the love
[10:27] <Chipaca> niemeyer: I -1'ed a PR of his
[10:27] <Chipaca> with a WAT
[10:28] <Chipaca> but he's still awesome
[10:28] <niemeyer> Damn.. I've mistaken a potential fight for love
[10:28] <ogra> love is full of fights, aint it ?
[10:30] <Chipaca> niemeyer: my hug was to emphasize that my criticism was with his work, not with himself
[10:30] <Chipaca> which is easy to forget
[10:31] <pedronis> Chipaca: is command-chain supposed to support arguments at all ?
[10:31] <niemeyer> Chipaca: Ah, I thought maybe you were hugging him as a matter of self-protection
[10:31] <Chipaca> pedronis: well, in that implementation it does
[10:31] <niemeyer> ;P
[10:31] <Chipaca> niemeyer: I'm not scared of him, for two reasons
[10:31] <pedronis> Chipaca: brokenly, though?
[10:31] <Chipaca> niemeyer: one, he's on the other side of the world
[10:31] <Chipaca> niemeyer: two, I can run longer
[10:32] <pedronis> heh
[10:33] <niemeyer> pedronis, Chipaca: No, it shouldn't support arguments.. at least until we understand why
[10:33] <Chipaca> 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] <pedronis> niemeyer: that was my understanding as well
[10:33] <pedronis> seems there is confusion around that though
[10:33] <niemeyer> The idea is to have the command able to be called as "foo bar baz actual-command -its -args"
[10:34] <niemeyer> If there are arguments, then we'll start to worry about ordering issues and whatnot
[10:34] <pedronis> maybe is just a matter of missing validation
[10:34] <pedronis> Chipaca I suppose knows more, he looked at the PR
[10:34] <Chipaca> heh
[10:34] <Chipaca> wait, if that _is_ what's wanted maybe the pr is ok
[10:35] <Chipaca> 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] <Chipaca> given the feature is presented as a way to avoid having a wrapper, I thought this was not what was intended
[10:36] <Chipaca> IOW I thought what was wanted was 'chain1; chain2; actualcmd arg arg arg'
[10:36] <pedronis> no, the former
[10:36] <Chipaca> because, you can _already_ have chain1 chain2 chain3 in cmd
[10:36] <pedronis> but no args
[10:36] <pedronis> Chipaca: yes, but then no --shell
[10:36] <pedronis> etc
[10:36] <Chipaca> can you give me an example of what chains are, then?
[10:37] <Chipaca> I did read the forum post but it wasn't illuminating
[10:37] <pedronis> Chipaca: first class (as in demarcated) wrappers
[10:37] <pedronis> ?
[10:38] <pedronis> niemeyer can probably say more
[10:39] <niemeyer> Chipaca: Sure, sorry for the lack of context
[10:39] <niemeyer> Chipaca: The idea is enabling wrappers to be dropped as they exist today
[10:39] <niemeyer> Chipaca: snapcraft today has to inject some logic via its plugins
[10:39] <niemeyer> Chipaca: The result is we get the messy shell script where "command" is just a line at the end of it
[10:40] <Chipaca> niemeyer: so the wrappers would still exist, they'd just be modified to take args like sudo & etc?
[10:40] <niemeyer> 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] <niemeyer> Chipaca: This enables the script to generate its environment, and have the rest of the chain within it
[10:41] <niemeyer> Chipaca: That also means it may be composed, seeing what's before and after it as a blackbox
[10:42] <niemeyer> 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] <niemeyer> Chipaca: Right, they'd exist but be more isolated than they are today
[10:43] <niemeyer> Chipaca: Adding a wrapper just means adding the command to the end of the chain
[10:44] <niemeyer> This also makes templates work more easily
[10:44] <Chipaca> niemeyer: ok
[10:45] <Chipaca> niemeyer: I still fear tab completion might be too brittle to support this
[10:45] <Chipaca> niemeyer: but I'll leave it to implementers to figure out :-)
[10:46] <niemeyer> Chipaca: Not sure why?
[10:46] <niemeyer> Chipaca: I mean, the end result is effectively the same
[10:47] <niemeyer> Chipaca: I mean, today wrapped commands are already called inside a shell script, in a chain
[10:48] <Chipaca> niemeyer: right, but the completer wasn't wrapped
[10:49] <Chipaca> bah, as long as it all ends in an exec of what used to be exec'ed it'll be fine
[10:52] <niemeyer> Chipaca: Right, that's what I imagined
[10:52] <niemeyer> Chipaca: Or at least hoped.. :)
[10:52] <Chipaca> niemeyer: :-)
[11:02] <Son_Goku> niemeyer, mvo, JamieBennett, popey: so I'm back home from Flock
[11:02] <Son_Goku> I can honestly say that the talk was a great success
[11:02] <Son_Goku> people were really interested (some difficult questions about store stuff aside)
[11:03] <Son_Goku> and there's definitely interest in plugging in snap delivery into the Fedora pipeline
[11:07] <mvo> 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] <popey> Son_Goku: excellent, great to hear! Was it filmed?
[11:08] <Son_Goku> yes, but probably poorly
[11:08] <popey> hah
[11:09] <Son_Goku> 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] <Son_Goku> so you can guess it was kind of rickety
[11:09] <Son_Goku> :/
[11:09] <pstolowski> 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] <pstolowski> mvo: can we just sync with upstream again whe your fix lands? there shouldn't be many changes, if any
[11:13] <mvo> pstolowski: yeah, no changes afaict, so that should be fine. I will propsoe the same pr against master now
[11:14] <pstolowski> mvo: ok. either way is fine
[11:16] <mvo> 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] <pstolowski> mvo: great, ty! was it causing failures?
[11:17] <mvo> pstolowski: yes, build failure on powrpc
[11:17] <pstolowski> mvo: hmm, curious why didn't it fail when it landed earlier?
[11:18] <mvo> pstolowski: it probably did and it was lost in the noise
[11:18] <pstolowski> i see
[11:18] <pstolowski> ok, thanks for the fix!
[11:18] <mvo> pstolowski: but maybe not, might be worth investigating
[11:18] <mvo> pstolowski: do you remember when this landed? a while ago, right?
[11:19] <pstolowski> mvo: yes, at least 4-5 weeks ago
[11:21] <mvo> pstolowski: yeah, it looks like its failing since Jul 17 wich matches (roughly) the merge of go-udev stuff
[11:25] <pstolowski> mvo: and it's autopackage tests right?
[11:25] <mvo> pstolowski: yeah
[11:26] <pstolowski> mvo: right.. that's why it went under the radar
[11:26] <mvo> pstolowski: yeah, no biggie
[11:26] <mvo> pstolowski: but those small arches are always extra work
[11:30] <ogra> Son_Goku, a clever person would just have set up a mobile phone in each room to record videos ;)
[11:30] <Son_Goku> you don't know how close you are to how the video was recorded
[11:30] <ogra> :D
[11:33] <Chipaca> ogra: dashcams are really cheap right now
[11:39]  * niemeyer steps out for lunch
[11:42] <ogra> Chipaca, +1
[11:46] <Chipaca> jdstrand: did you get a chance to look at the hostnamectl denials?
[11:55] <mborzecki> 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] <pedronis> mvo:  I reviewed #5611
[12:12] <pedronis> we lost mup?
[12:13] <mborzecki> pedronis: yes, it's been silent for the last 2+ weeks
[12:23] <popey> Did mup go on holiday with niemeyer :)
[12:26] <mvo> pedronis: thank you! looking
[12:27] <mborzecki> pstolowski: pushed an update to https://github.com/snapcore/snapd/pull/5614
[12:28] <pstolowski> mborzecki: thanks, will check in a moment
[12:43] <pstolowski> +1
[12:45] <mborzecki> pstolowski: thanks
[12:47] <niemeyer> He broke down last Tuesday, apparently..
[12:47] <niemeyer> mup: You okay now?
[12:48] <niemeyer> mup: no?
[12:48] <niemeyer> mup: echo foo
[12:55] <niemeyer> mup: How about now?
[13:01] <zyga> oh
[13:01] <zyga> standup!
[13:02] <niemeyer> Hmm.. I can't login
[13:03] <niemeyer> Is it just me?
[13:04] <Chipaca> niemeyer: we're all here
[13:04] <Chipaca> niemeyer: we
[13:10] <pedronis> Chipaca: I reviewed a bit #5617
[13:12] <Chipaca> pedronis: thanks
[13:13] <Chipaca> 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] <niemeyer> mup: ping
[13:26] <pedronis> Chipaca: I checked myself and it seems to be true but not sure it was ever tested
[13:29] <Chipaca> pedronis: i think it has unit tests, but i'm not sure that's what you mean :-)
[13:30] <pedronis> Chipaca: I mean the proxying of registration
[13:30] <pedronis> in the proxy
[13:32] <Chipaca> pedronis: yes, that's what i mean
[13:33] <Chipaca> pedronis: it didn't support custom serial vaults, but did support forwarding to the generic one
[13:33] <Chipaca> pedronis: and i think there are unit tests to that effect
[13:45] <mborzecki> 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] <mborzecki> btw. 15th is a public holiday here (cc zyga pstolowski)
[13:48] <pstolowski> right, forgot about that
[13:49] <pstolowski> cachio: hey, you did some work around journalctl cursor in the spread test right
[13:49] <pstolowski> ?
[13:49] <cachio> yes
[13:49] <cachio> pstolowski, I implemented that in the tests
[13:49] <cachio> why?
[13:50] <pstolowski> 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] <pstolowski> cachio: note the " New test starts here " message
[13:50] <pstolowski> cachio: this is when the test thinks cursor starts
[13:51] <cachio> pstolowski, yes
[13:51] <pstolowski> cachio: so get_journalctl_log doesn't return the early snapd start messages (and i need to match those)
[13:51] <cachio> pstolowski, is there any problem there?
[13:52] <pstolowski> 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] <cachio> pstolowski, yes, it is intended
[13:53] <cachio> pstolowski, if we move the cursor initialization back, then we get a lot of messages from the previous test
[13:53] <cachio> pstolowski, and it was causing other issues
[13:53] <pstolowski> hmm allright
[13:54] <cachio> pstolowski, could you restart snapd as part of the test?
[13:54] <cachio> and check this initialization?
[13:54] <pstolowski> cachio: yes, that's what i was considering
[13:54] <pstolowski> just wanted to make sure it's intended
[13:54] <cachio> we are already doing that in one test
[13:54] <pstolowski> cachio: thanks
[13:54] <cachio> pstolowski, yaw
[13:54] <niemeyer> mup: You ok now?
[13:55] <cachio> pstolowski, check catalog-update teswt
[13:55] <cachio> pstolowski, I think this a similar test
[14:01] <niemeyer> mup: echo ok
[14:01] <mup> niemeyer: ok
[14:01] <niemeyer> Yep.. nickserv registration issues, related to the spam measures recently adopted
[14:01] <niemeyer> popey: ^
[14:01] <popey> \o/
[14:03] <pedronis> mborzecki: yes, will look at parallel installs after I have unblocked other things
[14:03] <mborzecki> pedronis: thanks
[14:11] <popey> niemeyer: what's the plan to prevent snap (your QA systems?) from flooding https://errors.ubuntu.com/ ?
[14:16] <mborzecki> popey: afaik snapd QA is not reporting errors back to errors.ubuntu.com
[14:17] <niemeyer> popey: On a call
[14:17] <niemeyer> popey: Will ping a moment
[14:17] <niemeyer> in a
[14:18] <cachio> zyga, hey
[14:18] <cachio> I ran the fedora base test on core
[14:18] <zyga> yes?
[14:18] <cachio> and it is failing
[14:18] <cachio> https://paste.ubuntu.com/p/cGs978ZWqy/
[14:19] <zyga> yes, it's expected until master hits edge but let me look at the failure
[14:19] <cachio> it is trying to get the snap.yaml from an incorrect path
[14:19] <zyga> yeah, that's exactly that
[14:19] <zyga> which version of snapd was that?
[14:19] <cachio> beta core
[14:19] <cachio> I am suing 2.34
[14:19] <cachio> I am suing 2.35
[14:19] <zyga> I will check if this is in master and in edge
[14:19] <niemeyer> 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] <cachio> zyga, if it has been addresses it is ok
[14:20] <zyga> cachio: fetching now, I'll let you know in a moment
[14:20] <mup> PR snapd#5638 opened: interfaces: basic spread test for udev monitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5638>
[14:20] <zyga> cachio: but the same test I used passed when the branch was merged
[14:20] <zyga> cachio: so I believe it is fixed now, just out of sync in that channel
[14:20] <zyga> cachio: (we added a spread test for it)
[14:20] <cachio> zyga, well, this spread test is failing
[14:21] <cachio> Error executing external:ubuntu-core-16-64:tests/main/fedora-base-smoke
[14:21] <zyga> 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] <zyga> one sec, almost done here
[14:22] <popey> 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] <popey> niemeyer: having the site flooded with snap crashes makes it less useful / usable.
[14:23] <zyga> cachio: reproduced in edge, so I suspect edge is just out of date
[14:23] <zyga> cachio: I will re-check with master
[14:23] <niemeyer> popey: I recall a related conversation back then, and I recall we actually landed changes to reduce how much we logged
[14:24] <niemeyer> 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] <popey> niemeyer: I will start a new thread
[14:26] <niemeyer> popey: Thank you
[14:36] <kyrofa> 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] <cachio> zyga, are yoiu planning to upload the fedora snapd for arm and other architectures?
[14:48] <cachio> zyga, it is failing on arm64
[14:48] <cachio> zyga, or should I push the PR to skip it?
[14:48] <zyga> skip it please
[14:49] <zyga> it's hard to cross-build today
[14:49] <zyga> it will auto build later when it's done inside the fedora infra
[14:49] <cachio> zyga, sure, tx
[14:49] <zyga> thank you
[14:49] <Chipaca> kyrofa: psh, don't come here with your "facts"
[14:51] <kyrofa> 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] <kyrofa> Fine*
[14:53] <kyrofa> I suspect this is simply an "easier to add functionality than remove it" argument, which is of course reasonable
[14:53] <Chipaca> kyrofa: you mean arguments in the chain?
[14:53] <Chipaca> kyrofa: yeah
[14:53] <kyrofa> Indeed
[14:55] <mup> PR snapd#5639 opened: snapcraft: set version information for the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5639>
[14:56] <Chipaca> kyrofa: I hope the review ended up making sense though
[14:57] <kyrofa> Chipaca, indeed. Does the functionality make sense, now?
[14:57] <mvo> kyrofa: silly question, when is the snapcraft version script run? after the build by any chance?
[14:58] <kyrofa> 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] <pedronis> mvo: +1 for #5611 with a nitpick
[14:59] <mup> PR #5611: devicestate: only run device-hook when fully seeded <Created by mvo5> <https://github.com/snapcore/snapd/pull/5611>
[14:59] <mvo> pedronis: thank you, checking
[15:00] <kyrofa> mvo, during the prime step
[15:02] <mvo> kyrofa: cool, thanks
[15:02] <pedronis> Chipaca: added a question to #5617, I think the answer is no, but making sure
[15:02] <mup> PR #5617: overlord/devicestate: DTRT w/a snap proxy to reach a serial vault <Created by chipaca> <https://github.com/snapcore/snapd/pull/5617>
[15:03] <mup> PR snapd#5640 opened: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>
[15:08] <pedronis> mvo: looked at #5631 as well, couple of comment/questions
[15:08] <mup> PR #5631: snapstate: ensure normal snaps wait for the "snapd" snap on refresh <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5631>
[15:18] <mup> PR core18#63 opened: [RFC] snapcraft.yaml: add current date to core18 rev <Created by mvo5> <https://github.com/snapcore/core18/pull/63>
[15:20] <mvo> pedronis: thanks for your comments on 5583 too!
[15:23] <pstolowski> 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] <mup> PR #5618: overlord: instantiate UDevMonitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5618>
[15:23] <mup> PR #5632: overlord: integrate device enumeration with udev monitor <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632>
[16:07] <cachio_> Chipaca, https://paste.ubuntu.com/p/FJVhj5H2H7/ see those permissions
[16:07] <cachio_> I saw you changed install-sideload to check this
[16:08] <cachio_> but in core it is failing
[16:49] <sergiusens> 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] <Chipaca> cachio_: how are those files getting there?
[16:51] <mup> PR snapcraft#2209 closed: tests: add spread suite for tar-content plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2209>
[16:59] <cachio_> Chipaca, which ones??
[16:59] <cachio_> all of them?
[16:59] <cachio_> I think those are downloaded during test executions
[17:22] <ogra> sergiusens, but set-version only works from an override or am i wrong ?
[17:23] <ogra> (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] <sergiusens> ogra: so? snapcraftctl <step> makes what you would otherwise override actually run
[17:32] <kyrofa> cachio_, spread from master can't seem to run with snapd's spread.yaml: preserve-size is an invalid size string?
[17:32] <kyrofa> Know anything about that?
[17:33] <cachio_> kyrofa, you need to update spread
[17:33] <kyrofa> cachio_, I did
[17:33] <cachio_> mmm
[17:33] <cachio_> did you download a spread again?
[17:34] <kyrofa> I ran `go get`
[17:34] <cachio_> curl -s -O https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz && tar xzvf spread-amd64.tar.gz
[17:34] <cachio_> try that
[17:34] <niemeyer> kyrofa: zyga mentioned that yesterday.. I need to update, sorry
[17:35] <kyrofa> Isn't that this? https://github.com/snapcore/spread/pull/66
[17:35] <mup> PR spread#66: Define storage at system level <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/66>
[17:35] <kyrofa> The one in aws contains stuff that hasn't been merged?
[17:44] <niemeyer> kyrofa: Sorry, I thought you were talking about the snap
[17:45] <niemeyer> kyrofa: I have no local changes
[17:45] <cachio_> niemeyer, I pushed this last week https://github.com/snapcore/spread/pull/66
[17:45] <mup> PR spread#66: Define storage at system level <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/66>
[17:45] <cachio_> niemeyer, could you take a look when you have a time?
[17:45] <niemeyer> Yeah, but that's not kyrofa's point I assume
[17:45] <niemeyer> If it's not merged it can't be used by snapd's spread.yaml
[17:46] <niemeyer> and the tarball from S3 can't help either
[17:46] <kyrofa> Chipaca, https://github.com/snapcore/snapd/pull/5569 has been updated
[17:46] <mup> PR #5569: snap,snap-exec: support command-chain for app <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5569>
[17:48] <kyrofa> niemeyer, cachio_ false alarm, I just don't know how to use go apparently :)
[17:49] <kyrofa> niemeyer, yeah, I don't use the snap as I use lxc
[18:07] <Chipaca> kyrofa: dude
[18:07] <Chipaca> kyrofa: that's so much nicer, as a diff
[18:12] <Chipaca> kyrofa: +1'ed with a long-winded comment :-)
[18:19] <kyrofa> Chipaca, oh darn, good catch on the env, yes, we need that
[18:19] <kyrofa> Which means I'm missing a test, too
[18:22] <kyrofa> Wait, no, I'm being silly
[18:22] <kyrofa> I'll respond on the PR
[18:26]  * cachio_ afk
[18:28] <zyga> is Graham on IRC?
[18:34] <sergiusens> zyga: I can ask him
[18:34] <zyga> sergiusens: I'm just curious, I never thought about his IRC handle
[18:34] <pedronis> zyga: he is on holiday this week and the next afaik
[18:35] <zyga> ah, I see
[18:35] <zyga> thanks
[18:35] <sergiusens> zyga: should be seen as degville
[19:08] <jdstrand> Chipaca: which hostnamectl issue are you referring to?
[19:08] <jdstrand> Chipaca: and hi!
[19:23] <zyga> jdstrand: hey :)
[19:23] <jdstrand> hey zyga :)
[19:27] <mup> PR snapcraft#2191 closed: Improve pr template and tools ignored files <Created by touilleMan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2191>
[19:46] <mup> PR snapd#5641 opened: interfaces: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5641>
[19:50] <mup> PR snapd#5642 opened: interfaces: miscellaneous policy updates - 2.35 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5642>
[19:54] <tomreyn> hi. i'm wondering how to tell apart snap packages (and developers) to trust and those not to trust. surely oyu can't decide this for me, but i notice a lot of packages are submitted by a developer named 'Snapcrafters', and wonder whether you can tell me more about this (generic sounding) developer.
[19:55]  * kyrofa points tomreyn to popey
[19:56]  * tomreyn throws spinach towards popey
[19:58] <popey> I am afk
[19:58] <popey> But. Look on GitHub for snapcrafters
[19:58] <popey> It's a repo full of snaps, that are maintained by canonical and the wider community
[20:15] <tomreyn> thanks
[22:04] <mup> PR snapd#5569 closed: snap,snap-exec: support command-chain for app <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/5569>
[22:10] <mup> PR snapd#5643 opened: interfaces/builtin: addtl network-manager resolved DBus fix <Created by tonyespy> <https://github.com/snapcore/snapd/pull/5643>
[22:37] <Chipaca> jdstrand: hi!
[22:39] <mup> PR snapd#5644 opened: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
[22:45] <jdstrand> eexit
[23:37] <mup> PR snapcraft#2211 closed: tests: add spread suite for ament plugin <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2211>