[06:20] <mborzecki> morning
[06:38] <zyga> Hey :-)
[06:38] <zyga> I still owe you that review
[06:40] <mborzecki> zyga: hey :) haha
[06:44] <mborzecki> zyga: heh love how unpredictable our spread runs are
[06:48] <mvo> hey mborzecki and zyga
[06:48] <mborzecki> mvo: hey
[06:50] <zyga> Hey mvo
[06:53] <pedronis> seems no mup
[06:53] <pedronis> hi
[06:53] <pedronis> mvo: hi, https://github.com/snapcore/snapd/pull/6747
[06:53] <mborzecki> mup_: ping
[06:54] <pedronis> mvo: read the description as well, hope it makes sense
[06:54] <mvo> pedronis: yeah, thank you!
[06:54] <mvo> pedronis: I'm reading it now (but just started only in 3rd file or so)
[06:55] <pedronis> mvo: TBH, not surprisingly tests were most of the work
[06:55]  * mvo nods
[07:13] <pstolowski> morning
[07:19] <pedronis> mvo: I answered the comment, could you reply?
[07:20] <mborzecki> zyga: interesting find, on centos, when snapd runs runuser, it somehow triggers keyctl()
[07:22] <mvo> pedronis: yes, that makes sense
[07:22] <mvo> pedronis: its more a warning for the future, that makes sense now
[07:23] <pedronis> mvo: ok, I'll change it, and rewrap a couple of doc comments
[07:23] <pedronis> which I noticed are bit too long one liners atm
[07:28] <pedronis> done
[07:29]  * mvo nods
[07:29] <pedronis> 3 of my PRs need a 2nd review,  one probably is best to wait of the prereq to land
[07:29]  * pedronis is going back to do some reviews too
[07:33] <zyga> mborzecki: keyctl, that's interesting
[07:33] <mborzecki> zyga: mhm, found that they adjusted the core policy around rhel 6.5 release, to account for logrotate calling runuser too
[07:36] <zyga> I will be in the office in 20
[07:38] <mvo> zyga: quick question - does 6717 also addresses the bug 1819318 ? the htop implicit slots/plugs?
[07:41] <zyga> mvo: one moment, let me look
[07:41] <pedronis> mvo: yes, I don't think I need to review closely 6741
[07:42] <zyga> mvo: no, it is not related
[07:44] <mvo> zyga: ok, trying to understand the remaining blockers
[07:45] <mvo> zyga: thanks, I understand now I think
[07:45] <mvo> zyga: so the fix is to install the snapd snap automatically when the first snap gets installed, thats fine
[07:46] <zyga> I would say the condition is:
[07:46] <pedronis> mvo: ah, that bug, yes
[07:46] <zyga> No core snap, no snapd snap, any app snap: install snapd
[07:46] <zyga> Remember that systems in the field are broken
[07:49] <mvo> zyga: yes
[07:50] <mvo> zyga: I think we can do that right after 6741 landed
[07:51] <mborzecki> zyga: probably interesting for you too: https://github.com/snapcore/snapd/pull/6748
[07:52] <mborzecki> zyga: still, makes me wonder how / got devpts_t label
[07:56] <mvo> pedronis: just to double check - for the remodel use-case I just add code to DeviceCtx(.., task, ...) that gets it from the task (and hang it on the right task in devicestate.Remodel() (?)
[07:57] <zyga> mborzecki: what does -i do?
[07:57] <mborzecki> zyga: --interpret
[07:58] <mborzecki> zyga:  tehre's an example in PR description
[07:58] <mborzecki> (and a commit message too)
[08:04] <zyga> back now
[08:06] <pedronis> mvo: not quite like that
[08:06] <pedronis> mvo: where do you need the info again?
[08:07] <mvo> pedronis: I think I have ideas now, I can pastebin in 5-10min what I have. I need the info in the mount-snap handler in snapstate
[08:07] <pedronis> mvo: I still think we should set the model on the change
[08:07] <mvo> pedronis: my idea was to define "ModelForTask" (similar to ModelFromTask) that adds a new remodelDeviceContext
[08:08] <mvo> pedronis: aha, ok
[08:08] <pedronis> mvo: you should not need new helper
[08:08] <pedronis> s
[08:08] <pedronis> I did it wrong if you do
[08:08] <pedronis> you need more code in devicestate
[08:09] <mvo> pedronis: I was thinking I need a new "remodelDeviceContext" struct and then need to add it as data to task/change, yes?
[08:09] <zyga> okay
[08:09]  * zyga checks backlog first
[08:09] <zyga> then reviews
[08:10] <pedronis> mvo: yes, you need a remodelDeviceContext correct
[08:10] <pedronis> mvo: then you need to teach  devicestate.DeviceCtx that if task is passed in
[08:10] <pedronis> and it's change has  new-model data attr,  to make a remodelDeviceContext
[08:11] <mvo> pedronis: cool, so I add remodelDeviceContext and change Remodel() to return a change and in the handlers will get the remodel from the change (via DeviceCtx)
[08:11] <pedronis> mvo: because Install etc also might check model
[08:11] <pedronis> you also want to make remodelDeviceContext by hand inside Remodel
[08:11] <pedronis> and pass to Install Update etc
[08:11] <mvo> pedronis: right
[08:12] <pedronis> as I explained in the PR description its a simple change
[08:12] <pedronis> there's an example of what should happen to install for example
[08:12] <pedronis> we need to do that only for snapstate functions that we plan to use in the remodel
[08:12]  * mvo nods
[08:12] <pedronis> mvo: this change will need some kind of unit test though
[08:14] <pedronis> mvo: when there will be a temporary store as well this changes will also help
[08:14] <pedronis> together with the changes I will do around the use of snapstate.Store
[08:14] <mvo> pedronis: indeed
[08:15] <mvo> pedronis: for my current PR (allow different kernel) I *may* not need to change Install() as we do the checks late in mount-snap if we can install the kenrel or not. I can still change the signtuare or keep it for the initial PR, what do you prefer?
[08:16] <pedronis> mvo: as you prefer, if you don't do the change please add a TODO at least
[08:16] <pedronis> though
[08:16] <mvo> pedronis: thanks, will do - I dive deeper now
[08:16] <pedronis> (I might have forgotten everything after my vacation ;) )
[08:17] <mvo> pedronis: heh :)
[08:19] <pedronis> mvo: I forgot about ifacestate (because it's using directly  devicestate)
[08:20] <pedronis> mvo: it's actually clear that except some form for tests, devicestate.Device/SetDevice/Model/Serial should go away
[08:20] <pedronis> as public methods
[08:21] <zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1825298
[08:22] <pedronis> mvo: daemon etc can use the methods on the DeviceManager itself
[08:22] <pedronis> mvo: to be clear it's not a blocker for your work, just shows there is a bit more to do
[08:22] <mvo> pedronis: ok, I think we need to add this to a card somewhere
[08:23] <pedronis> and that some aspects of the old devicestate api is dangerous now
[08:23] <pedronis> because what is the relevant model is not so a fixed concept
[08:26]  * pstolowski doh @ get_journal_log
[08:33] <pedronis> mvo: don't know if noticed but seems we need to increase the timeout on debian-sid-64:tests/main/sbuild
[08:34] <pedronis> I have seen it fail timing out quite often
[08:34] <pedronis> https://api.travis-ci.org/v3/job/521593407/log.txt
[08:35] <pedronis> (maybe is just a symptom, anyway9
[08:59] <pedronis> Chipaca: degville: some wondering from me that you might consider in my comments to #6669, also Chipaca that one is something for you to review when you have a bit of time
[08:59] <Chipaca> pedronis: I wasjust about to say
[08:59] <Chipaca> pedronis: 'expiration' is a date
[08:59] <Chipaca> not a duration
[08:59] <pedronis> yes, not a fan
[08:59] <Chipaca> and obviously it makes no sense for this to be a date
[09:00] <pedronis> no
[09:01] <Chipaca> automatic-snapshots.keep ?
[09:01] <Chipaca> then it could be a duration or "no"
[09:01] <pedronis> that is too terse
[09:01] <pedronis> for me
[09:02] <pedronis> Chipaca: we are trying to get rid of automatic-snapshots
[09:02] <pedronis> it needs to be snapshots.something
[09:02] <pedronis> also
[09:02] <Chipaca> right
[09:02] <zyga> snapshot.retention
[09:03] <pedronis> auto-saves-retention=2h or no
[09:03] <pedronis> would seem ok (a bit clunky but ok)
[09:03] <pedronis> I don't want to just have retention because it doesn't apply
[09:03] <pedronis> to other snapshots
[09:03] <zyga> mmm
[09:03] <Chipaca> snapshots.auto-saves-retention seems a'ight
[09:04] <zyga> snapshots.automatic.retention?
[09:04] <Chipaca> ooh
[09:04] <Chipaca> schnazzy
[09:04] <pedronis> nesting
[09:04] <pedronis> losting
[09:04] <zyga> losting? :)
[09:04] <Chipaca> snapshots.automatic.on-removal=no
[09:04] <Chipaca> :-)
[09:04] <pedronis> I'm 50/50 whether I want more nesting or not
[09:05] <zyga> flip a coin
[09:05] <zyga> I take tails
[09:05] <pedronis> not today
[09:05]  * Chipaca watches it land on its edge
[09:05] <pedronis> no coin flipping before holidays
[09:05] <Chipaca> shouldn't've used a pound coin
[09:05] <pedronis> hard rule
[09:05] <zyga> "god does not throw a coin" said someone, somewhere
[09:06] <Chipaca> zyga: *play dice
[09:06] <zyga> I know :D
[09:06] <zyga> in absence of dies you use dimes ;)
[09:06] <Chipaca> zyga: clearly einstein was a lousy DM
[09:06] <pedronis> Chipaca: do we have anything already with two levels?
[09:08] <Chipaca> yes
[09:08] <Chipaca> pedronis: service.rsyslog.disable
[09:09] <Chipaca> pedronis: and ssh, same
[09:22] <degville> pedronis: Chipaca: ...ah, I've only just seen this discussion :) for some reason my IRC session was stuck a few pages up. Actually, my nick had disconnected.
[09:24] <Chipaca> degville: the internets. because just simple networks were too reliable.
[09:24] <pedronis> Chipaca: pstolowski: let's go with snapshots.automatic.retention
[09:25] <Chipaca> \o/
[09:25] <zyga> woot
[09:25]  * zyga helped name something :)
[09:26] <pstolowski> pedronis: sounds good
[09:26] <pstolowski> and gives room for more options under "automatic"
[09:27] <degville> sounds good!
[09:32] <zyga> mborzecki: looking at the volumes PR again
[09:32] <mborzecki> zyga: great, thanks!
[09:41] <zyga> Chipaca: if the string value is relevant then simply explain that
[09:41] <zyga> Chipaca: my point was that it is a magic string
[09:41] <zyga> so some context is useufl
[09:41] <zyga> *useful
[09:41] <Chipaca> # magic
[09:42] <Chipaca> zyga: noted
[09:42] <Chipaca> wait was your comment on the 'snap download --cohort' test done in the create-cohort pr
[09:43] <zyga> yes
[09:43] <zyga> I didn't notice there are two
[09:43] <Chipaca> :-)
[10:15] <Chipaca> I'm off to do some exercise again, bbiab
[10:21]  * Chipaca really goes now
[10:38] <pstolowski> fun fact. the semantics of (some) network errors in Go are different between 16.04 & 18.04 - at least in the case i'm interested wrt to auto-refresh issue :/
[10:43] <pstolowski> that's the little unexpected dragon hiding there after all
[10:46] <zyga> mborzecki: sent partial review on gadget validation
[10:48] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6749 one for you, mainly to check if you agree with the rationale
[10:49] <zyga> pstolowski: and if you are in review mood, maybe also https://github.com/snapcore/snapd/pull/6717
[10:49] <pstolowski> zyga: yeah i remember about that one, sorry i didn't get to it yet. it needs full focus
[10:49] <zyga> pstolowski: no apologies needed
[10:50] <zyga> the watch is telling me to get up but I sprained my ankle yesterday
[10:50] <zyga> eh
[10:57] <mborzecki> zyga: hm the offset thing is inability of current structure to distinguish a case when there's explicit offset:0 and when no offset was set at all, i have a patch for that in another branch, maybe i should include it in the PR
[10:57] <zyga> please
[10:57] <mborzecki> zyga: fwiw it's kind of ugly :/ things become pointers and so on
[10:58] <zyga> yes, unavoidably so
[10:58] <mborzecki> wish we could do better but not with Go
[10:58] <zyga> or start to use magic -1 ;)
[10:58] <mborzecki> haha :P
[10:58] <zyga> how would we do better?
[10:59] <mborzecki> zyga: we'd need to have a none like thing
[10:59] <zyga> that's *exactly* a pointer :)
[11:00] <mborzecki> well, not exactly, but i won't start that without a glass of beer :P
[11:01] <zyga> mborzecki: value vs reference but yeah
[11:01] <zyga> actually beer sounds good regardlesss ;)
[11:16] <pstolowski> zyga: +1 with one remark
[11:17] <zyga> pstolowski: thanks
[11:17] <zyga> just to clarify here before I commit to the code: they are optional in the sense that we don't die on absence of a cookie
[11:17] <zyga> unless you think that should change
[11:20] <pstolowski> zyga: no, that is fine; we need to have a clue if that happens, and snapctl should give us one (but that shouldn't happen anymore)
[11:22]  * pstolowski lunch
[11:44] <pedronis> zyga: I still dislike the solution in 6117, as did originally
[11:44] <zyga> hmm?
[11:45] <zyga> probably wrong PR number
[11:45] <pedronis> 6717
[11:45] <zyga> ah
[11:45] <zyga> because of the public data piece (Scoped)?
[11:45] <pedronis> yes
[11:45] <zyga> I can make it private and write a PublicDeepEquals
[11:45] <zyga> it's really only public because of unit tests
[11:46] <pedronis> that doesn't sound better
[11:46] <zyga> hmm
[11:46] <zyga> so is it the data piece of the access to the data piece that is problematic in your eyes?
[11:47] <pedronis> zyga: the data, we use Plug/SlotInfo too much as standalone things
[11:47] <pedronis> also it makes public a semantics detail
[11:47] <pedronis> of which nothing later should care about afaik
[11:47] <zyga> hmm, not sure I follow, the standalone aspect is that they are too standlone or?
[11:48] <pedronis> I still prefer some kind of private maps on Info
[11:48] <zyga> counterpoint: maps take more memory, this is literally a bit of information (well, a word because go)
[11:50] <zyga> pedronis: please add a comment to the PR, I can rework it to use private maps if you strongly prefer that
[11:51] <zyga> though personally I think this is okay, I don't see the risk of storing it this way (I only dislike that it is public)
[11:52] <pedronis> strictly speaking we don't even need to attach the maps to the struct
[11:52] <zyga> interesting
[11:52] <zyga> I think the calling order is a bit unfortunate but with some shuffling I think  you are right
[11:53] <zyga> perhaps I remember wrong but AFAIR implicit hooks are added in a separate pass at a later stage so we'd have to return the maps to that stage to proceed
[11:53] <pedronis> infoFromSnapYamlWithSideInfo
[11:53] <pedronis> is internal
[11:54] <pedronis> so we can change it's signature
[11:54] <zyga> yeah
[11:54] <zyga> I will also explore the idea to load the hooks first
[11:54] <pedronis> to return a map or take one
[11:54] <zyga> that would be easier, as the maps would be totally internal
[11:54] <pedronis> that might be painful I fear
[11:55] <pedronis> anyway all that code is a bit strange (evolved very organically)
[11:55] <zyga> I agree :)
[11:55] <pedronis> and under weird constraints (some we cannot get rid of though)
[11:55] <zyga> I'm happy to rework it, probably tomorrow because today I need to break for a doctor visit
[11:56] <zyga> it would be nice to rework to something that uses canonical yaml
[11:56] <zyga> and a series of passes that transform the input yaml
[11:56] <zyga> and yaml is used freely here, it's just the yaml* types that we have there
[11:56] <zyga> load yaml, (processing passes), single analysis pass that reads "canonical form"
[11:57] <pedronis> we are still trying to fix a bug, not rework the all thing over 3 months
[11:57] <zyga> yes :)
[11:57] <zyga> I'm only making a point on how it could be cleaned up from the organic growth
[11:57] <zyga> we could merge as-is and iterate
[11:57] <zyga> the bug would be fixed for 2.39
[11:59] <pedronis> were to we check that a plug and a slot cannot have the same name?
[11:59] <pedronis> *where
[11:59] <pedronis> *where do we
[11:59] <zyga> pedronis: we have a checker for that
[11:59]  * zyga looks
[11:59] <zyga> ohh
[11:59] <zyga> maybe we only do in repo
[11:59] <zyga> let's check
[11:59] <pedronis> we shouldn't do it only that late
[11:59] <pedronis> fwiw
[11:59] <pedronis> if that's the case
[12:00] <zyga> plugsSlotsUniqueNames
[12:00] <zyga> fortunately we do validate early
[12:03] <cachio> zyga, hey, I found a problem in the test core16-provided-by-core and I think it is realted to ns
[12:04] <zyga> cachio: tell me
[12:04] <cachio> zyga, if you run spread -debug -repeat 2 google:ubuntu-core-16-64:tests/main/core16-provided-by-core
[12:04] <cachio> zyga, it fails the second execution
[12:04] <cachio> bacause it is not falling back to core
[12:04] <pedronis> zyga: it's in validate though, so we do it after everything else
[12:05] <pedronis> anyway that's fine
[12:05] <cachio> I was debugging this and the problem is about how we reset
[12:05] <zyga> cachio: how do we reset?
[12:05] <zyga> cachio: (please tell me all you know)
[12:06] <cachio> zyga, the reset.sh uninstall all the snaps
[12:06] <cachio> but core, kernel. etc
[12:06] <cachio> and then
[12:06] <cachio> discard all mount namespaces and active mount profiles
[12:06] <zyga> active mount profiles?
[12:07] <cachio> zyga, https://paste.ubuntu.com/p/8tW5M7Bcgy/
[12:07] <cachio> is it doing that
[12:07] <zyga> ah, the comment is confusing, I understand
[12:08] <cachio> when I run this it makes the test fail
[12:08] <cachio> in fact the test is failing master with the same error
[12:08] <cachio> depending of the tests which run before
[12:09] <zyga> how does the test fail? do you understand the problem and know what do do about it or are sharing information to get support in fixing it?
[12:09] <cachio> zyga, I don't really understand why it is happening
[12:10] <cachio> I took the look to the code and I think it is failing in snap-confine-invocation.c
[12:10] <zyga> how is it failing?
[12:11] <cachio> I mean there is where it should fall back to core and it is skipping that part
[12:11] <cachio> but not sure
[12:11] <cachio> perhaps you do :)
[12:11] <zyga> no, I don't
[12:12] <zyga> that part is never skipped
[12:12] <zyga> I bet that the problem is indeed in how we reset
[12:12] <pedronis> zyga: I'm loooking at it myself, I don't think reworking it from the current state should be a lot of work (last famous words)
[12:12] <zyga> and that if we look at the before / after state (before 1st run, after reset on 1st run) you will see the difference
[12:12] <zyga> pedronis: +1
[12:13] <zyga> pedronis: do push if you have a patch, my remark was really only about that it is fixing the bug as-is and it's green; it's certainly something we can rework
[12:13] <cachio> zyga, ok, I'll add some debug to the code to see if that helps
[12:13] <zyga> cachio: please do, my recommendation is really to start checking for leftovers
[12:14] <zyga> if the code fails on 2nd run reliably
[12:14] <zyga> it is clearly because the environment is no longer the same
[12:14] <zyga> right?
[12:15] <cachio> zyga, I suppose that
[12:15] <cachio> I already compared that
[12:15] <zyga> what state did you compare and what did you find?
[12:15] <cachio> and I couldnt detect the diff
[12:16] <cachio> everything inside /run/snapd/ns/
[12:16] <zyga> that's not sufficient, the code looks at /snap/*
[12:16] <cachio> ok
[12:16] <zyga> my advice is to compare: /snap/* , /var/lib/snapd/* and /run/snapd/ns
[12:16] <cachio> zyga, I'll compare that too
[12:16] <zyga> I'm sure that whatever you will surely find will fix not only this test
[12:17] <zyga> but many others
[12:17] <cachio> zyga, great
[12:17] <zyga> cachio: you can also compare /proc/self/mountinfo
[12:17] <zyga> to see if we are leaking something
[12:17] <zyga> perhaps also look inside existing mount namespaces, among the set we are not discarding
[12:17] <zyga> good luck
[12:17] <cachio> zyga, nice
[12:18] <cachio> zyga, thanks, I'll continue with this
[12:18] <zyga> thank you!
[12:50] <pedronis> zyga: I have the rework, to you want me to push it separately or on the PR ?
[12:53] <diddledan> ergh. I wish the build.snapcraft.io would tell me why it thinks the yaml is invalid!!
[12:55] <diddledan> how can I fix it if it won't tell me what's wrong?!
[13:14] <zyga> pedronis: push it directly there please
[13:15] <pedronis> zyga: in meetings, but will do, it seems to work nicely, but it was quick hacking so names etc can maybe be tweaked
[13:15] <zyga> sure
[13:15] <zyga> thank you!
[13:56] <cachio> zyga, well I found the problem
[13:56] <cachio> zyga, well, almost
[13:56] <cachio> after reset
[13:56] <cachio> zyga, https://paste.ubuntu.com/p/S25ntst2xQ/
[13:57] <cachio> core16 is not installed but it remains in /snap
[13:57] <cachio> zyga, https://paste.ubuntu.com/p/NqdzDvjKVg/
[13:59] <cachio> I am trygin a fix now
[14:27] <pedronis> zyga: I pushed it
[14:32] <mborzecki> zyga: pushed updates to cross structure validation PR
[14:33] <zyga> pedronis, mborzecki: ack
[14:35] <zyga> pedronis: I opened trivial https://github.com/snapcore/snapd/pull/6751
[14:36] <zyga> it's the whole feature sans the tests
[14:36] <zyga> at +16,-3 it's the smallest feature branch I can recall :)
[14:47] <zyga> off-topic: being in snap world where releases happen often and when they are ready I find the current craze around 19.04 release oddly quaint :)
[14:48] <zyga> non the less, time to update
[15:00]  * Chipaca wanders off
[15:03] <cachio> zyga, found the issue
[15:03] <cachio> https://paste.ubuntu.com/p/CwPtSXqcdV/
[15:03] <zyga> where is that code? in the test?
[15:03] <cachio> we need to trim the variable when there is just 1 base snap to remove
[15:03] <zyga> aah
[15:03] <zyga> heh
[15:03] <cachio> I added logs to reset.sh
[15:03] <zyga> I see
[15:03] <cachio> hehehe
[15:03] <zyga> how was that not broken?
[15:03] <zyga> as in, not breaking the execution before
[15:04] <zyga> is the error ignored?
[15:04] <zyga> cachio: in any case, super nice find, thank you for chasing this! :)
[15:04] <cachio> set -e -x
[15:04] <cachio> I'll fix it
[15:05] <cachio> zyga, and also I'll add a new pr to print the tree for the state and compare it with the initial one
[15:05] <cachio> thanks to that I found the problem
[15:05] <zyga> cachio: please coordinate with Chipaca on that work, he's started this under the invariants theme
[15:06] <cachio> zyga, yes
[15:19] <pedronis> pstolowski: I added some comments to your timings PRs
[15:19] <pstolowski> pedronis: ty
[15:19] <pstolowski> pedronis: btw are you off tomorrow?
[15:19] <pedronis> yes
[15:19] <pstolowski> and then on vacation?
[15:21] <pedronis> yes, back on April 30
[15:22] <pstolowski> ok
[15:26] <zyga> mborzecki: 2nd pass on 6688
[15:54] <cachio> zyga, this is the fix #6753
[15:55] <zyga> mvo: https://github.com/snapcore/snapd/pull/6753 needs a 2nd review
[15:55]  * zyga EODs
[15:55] <zyga> ttyl everyone
[15:55] <cachio> zyga, thanks for the review
[16:03] <cachio> zyga, #6744 updated
[16:04] <cachio> thanls
[16:04]  * cachio lunch
[16:17] <mvo> zyga: thank you
[16:26] <mvo> a second review for 6720 would be great
[16:39] <mvo> cachio: I will release 2.39~pre1 to beta hopefully later tonight, its already building in the ppa
[17:31] <mvo> cachio: can we move the 2.38.1 snapd snap to candidate? or is there more validation required?
[17:44] <cachio> mvo, my validation is done for 2.38.1
[17:44] <cachio> I was waiting for cert
[17:44] <cachio> let me check
[17:44] <mvo> cachio: ta
[19:31] <om26er> Hi! Is there someone I could ping here to get that done quickly https://forum.snapcraft.io/t/please-transfer-flatc/10980
[19:32] <om26er> @popey ^^
[19:43] <roadmr> om26er: hi I can help
[19:44] <om26er> roadmr thanks for verification https://github.com/google/flatbuffers/pull/5293#issuecomment-484654914
[19:45] <roadmr> om26er: a github conversation is super helpful because it lets me verify the recipient's acceptance and identity in addition to verifying your email in github matches your snap store developer email :)
[19:47] <om26er> roadmr heh, true. I added a comment on the forum :-)
[19:52] <roadmr> done, om26er ✅
[19:53] <om26er> roadmr super! thank you. So what would be the next step here, should I delete the autobuild entry I had created in https://build.snapcraft.io/user/om26er ?
[19:54] <roadmr> om26er: hm, not very sure about what happens with build.snapcraft.io but I think it would be sane for you to delete it and let upstream set up auto-builds
[19:55] <zyga> Chipaca: https://eng.uber.com/optimizing-m3/ <- interesting, also in terms of our state engine and memory usage
[19:56] <om26er> roadmr ok, so if he setups the autobuild, will I be a "collaborator" by default or would he need to add me again ?
[19:57] <roadmr>         om26er you're already a collaborator, this is set up at the snap store level and is done automatically when a snap is transferred
[19:57] <roadmr> om26er: as a collab, in principle you could own the auto-build on build.snapcraft.io (you have access to the upstream source, and can publish/release revisions for the snap)
[19:58] <roadmr> om26er: so in principle, what you have *should* work, but because the ownership changed, maybe the authentication credentials will go stale and you might need to reauthenticate or something
[20:00] <om26er> roadmr ok, thanks a lot for the help :-)
[20:01] <roadmr> np, happy to help!