| nigelb | wallyworld_: \o/ | 01:01 |
|---|---|---|
| nigelb | It works, except for the anonymous user case, which I'm fix0ring now :) | 01:01 |
| lifeless | can has review? https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71794 | 01:17 |
| lifeless | can has review two? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71795 | 01:18 |
| lifeless | can has review three? https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71796 | 01:18 |
| lifeless | 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 |
| lifeless | ? | 01:19 |
| wgrant | lifeless: Why has that started spamming us now, anyway? | 01:21 |
| wgrant | lifeless: I wonder if somebody broke asuka's mail capturing. | 01:21 |
| lifeless | probably puppetisation | 01:22 |
| lifeless | rt 47413 | 01:24 |
| lifeless | and set to prior 90 | 01:24 |
| wgrant | Would be nice if we were warned when nasty machines like that were puppetised, so we could watch for breakage. | 01:24 |
| wgrant | Only 90? | 01:25 |
| wgrant | We may be spamming innocents. | 01:25 |
| lifeless | 90 is zomg | 01:25 |
| wgrant | All Zopeless mail is probably untrapped. | 01:25 |
| lifeless | drop-everything | 01:25 |
| wgrant | Ah | 01:25 |
| lifeless | the only higher thing I can sanely do is ring the escalation phone at 2:25am | 01:25 |
| lifeless | This hasn't been picked up on for several days. | 01:26 |
| wgrant | Yeah. | 01:26 |
| lifeless | so I think that would be overkill | 01:26 |
| wgrant | Indeed. | 01:26 |
| * lifeless looks around for a revuer | 01:27 | |
| StevenK | lifeless: Hm? | 01:32 |
| lifeless | StevenK: oh hai; I have three small reviews up ^ | 01:33 |
| lifeless | StevenK: (they really are small. The Genuine Article.) | 01:33 |
| jtv | StevenK, wgrant: mind if I update & restart dogfood? | 01:43 |
| StevenK | jtv: Go ahead | 01:44 |
| jtv | OK | 01:44 |
| lifeless | StevenK: thanks! | 02:09 |
| * StevenK tries to get his eyes unglazed after reading 4,000 lines of diffs | 02:10 | |
| lifeless | time for a vodka tonic ? | 02:10 |
| StevenK | At midday? | 02:10 |
| lifeless | every 4000 lines :P | 02:11 |
| lifeless | code review drinking game | 02:11 |
| StevenK | 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 |
| lifeless | ah, thank you internet: http://movieboozer.com/2011/07/04/source-code-2011-drinking-game/ close enough | 02:12 |
| lifeless | StevenK: that works too | 02:13 |
| lifeless | fun | 02:23 |
| lifeless | http://www.depesz.com/index.php/2011/07/06/bloat-happens/#more-2231 | 02:23 |
| jtv | 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:01 |
| jtv | 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 |
| jtv | *Unfortunately* it breaks at the "make" where the Makefile tries to rm -rf /var/tmp/mailman, which is root-owned on dogfood. | 03:02 |
| wgrant | A few minutes? | 03:03 |
| wgrant | You mean a few hours? | 03:03 |
| jtv | Although… no, /var/tmp/mailman's been fixed. | 03:04 |
| jtv | wgrant: no, a few minutes. | 03:04 |
| jtv | It doesn't update the database (though it does update the schema) | 03:04 |
| jtv | 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 |
| jtv | :) | 03:05 |
| jtv | I just ran the thing, actually. | 03:05 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| jtv | wgrant: have a look — ~launchpad/bin/upgrade-dogfood-launchpad | 03:06 |
| wgrant | I've only SSHed into the DC once this week, and I'm trying to not do it again :) | 03:07 |
| jtv | OK OK OK | 03:07 |
| jtv | Just try it sometime. :) | 03:07 |
| StevenK | Haha | 03:08 |
| jtv | Uh-oh. StevenK's laughing at me. This can't be good. | 03:09 |
| nigelb | wgrant: Are you still on vacation? | 03:09 |
| jtv | nigelb: if you have to ask, I guess that means he never was. | 03:10 |
| nigelb | jtv: haha. I think he needs to vacation in some small island without internet. | 03:11 |
| jtv | I thought he lived on one? | 03:11 |
| nigelb | "small" | 03:11 |
| jtv | 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 |
| StevenK | jtv: You can talk | 03:11 |
| jtv | Yes. | 03:12 |
| nigelb | haha | 03:12 |
| jtv | Yes, I can. | 03:12 |
| StevenK | jtv: I think Australia has more Internet than Thailand | 03:12 |
| jtv | That can't be right. Thailand has more internet than any other country in the world. | 03:12 |
| jtv | Measured by the number of sites the government censored, at least. | 03:12 |
| nigelb | jtv: is in Thailand? | 03:12 |
| jtv | More than China. Come on, who's laughing now? | 03:13 |
| nigelb | I thought it was stub in Thailand. | 03:13 |
| jtv | Yes, yes, you're right. I'm mistaken. | 03:13 |
| lifeless | nigelb: we are allowed > 1 person in a country :) | 03:19 |
| lifeless | jamesh: hi | 03:20 |
| jamesh | hi lifeless | 03:20 |
| lifeless | jamesh: did you release that python-gpg update? | 03:20 |
| nigelb | lifeless: haha | 03:20 |
| jamesh | no I haven't. I may as well sort that out now. | 03:20 |
| lifeless | jamesh: I can put a nag into cron if thats better for you :P | 03:21 |
| lifeless | jamesh: also how much do you know about wsgi-oops | 03:22 |
| jamesh | 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:23 |
| lifeless | jamesh: yeah | 03:24 |
| jamesh | what did you want to know? | 03:24 |
| lifeless | jamesh: I'm redoing that but differently... and migrating LP at the same time rather than never :) | 03:24 |
| lifeless | jamesh: well, the traceback extract grabs an awful lot of data | 03:24 |
| lifeless | jamesh: thats not marshallable in a sane way into the current rfc822 format | 03:24 |
| lifeless | 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:25 |
| jamesh | 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:26 |
| jamesh | 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 |
| lifeless | jamesh: right; I'm more talking about the stack-walking variable extraction code than format | 03:27 |
| jamesh | oh. | 03:28 |
| lifeless | 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:28 |
| jamesh | lifeless: are you talking about wsgi-oops, or the LP oops code here? | 03:30 |
| lifeless | 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 |
| jamesh | I remember the LP oops code used zope's traceback collection API, but the wsgi-oops one seems fairly simple | 03:31 |
| jamesh | oh. I see what you're talking about. | 03:33 |
| jamesh | I don't think the locals or globals dictionaries from the traceback frames ever make it into the serialised oops report | 03:35 |
| lifeless | jamesh: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/createhooks.py#L91 | 03:35 |
| lifeless | jamesh: right, because the rfc822 format is so limited ;) | 03:35 |
| jamesh | I know the LP code used Zope's traceback formatter, which did include some locals in the output | 03:35 |
| lifeless | jamesh: yeah, so the lp errorlog module now installs its own exc_info grabber | 03:36 |
| lifeless | which is about the same as the code I just linked to, but usin the zope thingy | 03:36 |
| jamesh | 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:38 |
| lifeless | jamesh: thanks | 03:39 |
| lifeless | jamesh: I had tentatively concluded that | 03:39 |
| lifeless | time to register yet another lp project | 03:39 |
| lifeless | python-oops-wsgi, to avoid confusion :P | 03:39 |
| jamesh | 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:39 |
| jamesh | (or you might have already done that) | 03:40 |
| lifeless | jamesh: I've chatted with them about this project, not about that specific bit of detail. | 03:40 |
| lifeless | it should be easy enough to port the logic later | 03:40 |
| lifeless | 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 |
| lifeless | with strict dependency boundaries - for folk shipping it, don't want to bring in the universe | 03:41 |
| lifeless | second goal will be updating oops-tools to use the parser module from datedir-repo to replace its homegrown one | 03:42 |
| lifeless | then we can add a new serialiser to datedir-repo and win. | 03:42 |
| jamesh | lifeless: https://launchpad.net/pygpgme/trunk/0.2 | 03:56 |
| lifeless | jamesh: sweet | 03:57 |
| lifeless | now to get it uploaded $everywhere :) | 03:57 |
| lifeless | jamesh: http://pypi.python.org/pypi/pygpgme | 03:57 |
| jamesh | I'm doing that. | 03:57 |
| lifeless | jamesh: heh, sorry! | 03:58 |
| jamesh | http://pypi.python.org/pypi/pygpgme/0.2 | 04:00 |
| lifeless | jamesh: awesome | 04:04 |
| lifeless | I'll chase up lp's dep versions a little layer | 04:04 |
| poolie | 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:08 | |
| lifeless | https://dev.launchpad.net/ReleaseChecklist | 04:13 |
| lifeless | poolie: it is do it yourself | 04:13 |
| poolie | lifeless: what i really meant is, can't the lp core team do it? | 04:13 |
| lifeless | modulo the pypi permissions (we -really- would benefit from a teams module there) | 04:14 |
| lifeless | and I can grant pypi permissions as needed, I think flacoste added me to everything | 04:14 |
| lifeless | this checklist needs trimming and automation, rather desperately, but it is functional | 04:15 |
| poolie | phut | 04:18 |
| poolie | i feel like i'm already kind of doing at least half the work by fixing the bug | 04:18 |
| poolie | oh well | 04:19 |
| lifeless | sure | 04:19 |
| lifeless | I mean, thats what bzr contributors expect - they fix, core team releases on $whatever schedule | 04:20 |
| lifeless | are you asking because a release is long overdue? or its particularly urgent? | 04:20 |
| poolie | the first | 04:21 |
| poolie | let me check if this is actually true though | 04:22 |
| poolie | not all that long | 04:25 |
| poolie | perhaps the difference is there's no obvious schedule | 04:26 |
| lifeless | how much merged work is sitting unreleased? | 04:26 |
| poolie | though, that's also somewhat true for bzr plugins | 04:26 |
| poolie | just two https://launchpad.net/lazr.restfulclient/+milestone/0.11.3 | 04:26 |
| poolie | it's not urgent, it just would be a shame to have them sit for a long time | 04:27 |
| poolie | i thought there were more in other lp dependencies | 04:27 |
| lifeless | so one possibility is that the system is working | 04:29 |
| lifeless | another possibility is that with leonard gone, folk are not releasing-on-land, nor will anyone release-on-schedule | 04:29 |
| jtv | \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:30 |
| poolie | that's the uncertainty that was in my mind | 04:31 |
| lifeless | I think some discussion on list is in order | 04:32 |
| lifeless | 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:32 |
| lifeless | jtv: isn't lp-sourcedeps normally a level up ? | 04:34 |
| jtv | Normally, yes. | 04:34 |
| jtv | But these scripts evolve over time. | 04:35 |
| jtv | So it depends on the age of the LP installation. | 04:35 |
| jtv | And in this case, permissions and responsibilities. | 04:35 |
| jtv | If my hunch is right, fixing up rocketfuel-get is the least invasive. | 04:35 |
| lifeless | ugh | 04:49 |
| lifeless | failing buildmaster tests | 04:49 |
| lifeless | could not stab /var/tmp/buildd/build-slave.pid | 04:50 |
| StevenK | Oh, screw you, testrepository | 04:50 |
| lifeless | StevenK: ? | 04:50 |
| lifeless | oh, and for bonus I have a test fail in there too | 04:51 |
| StevenK | testr failing --list => no output, testr run --failing => I'll just run every single test, lol | 04:51 |
| lifeless | StevenK: heh | 04:51 |
| StevenK | With no output | 04:51 |
| lifeless | StevenK: bit of a foot-gun event, I guess. | 04:51 |
| StevenK | steven@liquified:~/launchpad/lp-branches/denorm-bspph% testr run --failing | 04:51 |
| StevenK | running=xvfb-run ./bin/test --subunit | 04:51 |
| lifeless | jamesh: do you happen to know how I can reset gnome-gpg to ask for my passphrase again ?! | 05:09 |
| lifeless | and preferrably nuke the silly thing that ever captured it | 05:10 |
| jamesh | lifeless: delete the passphrase from the keyring using the "Passwords and Encryption Keys" app | 05:10 |
| jamesh | I haven't used gnome-gpg in years (gnupg-agent seems to do a good job) | 05:10 |
| lifeless | jamesh: that seems to want to change the actual gpg managed passphrase | 05:11 |
| lifeless | jamesh: which isn't what I intend | 05:12 |
| jamesh | lifeless: you're looking on the passwords tab, right? | 05:12 |
| jamesh | not the "My Personal Keys" or "Other Keys" tabs | 05:12 |
| lifeless | jamesh: it shows 'passwords: default and 'Passwords: login' | 05:13 |
| jamesh | lifeless: right. expand those and find the entry gnome-gpg added. | 05:14 |
| lifeless | there isn't one :) | 05:14 |
| jamesh | well, that's where gnome-gpg would be storing the passphrase | 05:14 |
| lifeless | ah | 05:14 |
| lifeless | I had to click 'unlock' | 05:14 |
| lifeless | to unlock the first folder, before it would show me its contents. | 05:14 |
| lifeless | ui win! | 05:14 |
| lifeless | jamesh: thanks! | 05:15 |
| jamesh | "passwords: default" would be a keyring from before the PAM integrated login keyring | 05:15 |
| jamesh | if it doesn't hold anything interesting you would probably be best off deleting it. | 05:15 |
| lifeless | jamesh: I've been running this homedir uninterrupted since, uhm, 2000 | 05:15 |
| lifeless | jamesh: it appears to have a lot of semi interesting things | 05:16 |
| jamesh | the login keyring is locked and unlocked automatically by pam | 05:16 |
| jamesh | the default one requires manual password entry (assuming it has a password set) | 05:17 |
| lifeless | thanks | 05:19 |
| lifeless | bbiab | 05:19 |
| === almaisan-away is now known as al-maisan | ||
| StevenK | jtv: O hai. Do you have time for a small review? | 05:31 |
| jtv | Yes, okay | 05:32 |
| StevenK | jtv: https://code.launchpad.net/~stevenk/launchpad/denorm-bspph-qualified/+merge/71812 | 05:32 |
| jtv | I find it odd that you should come to me with this request, after all my hard work to scare you off. | 05:32 |
| StevenK | jtv: lifeless owed me, but he's buggered off. And you're supposed to be OCR anyway | 05:33 |
| jtv | ah yes | 05:33 |
| jtv | Anyway, I see a familiar pattern: it's as if someone has tried to make the SQL harder to figure out. | 05:34 |
| StevenK | Hah | 05:34 |
| jtv | By arbitrarily turning some keywords into lower-case, and putting the line breaks in odd places. | 05:34 |
| jtv | Could you please just put the FROM, in all caps, at the beginning of the line? | 05:35 |
| StevenK | jtv: In bugtask? | 05:35 |
| jtv | Yes. And maybe make the other SQL keywords consistently upper-case as well? | 05:35 |
| wgrant | I wish it was practical to write a lint check to force that. | 05:36 |
| jtv | Yes! Oh God, yes! | 05:36 |
| jtv | And go away. You are not here. | 05:36 |
| wgrant | Few reviewers do. | 05:36 |
| wgrant | Hah. | 05:36 |
| jtv | Reviewers nowadays are a bunch of pussies. | 05:36 |
| jtv | "Oh yes, I can't read this, but if you get it past the python parser I'll approve it." | 05:37 |
| StevenK | jtv: Anything else? | 05:37 |
| jtv | AFAICT it's all cosmetic. Am I missing something? | 05:38 |
| StevenK | wgrant: I'd solve the bloody problem and storm-ify the methods, but they make my eyes bleed. | 05:38 |
| StevenK | jtv: It's lead-up to adding a sourcepackagename column to SPPH | 05:38 |
| lifeless | if you can make a lint check for it, you can make an automated fixer for it. | 05:39 |
| jtv | Then go forth and land ye your branches, that they may be merged. | 05:39 |
| jtv | 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:41 |
| jtv | 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:42 |
| lifeless | mmm, I can see an argument for that, but I'm not convinced | 05:44 |
| jtv | I'm not making an argument, I'm telling you how it is. It helps. | 05:46 |
| wgrant | Let's just version control the AST. | 05:46 |
| lifeless | if python was just a little less fragile | 05:47 |
| lifeless | now where, was I, thats right, housework. Then extracting code to oops-wsgi | 05:47 |
| * jtv wonders if that is pronounced "oopski" | 05:48 | |
| === 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 | ||
| LPCIBot | Project db-devel build #814: FAILURE in 5 hr 47 min: https://lpci.wedontsleep.org/job/db-devel/814/ | 06:49 |
| jtv | thanks for the surprise review, lifeless :) | 07:07 |
| lifeless | jtv: de nada | 07:12 |
| rvba | StevenK: Hi! Thanks for the review Steven, I made the corrections you suggested. | 07:25 |
| adeuring | good morning | 07:36 |
| jtv | morning adeuring | 07:40 |
| adeuring | hi jtv! | 07:41 |
| === al-maisan is now known as almaisan-away | ||
| jtv | StevenK: you're not still reviewing, are you? Because I've got this: https://code.launchpad.net/~jtv/launchpad/bug-824553/+merge/71823 | 07:52 |
| bigjools | morning all | 08:05 |
| mrevell | Good morning | 08:07 |
| StevenK | rvba: r=me | 08:15 |
| rvba | StevenK: Thanks! | 08:16 |
| === 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 | ||
| stub | 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 |
| lifeless | librarian | 09:33 |
| lifeless | 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:33 | |
| lifeless | or truncate the log, or something. | 09:34 |
| lifeless | stub: stress test time! | 09:34 |
| stub | HUP HUP HUP HUP HUP OH JUST FSCK OFF | 09:34 |
| lifeless | stub: one easy way would be to diff the log in memory - read or stat at the start, and etc | 09:34 |
| stub | Maintain an open file, seeking to the end after each test. | 09:35 |
| stub | fsync before the seek if you care. | 09:35 |
| stub | somehow handle the tests that test Librarian log file rotation :-) | 09:36 |
| stub | 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:39 |
| poolie | hi all | 09:45 |
| poolie | any lazr or lplib experts that could look at https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832 ? | 09:45 |
| poolie | is there a more kosher way to do it? | 09:45 |
| lifeless | stub: it may; but if the texts are identical it should never. | 09:47 |
| lifeless | and -woo- we have a wsgi layer. | 09:47 |
| stub | So as long as I don't have to resolve conflicts should be fine. | 09:47 |
| lifeless | and its (at least to me) a lot cleaner than the launchpad-loggerhead on. I may be biased. | 09:47 |
| cjwatson | 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:51 |
| jtv | cjwatson: funnily enough I was just composing another IRC message for you. :) | 09:52 |
| jtv | I'm having a look. | 09:52 |
| lifeless | poolie: whats your cli for pqm called again ? | 09:52 |
| lifeless | (and bugs etc, your nih api client :P) | 09:52 |
| jml | lifeless: hydrazine? | 09:53 |
| lifeless | yes! | 09:53 |
| jml | lifeless: not to be confused with lptools or ubuntu-dev-tools ("ubuntu-dev" being code for "launchpad" there) | 09:53 |
| poolie | feed-pqm | 09:54 |
| poolie | in hydrazine | 09:54 |
| poolie | the nih api client is 'wrested' | 09:54 |
| lifeless | poolie: I needed it to do that review for you :) | 09:54 |
| poolie | which? | 09:54 |
| lifeless | hydrazine | 09:55 |
| jtv | cjwatson: taking a while for the MP to update. Did you get a failure email by any chance? | 09:58 |
| cjwatson | not yet ... | 09:58 |
| * cjwatson pokes offlineimap just in case | 09:59 | |
| cjwatson | jtv: it seems to be up to date when I look from here | 09:59 |
| jtv | cjwatson: yup, just got it at last. | 10:00 |
| jtv | cjwatson: not much I can do with this one, but reviewed. | 10:04 |
| jtv | Meanwhile, about those custom uploads... :) | 10:04 |
| jtv | cjwatson: can you land it yourself? I'm not even sure I can, tbh | 10:05 |
| jtv | Your MP I mean, not mine. | 10:05 |
| danilos | jtv, heya, I've got a branch up for review: https://code.launchpad.net/~danilo/launchpad/bug-826692/+merge/71836 | 10:06 |
| jtv | danilos: do you now? Good for you mate! | 10:07 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilos | Critical bugs: 238 - 0:[#######=]:256 | ||
| cjwatson | 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 |
| danilos | jtv, yeah, I am just bragging around, thanks | 10:07 |
| cjwatson | judging from the commit history | 10:07 |
| jtv | cjwatson: yes, that's how it happens with the less well-managed branches. Can't say I'm familiar with this one. | 10:07 |
| cjwatson | jtv: I can deal with talking to IS about the actual deployment stuff after that | 10:07 |
| jtv | danilos: let me just help colin out here, and then I'll get to your branch | 10:08 |
| jtv | Or maybe the other OCR… oh. | 10:08 |
| danilos | jtv, sure, thanks | 10:08 |
| danilos | :) | 10:08 |
| jtv | Oh wow, I've worked with meta-lp-deps in the distant past. | 10:09 |
| danilos | jtv, yesterday? | 10:09 |
| cjwatson | jtv: going to try to get my head round your mail now | 10:09 |
| jtv | Your considerable head. | 10:10 |
| jtv | Shouldn't be too hard. | 10:10 |
| stub | 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:19 |
| danilos | stub, sure, need it on latest stable/devel/db-stable/db-devel? | 10:21 |
| stub | danilos: stable or whatever. I think it is an old problem nobody noticed. | 10:22 |
| danilos | stub, running now, you got me confused for a moment with bin/test.py instead of bin/test :) | 10:24 |
| stub | DWIM | 10:24 |
| jelmer | poolie: btw, can you land my branches on lp:lptools, or should I apply for members? | 10:25 |
| stub | Actually, needs to be stable or devel - I think a cherry pick from db-devel -> devel killed it. | 10:25 |
| jelmer | *membership | 10:25 |
| stub | danilos: ^^ | 10:25 |
| poolie | there's already a bug for https://code.launchpad.net/~ubuntu-branches/ timing out right? | 10:26 |
| jtv | cjwatson: your change has landed. | 10:27 |
| poolie | jelmer: i'll look | 10:27 |
| danilos | stub, right, I am trying with stable | 10:27 |
| jelmer | poolie: thanks :) | 10:27 |
| poolie | you have the power! | 10:27 |
| danilos | stub, I am having some troubles with tests actually failing | 10:30 |
| stub | danilos: database in use errors? | 10:31 |
| danilos | stub, nope, LaunchpadSilentFailure or something :/ | 10:33 |
| danilos | let me check my dependencies | 10:33 |
| danilos | (it's likely my download-cache is out of date) | 10:35 |
| cjwatson | jtv: thanks! and replied (though whether you'll like the reply I'm not sure ...) | 10:35 |
| jtv | danilos: can't the preloading you're doing be done with load_related? | 10:35 |
| jtv | cjwatson: argh! | 10:35 |
| jtv | danilos: thinking specifically of do_eager_load (I understand you probably don't want to mess with that other code in detail) | 10:36 |
| danilos | 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 |
| danilos | jtv, i.e. I need double "related" indirection | 10:36 |
| jtv | Can't you pass a result set to load_related? | 10:36 |
| stub | 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:36 |
| jtv | danilos: ahhh, iswym | 10:37 |
| jtv | you're starting out with a python-constructed nontrivial set of ids, not of objects. | 10:37 |
| stub | oh... nm. it is still in stable. It is in testfuncs.sql, not trusted.sql | 10:38 |
| stub | Running stable tests with a db-devel database... and it sometimes works! | 10:39 |
| jtv | danilos: done | 10:39 |
| danilos | jtv, thanks | 10:39 |
| jtv | cjwatson: aren't ddtp-translations tarballs flushed from the librarian after a while? | 10:42 |
| jtv | I mean, it's GC'ed automatically. | 10:43 |
| jtv | And AFAIK fairly aggressively. | 10:43 |
| jtv | (Also note that dsync isn't currently used.) | 10:43 |
| cjwatson | jtv: surely not *that* frequently? there's usually a ddtp-tarball upload not very long before release | 10:46 |
| jtv | cjwatson: are we talking hours, days..? | 10:46 |
| danilos | stub, ok, finally got it all to a clean state, I don't see the lag: https://pastebin.canonical.com/51339/ | 10:46 |
| stub | danilos: ta | 10:47 |
| cjwatson | jtv: for natty it was about two weeks (https://lists.ubuntu.com/archives/natty-changes/2011-April/011309.html) | 10:47 |
| cjwatson | jtv: but we could copy them if they're available and not worry if they aren't, I'd have thought | 10:48 |
| cjwatson | jtv: dsync> that's a shame | 10:48 |
| jtv | 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:48 |
| wgrant | jtv: ddtp-translations is probably not expired. | 10:49 |
| cjwatson | jtv: what generates the md5sums index then? | 10:49 |
| wgrant | jtv: Rosetta translations are. | 10:49 |
| jtv | ahh | 10:49 |
| cjwatson | lp_archive@cocoplum:~$ ls -l /srv/launchpad.net/ubuntu-archive/ubuntu/indices/md5sums.gz | 10:49 |
| cjwatson | -rw-r--r-- 1 lp_publish lp_publish 29926782 Aug 8 10:23 /srv/launchpad.net/ubuntu-archive/ubuntu/indices/md5sums.gz | 10:49 |
| jtv | Okay, so we could add ddtp-translations. | 10:49 |
| cjwatson | that looks unfortunate | 10:49 |
| jtv | However | 10:49 |
| wgrant | cjwatson: It was generated by dsync. | 10:49 |
| cjwatson | (I'm fairly sure that there exist mirroring tools which look at indices/md5sums.gz) | 10:49 |
| stub | 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 |
| wgrant | Which we should really running again. | 10:49 |
| cjwatson | wgrant: yes, that's my point :) | 10:49 |
| stub | We can change that timeout easily enough, although we pay for it in disk space. | 10:50 |
| jtv | 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 |
| cjwatson | jtv: that's fair enough, but I would like to see those comments addressed at some point | 10:51 |
| jtv | Absolutely. | 10:51 |
| cjwatson | I wasn't intending these to be blockers, but you did ask for a review :-) | 10:51 |
| jtv | 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 |
| cjwatson | I *think* your date comparison approach is safe, even if IMO not the right thing | 10:52 |
| jtv | 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 |
| cjwatson | perhaps you can turn it into bugs | 10:52 |
| jtv | Sure. | 10:53 |
| jtv | I was thinking kanban cards, but I can do both. | 10:53 |
| cjwatson | or that, I don't know your processes :) | 10:53 |
| cjwatson | just avoid being forgotten | 10:53 |
| jtv | An advantage of splitting these off is that other people can work on them, who knows, maybe even at the same time. :) | 10:53 |
| cjwatson | :-) | 10:53 |
| cjwatson | thanks | 10:53 |
| jtv | Glad to help. If you'll let me. :-P | 10:53 |
| jtv | cjwatson: by the way, any idea where in LP these tarball names are already being parsed? | 10:56 |
| cjwatson | jtv: lib/lp/archivepublisher/{debian_installer,dist_upgrader,ddtp_tarball}.py | 10:56 |
| poolie | hello | 10:56 |
| jtv | Great, thanks. | 10:56 |
| poolie | 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 <Launchpad itself:New> < https://launchpad.net/bugs/827935 > | 10:57 |
| cjwatson | which is what processes those uploads in the first place | 10:57 |
| cjwatson | # This code is mostly owned by Colin Watson and is partly refactored by | 10:57 |
| cjwatson | # Daniel Silverstone who should be the first point of contact for it. | 10:57 |
| cjwatson | current comments 'r' us | 10:57 |
| poolie | :) | 10:57 |
| poolie | i love how many old names still appear in the lp test data | 10:58 |
| poolie | daf, daniels, | 10:58 |
| poolie | stevea | 10:58 |
| cjwatson | (custom uploads used to be processed entirely by hand. it was horrendous) | 10:58 |
| jtv | 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? | 10:59 |
| jtv | 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:00 |
| jtv | And that if there's no architecture, that means "all." | 11:01 |
| cjwatson | 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 |
| cjwatson | ISTR an enum for it | 11:02 |
| jtv | Hmmm | 11:03 |
| jtv | bigjools, do you know about this? ^^ | 11:03 |
| cjwatson | all the current parsers just ignore the first component | 11:03 |
| cjwatson | lib/lp/soyuz/enums.py:PackageUploadCustomFormat | 11:03 |
| cjwatson | existence of that suggests to me that the type is stored in the db somewhere | 11:03 |
| cjwatson | though I guess that could just be queue rows | 11:04 |
| bigjools | it is somewhere | 11:04 |
| cjwatson | if it isn't stored, then in practice you can probably get away with looking at the first component of the tarball name, since AFAIK they've never changed yet | 11:04 |
| cjwatson | jtv: TBH I have no idea what would happen if we ever tried to upload architecture-dependent dist-upgrader tarballs | 11:05 |
| bigjools | jtv: see PackageUpload.contains_* | 11:05 |
| cjwatson | jtv: but certainly a powerpc version of the debian-installer images tarball does not replace an i386 one with otherwise the same tarball name | 11:05 |
| jtv | cjwatson: PackageUploadCustomFormat just distinguishes between debian-installer, ddtp-translations, dist-upgrader, rosetta-translations. Much coarser. | 11:05 |
| cjwatson | jtv: then I do not know what you mean by "the first parameter in the tarball name" | 11:05 |
| bigjools | which uses PackageUploadCustom.customformat | 11:06 |
| jtv | So again, not what we're looking for. | 11:06 |
| jtv | The PackageUploadCustom is already fully accounted for. | 11:07 |
| bigjools | can you re-state the question in simple terms then so I don't have to wade through backscroll | 11:07 |
| cjwatson | the tarballs are debian-installer-images_VERSION_ARCH.tar.gz, dist-upgrader_VERSION_ARCH.tar.gz, or translations_COMPONENT_VERSION.tar.gz; I assumed you meant the "debian-installer-images", "dist-upgrader", or "translations" part when you said "the first parameter" | 11:07 |
| jtv | OK: if we get two custom uploads of the same type for the same distroseries, what information should I take into account to determine whether the one supersedes the other, or is a separate thing that may also need to be copied? | 11:08 |
| jtv | And I understand that this differs by custom type, but I'd like to know the specifics for debian-installer; dist-upgrader; and ddtp-translations. | 11:08 |
| cjwatson | For debian-installer-images and dist-upgrader, different version + same arch means it supersedes. For translations, different version + same component means it supersedes. | 11:08 |
| cjwatson | i.e. we want the most current version of (debian-installer-images/per-arch, dist-upgrader/per-arch, translations/per-component) | 11:09 |
| jtv | OK | 11:10 |
| bigjools | jtv: in lp/archivepublisher/ there are custom file handlers for publishing | 11:10 |
| jtv | That's not too far off what I have now, except (1) I currently don't have support for ddtp translations and (2) I currently also disambiguate by the "name" part (e.g. "debian-installer-images" vs. "dist-upgrader"). | 11:10 |
| jtv | bigjools: yes, colin just pointed those out. | 11:11 |
| bigjools | jtv: they are called via PackageUploadCustom.publish... | 11:11 |
| bigjools | the whole custom file thing is hideous | 11:11 |
| jtv | Does that logic encode anything about what supersedes what? If so, it may be better to extract and reuse. | 11:11 |
| cjwatson | yes, to some extent | 11:12 |
| bigjools | it does, somewhere, trying to find it | 11:12 |
| cjwatson | e.g. I pointed to the fixCurrentSymlink stuff which does version comparison | 11:12 |
| bigjools | right | 11:12 |
| cjwatson | jtv: if the name changes, then the version will also change, so there isn't really much point in disambiguating on it | 11:13 |
| cjwatson | this is guaranteed because if you don't change the version then you don't get a new directory under /dists/$SERIES/main/$BLAH/ | 11:13 |
| jtv | That's fine then. It's just that for one of the upload types I ended up not supporting (translations I guess), the name part seemed to be a package name. | 11:13 |
| cjwatson | no, it's NAME_COMPONENT_VERSION in that case | 11:14 |
| cjwatson | where NAME == "translations" (not enforced/required but in practice true right now), COMPONENT in ("main", "restricted", "universe", "multiverse") | 11:14 |
| cjwatson | that's the ddtp-tarball type | 11:14 |
| cjwatson | rosetta-translations might have a package name there, but we don't care about rosetta-translations for this because they aren't published to dists/ | 11:15 |
| jtv | So only custom type & architecture matter for now, and for ddtp, component will also matter. | 11:17 |
| jtv | Ah, I have some examples in the database now. That helps. | 11:19 |
| cjwatson | jtv: and ddtp isn't per-architecture, *only* per-component | 11:19 |
| cjwatson | I expect at least part of the code for this ought to live in the DebianInstaller etc. classes ... | 11:20 |
| jtv | Well I treat "no architecture" as "all" for genericity. | 11:20 |
| cjwatson | err, DebianInstallerUpload I mean | 11:20 |
| cjwatson | that sounds like an encapsulation bug, if you're having to consider architecture in generic code that suggests that actually the decision ought to be pushed down to the classes that know about the specific upload format | 11:21 |
| cjwatson | IYSWIM | 11:21 |
| jtv | Nah. | 11:21 |
| nigelb | mrevell: Hi! | 11:21 |
| jtv | The point is to isolate the format-specific part, so that it only extracts enough information to group the uploads such that of each group, only the latest matters. | 11:22 |
| henninge | jtv: here is a fun branch to review for you ;-) https://code.launchpad.net/~henninge/launchpad/devel-update-testtools-r228/+merge/71659 | 11:22 |
| jtv | henninge: sorry, past eod | 11:23 |
| mrevell | nigelb, Hi, on the phone just now. | 11:23 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | Critical bugs: 238 - 0:[#######=]:256 | ||
| henninge | jtv: np | 11:23 |
| jtv | Thanks. | 11:23 |
| henninge | danilos:: here is a fun branch to review for you ;-) https://code.launchpad.net/~henninge/launchpad/devel-update-testtools-r228/+merge/71659 | 11:23 |
| wgrant | jtv: Regretting your evil endeavour yet? | 11:23 |
| nigelb | mrevell: cool, can you please poke me once youre done? :) | 11:23 |
| jtv | wgrant: not at all—it turns out not to be impossible at all and my design can stay largely intact. | 11:24 |
| nigelb | Seeing how much wgrant is failing to disappear from here during vacation, I'd suggest a +b from #launchpad-* during vacation time ;) | 11:24 |
| jtv | Ooooh good idea | 11:24 |
| wgrant | I only drop in occasionally! | 11:25 |
| nigelb | where ocassionaly = ~2 hours | 11:25 |
| jtv | …and then stay for how long, would you say? | 11:26 |
| jtv | bigjools, cjwatson: different concern… I notice that the uniqueness check for debian-installer uploads distinguishes between uploads with ".0." in them and ones without! | 11:27 |
| cjwatson | jtv: true, although we haven't used that for years | 11:28 |
| cjwatson | perhaps we should just ditch that, it is a rather bizarre way to do it | 11:29 |
| jtv | Aye, that it is | 11:29 |
| jtv | Question is, what should be done about it? | 11:29 |
| cjwatson | in fact I don't think we've used it since we switched to LP | 11:29 |
| cjwatson | it dates from the similar dak code | 11:29 |
| cjwatson | so if it's causing problems I suggest just binning it | 11:30 |
| * jtv files separate bug | 11:31 | |
| nigelb | Does rocketfuel setup a password for postgres after I install postgres with that? | 11:31 |
| cjwatson | I mean, in theory I suppose daily builds of d-i would be kind of nice ... but they were a lot more useful in the early days than they are now, and in practice just uploading d-i again whenever I need to works out fine | 11:32 |
| cjwatson | definitely not worth awkward infrastructure to support it | 11:32 |
| danilos | jam: hi, do you think you could have a go at https://code.launchpad.net/~danilo/loggerhead/bug-718566/+merge/71849 | 11:33 |
| danilos | henninge, looking at your branch now | 11:34 |
| jtv | nigelb: it configures a trusted TCP login from localhost. | 11:34 |
| henninge | danilos: thanks | 11:34 |
| nigelb | jtv: so, can I safely do sudo passwd postgres and not break my lp install? | 11:34 |
| jtv | nigelb: oh, a system password for the postgres user? I don't see any reason why it should have a password at all. | 11:35 |
| nigelb | oh. | 11:35 |
| jtv | nigelb: sorry, I thought you were talking about a password for logging into the postgres databases. | 11:35 |
| jtv | System users generally shouldn't have passwords. No good for anyone but attackers. :) | 11:35 |
| nigelb | I'm just following instructions for hacking on harvest, which I think maybe a bit overzealous | 11:36 |
| danilos | henninge, that was an easy one, r=me :) | 11:37 |
| jam | danilos: commented | 11:38 |
| henninge | danilos: indeed. Thanks ;-) | 11:38 |
| danilos | jam: thanks, I'll try it out on a LP branch (I suppose you are suggesting doing it locally) | 11:39 |
| jam | yeah | 11:40 |
| jam | note that the *first* request is going to be uncached as well | 11:40 |
| jam | since it has to do the work | 11:40 |
| jam | my feeling is that it is already fast enough that we don't need the cache at all anymore | 11:40 |
| danilos | jam: yeah, I can't really tell the difference between the two (trunk and the branch with removed changes), I'll do something more scientific from the terminal :) | 11:43 |
| jam | danilos: probably try to find a revision with a particularly large number of changes | 11:46 |
| jam | like when you merge into db-devel or whatever it is called now | 11:46 |
| danilos | jam: right, I'll do that, and use "ab" to get actual data | 11:46 |
| danilos | jam: fwiw, I got the following exception with trunk when benchmarking: https://pastebin.canonical.com/51341/ | 11:53 |
| jam | danilos: I've seen ScopeReplacer issues when running a lot of multithreaded requests as the "first" requests on a new loggerhead startup | 11:54 |
| jam | danilos: so you can try starting loggerhead, making a single request | 11:54 |
| jam | then running ab | 11:54 |
| danilos | jam: right, thanks | 11:54 |
| jam | ScopeReplacer happens at 'import' times, and it is known not to be threadsafe | 11:54 |
| danilos | ah, makes sense, should I file a bug about it somewhere? | 11:55 |
| === henninge is now known as henninge-lunch | ||
| LPCIBot | Project devel build #979: FAILURE in 5 hr 23 min: https://lpci.wedontsleep.org/job/devel/979/ | 12:13 |
| jam | danilos: there is a bug already | 12:15 |
| danilos | jam: cool, I've added benchmarking results with a summary on https://code.launchpad.net/~danilo/loggerhead/bug-718566/+merge/71849 | 12:16 |
| danilos | jam: tell me if you think I should land this considering the "mild" performance degradation | 12:16 |
| jam | danilos: going from the Launchpad discussion. Which is "things MUST complete in <9s (or 5s, ymmv), and SHOULD complete in <1s". We are still well underneath satisfying the 5s rule, and even the 1s rule. | 12:18 |
| jam | btw, I wouldn't expect /changes to differ | 12:18 |
| jam | let me grab a URL, just a sec | 12:18 |
| danilos | jam: sure, I wasn't sure if /changes used this cache as well | 12:19 |
| jam | it is the +revlog URLs that would be affected, I think | 12:20 |
| jam | http://bazaar.launchpad.net/+branch/bzr/+revlog/pqm@pqm.ubuntu.com-20110817084016-600z65qzqmmt44w7 | 12:20 |
| jam | /changes doesn't show you the file changes until you expand something | 12:20 |
| danilos | jam: ok, I'll test it directly as well | 12:24 |
| jam | danilos: updated the mp with my comment | 12:24 |
| jam | I think I have a URL for you to try | 12:25 |
| jam | (posted to the mp) | 12:25 |
| jtv | cjwatson: see email. All that needed immediate fixing then was that the "name" part of those tarball filenames is irrelevant, right? I just fixed that. | 12:25 |
| jtv | (And cross-referenced to all those bugs I filed, *pant*) | 12:25 |
| danilos | jam: right, I was already benchmarking that URL | 12:25 |
| jam | danilos: I'm expected that to regress approximately the same as /revision, which would still put it in the "fully acceptable" realm. | 12:26 |
| danilos | jam, that's right, 325ms vs 267ms for the trunk | 12:27 |
| danilos | (trunk with cache populated, already accessed the page from the browser first) | 12:27 |
| jam | danilos: right. And ultimately a cache will always be faster, so what is "enough". And I think using SQUID to cache these pages is far superior to trying to do a file-change cache. | 12:28 |
| jam | you might also try one more URL | 12:28 |
| jam | something with a small change | 12:28 |
| jam | which should be much less sensitive | 12:28 |
| danilos | jam: yep, I'll do that too | 12:29 |
| rvba | danilos: Hi, can I add this MP to your queue? https://code.launchpad.net/~rvb/launchpad/desc-header-827893/+merge/71842 | 12:45 |
| danilos | jam: anyway, smaller revision is actually faster in the few runs I did (259ms vs 264ms), so all good | 12:47 |
| danilos | rvba, a queue, there's a queue? :) | 12:47 |
| jam | danilos: good deal | 12:47 |
| rvba | danilos: :) | 12:47 |
| cjwatson | jtv: yep | 12:48 |
| cjwatson | jtv: thanks for the attention to detail :-) | 12:48 |
| danilos | rvba, nice, simple and clean, r=me (and thanks for the formatting fixes as well) | 12:49 |
| rvba | danilos: Thanks! | 12:49 |
| danilos | jam: now, how do I go land loggerhead changes? just merge into trunk (I see nobody is using [r=...] tags) | 12:51 |
| jam | danilos: yeah, merge it to trunk, comimt | 12:51 |
| jam | then make a proposal against Launchpad to use the new loggerhead code. | 12:51 |
| jam | utilities/source_deps I believe | 12:51 |
| StevenK | utilities/sourcedeps.conf | 12:54 |
| StevenK | jam: ^ | 12:54 |
| deryck | Morning, all. | 13:04 |
| StevenK | stub: If you're still around, can you please re-rubber stamp https://code.launchpad.net/~stevenk/launchpad/denorm-bspph/+merge/71811 ? I've had to resubmit due to the addition of a pre-req branch. | 13:12 |
| === al-maisan is now known as almaisan-away | ||
| deryck | abentley, let's chat about this shortly: https://code.launchpad.net/~deryck/launchpad/bug-heat-wonky-recent-activity-check-688364/+merge/71756 | 13:47 |
| deryck | abentley, and thanks! :) | 13:47 |
| abentley | deryck: np | 13:47 |
| === henninge-lunch is now known as henninge | ||
| deryck | abentley, I'm free now, if you have a minute to chat about that MP. | 14:04 |
| deryck | abentley, mumble 1 o 1? | 14:04 |
| abentley | deryck: sure | 14:04 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256 | ||
| === almaisan-away is now known as al-maisan | ||
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 238 - 0:[#######=]:256 | ||
| === al-maisan is now known as almaisan-away | ||
| LPCIBot | Project devel build #980: STILL FAILING in 2 hr 25 min: https://lpci.wedontsleep.org/job/devel/980/ | 14:38 |
| * barry sees lots of timeouts today | 14:54 | |
| rvba | deryck: Hi, do you have a few minutes for a small JS question? | 15:08 |
| LPCIBot | Project devel build #981: STILL FAILING in 31 min: https://lpci.wedontsleep.org/job/devel/981/ | 15:10 |
| barry | has anybody else noticed a high number of timeouts today? | 15:11 |
| nigelb | mrevell: are you free-er? | 15:11 |
| benji | Is anyone else seeing "ImportError: No module named html5browser" on devel? | 15:12 |
| benji | the last buildbot run that wasn't killed by a KeyboardInterrupt was clean and I don't see any bugs filed about it | 15:12 |
| barry | here are two urls that are consistently timing out for me today, but were fine yesterday: | 15:13 |
| barry | https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bug/807950 | 15:13 |
| _mup_ | Bug #807950: zeitgeist-daemon crashed with LookupError in remove_from_connection(): <_zeitgeist.engine.remote.RemoteInterface at /org/gnome/zeitgeist/log/activity at 0xb74ee2cc> is not exported at a location matching (None,None) <apport-crash> <bugpattern-needed> <i386> <oneiric> <running-unity> <unity-2d> <zeitgeist (Ubuntu):Triaged> <zeitgeist (Ubuntu Oneiric):Triaged> < https://launchpad.net/bugs/807950 > | 15:13 |
| barry | https://launchpad.net/ubuntu/+search?text=chromium-browser | 15:13 |
| mrevell | Hi nigelb, sure. How can I help? | 15:13 |
| nigelb | mrevell: I'm looking to see if you have suggestions on how the subscription could be improved | 15:14 |
| nigelb | I found it non-intuitive | 15:14 |
| deryck | rvba, sure. voice or chat? | 15:14 |
| nigelb | fixing it would be trivial, but the UX is probably of more concern here than the actual patch | 15:14 |
| benji | the ImportError can be reproduced with "bin/test -c -t test_archivesubscribers_index" | 15:14 |
| nigelb | *comparitively trivial | 15:14 |
| rvba | deryck: great, I think chat is ok ... I'll paste my understanding of the problem .. | 15:15 |
| timrc | calling addArchiveDependency() on PPA's (belonging to my LP user ~timrchavez) via the web service is resulting in OOPses in the web UI | 15:15 |
| rvba | deryck: It's weird problem with FormOverlay. Basically, when the overlay is closed (for instance 'cancelled') it stays in the page (which is normal) but since it's only hidden using "visibility: hidden" it prevents me from clicking on the radio button that is underneath it. | 15:15 |
| rvba | Here is the real example: | 15:15 |
| rvba | If you open up a row on this page https://dogfood.launchpad.net/ubuntu/oneiric/+localpackagediffs then changed the "Ignored" status using the radio buttons, you'll get an overlay to enter a comment (to describe *why* you changed the ignored status). Cancel the overlay and you will see that now you can't click on the radio buttons any more. | 15:15 |
| rvba | I'm not the only one to have this problem it seems: http://stackoverflow.com/questions/1751861/do-controls-in-firefox-receive-mouse-events-when-their-css-visible-property-is-fa | 15:15 |
| rvba | This fixes it: http://paste.ubuntu.com/668072/ | 15:16 |
| rvba | deryck: But obviously I don't want to mess with that without the advice of a JS expert ;) | 15:16 |
| mrevell | nigelb, Subscription to what? Sorry, I've not really been following this channel much today. | 15:16 |
| deryck | rvba, reading back, thinking..... | 15:16 |
| nigelb | mrevell: Oh, I should have been clearer. I meant bug subscription, more specifically, subscribing myself to a bug | 15:17 |
| timrc | Here is a script that should allow you to reproduce the problem (replace the PPA with a PPA you own): https://pastebin.canonical.com/51356/ | 15:17 |
| deryck | rvba, yes, display none is what I would prefer. I always wondered why we used visibility anyway. | 15:19 |
| deryck | rvba, I couldn't think of this exact issue, but I knew there was something with invisibility vs display like this. | 15:19 |
| bigjools | timrc: an OOPS code is more useful | 15:20 |
| timrc | bigjools, certainly, OOPS-2055AU68 | 15:20 |
| bigjools | thanks | 15:20 |
| rvba | Looks much saner to me to use "display: none" too ... I'll do the change then ... I hope it won't break other overlays ;) | 15:21 |
| bigjools | timrc: FTR you can't add 2 dependencies on Ubuntu like that | 15:21 |
| bigjools | just the latter one will do | 15:21 |
| timrc | bigjools, it was originally a test to verify that... however | 15:21 |
| timrc | bigjools, the first call to add the dep is what blows these ppas up | 15:21 |
| rvba | deryck: thanks for looking into it. | 15:21 |
| bigjools | ah | 15:21 |
| timrc | bigjools, just did it again on a ppa owned by ~oem-archive user, OOPS-2055AR56 | 15:21 |
| bigjools | I need to wait for the oops to sync | 15:22 |
| deryck | rvba, np | 15:22 |
| timrc | bigjools, our goal is to try to figure out how to get this option via the web service, http://i.imgur.com/ewHzM.png | 15:22 |
| timrc | bigjools, maybe you know off hand :)? | 15:22 |
| timrc | not specifying any component gives us the second option | 15:23 |
| bigjools | timrc: it defaults to that, no? | 15:23 |
| timrc | bigjools, when we call addArchiveDepedency without a component specified, it defaults to "Use all the same components..." I believe | 15:23 |
| bigjools | timrc: don't call addArchiveDependency at all, it defaults to use everything | 15:24 |
| timrc | bigjools, but need to chang the Ubuntu Dependency... | 15:25 |
| timrc | bigjools, we need to set the equivalent of "Basic" from "Default" in the web ui | 15:25 |
| bigjools | timrc: ok your image paste didn't make that clear | 15:26 |
| timrc | bigjools, sorry :) | 15:27 |
| bigjools | ummm | 15:27 |
| bigjools | not sure you can change this over the API tbh | 15:27 |
| timrc | http://i.imgur.com/aDHjJ.png | 15:27 |
| timrc | bigjools, would you consider this a bug then? | 15:28 |
| bigjools | timrc: let me investigate a little | 15:28 |
| mrevell | nigelb, We have a bug report ... bug 816105 ... I agree it's not easy to find the "subscribe me" option right now | 15:28 |
| _mup_ | Bug #816105: UI for subscribing to a bug is confusing <bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/816105 > | 15:28 |
| mrevell | nigelb, Was there something else you found non-intuitive? | 15:28 |
| nigelb | mrevell: the other bits are great. I'd love to fix the bug if there's a consensus on what needs to be done. | 15:29 |
| mrevell | nigelb, I'm about to go into another phone call ... I'd love to read your thoughts in a comment on that bug and then talk to you again later int he week, if that's okay. | 15:30 |
| nigelb | mrevell: that sounds good. | 15:30 |
| mrevell | great :) | 15:30 |
| timrc | Two bugs, 1) using addArchiveDependency() is causing OOPses (which seems like a regression); and 2) Cannot express "Use all components availalbe" via the web service for addArchiveDependency() | 15:30 |
| timrc | bigjools, ^ | 15:30 |
| cody-somerville | bigjools, https://lp-oops.canonical.com/?oopsid=OOPS-2055AZ51 | 15:35 |
| adeuring | abentley: fancy a "double review"? https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-slicing-only-in-factory/+merge/71913 and https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-slicing-only-in-factory/+merge/71913 | 15:44 |
| abentley | adeuring: sure, I'll have a look. | 15:45 |
| adeuring | abentley: one link should be https://code.launchpad.net/~adeuring/launchpad/bug-739052-6/+merge/71912 | 15:45 |
| bigjools | timrc: grar, ok please stop adding those, we need SQL to clean the DB | 15:50 |
| bigjools | timrc: can you get me a complete list of PPAs where you've done this and I will wipe all their dependencies | 15:50 |
| timrc | bigjools, lol, okay | 15:51 |
| timrc | bigjools, https://pastebin.canonical.com/51366/ | 15:54 |
| allenap | matsubara: Are you the person to talk to about qa-tagger? | 15:55 |
| matsubara | allenap, I'd be happy to talk to you about it. Anyone in the maintenance teams is encouraged to fix bugs there too. | 15:58 |
| bigjools | timrc, cody-somerville: FYI: https://bugs.launchpad.net/launchpad/+bug/828133 | 15:58 |
| _mup_ | Bug #828133: Archive:+edit-dependencies OOPS <oops> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/828133 > | 15:58 |
| allenap | matsubara: Ah, okay. Well, I'm wondering if it has missed a bug. The branches in https://bugs.launchpad.net/launchpad/+bug/824499 seem to have landed in stable but qa-tagger has not updated the bug. I'm trying to figure out why. | 15:59 |
| _mup_ | Bug #824499: "All derived distros" option for publish-ftpmaster <derivation> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/824499 > | 15:59 |
| timrc | bigjools, this bug was Fixed Release, so it seems to imply the interface should be usable for adding Ubuntu deps... https://bugs.launchpad.net/launchpad/+bug/776449, no? | 16:00 |
| _mup_ | Bug #776449: Set Ubuntu dependencies for PPA via API <api> <bad-commit-13157> <escalated> <not-pie-critical> <oem-services> <ppa> <qa-ok> <Launchpad itself:Fix Released by abentley> < https://launchpad.net/bugs/776449 > | 16:00 |
| allenap | matsubara: Ah, I think I've figured it out. The wrong bug number was used in the commit message. | 16:00 |
| allenap | Sorry for the noise. | 16:01 |
| bigjools | timrc: I forgot about that | 16:01 |
| bigjools | timrc: I guess it has a bug | 16:01 |
| timrc | bigjools, I should note that this was working (at least setting the Dep) up until recently (not sure when it went bad)... what wasn't working was the ability to achieve the first Components option in the web ui from the web service | 16:02 |
| matsubara | np allenap | 16:03 |
| abentley | adeuring: r=me | 16:09 |
| adeuring | abentley: thanks! | 16:09 |
| timrc | bigjools, here's the other bug | 16:17 |
| timrc | https://bugs.launchpad.net/launchpad/+bug/828145 | 16:17 |
| _mup_ | Bug #828145: Cannot add an archive dependency that uses all Ubuntu components available via the web service <oem-services> <Launchpad itself:New> < https://launchpad.net/bugs/828145 > | 16:17 |
| bigjools | timrc: I think you misunderstand | 16:18 |
| * bigjools writes on bug | 16:19 | |
| timrc | bigjools, probably :) | 16:19 |
| timrc | bigjools, all I know is addArchiveDependency() will change the what's displayed in that view | 16:19 |
| timrc | bigjools, so I expect to be able to do everything via the API that I can do in that view :)... is that too much to expect? | 16:19 |
| bigjools | timrc: yeah :) | 16:20 |
| bigjools | the addArchiveDependency does not allow you to change the ubuntu dependencies | 16:20 |
| bigjools | just add new ones | 16:20 |
| timrc | bigjools, when I create a PPA and use addArchiveDependency() to add an ubuntu dependency, it alters what's displayed in "Ubuntu dependencies"... | 16:21 |
| bigjools | timrc: you're trying to change the ubuntu dependency to just "main" aren't you? | 16:21 |
| bigjools | timrc: ah ok | 16:21 |
| bigjools | right, I remember how it works internally now | 16:21 |
| timrc | bigjools, here's our actual method... this will change the selection to the "Basic" Ubuntu dependency | 16:22 |
| timrc | bigjools, http://paste.ubuntu.com/668400/ | 16:23 |
| timrc | bigjools, however, it assumes the wrong Components choice | 16:23 |
| bigjools | timrc: see my comments on the bug | 16:23 |
| timrc | bigjools, ah | 16:24 |
| timrc | bigjools, works like a charm | 16:26 |
| bigjools | great! | 16:26 |
| timrc | cody-somerville, honestly a little surprised you didn't catch that... tsk | 16:26 |
| timrc | :P | 16:26 |
| mrevell | Hey, sinzui, have you seen bug 827902? | 16:27 |
| _mup_ | Bug #827902: Private teams not able to subscribe to bugs or blueprints for email updates <disclosure> <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/827902 > | 16:27 |
| bigjools | abentley: you know you did that change so that PPA dependencies can be set on the API? Can you have a look at this bug that it's causing: https://bugs.launchpad.net/launchpad/+bug/828133 | 16:38 |
| _mup_ | Bug #828133: Archive:+edit-dependencies OOPS <oem-services> <oops> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/828133 > | 16:38 |
| abentley | bigjools: I don't think I have any special insight. | 16:41 |
| bigjools | abentley: it's extremely weird | 16:41 |
| bigjools | the data looks sane | 16:42 |
| abentley | bigjools: It looks like a lp.soyuz.model.component.Component is the input to the getTerm. Is that correct? | 16:45 |
| bigjools | abentley: should be, it's worked for ages with no changes | 16:46 |
| === beuno is now known as beuno-lunch | ||
| bigjools | shame Component doesn't have a __repr__ :/ | 16:49 |
| bigjools | oh it does | 16:50 |
| bigjools | so it doesn't get used when the security proxy is in the way | 16:50 |
| cody-somerville | timrc, catch what? | 16:55 |
| bigjools | abentley: I see what's wrong | 16:56 |
| sinzui | mrevell, I have. I added the disclosure tag | 16:56 |
| bigjools | abentley: the API allows you to add data that the form cannot cope with | 16:56 |
| bigjools | timrc: set that component to "multiverse" and it'll be OK. | 16:58 |
| timrc | cody-somerville, that by specifying 'multiverse' as the component, for example, it pulls in 'main', 'restricted', and 'universe' as well | 16:58 |
| bigjools | the form code for the page only knows about multiverse and None :) | 16:58 |
| === almaisan-away is now known as al-maisan | ||
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| abentley | deryck: Why aren't comments 8 and 9 showing? https://bugs.qastaging.launchpad.net/launchpad/+bug/1000 | 18:28 |
| _mup_ | Bug #1000: There are too many bug reports in Malone <lp-foundations> <Launchpad itself:Invalid> <Ubuntu:Invalid> < https://launchpad.net/bugs/1000 > | 18:28 |
| * deryck looks | 18:29 | |
| abentley | deryck: These are comments I created using the 'macintosh' charset, but I wouldn't expect that to hide them... | 18:29 |
| deryck | abentley, hmmm, I have no idea. I wouldn't expect them to be hidden either. | 18:30 |
| deryck | abentley, I can get to them directly, too. Weird. | 18:31 |
| === al-maisan is now known as almaisan-away | ||
| abentley | deryck: They are missing the Subject line, unlike 7 which was the same except it used the 'mac-roman' charset. | 18:32 |
| deryck | abentley, ah, good catch. curious that a missing subject line on an email generated comment would cause the comment to hide. | 18:33 |
| abentley | deryck: The Subject was present on the email, though. | 18:34 |
| deryck | abentley, right, I followed. I assumed we tripped over it somehow and didn't store it in the db. | 18:35 |
| abentley | deryck: Yeah, I suspect. | 18:36 |
| deryck | abentley, seems like another bug that the comment won't display without a subject. | 18:36 |
| abentley | deryck: I doubt it's just any missing subject. | 18:37 |
| abentley | deryck: I bet it's related to the charset. | 18:37 |
| abentley | deryck: I've sent a latin-1 email with absolutely no subject, to see what happens. | 18:39 |
| deryck | abentley, good idea | 18:39 |
| abentley | deryck: subject-free comment is not hidden. | 19:05 |
| deryck | abentley, ok, good to know. Thanks for confirming. | 19:07 |
| abentley | deryck: I am marking bug 820039 qa-ok, and filing a new critical bug for "bug comments with macintosh encoding not displayed". | 19:08 |
| _mup_ | Bug #820039: process-mail.py fails with a LookupError: unknown encoding: macintosh error <mail> <oops> <qa-needstesting> <Launchpad itself:Fix Committed by abentley> < https://launchpad.net/bugs/820039 > | 19:08 |
| deryck | abentley, sounds good. | 19:08 |
| benji | abentley: do you have a minute for a review? https://code.launchpad.net/~benji/launchpad/bug-162868-2/+merge/71942 | 20:01 |
| abentley | benji: sure. | 20:01 |
| benji | abentley: here's the soundtrack: http://www.youtube.com/watch?v=0O2aH4XLbto&feature=channel_video_title | 20:01 |
| abentley | benji: The change looks reasonable. The docstring on Macro is sort-of obsoleted by the branch. | 20:08 |
| abentley | benji: it talks about the present state, rather than the state we'll have once the branch lands. | 20:08 |
| benji | abentley: hmm, you might be right; I'll take a second look | 20:08 |
| abentley | benji: e.g. "that pattern also has the side effect of making the template URL traversable from any object" could be "without this class, that pattern would make the template URL traversable..." | 20:09 |
| abentley | benji: r=me. | 20:11 |
| benji | abentley: sounds good, I'll change that; I'd like to keep the docstring though, I like that it provides both a justification for why the class exists and describes how it should be used. I often wish someone had written something like that when reading code. | 20:11 |
| abentley | benji: yes, I agree. | 20:11 |
| benji | cool | 20:12 |
| abentley | benji: You might want to update this page: https://dev.launchpad.net/Web/TemplateCodeReuse | 20:13 |
| benji | abentley: ooh, thanks | 20:14 |
| sinzui | jcsackett, mumble? | 20:45 |
| jcsackett | sinzui: sure, one moment. | 20:46 |
| === gary-lunch is now known as gary_poster | ||
| lifeless | allenap: hi | 21:11 |
| lifeless | allenap: I've commented on the review; I have to run now to a hospital visit; I hope I haven't been too brief with my description. | 21:14 |
| lifeless | allenap: if I have, please ask here or there and we can refine our understanding of whats going on | 21:14 |
| lifeless | ok, popping out to my monthly allergy injection, at l'hopital, back in ~ 3hr | 21:35 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
