| tomwardill | cjwatson: SnapBuild has a `calculateScore` with a hardcoded number of 2510, is that important? | 10:24 |
|---|---|---|
| cjwatson | tomwardill: Yes (https://help.launchpad.net/Packaging/BuildScores). Just returning a constant 2510 is fine for now (self.archive.relative_build_score doesn't make sense here), though we'll probably want to add a relative_build_score to the OCIRecipe at some point so that we can score individual recipes up or down | 10:36 |
| cjwatson | Build scores are less important than they were when the build farm was hideously underprovisioned, but of course they do still matter sometimes | 10:37 |
| tomwardill | righto, makes sense | 10:42 |
| tomwardill | cjwatson: I'm unclear on the process of inferring `virtualized` for a recipe build (essentially, what is involved and where that lives). | 14:15 |
| tomwardill | I don't know what the rules are that make something virtualized vs not | 14:15 |
| tomwardill | is there somewhere I should be looking to find it? | 14:16 |
| tomwardill | this was in my head, once upon a time | 14:18 |
| cjwatson | tomwardill: require_virtualized is a column on the recipe, defaulting to true and only settable by (some variety of) admins, because setting it to false may allow privilege escalation depending on the current configuration of the build farm. virtualized on an individual recipe build is derived from a logical combination of the configuration of the Processor it's building for and the ... | 14:20 |
| cjwatson | ... appropriate OCIRecipe.require_virtualized | 14:20 |
| cjwatson | tomwardill: Conventionally set in FooBuildSet.new, in this case probably "not distro_arch_series.processor.supports_nonvirtualized or recipe.require_virtualized" | 14:21 |
| tomwardill | right, that makes sense | 14:21 |
| cjwatson | So if the Processor doesn't "support" running non-virtualized (really, is forbidden from doing so) then all its builds are virtualized; otherwise, it depends on the recipe | 14:22 |
| cjwatson | SnapBuildSet.new and LiveFSBuildSet.new take archive.require_virtualized into account too, and actually that's kind of weird, I wonder why | 14:22 |
| cjwatson | The archive is a source rather than a target in both those cases | 14:23 |
| cjwatson | I can't really think of why that's the case and I suspect it's a bug | 14:23 |
| cjwatson | It makes sense in BinaryPackageBuildSet.new because the archive is a target and the build is in some sense "within" it | 14:25 |
| tomwardill | huh, interesting | 14:27 |
| tomwardill | factory.py just caused my VSCode to force close | 14:36 |
| tomwardill | that's a new one | 14:36 |
| pappacena | Well, maybe 5k lines of code is too much for VSCode... such a week software. hehe | 14:57 |
| tomwardill | hah | 14:57 |
| tomwardill | I think it's more that I ran out of ram | 14:57 |
| tomwardill | 34Gb commited caused some problems | 14:58 |
| tomwardill | cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/376132 is ready again, if you've got some time to look over it to check I've not wrecked anythign with the post-review changes :) | 15:19 |
| tomwardill | oh damn, forgot the personmerge | 15:35 |
| * tomwardill does the thing (also, yay todo lists) | 15:35 | |
| cjwatson | https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378908 should sort out the deployment trouble from earlier today | 16:10 |
| cjwatson | tomwardill: thanks, let me know once you're done with personmerge and I'll re-review | 16:11 |
| tomwardill | cjwatson: just pushed | 16:13 |
| tomwardill | ooh, my buildtheworld thing can actually install launchpad. | 17:25 |
| tomwardill | Now for the hard part of config hacking until it works | 17:25 |
| cjwatson | nice | 17:25 |
| cjwatson | tomwardill: Could you run utilities/format-new-and-modified-imports over that whole MP? | 21:39 |
| cjwatson | system-site-packages avoidance symlink hack seems to at least sort of work. Trying to productise it a bit and test it now | 21:54 |
| cjwatson | And removing a collection of small hacks in various places that only existed due to that | 21:55 |
| wgrant | Nice | 21:55 |
| cjwatson | Hm, we never properly landed the cowboy of python-tdb onto code import workers, did we | 21:57 |
| cjwatson | wgrant: Could you review https://code.launchpad.net/~cjwatson/meta-lp-deps/remove-python-subversion/+merge/378802 and https://code.launchpad.net/~cjwatson/meta-lp-deps/python-tdb/+merge/378925 ? I doubt anyone else has enough background to review those usefully at the moment | 22:02 |
| wgrant | cjwatson: lgtm | 22:03 |
| wgrant | What was the cowboy? | 22:03 |
| wgrant | Oh you mean installing it at all | 22:03 |
| cjwatson | Yeah | 22:03 |
| cjwatson | The undocumented dep hit us when we deployed alnitak and izar | 22:04 |
| cjwatson | (I love the Arabic star names scheme. Every so often I'm out with Judith at something astronomy-related and I see a machine name in a star map) | 22:04 |
| cjwatson | Alnitak's in Orion so you see it all the time | 22:05 |
| * cjwatson discovers a variety of ridiculous ancient dependencies (e.g. cscvs → honest-to-goodness original python-sqlite) | 22:18 | |
| cjwatson | One of those "considerably less effort to just back away and leave it there" things | 22:19 |
| cjwatson | Will probably have to port it to SQLite 3 at some point if CVS imports haven't died by then | 22:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!