[01:01] wallyworld_: \o/ [01:01] It works, except for the anonymous user case, which I'm fix0ring now :) [01:17] can has review? https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71794 [01:18] can has review two? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71795 [01:18] can has review three? https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71796 [01:19] was there any objection to just nuking 2011-08-17 01:12:19 WARNING Found 2 competing templates with translation domain 'javascript': "openerp-javascript in OpenERP Web Client 6.0"; "view-calendar-javascript in OpenERP Web Client 6.0". [01:19] ? [01:21] lifeless: Why has that started spamming us now, anyway? [01:21] lifeless: I wonder if somebody broke asuka's mail capturing. [01:22] probably puppetisation [01:24] rt 47413 [01:24] and set to prior 90 [01:24] Would be nice if we were warned when nasty machines like that were puppetised, so we could watch for breakage. [01:25] Only 90? [01:25] We may be spamming innocents. [01:25] 90 is zomg [01:25] All Zopeless mail is probably untrapped. [01:25] drop-everything [01:25] Ah [01:25] the only higher thing I can sanely do is ring the escalation phone at 2:25am [01:26] This hasn't been picked up on for several days. [01:26] Yeah. [01:26] so I think that would be overkill [01:26] Indeed. [01:27] * lifeless looks around for a revuer [01:32] lifeless: Hm? [01:33] StevenK: oh hai; I have three small reviews up ^ [01:33] StevenK: (they really are small. The Genuine Article.) [01:43] StevenK, wgrant: mind if I update & restart dogfood? [01:44] jtv: Go ahead [01:44] OK [02:09] StevenK: thanks! [02:10] * StevenK tries to get his eyes unglazed after reading 4,000 lines of diffs [02:10] time for a vodka tonic ? [02:10] At midday? [02:11] every 4000 lines :P [02:11] code review drinking game [02:12] Oh, I was going to go with "Every time you mark an MP as approve, take a drink. Every time you mark an MP as Needs Fixing, finish the glass." [02:12] ah, thank you internet: http://movieboozer.com/2011/07/04/source-code-2011-drinking-game/ close enough [02:13] StevenK: that works too [02:23] fun [02:23] http://www.depesz.com/index.php/2011/07/06/bloat-happens/#more-2231 [03:01] btw StevenK, wgrant: I put a script on dogfood that updates the code / dependencies / db permissions, rebuilds the current branch, and restarts the app server. [03:02] Takes a few minutes but it's convenient, and can save us the "damn this time a partial update doesn't quite do it" exceptions. [03:02] *Unfortunately* it breaks at the "make" where the Makefile tries to rm -rf /var/tmp/mailman, which is root-owned on dogfood. [03:03] A few minutes? [03:03] You mean a few hours? [03:04] Although… no, /var/tmp/mailman's been fixed. [03:04] wgrant: no, a few minutes. [03:04] It doesn't update the database (though it does update the schema) [03:05] Of course if you didn't run it for months on end, it'd probably take a lot longer. But having it be easy to run would also solve that. : [03:05] :) [03:05] I just ran the thing, actually. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [03:06] wgrant: have a look — ~launchpad/bin/upgrade-dogfood-launchpad [03:07] I've only SSHed into the DC once this week, and I'm trying to not do it again :) [03:07] OK OK OK [03:07] Just try it sometime. :) [03:08] Haha [03:09] Uh-oh. StevenK's laughing at me. This can't be good. [03:09] wgrant: Are you still on vacation? [03:10] nigelb: if you have to ask, I guess that means he never was. [03:11] jtv: haha. I think he needs to vacation in some small island without internet. [03:11] I thought he lived on one? [03:11] "small" [03:11] It's that blip just off the cost of Asia, isn't it? It has that airport where you refuel on the way to South America. [03:11] jtv: You can talk [03:12] Yes. [03:12] haha [03:12] Yes, I can. [03:12] jtv: I think Australia has more Internet than Thailand [03:12] That can't be right. Thailand has more internet than any other country in the world. [03:12] Measured by the number of sites the government censored, at least. [03:12] jtv: is in Thailand? [03:13] More than China. Come on, who's laughing now? [03:13] I thought it was stub in Thailand. [03:13] Yes, yes, you're right. I'm mistaken. [03:19] nigelb: we are allowed > 1 person in a country :) [03:20] jamesh: hi [03:20] hi lifeless [03:20] jamesh: did you release that python-gpg update? [03:20] lifeless: haha [03:20] no I haven't. I may as well sort that out now. [03:21] jamesh: I can put a nag into cron if thats better for you :P [03:22] jamesh: also how much do you know about wsgi-oops [03:23] lifeless: I've only made a few small changes to it. It started out with the Landscape team trying to extract the LP OOPS system, and then we added some WSGI glue to that [03:24] jamesh: yeah [03:24] what did you want to know? [03:24] jamesh: I'm redoing that but differently... and migrating LP at the same time rather than never :) [03:24] jamesh: well, the traceback extract grabs an awful lot of data [03:24] jamesh: thats not marshallable in a sane way into the current rfc822 format [03:25] jamesh: but I'm wondering whether its been useful to folk; should I file a wishlist bug on python-oops to port that code across ? [03:26] lifeless: back when I was on the LP team, one of the long term goals was to switch to storing OOPS reports as zip files, as a way to make it easy to represent attachments like the traceback and sql statement log. Obviously that has never happened [03:27] lifeless: at this point, if the reports are readable by oops-tools, I don't think many people would care what format they are stored in [03:27] jamesh: right; I'm more talking about the stack-walking variable extraction code than format [03:28] oh. [03:28] jamesh: porting oops-tools to use lp:python-oops-datedir-repo/serializer_rfc822 is fairly straight forward - and once thats done migration to e.g. bson dicts is trivial. [03:30] lifeless: are you talking about wsgi-oops, or the LP oops code here? [03:31] jamesh: wsgi-oops has stack-variable-extraction, LP oops doesn't (it just uses zope.exceptions.format_exception), oops (the new module) doesn't, (It just uses traceback.format_traceback) [03:31] I remember the LP oops code used zope's traceback collection API, but the wsgi-oops one seems fairly simple [03:33] oh. I see what you're talking about. [03:35] I don't think the locals or globals dictionaries from the traceback frames ever make it into the serialised oops report [03:35] jamesh: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/createhooks.py#L91 [03:35] jamesh: right, because the rfc822 format is so limited ;) [03:35] I know the LP code used Zope's traceback formatter, which did include some locals in the output [03:36] jamesh: yeah, so the lp errorlog module now installs its own exc_info grabber [03:36] which is about the same as the code I just linked to, but usin the zope thingy [03:38] lifeless: so, given that we aren't storing this data, perhaps it would be okay to leave it out of the new system you're building. If it is useful, then perhaps we can work out a way of storing it later. [03:39] jamesh: thanks [03:39] jamesh: I had tentatively concluded that [03:39] time to register yet another lp project [03:39] python-oops-wsgi, to avoid confusion :P [03:39] lifeless: it might be worth checking up with the Landscape folks to see if they are using a different serialiser that does actually store the data though. [03:40] (or you might have already done that) [03:40] jamesh: I've chatted with them about this project, not about that specific bit of detail. [03:40] it should be easy enough to port the logic later [03:41] my first goal is a generic, used by LP, and used by a non-LP wsgi app (the gpgverify one by choice), implementation [03:41] with strict dependency boundaries - for folk shipping it, don't want to bring in the universe [03:42] second goal will be updating oops-tools to use the parser module from datedir-repo to replace its homegrown one [03:42] then we can add a new serialiser to datedir-repo and win. [03:56] lifeless: https://launchpad.net/pygpgme/trunk/0.2 [03:57] jamesh: sweet [03:57] now to get it uploaded $everywhere :) [03:57] jamesh: http://pypi.python.org/pypi/pygpgme [03:57] I'm doing that. [03:58] jamesh: heh, sorry! [04:00] http://pypi.python.org/pypi/pygpgme/0.2 [04:04] jamesh: awesome [04:04] I'll chase up lp's dep versions a little layer [04:08] lifeless: hi; how would we go about getting a release of restfulclient and co [04:08] * poolie is hoping for something better than 'do it myself' [04:13] https://dev.launchpad.net/ReleaseChecklist [04:13] poolie: it is do it yourself [04:13] lifeless: what i really meant is, can't the lp core team do it? [04:14] modulo the pypi permissions (we -really- would benefit from a teams module there) [04:14] and I can grant pypi permissions as needed, I think flacoste added me to everything [04:15] this checklist needs trimming and automation, rather desperately, but it is functional [04:18] phut [04:18] i feel like i'm already kind of doing at least half the work by fixing the bug [04:19] oh well [04:19] sure [04:20] I mean, thats what bzr contributors expect - they fix, core team releases on $whatever schedule [04:20] are you asking because a release is long overdue? or its particularly urgent? [04:21] the first [04:22] let me check if this is actually true though [04:25] not all that long [04:26] perhaps the difference is there's no obvious schedule [04:26] how much merged work is sitting unreleased? [04:26] though, that's also somewhat true for bzr plugins [04:26] just two https://launchpad.net/lazr.restfulclient/+milestone/0.11.3 [04:27] it's not urgent, it just would be a shame to have them sit for a long time [04:27] i thought there were more in other lp dependencies [04:29] so one possibility is that the system is working [04:29] another possibility is that with leonard gone, folk are not releasing-on-land, nor will anyone release-on-schedule [04:30] \o/ I think I've figured out what's breaking rocketfuel-get on dogfood. When it looks for "sourcecode" dirs to re-link, in dogfood's setup it also finds lp-sourcedeps. Maybe rocketfuel-get should exclude lp-sourcedeps explicitly. [04:31] that's the uncertainty that was in my mind [04:32] I think some discussion on list is in order [04:32] I'm not sure what (or even whether) we have a policy about doing-releases-of-things-we-garden [and perhaps we don't need one... but perhaps we do] [04:34] jtv: isn't lp-sourcedeps normally a level up ? [04:34] Normally, yes. [04:35] But these scripts evolve over time. [04:35] So it depends on the age of the LP installation. [04:35] And in this case, permissions and responsibilities. [04:35] If my hunch is right, fixing up rocketfuel-get is the least invasive. [04:49] ugh [04:49] failing buildmaster tests [04:50] could not stab /var/tmp/buildd/build-slave.pid [04:50] Oh, screw you, testrepository [04:50] StevenK: ? [04:51] oh, and for bonus I have a test fail in there too [04:51] testr failing --list => no output, testr run --failing => I'll just run every single test, lol [04:51] StevenK: heh [04:51] With no output [04:51] StevenK: bit of a foot-gun event, I guess. [04:51] steven@liquified:~/launchpad/lp-branches/denorm-bspph% testr run --failing [04:51] running=xvfb-run ./bin/test --subunit [05:09] jamesh: do you happen to know how I can reset gnome-gpg to ask for my passphrase again ?! [05:10] and preferrably nuke the silly thing that ever captured it [05:10] lifeless: delete the passphrase from the keyring using the "Passwords and Encryption Keys" app [05:10] I haven't used gnome-gpg in years (gnupg-agent seems to do a good job) [05:11] jamesh: that seems to want to change the actual gpg managed passphrase [05:12] jamesh: which isn't what I intend [05:12] lifeless: you're looking on the passwords tab, right? [05:12] not the "My Personal Keys" or "Other Keys" tabs [05:13] jamesh: it shows 'passwords: default and 'Passwords: login' [05:14] lifeless: right. expand those and find the entry gnome-gpg added. [05:14] there isn't one :) [05:14] well, that's where gnome-gpg would be storing the passphrase [05:14] ah [05:14] I had to click 'unlock' [05:14] to unlock the first folder, before it would show me its contents. [05:14] ui win! [05:15] jamesh: thanks! [05:15] "passwords: default" would be a keyring from before the PAM integrated login keyring [05:15] if it doesn't hold anything interesting you would probably be best off deleting it. [05:15] jamesh: I've been running this homedir uninterrupted since, uhm, 2000 [05:16] jamesh: it appears to have a lot of semi interesting things [05:16] the login keyring is locked and unlocked automatically by pam [05:17] the default one requires manual password entry (assuming it has a password set) [05:19] thanks [05:19] bbiab === almaisan-away is now known as al-maisan [05:31] jtv: O hai. Do you have time for a small review? [05:32] Yes, okay [05:32] jtv: https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-qualified/+merge/71812 [05:32] I find it odd that you should come to me with this request, after all my hard work to scare you off. [05:33] jtv: lifeless owed me, but he's buggered off. And you're supposed to be OCR anyway [05:33] ah yes [05:34] Anyway, I see a familiar pattern: it's as if someone has tried to make the SQL harder to figure out. [05:34] Hah [05:34] By arbitrarily turning some keywords into lower-case, and putting the line breaks in odd places. [05:35] Could you please just put the FROM, in all caps, at the beginning of the line? [05:35] jtv: In bugtask? [05:35] Yes. And maybe make the other SQL keywords consistently upper-case as well? [05:36] I wish it was practical to write a lint check to force that. [05:36] Yes! Oh God, yes! [05:36] And go away. You are not here. [05:36] Few reviewers do. [05:36] Hah. [05:36] Reviewers nowadays are a bunch of pussies. [05:37] "Oh yes, I can't read this, but if you get it past the python parser I'll approve it." [05:37] jtv: Anything else? [05:38] AFAICT it's all cosmetic. Am I missing something? [05:38] wgrant: I'd solve the bloody problem and storm-ify the methods, but they make my eyes bleed. [05:38] jtv: It's lead-up to adding a sourcepackagename column to SPPH [05:39] if you can make a lint check for it, you can make an automated fixer for it. [05:39] Then go forth and land ye your branches, that they may be merged. [05:41] lifeless: you can, but lately I've really come to appreciate the affirmative power of manual formatting: "yes I've thought about this, yes I mean this to be in the source code as it is." [05:42] I even rely on it by not inserting proper spacing into temporary debug statements etc, as an extra safeguard against accidentally leaving them in. [05:44] mmm, I can see an argument for that, but I'm not convinced [05:46] I'm not making an argument, I'm telling you how it is. It helps. [05:46] Let's just version control the AST. [05:47] if python was just a little less fragile [05:47] now where, was I, thats right, housework. Then extracting code to oops-wsgi [05:48] * jtv wonders if that is pronounced "oopski" === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugs: 238 - 0:[#######=]:256 === jtv is now known as jtv-eat [06:49] Project db-devel build #814: FAILURE in 5 hr 47 min: https://lpci.wedontsleep.org/job/db-devel/814/ [07:07] thanks for the surprise review, lifeless :) [07:12] jtv: de nada [07:25] StevenK: Hi! Thanks for the review Steven, I made the corrections you suggested. [07:36] good morning [07:40] morning adeuring [07:41] hi jtv! === al-maisan is now known as almaisan-away [07:52] StevenK: you're not still reviewing, are you? Because I've got this: https://code.launchpad.net/~jtv/launchpad/bug-824553/+merge/71823 [08:05] morning all [08:07] Good morning [08:15] rvba: r=me [08:16] StevenK: Thanks! === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [09:33] lifeless: Was the reason pqm results weigh in at 400k for a single test failure because of the Librarian logs not being cycled between tests, or something else? [09:33] librarian [09:33] there is a bug open I think; all that needs to happen is the fixture glue to be tweaked to only attach new rows from the log, rather than all of it. [09:33] * stub wonders how the Librarian would cope with that many HUPs [09:34] or truncate the log, or something. [09:34] stub: stress test time! [09:34] HUP HUP HUP HUP HUP OH JUST FSCK OFF [09:34] stub: one easy way would be to diff the log in memory - read or stat at the start, and etc [09:35] Maintain an open file, seeking to the end after each test. [09:35] fsync before the seek if you care. [09:36] somehow handle the tests that test Librarian log file rotation :-) [09:39] How good is the bzr cherry picking story now? If I merge a revision from db-stable into devel, will it cause a conflict when stable is merged to db-devel? [09:45] hi all [09:45] any lazr or lplib experts that could look at https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832 ? [09:45] is there a more kosher way to do it? [09:47] stub: it may; but if the texts are identical it should never. [09:47] and -woo- we have a wsgi layer. [09:47] So as long as I don't have to resolve conflicts should be fine. [09:47] and its (at least to me) a lot cleaner than the launchpad-loggerhead on. I may be biased. [09:51] jtv: sorry, I know I still owe you an assessment of your custom upload plans, and I promise to figure out what I think today - but any chance you could review https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection/+merge/71840 for me? there was a regression when IS tried to deploy my previous meta-lp-deps change last night [09:52] cjwatson: funnily enough I was just composing another IRC message for you. :) [09:52] I'm having a look. [09:52] poolie: whats your cli for pqm called again ? [09:52] (and bugs etc, your nih api client :P) [09:53] lifeless: hydrazine? [09:53] yes! [09:53] lifeless: not to be confused with lptools or ubuntu-dev-tools ("ubuntu-dev" being code for "launchpad" there) [09:54] feed-pqm [09:54] in hydrazine [09:54] the nih api client is 'wrested' [09:54] poolie: I needed it to do that review for you :) [09:54] which? [09:55] hydrazine [09:58] cjwatson: taking a while for the MP to update. Did you get a failure email by any chance? [09:58] not yet ... [09:59] * cjwatson pokes offlineimap just in case [09:59] jtv: it seems to be up to date when I look from here [10:00] cjwatson: yup, just got it at last. [10:04] cjwatson: not much I can do with this one, but reviewed. [10:04] Meanwhile, about those custom uploads... :) [10:05] cjwatson: can you land it yourself? I'm not even sure I can, tbh [10:05] Your MP I mean, not mine. [10:06] jtv, heya, I've got a branch up for review: https://code.launchpad.net/~danilo/launchpad/bug-826692/+merge/71836 [10:07] danilos: do you now? Good for you mate! === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilos | Critical bugs: 238 - 0:[#######=]:256 [10:07] jtv: I can't; it should just involve merging it into lp:meta-lp-deps, which is owned by ~launchpad-committers and which apparently you just push stuff to directly rather than via PQM [10:07] jtv, yeah, I am just bragging around, thanks [10:07] judging from the commit history [10:07] cjwatson: yes, that's how it happens with the less well-managed branches. Can't say I'm familiar with this one. [10:07] jtv: I can deal with talking to IS about the actual deployment stuff after that [10:08] danilos: let me just help colin out here, and then I'll get to your branch [10:08] Or maybe the other OCR… oh. [10:08] jtv, sure, thanks [10:08] :) [10:09] Oh wow, I've worked with meta-lp-deps in the distant past. [10:09] jtv, yesterday? [10:09] jtv: going to try to get my head round your mail now [10:10] Your considerable head. [10:10] Shouldn't be too hard. [10:19] Can someone else run bin/test.py -vv test_garbo , and tell me if it hangs for over a minute on test_HWSubmissionEmailLinker and test_ObsoleteBugAttachmentPruner ? [10:21] stub, sure, need it on latest stable/devel/db-stable/db-devel? [10:22] danilos: stable or whatever. I think it is an old problem nobody noticed. [10:24] stub, running now, you got me confused for a moment with bin/test.py instead of bin/test :) [10:24] DWIM [10:25] poolie: btw, can you land my branches on lp:lptools, or should I apply for members? [10:25] Actually, needs to be stable or devel - I think a cherry pick from db-devel -> devel killed it. [10:25] *membership [10:25] danilos: ^^ [10:26] there's already a bug for https://code.launchpad.net/~ubuntu-branches/ timing out right? [10:27] cjwatson: your change has landed. [10:27] jelmer: i'll look [10:27] stub, right, I am trying with stable [10:27] poolie: thanks :) [10:27] you have the power! [10:30] stub, I am having some troubles with tests actually failing [10:31] danilos: database in use errors? [10:33] stub, nope, LaunchpadSilentFailure or something :/ [10:33] let me check my dependencies [10:35] (it's likely my download-cache is out of date) [10:35] jtv: thanks! and replied (though whether you'll like the reply I'm not sure ...) [10:35] danilos: can't the preloading you're doing be done with load_related? [10:35] cjwatson: argh! [10:36] danilos: thinking specifically of do_eager_load (I understand you probably don't want to mess with that other code in detail) [10:36] jtv, not that I know of, since I need to do a bunch of "get me this and then stuff that is related to it" (I did start with a bunch of load_related and load_referencing initially) [10:36] jtv, i.e. I need double "related" indirection [10:36] Can't you pass a result set to load_related? [10:36] So on stable, database/schema/trusted.sql no longer has _killall_backends - this removed in db-devel along with code changes. Looks like trusted.sql has ended up in stable without the code changes, which makes the db teardown rather flakey and slow for tests that used the librarian. [10:37] danilos: ahhh, iswym [10:37] you're starting out with a python-constructed nontrivial set of ids, not of objects. [10:38] oh... nm. it is still in stable. It is in testfuncs.sql, not trusted.sql [10:39] Running stable tests with a db-devel database... and it sometimes works! [10:39] danilos: done [10:39] jtv, thanks [10:42] cjwatson: aren't ddtp-translations tarballs flushed from the librarian after a while? [10:43] I mean, it's GC'ed automatically. [10:43] And AFAIK fairly aggressively. [10:43] (Also note that dsync isn't currently used.) [10:46] jtv: surely not *that* frequently? there's usually a ddtp-tarball upload not very long before release [10:46] cjwatson: are we talking hours, days..? [10:46] stub, ok, finally got it all to a clean state, I don't see the lag: https://pastebin.canonical.com/51339/ [10:47] danilos: ta [10:47] jtv: for natty it was about two weeks (https://lists.ubuntu.com/archives/natty-changes/2011-April/011309.html) [10:48] jtv: but we could copy them if they're available and not worry if they aren't, I'd have thought [10:48] jtv: dsync> that's a shame [10:48] cjwatson: stub will correct me on this if needed but I think Librarian is on a much tighter GC schedule than that. IIRC wgrant said flat-out that it would be impossible to do the copying for ddtp-translations. [10:49] jtv: ddtp-translations is probably not expired. [10:49] jtv: what generates the md5sums index then? [10:49] jtv: Rosetta translations are. [10:49] ahh [10:49] lp_archive@cocoplum:~$ ls -l /srv/launchpad.net/ubuntu-archive/ubuntu/indices/md5sums.gz [10:49] -rw-r--r-- 1 lp_publish lp_publish 29926782 Aug 8 10:23 /srv/launchpad.net/ubuntu-archive/ubuntu/indices/md5sums.gz [10:49] Okay, so we could add ddtp-translations. [10:49] that looks unfortunate [10:49] However [10:49] cjwatson: It was generated by dsync. [10:49] (I'm fairly sure that there exist mirroring tools which look at indices/md5sums.gz) [10:49] If the LibraryFileAlias is linked to another row in the DB, it is not garbage collected. If it is not linked, it will be removed in <72hours IIRC. [10:49] Which we should really running again. [10:49] wgrant: yes, that's my point :) [10:50] We can change that timeout easily enough, although we pay for it in disk space. [10:51] cjwatson: I have no doubt that it could be improved in lots of ways, but unless there's something decidedly wrong or unsafe I'd much prefer to get a partial solution in now and improve on it later, than drag this out further. It's already sat around bit-rotting for longer than is usual nowadays. [10:51] jtv: that's fair enough, but I would like to see those comments addressed at some point [10:51] Absolutely. [10:51] I wasn't intending these to be blockers, but you did ask for a review :-) [10:52] But since this was originally billed as "if you think there's something you can do about it easily, you know, in a day or so..." [10:52] I *think* your date comparison approach is safe, even if IMO not the right thing [10:52] Well it was more a "if you know of any reason why this should not land, speak now or forever hold your peace" kind of thing. [10:52] perhaps you can turn it into bugs [10:53] Sure. [10:53] I was thinking kanban cards, but I can do both. [10:53] or that, I don't know your processes :) [10:53] just avoid being forgotten [10:53] An advantage of splitting these off is that other people can work on them, who knows, maybe even at the same time. :) [10:53] :-) [10:53] thanks [10:53] Glad to help. If you'll let me. :-P [10:56] cjwatson: by the way, any idea where in LP these tarball names are already being parsed? [10:56] jtv: lib/lp/archivepublisher/{debian_installer,dist_upgrader,ddtp_tarball}.py [10:56] hello [10:56] Great, thanks. [10:57] if there's anyone on maintenance good at sql perhaps they could look at bug 827935 [10:57] <_mup_> Bug #827935: consistent timeout on user branch listing page < https://launchpad.net/bugs/827935 > [10:57] which is what processes those uploads in the first place [10:57] # This code is mostly owned by Colin Watson and is partly refactored by [10:57] # Daniel Silverstone who should be the first point of contact for it. [10:57] current comments 'r' us [10:57] :) [10:58] i love how many old names still appear in the lp test data [10:58] daf, daniels, [10:58] stevea [10:58] (custom uploads used to be processed entirely by hand. it was horrendous) [10:59] cjwatson: and you're saying that the first parameter in the tarball name is not needed for disambiguation? It can change in the next upload while still being a complete replacement for the current one with a different prefix to the tarball name? [11:00] I've been assuming that architecture _if present in the tarball name_ does disambiguate, i.e. a ppc dist-upgrader does not replace an i386 dist-upgrader with otherwise the same tarball name. [11:01] And that if there's no architecture, that means "all." [11:02] the upload code disambiguates the tarball type by a field in the .changes file ('raw-debian-installer' etc.) rather than by the tarball prefix. Ideally that would be preserved somewhere in the database too, and I thought it was [11:02] ISTR an enum for it [11:03] Hmmm [11:03] bigjools, do you know about this? ^^ [11:03] all the current parsers just ignore the first component [11:03] lib/lp/soyuz/enums.py:PackageUploadCustomFormat [11:03] existence of that suggests to me that the type is stored in the db somewhere [11:04] though I guess that could just be queue rows [11:04]