[00:00] I don't know what I did but it worked. Ok, lets get this done [00:07] kyrofa, I don't want to do this by hardcoding the string before returning the version number. Besides, it is not testable because the click method will return "run, version xxx \n" and it is not comparable. Any alternative I'm not thinking of? [00:08] return in the tests [04:12] PR snapd#4261 opened: test: ignore /snap/README [06:05] morning everyone [06:26] mvo: https://addons.mozilla.org/en-US/firefox/addon/noscript/versions/ [06:29] hey mborzecki ! yeah, I have it installed already :-D I'm (mostly) a happy puppy again [06:29] hahaha ;) [06:30] PR snapd#4261 closed: test: ignore /snap/README [06:36] uhh travis killed a job because the log is > 4MB [06:36] https://s3.amazonaws.com/archive.travis-ci.org/jobs/305083520/log.txt?X-Amz-Expires=30&X-Amz-Date=20171121T063527Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171121/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=baac296620d373b75ce53d3ec299699b38b4620d3b9af63ba054c9a679db6d27 [07:09] mvo: thank you for the README branch [07:09] mvo: how did you run into that issue? [07:26] zyga-ubuntu: I saw it in travis [07:26] mvo: do you think it was a random failure? I never saw something like that [07:27] mvo: shall I merge 4239? [07:27] zyga-ubuntu: 4239> yeah, please do [07:27] zyga-ubuntu: I think it was order dependent, yes, i.e. in what order things got run [07:29] PR snapd#4239 closed: tests: more debug info for classic-ubuntu-core-transition [07:29] zyga-ubuntu: ta [07:29] can you take a look at https://travis-ci.org/snapcore/snapd/builds/304678796 ? doesn't make much sense to me [07:30] looking [07:30] rm -rf /var/lib/snapd fails with : cannot remove /var/lib/snapd: Directory not empty [07:30] hmm [07:30] right [07:31] no idea, I wish we had debug [07:31] mborzecki: definitely strange, I suspect something is writing to the dir, so the rm(all_files_in_$dir), rmdir($dir) step fails because something sneaked files in but that is just a guess. indicates something was not stopped properly [07:32] and it's rm -rf, that really stops for nothing [07:32] mborzecki: yeah [07:32] i'll restart the build [07:32] pedronis: slightly crazy question - do you think we should have a "overlord/refreshstate", i.e. move all the refresh related bits out of snapstate into their own manager? [07:33] pedronis: I'm slightly unhappy about the mixing we have in snapstate currently and wonder about the best way to untangle [07:33] mborzecki: thanks [07:38] mborzecki: http://paste.ubuntu.com/26010609/ will (sometimes) produce the same error: write(2, ": Directory not empty", 21: Directory not empty) = 21 [07:38] mborzecki: so maybe/probably racy but the interessting question is of course what is left running and writes to that dir :/ [07:41] yeah, something must have been created between opendir() & listing and before rmdir() [07:42] very curious [07:42] mvo: actually [07:43] mvo: the & is sufficient [07:43] mvo: no wonder this fails [07:43] * zyga-ubuntu didn't see it on initial read [07:44] zyga-ubuntu: you mean http://paste.ubuntu.com/26010628/ is the easier to read version? yes, I think you are right [07:44] zyga-ubuntu: also fails more reliable :) [07:44] yes, it's the same deal [07:45] mvo: rm -rf is userspace, so we open and unlink elements recursively [07:45] zyga-ubuntu: *nod* [07:45] zyga-ubuntu: indeed [07:45] mvo: but there is a concurrent writer that adds new entries [07:45] zyga-ubuntu: yes, I really wonder what we kept running [07:46] probably snapd [07:47] zyga-ubuntu: hm, if we don't stop that that would be bad indeed, I have not looked yet but that sounds like something to dig into [07:48] the test that failed was linode:ubuntu-14.04-64:tests/main/refresh:strict_fake and i think it failed in prepare step [07:49] mborzecki: the problem is often the order of execution [07:49] mborzecki: one test that ran 100 steps earlier may have failed to clean up [07:49] * mvo is depressed about this [07:50] mvo: I once patched spread to collect system info after each test [07:50] how does spread 'soread' the tests? is it node per test or a bunch of tests per node? [07:50] mvo: and before first test [07:50] wonder if we should look into doing crazy stuff like runing things inside a systemd-run context that we can fully clean again [07:50] mborzecki: it's N/constant where constant is number of machines of given type [07:50] zyga-ubuntu: aha, yeah, that would be useful [07:50] mvo: I think we cannot afford do that [07:50] mvo: but I also think we cannot afford do not do something [07:50] zyga-ubuntu: heh [07:50] mvo: tests are just failing 90% of the time [07:51] mborzecki: spread uses a work-steal model, not sure if that was the question though [07:51] zyga-ubuntu: yeah, currently tests are really in a bad shape, its very annoying [07:52] mvo: ta [07:54] as for the state of the tests, travis failing the job because the log > 4MB is also quite hilarious :) [07:55] hmm [07:55] mvo: do you remember my qemu snapshot code [07:55] mborzecki: yes [07:55] mborzecki: and the silly and very very slow javascript code that displays it [07:55] mborzecki: the "full log" link should be at the top, not at the endless bottom [07:56] hahah, yeah, all the parallelism work on ff and travis ui is still quite a challenge [07:56] mvo: the LXD approach didn't work (yet), after discussing with jdstrand he suggested a hybrid of an earlier approach with some code in snap-confine (current approach was effectively unconfining s-c) [07:56] zyga-ubuntu: there's raw log button on the right [07:56] mborzecki: oh, I didn't see one [07:58] zyga-ubuntu: hm, interessting (and also slightly sad). but at least there is a way forward [08:12] mvo: if you think that it helps clarity it's worth a try [08:15] pedronis: thank you, I think I give it a shoot and see what it looks like (as an experiment) [08:30] #4158 needs a 2nd review btw [08:30] PR #4158: snapctl: don't error out on start/stop/restart from configure hook during install or refresh [09:09] hrmpf, what a great start in the day, ecrypts bug corrupted my filesystem, now hopefully back to normal [09:10] ow [09:15] PR snapd#4262 opened: store: do not log the http body for catalog updates === __chip__ is now known as Chipaca [09:55] mvo: I'm looking into test failures, I'm patching spread and working with our test suites [09:55] really wish the check package had subtests like `testing.T.Run()` [09:57] mborzecki: yeah, agreed [09:58] mborzecki: gustavo maintains check so ... probably we can patch it [09:58] i suppose [10:00] mborzecki: pardon my ignorance but could you expand on the subtests a bit, a link or something? [10:00] mvo: https://godoc.org/testing#T.Run [10:00] * mvo looks [10:00] let me find a snippet [10:01] mborzecki: aha, interessting. I think I get the idea [10:01] the nice thing is that go test -run will match agains subtest names [10:03] mvo: https://github.com/mendersoftware/deviceauth/blob/master/api/http/api_devauth_test.go#L868 for instance this function will appear as TestApiDevAuthGetLimit/0, TestApiDevAuthGetLimit/1, TestApiDevAuthGetLimit/2.. [10:03] mborzecki: you can run a subset of the tests with check via "go test -check.f names" [10:03] mborzecki: but of course not as powerful as I think what subtests are doing [10:04] mborzecki: aha, nice [10:04] -check.f is not helpful if there's a list of test cases and you loop over them [10:04] mborzecki: yes :/ [10:23] FYI, I patched the check package to display diffs when values fail Equals, DeepEquals checks, the output looks like this: https://paste.ubuntu.com/26011308/ [10:25] ooh, shin [10:25] shiny :) [10:25] I wasted hours diffing manually over the years [10:26] it's obviously nicer if there's a couple of fields: https://paste.ubuntu.com/26011319/ [10:27] i'm using github.com/davecgh/go-spew/spew and github.com/pmezard/go-difflib/difflib [10:31] mborzecki: very nice [10:43] mborzecki: while you're in there, can you make the output of pointers to structs show the structs and not just the pointers? [10:45] oh, yes, that one is bugging me too [10:45] mborzecki: "hahahaha lol no" is a valid answer fwiw [10:47] Issue snapcraft#1443 closed: new ament plugin (ros2) [10:47] PR snapcraft#1583 closed: ament plugin: new plugin [10:48] Chipaca: https://paste.ubuntu.com/26011426/ like this? [10:50] mborzecki: :-D [10:50] mborzecki: that'll do [10:52] pushed the changes to: https://github.com/bboozzoo/check/commits/bboozzoo/pretty-equals-not-equals [10:53] note that it pulls in some extra dependencies, and the check package has none at this moment, I'd guess niemeyer would prefer it this way [10:54] FWIW i think we could override Equals and DeepEquals checkers with our own, just assign them in some init() code in the tests [11:05] * Chipaca <- drowning in a cascade of changes due to golang#22739 [11:12] PR snapd#4263 opened: overlord/devicestate: best effort to go to early full retries for registration on the like of DNS no host [11:20] zyga-ubuntu: remind me, where was it that you called … was it mkdirat? in a loop, you had to open directories in a loop and keep a stack of file descriptors around [11:22] Chipaca: cmd/snap-update-ns/utils.go ? [11:22] Chipaca: yes [11:22] Chipaca: what are you thinking about? [11:23] siiiigh [11:23] zyga-ubuntu: yes [11:23] zyga-ubuntu: so, i have good news, and bad news for yoou [11:23] yes? [11:23] I want bad news [11:23] zyga-ubuntu: everywhere you see "uid int" or "gid int", it's wrong [11:23] Chipaca: pff, ;-) [11:23] Chipaca: we only use 0 [11:23] ;D [11:23] Chipaca: what should I have used? [11:23] func secureMkDir(fd int, segments []string, i int, perm os.FileMode, uid, gid int) (int, error) { [11:24] ^ that signature is wrong in particular [11:24] uint32 [11:24] but,... [11:24] -1 is valid value [11:24] so? [11:24] * zyga-ubuntu is confused [11:24] zyga-ubuntu: it's only valid because C doesn't give a fuck [11:24] it's actually 0xf...f [11:24] Chipaca: world is brutal [11:24] but, in go on 32 bits, it breaks [11:25] zyga-ubuntu: the good news is you probably don't need to change it in a hurry :-) [11:25] i'm doing the cascade of changes in snapd and snap, i'll get to the ones in other places later [11:25] zyga-ubuntu: am i right in thinking snap-update-ns shouldn't use osutil? [11:26] oh you do already [11:26] zyga-ubuntu: excellent :-) [11:26] Chipaca: well [11:27] Chipaca: apply restraint ;) [11:27] zyga-ubuntu: there'll be drop-in replacements with the right signature in osutil/user [11:27] replacements for chown, fchown, and chownat [11:28] Chipaca: thank you! [11:28] *fchownat [11:33] Hi guys, does anyone knows a beginner tutorial on how to develop interfaces (slot - plug) between snaps? [11:33] brunosfer: hey [11:34] brunosfer: it's both easy and complicated, it's easy because it's not very hard but complicated but the way to do it changes over time as code evolves [11:34] brunosfer: the best way to do it would be to post a topic on the fourm and look at how interfaces are implemented (look at the source tree in interfaces/builtin/) [11:34] brunosfer: and try to implement a new one while talking to us [11:37] mvo: I have a working and useful tool to measure damage to the test system [11:37] zyga-ubuntu: Hey Ziga, I saw your tutorial and also you video with Kyle and Sergio, but it was a bit too much advanced since I'm not comfortable with golang. [11:38] I'll follow your advice. Thanks [11:38] brunosfer: then I don't think you are in a position to implement one, I'd suggest asking on the forum, we routinely implement new interfaces on request [11:38] Issue snapcraft#1713 closed: catkin plugin: support for building all packages in a given workspace [11:38] PR snapcraft#1743 closed: catkin plugin: support building entire workspace [11:38] mvo, hey, running beta validation for 29.4 [11:38] zyga-ubuntu: Ok, thanks. [11:38] so far no issues [11:39] mvo: what's the best way to list apt packages? dpkg --get-selections? [11:41] Hellos [11:42] niemeyer: o/ [11:48] mvo: I'm now running main to detect problems in the test suite [11:48] mvo: I also pushed two branches for spread [11:49] mvo: one is trivial fix, the other is this feature [11:49] niemeyer: https://github.com/snapcore/spread/pull/46 [11:49] PR spread#46: Don't crash if suite is empty === gsilvapt_ is now known as gsilva [11:49] (the bugfix) [11:49] I'll propose the measurement after I get some more data about how it feels to use [11:50] the actual diff is here if you want to see https://github.com/snapcore/spread/compare/master...zyga:measure-each?expand=1 [11:51] kyrofa: you around? [12:12] zyga-ubuntu: That's in [12:13] gsilva: he's probably sleeping ;-) maybe I can help you? [12:15] niemeyer: thank you [12:25] niemeyer: i think there's something wrong with proposed day-in-week timer syntax and it's making the parser unnecessarily complicated, eg. mon1-wed3 - is that monday in first week until wednesday in 3rd week? [12:25] niemeyer: then wed3-mon1 is that wed, 3rd week until monday 1st week, wrap around a month? [12:27] mborzecki: We can forbid this syntax for now, so we can decide later how we want to interpret it, if at all [12:28] In other words, N must be >= M on N-M [12:28] Erm, the opposite [12:28] In other words, N must be <= M on N-M [12:46] cachio: thanks, keep me updated on the validate results [12:47] zyga-ubuntu: `apt list --installed` maybe? depends what exactly you need [12:47] zyga-ubuntu: spread> nice! [12:47] mvo: yeah, I have something useful now [12:58] zomg, http://git.savannah.nongnu.org/cgit/man-db.git/commit/src/man.c?id=002a6339b1fe8f83f4808022a17e1aa379756d99 [12:58] :-) [13:02] cachio: Coming? [13:11] PR snapcraft#1747 opened: static tests: enable type checking by use of mypy [13:17] PR snapcraft#1748 opened: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware [13:18] sergiusens: woot, thank you for using mypy! [13:18] sergiusens: I wonder if it found any issues in the code so far [13:18] in recent bionic proposed I see [13:19] ERROR: Syntax Error: Unknown line found in file /etc/apparmor.d/usr.lib.snapd.snap-confine.real line 15: [13:19] include "/var/lib/snapd/apparmor/snap-confine.d" /etc/ld.so.cache r [13:19] cpaelzer: interesting, is there a bug? [13:19] I think the include has to start with a # right? [13:19] cpaelzer: AFAIK no, it's just wonk [13:19] zyga-ubuntu: well I just happened to see it - no bug yet that I filed at least [13:19] wonky [13:20] when I add a # to include I get things to work [13:20] cpaelzer: can you pastebin that file? [13:20] sure [13:20] cpaelzer: maybe something changed, odd [13:20] http://paste.ubuntu.com/26012174/ [13:20] cpaelzer: I'm in a call, I'll check it out in a moment (~20 minutes) [13:20] I actually wanted to set something else with aa-complain, but that reloads all profiles and the issue shows up [13:21] yeah let me know if I can help further, but I think a bionic container with proposed enabled and setting anything via aa-complain should trigger [13:27] zyga-ubuntu: there needs to be a '#' in front of 'include' [13:28] zyga-ubuntu: oh nm, I think the paste is probably wrong [13:28] zyga-ubuntu: there is a missing trailing comma [13:28] '/etc/ld.so.cache r' should be '/etc/ld.so.cache r,' [13:28] meh [13:28] it was the '#' [13:29] irc hard [13:30] yes, this: 'include "/var/lib/snapd/apparmor/snap-confine.d"' needs to be '#include "/var/lib/snapd/apparmor/snap-confine.d"' [13:30] * jdstrand wonders how that made it through review let alone spread testing [13:30] * jdstrand guesses the cache file was used [13:31] jdstrand: does it? I read the spec somewhere and # was optional [13:31] jdstrand: and it passes plenty of tests [13:31] jdstrand: including one where that file (the included one) is not empty [13:31] zyga-ubuntu: maybe it is optional in newer parsers? I didn't know it was optional [13:31] jdstrand: anyway, something is broken, I'm just unsure what [13:31] jdstrand: aha, that's very likely [13:32] now that you mention it, I recall a discussion with upstream where they didn't care for the preprocessor-like syntax. I guess it was fixed [13:33] curious that this is on bionic... [13:33] anyway, add the '#' and it will all work. might be worth an apparmor bug for the inconsistency [13:33] sergiusens: how do i prepare a branch for an hotfix? [13:33] jdstrand: agreed [13:33] elopio: kalikiana ^ [13:33] jdstrand: hey :) [13:33] zyga-ubuntu: hello :) [13:34] jdstrand: I'm not working on features today, I was so fed up with tests not passing I've patched spread and I'm chasing the test suite to find the leaking tests [13:34] jdstrand: hopefully more green in the end [13:34] that sounds wonderful [13:35] jdstrand: in comparison to constant retries, yes [13:35] zyga-ubuntu: and in case you feel that is a thankless job. thank *you* :) [13:35] oh, and btw, unit tests appear to be broken: [13:36] http://pastebin.ubuntu.com/26012262/ [13:36] ... [13:36] ImportError: Start directory is not importable: 'unit' [13:36] that is unrelated from the above hot fix request, it's just that i can't unit test my patch on master due to this failure [13:45] ppisati: what do you mean by "for a hot fix"? other than just creating a PR as usual... [13:47] ppisati: regarding the tests, it should be `./runtests.sh snapcraft/tests/unit` now [13:51] * kalikiana lunch [14:04] niemeyer: I'm taking a walk break, should be back in ~1.5h , likely a bit before [14:05] pedronis: Sounds great [14:05] is it just me or is "fedora-25" quite unhappy right now in our spread tests? I get "Error Failed to synchronize cache for repo 'update'" [14:07] mvo: which is odd since the repo sync should be a NOP for almost EOLed distro [14:08] mvo: this is something we should raise with linode on that other IRC network [14:15] zyga-ubuntu: it is pretty consitently failing in my 4256 pr at least, I'm inclined to set to manual but we probably should look into updating to fedora-26 instead [14:17] ppisati I don't understand the question [14:18] mvo: +1 to set to manual, I will look at it as a part of the reliability focus [14:18] zyga-ubuntu some mypy issues are just because the graph it creates cannot handle code in __init__.py so there are some workarounds; but it didn't really find anything major (which means us the snapcraft team can pat ourselves in the back) [14:19] sergiusens: it's also incremental, I cannot wait to see how it plays in the long term on a large codebase [14:20] sergiusens: and by incremental I mean that as you add annotations the results get more precise [14:21] zyga-ubuntu yes, right now I am running it as the python plugin for vscode runs it but for the package `mypy --ignore-missing-imports --follow-imports=silent -p snapcraft` [14:22] getting rid of missing imports is a bit of a pain to setup as MYPY needs its own PYTHONPATH equivalent, and following imports triggers a bunch of errors on code we do not control :-) [14:39] niemeyer: hey, when you have a moment could you take a look at https://forum.snapcraft.io/t/mir-kiosk-mir-libs-auto-connection/2452/8 [15:02] niemeyer: hey, here is one that needs an architect: https://forum.snapcraft.io/t/manual-review-of-base-snaps/2839/3 [15:07] elopio: fyi, https://dashboard.snapcraft.io/dev/snaps/8294/ (ipfs-cluster) has a ton of passing revisions that aren't released [15:07] jdstrand: Thanks for the pings [15:08] elopio: oh, nm. that snap was revoked [15:08] * jdstrand looks at the other one [15:08] niemeyer: np [15:11] jdstrand: yes, it's now upstream :)) [15:12] Chipaca: hm, I poked a bit at the idea using context but go 1.6 does not have http.Request.Context so this is all a bit cumbersome. or do we know how to workaround this already? [15:12] mvo: we're using x/net/context aren't we? [15:13] elopio: it was confusing because the alias request didn't include the url to the store, the request came from you, but your snap was revoked [15:13] I got there eventually [15:13] (though always including the store url is preferred ;) [15:13] Chipaca: but that cheats and doesn't redefine Request to have Contxt [15:14] me is confused === cachio is now known as cachio_lunch [15:15] Chipaca: ah, no, I'm right, on pre 1.7 it cannot do anything with Request itself [15:16] * pedronis was looking at the wrong source file [15:16] Chipaca: we do, seems just a bit cumbersome compared to go1.7 which has http.Request.{,With}Context() [15:17] Chipaca: it seems for the approach that mborzecki suggested (check for the context log body flags) in the RoundTrip we need access to a context associcated with the http.request [15:18] mvo: how so? aren't we creating the context ourselves by hand? [15:18] and passing it by hand [15:18] iirc there's httpctx package [15:18] Chipaca: it doesn't reach where we need to consult it [15:19] Chipaca: yeah, what pedronis said [15:19] time to bump to 1.7! \o/ [15:19] heh, yeah [15:19] yes [15:19] mborzecki: httpctx is about responses, not requests :-/ [15:21] sergiusens: at same point, while working on another patch, someone mentioned that the patch could be eligible as an 'hot fix', something like 2.35.1 instead of waiting for 2.36 entirely [15:21] mvo: in any case, it's a rather large refactor, even if we had 1.7 [15:22] Chipaca: yeah, was mostly curious what it would look like [15:22] ah [15:22] Chipaca: I stop doing that now [15:22] mvo: then try it with 1.7 :-) [15:22] elopio: are you going to update the beta PR? I was going to check the results but it's behind master now [15:22] or 1.10 even [15:23] Chipaca: I did but when I wanted to spread test it things got a bit unhappy [15:23] Chipaca: anyways, I think I poked at it enough, time to get back to $stuff [15:24] ppisati who said that? [15:24] sergiusens: it was in a comment, during the review of a patch [15:25] kalikiana: no, I'm going to propose an alternative. [15:26] gsilva, I am now [15:26] niemeyer: I'm back btw [15:27] pedronis: Cool.. give me 5 and I'll be with you [15:30] PR snapcraft#1748 closed: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware [15:34] elopio: did I miss a discussion there? I recall you kind of hate that beta exists but the only alternative iirc was PRs with no commits pushed by hand [15:35] kalikiana: https://github.com/snapcore/snapcraft/pull/1749/commits/a9c189064a3368c8712408d9bbaf48fe8915e195 [15:35] PR snapcraft#1749: tests: add a script to run autopkgtests in the ppa [15:36] PR snapcraft#1749 opened: tests: add a script to run autopkgtests in the ppa [15:39] PR snapcraft#1750 opened: kernel plugin: don't assume /lib/firmware is present if !kernel-with-firmware [15:45] niemeyer: I'm in snappy-devel [15:53] kyrofa: I replied in the PR my question but I am around if you want to discuss the issue here [15:55] elopio: aaaaahhhh memory is returning, we did talk about the ppa === cachio_lunch is now known as cachio [16:07] kyrofa: i replied to your comment [16:07] chipaca: ping.... [16:07] jamesbenson: hi [16:07] hey! [16:07] did you want to try to debug the snap issue? [16:07] jamesbenson: sure [16:07] jamesbenson: does it happen every time? [16:08] I'm not the best with network capturing stuff... [16:08] yes [16:08] hence the real time desire [16:08] jamesbenson: you get an error which includes the url, yes? [16:09] the error was what was detailed in the forum. [16:09] it seems I can do everything but snap stuff. [16:10] jamesbenson: and can wget fetch that url? [16:11] or curl, if you don't have wget [16:14] https://paste.ubuntu.com/26013102/ [16:15] pedronis: re refactor of the autorefresh to make it easier to follow, how do you feel about something like https://github.com/snapcore/snapd/pull/4161/commits/36b10fc142a9558a1e0db8b543d7d591e6c9feb4 ?if that looks sensible I can do a followup that uses this pattern for catalogRefresh and autoRefresh, that will also make testing this in isolation a bit easier [16:15] PR #4161: snapstate: add support for refresh.schedule=managed [16:16] niemeyer, tell me when you are ready to work on the images [16:16] cachio: Just trying to spike something quick and will be with you next [16:16] niemeyer, sure [16:18] chipaca: ^^ [16:22] jamesbenson: does it download? [16:22] jamesbenson: i can't tell from that pastebin [16:22] oh [16:22] jamesbenson: quote the url [16:22] jamesbenson: it has &s in it, that are confusing the shell [16:27] mvo: looks reasonable, I think the Ensure call though should go in the main SnapManager ensure, no? [16:27] mvo: also it's always passing true to managed which doesn't seem right [16:28] I mean: &store.RefreshOptions{RefreshManaged: true} doesn't look right [16:30] pedronis: great, thank you. I will work on fixing this and adding proper tests then. should I include it in this PR or do a followup (for easier review)? [16:31] mvo: I don't know [16:31] mvo: my preference would be as prereqs, not as follow ups (though that might get tricky merge wise) [16:32] pedronis: sure, that sounds reasonable, let me do this [16:32] pedronis: I will deal with the fallout, no worries, whatever is easiest for you to review [16:33] mvo: I think doing this without worrying about managed and doing autorefresh and then reworking current branch would be best for me [16:33] pedronis: ok [16:33]