| === chihchun is now known as chihchun_afk | ||
| === ErichEickmeyer is now known as Eickmeyer | ||
| === tedg_ is now known as tedg | ||
| === bluesabre_ is now known as bluesabre | ||
| === coreycb_ is now known as coreycb | ||
| === bashfulrobot_ is now known as bashfulrobot | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === ShibaInu is now known as Shibe | ||
| mborzecki | morning | 06:20 |
|---|---|---|
| zyga | Hey :-) | 06:38 |
| zyga | I still owe you that review | 06:38 |
| mborzecki | zyga: hey :) haha | 06:40 |
| mborzecki | zyga: heh love how unpredictable our spread runs are | 06:44 |
| mvo | hey mborzecki and zyga | 06:48 |
| mborzecki | mvo: hey | 06:48 |
| zyga | Hey mvo | 06:50 |
| 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:53 |
| 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:54 |
| pedronis | mvo: TBH, not surprisingly tests were most of the work | 06:55 |
| * mvo nods | 06:55 | |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | morning | 07:13 |
| pedronis | mvo: I answered the comment, could you reply? | 07:19 |
| mborzecki | zyga: interesting find, on centos, when snapd runs runuser, it somehow triggers keyctl() | 07:20 |
| === chihchun_afk is now known as chihchun | ||
| mvo | pedronis: yes, that makes sense | 07:22 |
| mvo | pedronis: its more a warning for the future, that makes sense now | 07:22 |
| 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:23 |
| pedronis | done | 07:28 |
| * 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:29 | |
| 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:33 |
| zyga | I will be in the office in 20 | 07:36 |
| mvo | zyga: quick question - does 6717 also addresses the bug 1819318 ? the htop implicit slots/plugs? | 07:38 |
| zyga | mvo: one moment, let me look | 07:41 |
| pedronis | mvo: yes, I don't think I need to review closely 6741 | 07:41 |
| zyga | mvo: no, it is not related | 07:42 |
| mvo | zyga: ok, trying to understand the remaining blockers | 07:44 |
| 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:45 |
| 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:46 |
| mvo | zyga: yes | 07:49 |
| mvo | zyga: I think we can do that right after 6741 landed | 07:50 |
| mborzecki | zyga: probably interesting for you too: https://github.com/snapcore/snapd/pull/6748 | 07:51 |
| mborzecki | zyga: still, makes me wonder how / got devpts_t label | 07:52 |
| 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:56 |
| zyga | mborzecki: what does -i do? | 07:57 |
| mborzecki | zyga: --interpret | 07:57 |
| mborzecki | zyga: tehre's an example in PR description | 07:58 |
| mborzecki | (and a commit message too) | 07:58 |
| zyga | back now | 08:04 |
| pedronis | mvo: not quite like that | 08:06 |
| pedronis | mvo: where do you need the info again? | 08:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| === chihchun is now known as chihchun_afk | ||
| 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:14 |
| 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:15 |
| 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:16 |
| mvo | pedronis: heh :) | 08:17 |
| pedronis | mvo: I forgot about ifacestate (because it's using directly devicestate) | 08:19 |
| 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:20 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1825298 | 08:21 |
| 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:22 |
| 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:23 |
| * pstolowski doh @ get_journal_log | 08:26 | |
| pedronis | mvo: don't know if noticed but seems we need to increase the timeout on debian-sid-64:tests/main/sbuild | 08:33 |
| pedronis | I have seen it fail timing out quite often | 08:34 |
| pedronis | https://api.travis-ci.org/v3/job/521593407/log.txt | 08:34 |
| pedronis | (maybe is just a symptom, anyway9 | 08:35 |
| === chihchun_afk is now known as chihchun | ||
| 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 | 08:59 |
| pedronis | no | 09:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| Chipaca | yes | 09:08 |
| Chipaca | pedronis: service.rsyslog.disable | 09:08 |
| Chipaca | pedronis: and ssh, same | 09:09 |
| 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:22 |
| Chipaca | degville: the internets. because just simple networks were too reliable. | 09:24 |
| pedronis | Chipaca: pstolowski: let's go with snapshots.automatic.retention | 09:24 |
| Chipaca | \o/ | 09:25 |
| zyga | woot | 09:25 |
| * zyga helped name something :) | 09:25 | |
| pstolowski | pedronis: sounds good | 09:26 |
| pstolowski | and gives room for more options under "automatic" | 09:26 |
| degville | sounds good! | 09:27 |
| zyga | mborzecki: looking at the volumes PR again | 09:32 |
| mborzecki | zyga: great, thanks! | 09:32 |
| === chihchun is now known as chihchun_afk | ||
| 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:41 |
| Chipaca | zyga: noted | 09:42 |
| Chipaca | wait was your comment on the 'snap download --cohort' test done in the create-cohort pr | 09:42 |
| zyga | yes | 09:43 |
| zyga | I didn't notice there are two | 09:43 |
| Chipaca | :-) | 09:43 |
| === sparkieg` is now known as sparkiegeek | ||
| Chipaca | I'm off to do some exercise again, bbiab | 10:15 |
| * Chipaca really goes now | 10:21 | |
| 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:38 |
| pstolowski | that's the little unexpected dragon hiding there after all | 10:43 |
| zyga | mborzecki: sent partial review on gadget validation | 10:46 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/6749 one for you, mainly to check if you agree with the rationale | 10:48 |
| 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:49 |
| zyga | the watch is telling me to get up but I sprained my ankle yesterday | 10:50 |
| zyga | eh | 10:50 |
| === chihchun_afk is now known as chihchun | ||
| === amurray` is now known as amurray | ||
| 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:57 |
| 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:58 |
| mborzecki | zyga: we'd need to have a none like thing | 10:59 |
| zyga | that's *exactly* a pointer :) | 10:59 |
| mborzecki | well, not exactly, but i won't start that without a glass of beer :P | 11:00 |
| zyga | mborzecki: value vs reference but yeah | 11:01 |
| zyga | actually beer sounds good regardlesss ;) | 11:01 |
| pstolowski | zyga: +1 with one remark | 11:16 |
| 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:17 |
| 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:20 |
| * pstolowski lunch | 11:22 | |
| pedronis | zyga: I still dislike the solution in 6117, as did originally | 11:44 |
| zyga | hmm? | 11:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| zyga | pedronis: please add a comment to the PR, I can rework it to use private maps if you strongly prefer that | 11:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 |
| === chihchun is now known as chihchun_afk | ||
| zyga | we could merge as-is and iterate | 11:57 |
| zyga | the bug would be fixed for 2.39 | 11:57 |
| 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 | 11:59 |
| zyga | plugsSlotsUniqueNames | 12:00 |
| zyga | fortunately we do validate early | 12:00 |
| === cachio_ is now known as cachio | ||
| cachio | zyga, hey, I found a problem in the test core16-provided-by-core and I think it is realted to ns | 12:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| cachio | zyga, thanks, I'll continue with this | 12:18 |
| zyga | thank you! | 12:18 |
| pedronis | zyga: I have the rework, to you want me to push it separately or on the PR ? | 12:50 |
| diddledan | ergh. I wish the build.snapcraft.io would tell me why it thinks the yaml is invalid!! | 12:53 |
| diddledan | how can I fix it if it won't tell me what's wrong?! | 12:55 |
| zyga | pedronis: push it directly there please | 13:14 |
| 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:15 |
| === ricab is now known as ricab|lunch | ||
| 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:56 |
| cachio | core16 is not installed but it remains in /snap | 13:57 |
| cachio | zyga, https://paste.ubuntu.com/p/NqdzDvjKVg/ | 13:57 |
| cachio | I am trygin a fix now | 13:59 |
| === tinwood_ is now known as tinwood | ||
| === chihchun_afk is now known as chihchun | ||
| pedronis | zyga: I pushed it | 14:27 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | zyga: pushed updates to cross structure validation PR | 14:32 |
| zyga | pedronis, mborzecki: ack | 14:33 |
| zyga | pedronis: I opened trivial https://github.com/snapcore/snapd/pull/6751 | 14:35 |
| 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:36 |
| === ricab|lunch is now known as ricab | ||
| 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:47 |
| zyga | non the less, time to update | 14:48 |
| * Chipaca wanders off | 15:00 | |
| 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:03 |
| 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:04 |
| 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:05 |
| cachio | zyga, yes | 15:06 |
| 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:19 |
| pedronis | yes, back on April 30 | 15:21 |
| pstolowski | ok | 15:22 |
| zyga | mborzecki: 2nd pass on 6688 | 15:26 |
| cachio | zyga, this is the fix #6753 | 15:54 |
| 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 | 15:55 |
| cachio | zyga, #6744 updated | 16:03 |
| cachio | thanls | 16:04 |
| * cachio lunch | 16:04 | |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | zyga: thank you | 16:17 |
| mvo | a second review for 6720 would be great | 16:26 |
| mvo | cachio: I will release 2.39~pre1 to beta hopefully later tonight, its already building in the ppa | 16:39 |
| mvo | cachio: can we move the 2.38.1 snapd snap to candidate? or is there more validation required? | 17:31 |
| 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 | 17:44 |
| om26er | Hi! Is there someone I could ping here to get that done quickly https://forum.snapcraft.io/t/please-transfer-flatc/10980 | 19:31 |
| om26er | @popey ^^ | 19:32 |
| roadmr | om26er: hi I can help | 19:43 |
| om26er | roadmr thanks for verification https://github.com/google/flatbuffers/pull/5293#issuecomment-484654914 | 19:44 |
| 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:45 |
| om26er | roadmr heh, true. I added a comment on the forum :-) | 19:47 |
| roadmr | done, om26er ✅ | 19:52 |
| 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:53 |
| 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:54 |
| zyga | Chipaca: https://eng.uber.com/optimizing-m3/ <- interesting, also in terms of our state engine and memory usage | 19:55 |
| 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:56 |
| 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:57 |
| 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 | 19:58 |
| om26er | roadmr ok, thanks a lot for the help :-) | 20:00 |
| roadmr | np, happy to help! | 20:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!