=== jamalta-afk is now known as jamalta [01:04] thumper: woo, new code import mail with actual information in it \o/ [01:12] mwhudson: it looks like bzr-git will switch to a new caching format as of the next version [01:12] jelmer: does that mean we'll need to do something to update the old caches? [01:12] mwhudson: better performant, but I guess it'll also mean there's some changes that have to happen in lp-code to cope with new filenames, etc [01:13] or will regenerating them work? [01:13] yeah, guess so [01:13] should be easy though [01:13] jelmer: is the new format going to be pack based? [01:13] regenerating them should work, if it doesn't that's a bug in bzr-git :-) [01:13] mwhudson: not pack based, but based on bzr indexes (there's no content so no need for packs) [01:14] ah, ok [01:14] will it be a single file still? [01:15] no, it's a directory with multiple files [01:15] though if you wanted to you could trigger a repack so it ends up being just a single file (and a format indicator) in that directory [01:16] mmf, that sounds boring [01:16] probably tarring it up is easier [01:17] jelmer: will it be .bzr/repository/git-cache or something like that? [01:17] mwhudson: yeah, .bzr/repository/git [01:17] mwhudson: of course, Bazaar should really have hooks for fetch that allow us to copy this data along with the branch.. [01:18] jelmer: have you seen how AMAZINGLY SLOW the kernel import is going? https://code.edge.launchpad.net/~kiko/linux/2.6.31 [01:18] mwhudson: yeah [01:18] jelmer: yes, we should. [01:18] lifeless: is this the moment where you suggest I submit a patch ? ;-) [01:19] jelmer: I wouldn't insult your intelligence that way :) [01:19] actually this is not trivial to do well [01:19] and doing it badly will make push and pull suck arse for everyone [01:19] mwhudson: it'll be a bit faster with the new cache [01:19] jelmer: i *think* we have tests that will fail when bzr-git changes here [01:20] mwhudson: also, there's some Google folks working on improving the performance of Dulwich, that'll help a bit [01:20] jelmer: it will also be a bit faster when we get that new machine online... [01:20] jelmer: heh, interesting [01:21] lifeless: what are you thinking might make it problematic ? Figuring out what revisions to fetch? [01:21] do you know why it's so slow for the kernel? [01:21] just because it's a big tree? [01:21] jelmer: not triggering VFS on every pull [01:21] jelmer: and integrating with streaming [01:22] how much to fetch and so on is also interesting [01:22] but I was figuring plugins will need their own protocol for negotiating that shit [01:22] lifeless: yeah - how hard is it to add custom commands to the smart server protocol? [01:23] hopefully using the bzr btree indexes will also make it a bit easier to just fetch those keys that we need - it'd be trickier than tdb [01:24] mwhudson: It seemed to go from 3-5 hours per run to > 12 a couple of days ago. [01:24] wgrant: it depends on the machine [01:24] galapagos in particular is very slow [01:24] wgrant: galapagos seems particularly slow [01:25] i think elmo said one of the machines was one of canonical's very first machines :) [01:25] jelmer: custom commands are easy; making it all hook in well not so much - we don't want plugin-count extra round trips either [01:25] mwhudson: Ah, yeah, but neumayer isn't fast either by the look of things. [01:25] Yeah, galapagos is from the original naming scheme, so it makes sense that it's old... [01:26] oh right, yeah [01:26] lifeless: so even a single extra roundtrip if there's no data would be a problem? I guess in that case we really need something like what's specified in the 'branch baggage' spec to make it perform well [01:26] neumayer and russkaya are both antartic bases [01:26] Yep. [01:26] there's a new machine ready and waiting apparently [01:27] jelmer: something-mumble-mumble [01:27] Penguins, Antarctic bases, elements, fruits... is that it? [01:27] jelmer: imagine 10 plugins doing this [01:27] waiting for our sysadmin to recover from dental surgery :/ [01:27] mwhudson: Yeah :( [01:27] jelmer: if that was a rtt per just to probe, we'd spend 3 more seconds on an empty pull [01:27] for me <-> London [01:27] wgrant: yeah, still on friut afaik [01:28] jelmer: in other news [01:28] jelmer: bzr-hg's tests are appalling [01:29] mwhudson: don't say I didn't warn you :-P [01:29] this is true [01:36] mwhudson, thumper: oh, btw, is it possible to upgrade lp:django ? www.isgitbetterthanx.com uses it to show that bzr is slow, and since it uses 0.92 it's indeed very slow [01:37] jelmer: with a losa to help, yes :/ [01:38] jelmer: ask a question? [01:38] against launchpad-code and assign to losas? [01:38] yeah [01:38] i'll post some more details [01:39] huh [01:39] can't a branch expert upgrade it on the web ui? [01:39] not for an import branch, no [01:39] wgrant, jelmer: Can you look at this proposal if you have time? https://dev.launchpad.net/Registry/InvolvementPortletRefactor [01:40] EdwinGrubbs: Looking. [01:41] sorry, I have to leave now [01:42] EdwinGrubbs: Sure, I'll have a look (might be tomorrow morning CET though) [01:42] grar [01:42] calling mercurial.commands.commit() in a test is asking me to choose an editor [01:43] mwhudson: I think you can specify a custom ui object to prevent that [01:43] mwhudson: we have one that wraps a bzr ui factory [01:44] yeah, seems likely [01:44] oh right [01:48] woo, i think my tests are ok now [01:48] now why doesn't stop_revision to InterBranch.fetch() work... [02:01] and now to attempt to focus on work... [02:04] jelmer: still there? [02:04] mwhudson: yeah [02:04] jelmer: i'm not sure where to do the limit of importing in bzr-hg [02:05] it doesn't seem to produce a nice toposorted list of the hg revisions to import anywhere [02:05] unless a mercurial.changegroup.chunkiter() iterates in toposorted order? [02:06] yeah, that's guaranteed to be toposorted [02:06] although it would be nice to not fetch those revisions in the first place [02:07] jelmer: any movement on the bzr-hg bug that is causing 80% of them to fail? [02:07] jelmer: is that going to be possible? [02:07] given a head, you'll have to walk back to null to find which ones to import first, won't you? [02:09] thumper: is a 'revision feed' a feed of all revisions for a particular project [02:10] poolie: or person [02:10] or team [02:10] or project group [02:10] poolie: but yes [02:11] not quite [02:11] ok [02:11] latest revisions [02:11] there is a feed of new braches [02:11] in the last 30 days [02:12] and per branch a feed of revisions [02:12] I filed a bug asking for project feeds the day they went into beta [02:12] lifeless: and a revision feed for a project for over a year [02:12] lifeless: and I did it [02:12] mwhudson: I think that might be possible by doing the right thing in findmissing() [02:12] thumper: ah! For some reason I thought it hadn't been done. [02:12] thumper: sorry! [02:12] lifeless: it has been so long I've forgotten when I did it [02:12] thumper: not yet, I need to spend some quality time with a particular branch that's failing to figure out what's going wrong [02:13] thumper: and preferably write some tests that demonstrate the problem, that bit is probably the hardest [02:24] jelmer: ok [02:29] * mwhudson is completely confused [02:30] making a method which is called in one place which doesn't look at the return value return something causes tests to fail [02:31] ooh [02:31] * mwhudson slaps himself [02:36] jelmer: findmissing() is fairly opaque to me :/ [02:36] * mwhudson stares at it some more [02:37] mwhudson: what are you doing? [02:38] thumper: incremental imports for bzr-hg [02:38] ah [02:45] * thumper is still doing code review comment emails... [02:46] wgrant: bob seems to think it's building for me [02:48] jtv: I saw your bug reports that implied that, yeah. [02:48] Is it actually working? [02:48] no [02:48] :( [02:48] What does the slave think it's doing? [02:49] that's what I wanted to ask you: is there anything more to look at slave-side than the launchpad-buildd.log? [02:50] jtv: No. That's all there is. [02:50] and I just zapped that for my next attempt :) [02:50] But it should give you lots of information. [02:51] I can go through the setup pretty quickly now though [02:51] There wasn't much in it last time [02:51] Why are you reinstalling each time? [02:53] Am I? [02:54] I mean, I'm reinstalling every time I reinstall, obviously, but... [02:56] Why do you have to go through the setup again? [02:58] * NCommander wonders if anyone can explain why we keep copyright file contents in the database and not in librarian [02:58] NCommander: I asked that myself. [02:58] wgrant: was there an answer? [02:58] NCommander: No. [02:59] wgrant: various reasons. So far I haven't had to re-do the slave setup at all. [02:59] I have had to reboot a few times though. [03:01] wgrant: in many cases I had changes I _could_ just patch through without re-doing anything, but didn't want to because I'm trying to write up something reproducible. It's easy to mess that up without knowing it. [03:01] i don't like the mercurial code very much :/ [03:02] jtv: Ah, right. [03:03] wgrant: for example, between henning's work and mine we had a case where for him "dpkg -i ; apt-get -f install" worked, and for me the other way around worked, because the --force-depends was missing from the dpkg command line. [03:03] We'd like one order that works for everyone, but differences in our setup hid the problem in different ways [03:04] The dpkg, apt-get order should always work. [03:04] If it doesn't, give me examples because I don't believe you :P [03:06] Note the bit where I said --force-depends was missing... [03:06] if you do dpkg -i first, well, launchpad-buildd won't install because the dependencies aren't there [03:07] if you do apt-get -f first, I don't think there's necessarily anything there that'll make it install all dependencies [03:07] for the package you have yet to install [03:08] ...or maybe other stuff was broken in my case, which is the sort of thing you get when you don't re-do from scratch from time to time, which was my original point :-) [03:08] dpkg -i should keep the package installed but unconfigured. [03:08] Then apt-get -f install will satisfy the dependencies and finish installation. [03:09] dpkg -i leaves it unconfigured? [03:09] If the dependencies are not satisfied, yeah. [03:09] Anyway, when you do dpkg -i first, it refuses service because the dependencies aren't there, doesn't it? [03:09] The --force-depends forces it to break things, and then the apt-get -f can fix the deliberate breakage [03:10] It probably looks like it refuses, but it actually lets it go half way. [03:11] ah, like so [03:21] wgrant: meanwhile, it seems as if my job has stopped cold somewhere below the radar :( [03:21] The buildd-manager log says it's dispatching. The slave log says nothing. [03:21] Maybe the previous instance of the slave, which I killed a little late, grabbed it. [03:22] jtv: Is buildd-manager repeatedly dispatching it? [03:22] no, just once [03:22] And can you see buildd-manager currently polling in the slave log? [03:24] The launchpad-buildd log on the slave ended with "daemon ready." [03:24] So I think it went to the wrong buildd instance... I'm retrying. [03:43] wgrant: marking Bob as not-OK is not stopping its ongoing job this time... [03:44] Does changing the OK setting POST to the slave on xmlrpc? [03:44] jtv: Only buildd-manager can talk XML-RPC to the slave. [03:44] Marking it not-OK will stop scanning. [03:44] It will not touch the slave, but it should deassign the job in the UI. [03:45] And when you mark the builder OK again, buildd-manager should declare the builder lost (since it's building an unassigned job), and abort the builder. [03:45] The lost builder detection may not work in this case, however. [03:46] That sounds plausible [03:46] what would break it? [03:46] It being crap. [03:46] * wgrant finds the bug. [03:46] wgrant: ahhhh, _that_ explains _everything_! :-) [03:47] Bug #463041 [03:47] Bug #463041: Lost builder detection is insufficiently aggressive [03:47] Is there a way to make a @stepthrough consume multiple segments? [03:48] I want a @stepthrough method to take multiple arguments, without having to create intermediate objects. [03:48] * thumper stabs his tests [03:50] wgrant: i think you need to write your own navigation (?) to do that [03:51] there's something more general than @stepthrough, anyway [03:51] The closest thing I can think of is that BranchNamespace thingy. [03:52] yeah [03:53] * jtv has to be off for a bit [03:53] lp.registry.browser.person.BranchTraversalMixin [03:54] mwhudson: Ah, thanks. [03:56] gah [03:56] grrr [03:56] testing jobs is a PITA [03:56] It seems sort of evil, but it might work. [03:59] amen to that [04:22] * mwhudson EODs [04:23] * thumper waves at mwhudson [04:28] * thumper sprinkes some removeSecurityProxy around [04:30] heh heh [04:43] thumper: did robert ask you yesterday what happens if you set a bmp to state 'queued'? [04:43] does the world end? does the ui cope? [04:43] poolie: he did [04:43] poolie: I suggested that he shouldn't [04:44] poolie: weird shit may happen [04:44] it might work [04:44] it might not [04:44] poolie: thumper also said that staging would probably be a good enough indication [04:44] it should [04:44] of what weird shit would happen [04:44] it'll either work or not [04:44] staging should be able to tell you [04:46] * persia wonders of !ohmy is supposed to apply in launchpad channels [04:48] It is often violated here, but it seems unproblematic. [04:49] !ohmy? [04:49] !ohmy [04:49] No bot :( [04:54] so [04:55] what doth it mean? [04:55] 15:55:19 Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. [04:55] ah [04:56] persia: NZ has a slightly more relaxed attitude to swearing [04:57] persia: there are several prime time adds that use "bugger" and "bloody idiot" [04:57] sorry if I offended anyone [04:57] thumper: I'm sure. I don't claim that ohmy applies here, just asking. Mostly because of e.g. http://irclogs.ubuntu.com/2010/03/11/#launchpad-dev.txt [04:57] 'twas not my intention [04:58] * persia certainly isn't offended, but is so used to typing !ohmy in other channels, that the message had to be erased before the query [04:58] which bit? [05:00] persia: I don't see the thing that triggered you to say that [05:00] lifeless: i think you meant to say "wtf does that mean?" :) [05:00] the s-word [05:00] * thumper EODs [05:00] later people [05:00] cheerio [05:01] thump em and thump em again [05:01] oh, wow. [05:01] heh [05:04] persia: i think we share that attitude but i don't think tim's expression trips it [05:04] this may just show i need sensitivity training [05:04] In some channels it does. [05:05] as colloquial for 'things' 'my shit', 'weird shit' etc are pretty ingrained. 'your shit' would be an aggressive use and would trip my bad-censor [05:05] I blame the US for popular culture and tv shots. [05:05] s/shots/shows/ [05:05] poolie: Personally speaking, I'm open to lots of expressions. That said, I've seen long-winded arguments about usage of terms, and self-admitted 8-year-old people in some development channels. [05:05] * persia agrees with lifeless === jamalta is now known as jamalta-afk [05:07] ok, EODing [05:09] bye [06:03] where can I get a log of the local keyserver? I'm getting a 500 when I try to create a soyuz user [06:06] * persia has a sense that the query is dropping into the nebulous dark span that lies between NZ and EU timezones [06:08] nm, got it by killed twistd and restating everything [06:58] * wgrant appears. [06:58] NCommander: It all ended up working? [06:59] wgrant: when applied a heavy enough wrench, although the soyuz script didn't add my GPG key to the ppa-user, and I'm getting issues with rejection based on "Can not build for architecture: any" [07:01] NCommander: You specified the right email address? [07:01] The "Cannot build for architecture" thing normally means that your DASes either aren't enabled for virtualisation, or do not have chroots. [07:02] wgrant: yes, and the key posted to the internal keyserver [07:02] wgrant: it might have gotten confused though, I have my keys on a GPG smartcard [07:02] Hmm. [07:02] which makes gpg --list-keys look a bit different [07:02] Ah. [07:02] wgrant: second BTW, for pygpgme, there's a patch in the archive that fixes it [07:03] jtv: Did you have any more luck with the slave? [07:03] NCommander: We don't use the archive version :( [07:03] wgrant: no... [07:03] wgrant: right, but that patch can just be applied to the version in the tree [07:03] jtv: You didn't try, or it didn't work? [07:03] wgrant: I would do it, but I know diddly about pushing to launchpad-pqm or doing a review on an external component [07:04] wgrant: I didn't try, and waiting didn't help either :) [07:05] (helping out with something urgent here) [07:05] Ah. [07:05] wgrant: can you help me get ready to push my first changes to LP? I have a database change that needs to be made, and I'm kinda confused on how I edit the schema [07:05] NCommander: Sure. What's the change? [07:06] wgrant: first pat of implemented raw source changelogs [07:06] wgrant: the part I wrote causes new packages to have the changelog stripped out and put in the database [07:06] on upload [07:06] NCommander: ie. new column SPR.changelog -> LFA.id? [07:07] wgrant: no. just SPR.changelog [07:07] per bigjools and sadbfl's comments [07:07] But changelogs get unsmall. [07:09] THey don't "get" unsmall, they are by default. Still : https://bugs.edge.launchpad.net/soyuz/+bug/139028/comments/1 [07:09] Bug #139028: SPR.changelog should be renamed to 'changelog_entry' [07:11] Hmm. [07:11] Has the DBA been consulted? [07:12] pep8 names are preferred [07:12] if thats your concern [07:13] lifeless: I'm more wondering about the storing large strings in the DB thing. [07:13] wgrant: well, worse case, I rewrite a bit of code, and some comments :-) [07:13] stub: Do you have an opinion on this? [07:26] wgrant: while we wait, maybe you can explain how do I integrate a schema change? I've already gotten the bit htat I need db-devel [07:28] NCommander: Ah, right. I tried to find the wiki page, but then U1 ate my bandwidth. [07:28] I've killed it, so maybe it will work better this time. [07:29] I believe that https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess is the latest. [07:31] wgrant: cool, so now I need to learn how to interact better with bzr [07:32] * NCommander reads on bzr loom [07:33] NCommander: I prefer pipeline these days. [07:33] wgrant: pipeline? [07:33] * NCommander admits he perfers git when dealing with non-trivial archives [07:33] NCommander: https://launchpad.net/bzr-pipeline [07:33] NCommander: Why? [07:35] wgrant: git rebase is my best friend with dealing with local trees before submisison [07:36] NCommander: Ew. [07:36] History destruction is revolting. [07:36] (but bzr can rebase too) [07:36] wgrant: having all of ones changes ontop of the history is very handy [07:36] But we digress [07:37] * NCommander decides not to bother with looms or pipeline with this change [08:21] good morning [08:25] * thumper prefers pipelines too [08:26] Whoops. [08:29] thumper: different use cases [08:29] thumper: hey, how is your bzr using project going [08:29] lifeless: slowly [08:29] lifeless: how to I create a preview tree for a particular revision? [08:29] lifeless: I want to commit to it [08:30] lifeless: and either pull or merge into the main branch [08:31] wgrant, NCommander: (from 1 hour 15 mins ago) It depends :-) changelogs are not that big. If we want to search on them, they certainly can go in the database. If we don't, we are juggling the convenience of stuffing them in the database vs. sticking them in the librarian. I want to keep binary blobs out of the database, so if the text is in an unknown encoding it should definitely get stuffed in the Librarian. [08:32] thumper: a preview tree is the result of a merge done into a revision tree AIUI [08:32] thumper: so I'd look at the pipeline pump code [08:32] lifeless: ok [08:32] lifeless: a revision tree is tree based on a revision? [08:32] you can commit from the transform I believe [08:33] lifeless: can you commit to a revision tree? [08:33] thumper: a revision tree - b.basis_tree(), or b.repository.revision_tree(arbitrary_revid) [08:33] thumper: no [08:33] revision trees are immutable [08:33] 'MutableTree.commit()' commits a new tree to a branch. [08:33] stub: we already have copyright in the database and the encoding is guessed (although I realize that kinda is hit or miss). sabdfl made a comment that we should stuff it in the DB already as well [08:33] thumper: give my phone a ring; just going for a walk and voice will sort this quicker [08:33] stub: plus I want to retroactively add all the past changelogs, which is going to be about 5 GiB when done [08:34] NCommander: What do we do with them once they are stuffed in the database? Are we going to display them inline in the web UI or similar? [08:35] stub: ideally [08:35] If we are guessing encoding, is there a use case for keeping an unadulterated copy in the Librarian (eg. are they GPG signed) [08:35] stub: the file ripped out of the source package, the original can always be retrieved there [08:35] stub: right now, the code just exists to put them in the database. I need to talk to bigjools and persia on how we want to change +changelogs and the SRP page specifically. [08:36] Yup. Also, do we want to store the entire changelog (a potential DOS perhaps), or truncate it to some sane limit. [08:36] We pretty much need the whole thing. [08:37] * NCommander thinks wgrant can explain better than I can [08:37] Since we need to be able to produce an Ubuntu->Debian changelog delta. [08:38] Basic procedure for altering the schema is to create a database/schema/patch-2207-99-0.sql file containing a sequence of CREATE TABLE, ALTER TABLE etc. DDL commands. The first line and last line are dead chickens you can steal from one of the other patches. When requesting a review, request 'db' reviews from me (stub) and bjorn (bjornt). [08:38] So if I upload a sourcepackage to my PPA that when uncompressed contains a 60GB changelog.... ? [08:39] Right, we're screwed. [08:39] lifeless: sorry, called away [08:39] lifeless: I'll talk to you tomorrow about it [08:39] I suspect we do want some limit. Just pick an arbitrary number we won't hit except in case of a) major screwup or b) attack. [08:39] wgrant: meanwhile, on my simulated buildd, I've deleted the job that was in the way but my own is just not getting picked up. :( Still sits there w status 0 [08:39] er [08:39] * NCommander coughs [08:39] jtv: What does the query do? [08:40] wgrant: the candidate selection query? [08:40] jtv: put a break point in the candidate selection and follow it through. [08:40] Last time I tried that, it worked. Maybe it's failing for some new reason. [08:41] Aha. [08:41] NCommander: Of course, the 2GB limit on a text column is the arbitrary limit if you don't set one, so it probably doesn't matter. [08:41] stub: ugh :-/. [08:42] jtv: related to bug 536797 [08:42] Bug #536797: Builder pages break for job without build [08:42] noodles775: no, it's before it gets to that [08:42] jtv: I think it's straight forward to ensure that the builder index works for your jobs, but the harder part is how we present the history. [08:42] stub: thats really nasty :-/ [08:42] jtv: (no, I have a question about it ;)). [08:43] ah :) [08:43] (al-maisan, what's supposed to happen right after this query? SELECT SUM(BuildQueue.estimated_duration) FROM Archive, Build, buildpackagejob, BuildQueue, DistroArchSeries, Processor WHERE buildpackagejob.job = BuildQueue.job AND buildpackagejob.build = Build.id AND Build.distroarchseries = DistroArchSeries.id AND Build.archive = Archive.id AND DistroArchSeries.processorfamily = Processor.family AND Build.buildstate = 0 AND Archive.ena [08:43] ) [08:44] jtv: Currently the builder histor relies on the builds (as they are the only permanent record that something happened on the builder), but I'm guessing we'll need to modify it to instead rely on BuildFarmJob records, and not delete those immediately. Let me know what you think (you too wgrant) and I'll update the bug. [08:44] noodles775: I think I see what you mean. Yes, getting this right is going to be an interesting question; it also came up in the sprint. My immediate worry was getting it not oopsing though. :-) [08:44] jtv: where's that query from? [08:44] noodles775: I think we'll have to present each Job, with adapters for each type. [08:44] al-maisan: the buildd manager [08:44] I agree with wgrant [08:44] noodles775: Hmm, I guess TTBJs don't actually have a builder once the BuildQueue dies, do they? [08:44] (I have it not oopsing for now) [08:45] wgrant: nope, we'd need to defer the deletion of those, perhaps truncating the history to 1000 BuildFarmJobs or something. [08:45] I think we have too many tables. [08:46] +1 [08:46] noodles775: Why truncate them? [08:46] wgrant: at the moment we delete the BFJ, Job, QueueItem etc. once the (soyuz) build completes. [08:46] noodles775: I think just the BuildQueue is deleted. [08:46] The other three (Build, BPJ, Job) should survive. [08:46] I hope. [08:47] * wgrant checks. [08:47] Yes, the Build is permanent of course, but I'd thought the others were deleted, but haven't checked. Doing so now too. [08:48] wgrant: there's some propagation of deletions in the python though [08:48] noodles775: BuildBase appears to kill the buildqueue. [08:48] But not the others. [08:48] thumper: de nada [08:48] Oh. [08:48] But the BuildQueue kills the rest. [08:49] Damn. [08:49] Yep. [08:49] I think we should just keep them all. [08:49] FWIW: we also discussed briefly *not* deleting the BuildQueue records upon job completion and putting in place a purge mechanism that deletes them after some configurable period of time (e.g. a month) [08:49] We are going to have at least three five rows in other tables from each build for eternity anyway. [08:50] So three extra very tiny rows for each really shouldn't make much difference... [08:50] stub: so no issue with changelog in database aside from a sanity check on size? [08:50] Er, s/three // in that first sentence. [08:51] al-maisan: IIRC we argued this during the sprint, and nobody brought up a compelling reason to purge them. [08:51] wgrant: data volume? [08:52] al-maisan: It's trivial compared to the other stuff we store for each build. [08:52] jtv: so you've got a branch that ensures the builder-index doesn't oops for jobs without builds? [08:52] (the build, build log, changes file, upload entries...) [08:52] noodles775: yes [08:53]