| wallyworld | yep. sorry, bit slow on the uptake there. brain took a minute to context switch | 00:00 |
|---|---|---|
| sinzui | wgrant: mumble? | 00:03 |
| lifeless | anyone know if https://bugs.launchpad.net/launchpad/+bug/2810 is actually fixed now ? | 00:10 |
| _mup_ | Bug #2810: buildd <-> buildmaster protocol is undocumented <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/2810 > | 00:10 |
| LPCIBot | Project windmill build #220: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/220/ | 00:16 |
| jelmer | lifeless: that's a low bug number :) There wasn't anything like that when I was in the Soyuz team, if that's a useful data point. | 00:22 |
| lifeless | jelmer: thanks | 00:23 |
| lifeless | poolie: morning! you might like to do bug https://bugs.launchpad.net/launchpad/+bug/83928 yourself, given you know the ropes :) | 00:26 |
| _mup_ | Bug #83928: register launchpad url scheme <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/83928 > | 00:26 |
| poolie | hi lifeless | 00:26 |
| poolie | is it urgent? | 00:26 |
| poolie | oh, are you just reassigning tim's things? | 00:27 |
| sinzui | wallyworld: I am back | 00:27 |
| wallyworld | sinzui: ok | 00:27 |
| lifeless | poolie: I'm nuking the use of wishlist in the lp bugs db | 00:27 |
| poolie | benji: thanks for the mail refactoring review | 00:27 |
| benji | my pleasure | 00:27 |
| poolie | good | 00:30 |
| wgrant | NCommander: It will be implemented soon as part of the Derived Distros work. | 00:31 |
| NCommander | wgrant: handy, I was looking at LP and seems a far chunk was implemented since the last time I looked | 00:31 |
| wgrant | Yeah, some progress has been made. | 00:32 |
| lifeless | wgrant: https://bugs.launchpad.net/launchpad/+bug/2810 - has that changed recently? | 00:37 |
| _mup_ | Bug #2810: buildd <-> buildmaster protocol is undocumented <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/2810 > | 00:37 |
| wgrant | lifeless: No, it got even worse when I deleted the old docs (which were completely wrong, but still) | 00:37 |
| sinzui | wallyworld: lp:lp-production-crontabs/trunk | 00:37 |
| lifeless | hmm | 00:45 |
| lifeless | odd urlification here - https://bugs.launchpad.net/launchpad/+bug/409665/comments/2 | 00:45 |
| _mup_ | Bug #409665: reviews lose commit message context <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/409665 > | 00:45 |
| lifeless | see the 'lp)' | 00:45 |
| wgrant | Tags: lp-code | 00:46 |
| wgrant | Martin Pool wrote on 2007-02-08: #1 | 00:46 |
| wgrant | Oops. | 00:47 |
| poolie | ? | 00:49 |
| poolie | mispasted? | 00:49 |
| wgrant | Yes. | 00:50 |
| wgrant | StevenK: Does initialise-from-parent still work? | 01:03 |
| StevenK | It ought to. Why? | 01:03 |
| wgrant | Well, we sort of need it tomorrow. | 01:04 |
| wgrant | So it would be nice if it did. | 01:04 |
| wgrant | And a lot of that stuff has changed. | 01:04 |
| StevenK | wgrant: Trial run on DF? | 01:07 |
| wgrant | Might try that. | 01:08 |
| lifeless | wallyworld: ping | 01:11 |
| lifeless | re mp 58410 | 01:11 |
| wallyworld | lifeless: hi | 01:11 |
| lifeless | wallyworld: the permissions are per-project | 01:11 |
| lifeless | wallyworld: so I'm wondering why you say they don't need updating | 01:11 |
| wallyworld | lifeless: i wasn't aware of that. i'll recheck. i may need to change the xhr call as you said | 01:13 |
| lifeless | wallyworld: on https://bugs.launchpad.net/launchpad-project/+filebug | 01:13 |
| wallyworld | lifeless: the sample data used for testing is very limited so it was hard to get a full view as to what was updated when the project changed | 01:14 |
| lifeless | on dtdparser - submit something, expand extra options, no status/importance/assignee etc | 01:14 |
| lifeless | change the dropdown to lp | 01:14 |
| lifeless | same thing, but when extra options is expanded, all the fields are available | 01:15 |
| lifeless | wallyworld: sure, I'm giving you a demo is all | 01:15 |
| wallyworld | lifeless: ah, excellent. i really appreciate the input. tha's helps a lot | 01:15 |
| wallyworld | sinzui: ^^^^^ based on the above, i have some fixing to do before you finish the review. but you can always take an initial look | 01:17 |
| wgrant | I'm guessing nobody added the new prefixes. | 02:03 |
| wgrant | lifeless: Could you do that, with your newfound superpowers? | 02:03 |
| lifeless | they are already in the system | 02:05 |
| wgrant | We have very few OOPSes. | 02:05 |
| wgrant | Hm. | 02:05 |
| lifeless | \o/ | 02:05 |
| wgrant | Although at least 150 hwdb OOPSes are missing. | 02:05 |
| wgrant | And they're from loganberry... | 02:05 |
| StevenK | Haha. "That's a small number, so it can't be right." | 02:05 |
| wgrant | Or maybe they unbroke checkbox. | 02:05 |
| lifeless | diogo put A-Z into the system a while back | 02:05 |
| wgrant | Ah. | 02:06 |
| lifeless | I checked this yesterday :) | 02:06 |
| lifeless | and just now again to be sure | 02:06 |
| lifeless | wgrant: bug 770107 | 02:06 |
| wgrant | I assumed you would have, but the numbers were implausible. | 02:06 |
| _mup_ | Bug #770107: launchpad relies on login.ubuntu.com but does not sync email addresses <Launchpad itself:Triaged> < https://launchpad.net/bugs/770107 > | 02:06 |
| wgrant | Yes :( | 02:06 |
| lifeless | wgrant: I'm positive there is a bug about user confusion and login.launchpad.net | 02:06 |
| lifeless | neither sinzui nor I could find it yesterday | 02:06 |
| wgrant | There is, but I can never find it. | 02:06 |
| lifeless | grag | 02:07 |
| wgrant | I'm sure I've seen it. | 02:07 |
| wgrant | Has Google always mangled bug page titles? | 02:07 |
| wgrant | I don't recall seeing this before. | 02:07 |
| lifeless | ref ? | 02:08 |
| wgrant | Some of them are now "$SUMMARY - Launchpad Bugs" | 02:08 |
| wgrant | eg search for 'site:bugs.launchpad.net login.launchpad.net' | 02:08 |
| wgrant | Some of the results have the real titles, others don't. | 02:08 |
| lifeless | whee | 02:09 |
| wgrant | (not unreasonable, given our titles suck so much) | 02:09 |
| lifeless | I wonder if that will affect our google-api-search results | 02:10 |
| cody-somerville | hmm... is it known that if you expand a bug task for editing, the milestone field is set to '(no value)' instead of the milestone the task is currently assigned to if the milestone is deactivated? So if you go and edit a bug assigned to an old, deactivated milestone it'll remove it from the milestone and to fix it you have to go reactivate the milestone. total PITA | 02:13 |
| lifeless | cody-somerville: sounds like a bug | 02:14 |
| wgrant | lifeless: Ahem. | 02:18 |
| wgrant | rs = (store | 02:18 |
| wgrant | .find(FeatureFlag) | 02:18 |
| wgrant | .order_by( | 02:18 |
| wgrant | FeatureFlag.flag, | 02:18 |
| wgrant | FeatureFlag.scope, | 02:18 |
| wgrant | Desc(FeatureFlag.priority))) | 02:19 |
| wgrant | Spot the bug. | 02:19 |
| wgrant | This explains why none of the overrides are working. | 02:19 |
| StevenK | Hah | 02:19 |
| wgrant | So, we are *actually* running with a 9s timeout. | 02:20 |
| lifeless | wgrant: scope should be after priority | 02:20 |
| wgrant | Without exceptions. | 02:20 |
| wgrant | lifeless: Right. | 02:20 |
| lifeless | \o/ | 02:20 |
| lifeless | right, lets clean those out | 02:20 |
| lifeless | leave the rootlogin one behind | 02:20 |
| lifeless | but the rest are clearly tolerable | 02:20 |
| wgrant | I don't trust the OOPS counts, but yeah, we can add them back. | 02:20 |
| wgrant | 11:18:36 < lifeless> MTecknology: runs in a trusted context; not at all easy to change | 02:27 |
| wgrant | Huh? | 02:27 |
| * StevenK tries to remember the shell magic for 'show me everything that is in file1 that isn't in file2' | 02:30 | |
| StevenK | comm, I guess ... | 02:30 |
| StevenK | Argh, ENOSPONGE | 02:31 |
| lifeless | StevenK: diff ? | 02:32 |
| StevenK | Suppose | 02:32 |
| StevenK | comm did the job, so ... :-) | 02:32 |
| StevenK | And I've not used it for a while, so it's good to dust off the memory | 02:33 |
| MTecknology | so.. are recipes and packages not build in the same restrictive manner? | 02:36 |
| lifeless | MTecknology: not identical, no | 02:37 |
| wgrant | MTecknology: They are. | 02:37 |
| wgrant | Well, recipes are run outside the chroot, but that doesn't matter. | 02:37 |
| MTecknology | I just assumed they were so I didn't get why allowing recipes to run commands was dangerous - since deb/rules could easily be changed prior to an upload | 02:38 |
| StevenK | It isn't just debian/rules that's an issue | 02:40 |
| MTecknology | is debian/rules an issue? | 02:42 |
| StevenK | MTecknology: You just said 'since debian/rules could easily be changed prior to an upload' -- I think there are far more sinister things one could do if running external commands was allowed | 02:44 |
| MTecknology | StevenK: I just assumed you guys handle it if someone tried to do something in debian/rules; so I'm not understanding why recipes are different - or.. why they have to be so different that shell commands in there has to be so dangerous | 02:45 |
| cody-somerville | Recipe builds aren't executed in a fresh VM? | 02:45 |
| wgrant | cody-somerville: They are. | 02:45 |
| cody-somerville | So I guess I have the same question as MTecknology. | 02:46 |
| wgrant | Hmmmmm. | 02:53 |
| wgrant | lifeless: wgrant@carob:~/logs$ grep -l -r -e 'Exception-Type: \(LaunchpadTimeoutError\|RequestTimeout\)' */2011-04-26 | wc -l | 02:55 |
| wgrant | 452 | 02:55 |
| wgrant | * 228 Time Outs | 02:55 |
| wgrant | Does not compute. | 02:55 |
| lifeless | wgrant: I have a theory | 02:55 |
| wgrant | wgrant@carob:~/logs$ grep -l -r -e 'Exception-Type: SoftRequestTimeout' */2011-04-26 | wc -l | 02:55 |
| wgrant | 408 | 02:55 |
| wgrant | * 105 Soft Time Outs | 02:55 |
| wgrant | Computes even less. | 02:55 |
| lifeless | wgrant: histogram by machine? | 02:56 |
| wgrant | wgrant@carob:~/logs$ grep -l -r -e 'Exception-Type: SoftRequestTimeout' */2011-04-26 | cut -d/ -f1 | uniq -c | 02:56 |
| wgrant | 55 chaenomeles | 02:56 |
| wgrant | 63 gac | 02:56 |
| wgrant | 134 soybean | 02:56 |
| wgrant | 156 wampee | 02:56 |
| wgrant | (this is also only lpnet, not edge, so the numbers should be *lower*) | 02:57 |
| StevenK | But none of those can be combined to make 105 | 02:57 |
| wgrant | You are correct. | 02:58 |
| wgrant | Maybe with edge, though... | 02:58 |
| wgrant | Let me find the edge logs. | 02:58 |
| StevenK | As my father used to say, "He must have gone to a different school." | 02:58 |
| sinzui | /join #launchpad | 03:09 |
| wgrant | lifeless: /win 55 | 03:16 |
| wgrant | Argh. | 03:16 |
| lifeless | yes? | 03:17 |
| wgrant | lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-770576/+merge/59155 | 03:17 |
| lifeless | wgrant: why is FeatureFlag.scope still there? | 03:19 |
| lifeless | (flag, priority) is a unique | 03:20 |
| wgrant | True. | 03:20 |
| wgrant | Forgot that bit. | 03:20 |
| MTecknology | I wish I could understand what makes running commands in recipe builds dangerous... If it's a fresh vm and is basically (from what I can see), a locked down chroot; what makes that more insecure than upload builds where a person could put anything at all in debian/rules (with the exception that those uploads also provide an easy way to download packages [Build-Depends:]) | 03:21 |
| MTecknology | Sorry to be such a pain too... I just don't get it. :( | 03:21 |
| wgrant | MTecknology: It isn't dangerous. | 03:22 |
| wgrant | It's forbidden for other reasons. | 03:22 |
| wgrant | That are not entirely clear. | 03:22 |
| MTecknology | Is there any way to make those reasons more clear? | 03:23 |
| wgrant | I'm not sure. | 03:23 |
| wgrant | But still, you shouldn't have to run shell commands. | 03:23 |
| wgrant | Why do you want to? | 03:23 |
| MTecknology | https://code.launchpad.net/~nginx/+recipe/nginx-nightly | 03:23 |
| wgrant | That seems mildly insane. | 03:24 |
| MTecknology | indeed | 03:25 |
| wgrant | lifeless: That's fixed. | 03:30 |
| MTecknology | this is the recipe I'd like to use.. http://dpaste.com/536105/ | 03:33 |
| MTecknology | the nest-part only used because ..... i'd definitely do that part of the code differently | 03:37 |
| spiv | MTecknology: that strikes me as a kinda odd thing to want to do | 03:44 |
| MTecknology | spiv: changes is generated by hand on every release... about the only non-nest option would be with wget and that'd probably be an ugly option.. | 03:45 |
| spiv | MTecknology: I'm curious why the lp:nginx/stable branch isn't something that you could simply do a regular merge of, rather than picking just those files. | 03:45 |
| * spiv suddenly realises part of what this is trying to do | 03:46 | |
| MTecknology | spiv: because I want to make this something fully automated so I don't need to do a merge any time a branch changes | 03:47 |
| spiv | MTecknology: I'm not sure abusing nest-part to copy a file from a branch into a tree of the same branch is something we want to support | 03:47 |
| MTecknology | so far, it feels like recipes are pretty much worthless... | 03:47 |
| spiv | The point of the "merge" directive of recipes is exactly so that you don't need to do a merge yourself! | 03:48 |
| MTecknology | Why don't you tell me how I should do this so I set it up once and don't touch it again until a new stable exists? | 03:49 |
| StevenK | MTecknology: Then don't use them? | 03:49 |
| MTecknology | If I could just use 'run' then I wouldn't need to do the copy.. | 03:50 |
| StevenK | As in 'run wget' ? | 03:51 |
| MTecknology | 'run cp' | 03:51 |
| lifeless | MTecknology: why would you need to do a merge every time the branch changes ? | 03:53 |
| spiv | MTecknology: Perhaps this is a naïve question, but why not just use the files where they are, rather than cp'ing them? | 03:53 |
| MTecknology | when a version is released, there's a whole series of crap that takes place. Part of that is an auto tool that moves stuff around and compiles docs. the README file isn't just docs/text/README, if I could use run, I'd use cat and a redirection to actually build that file correctly. | 03:55 |
| MTecknology | but it's also not something the debian packaging should need to accomodate; because when a version is released, that stuff is in place | 03:56 |
| * spiv wonders if "nest-part deb lp:foo/debian debian; merge tweak-deb lp:foo/tweaked-debian" works (where lp:foo/tweaked-debian is a branch off lp:foo/debian)… | 03:56 | |
| spiv | So the problem is you want to use the debian packaging info designed for releases, but what you have are branches not releases, and these branches are almost but not quite laid out the same way? | 03:58 |
| MTecknology | yup | 03:59 |
| spiv | I'd probably try making a branch of the debian packaging then that accomodates those differences, and merge that in after the nest-part of the debian packaging branch. | 03:59 |
| spiv | I'm not sure if that would be too ugly. | 04:00 |
| MTecknology | would that work after things change in the packaging? | 04:01 |
| spiv | I can imagine a 'cp' or 'mv' directive in recipes being reasonable to add, but for this problem in general I don't think those would always be sufficient. | 04:01 |
| spiv | MTecknology: it should, if the changes inside debian/ don't conflict. | 04:02 |
| spiv | MTecknology: I'm not sure that it will work, but it ought to :) | 04:02 |
| MTecknology | so debian packaging is lp:nginx/debian and no debian/ dir; using nest it fits in just fine; the merge will need to be of the change, with a debian sub directory? | 04:03 |
| MTecknology | can I have just the debian/rules file in there? | 04:03 |
| lifeless | is there a sensible bugtracker for our moinmoin sites? https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/685482 | 04:03 |
| _mup_ | Bug #685482: Error logging in via launchpad openid to edit community wiki <openid> <Launchpad itself:New> <ubuntu-docs (Ubuntu):Incomplete> < https://launchpad.net/bugs/685482 > | 04:03 |
| === Ursinha is now known as Ursinha-afk | ||
| MTecknology | spiv: or would that probably not work? | 04:07 |
| spiv | MTecknology: just a branch of lp:nginx/debian with a change to its rules or whatever to do what you need | 04:10 |
| spiv | MTecknology: no renames of files in that branch or new directories, unless you really want to rename files in debian/ or make new directories in debian/ in the resulting recipe. | 04:11 |
| MTecknology | I meant- I was wondering if that branch could have only the changed files.. but i imagine not | 04:12 |
| MTecknology | then it'd be a crappy merge.. | 04:12 |
| spiv | MTecknology: right, just make the changes you need, and don't worry about the other files you don't need to change. | 04:13 |
| MTecknology | heh... | 04:13 |
| MTecknology | 'run make misc/GNUmakefile snapshot' | 04:14 |
| MTecknology | that'd be enough to replace all of this | 04:14 |
| StevenK | Then your rules file only needs one extra line | 04:14 |
| spiv | MTecknology: given that make rule does "svn export", probably not :) | 04:15 |
| MTecknology | well... I'd still need nest-part to work on files.. | 04:15 |
| MTecknology | ah.. missed that | 04:15 |
| spiv | I don't think "svn export . $(TEMP)/$(NGINX)" will work well in a bzr tree :) | 04:15 |
| MTecknology | probably not :P | 04:16 |
| spiv | ("bzr export . temp-dir" would work alright in an svn tree if you have bzr-svn installed, though ;) | 04:17 |
| MTecknology | doesn't that only eliminate the .SVN directories while copying to a new location? | 04:17 |
| spiv | And only copy versioned files, I'd expect | 04:19 |
| spiv | Which probably doesn't make a difference in a fresh tree. | 04:19 |
| MTecknology | I'm adding the extra stuff... setup: with setup added to .PHONY | 04:20 |
| MTecknology | looks like they actually did automate the release process, just too automated for a nightly snapshot liek this.. | 04:30 |
| LPCIBot | Project windmill build #221: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/221/ | 04:32 |
| MTecknology | now we see if it works.... | 04:34 |
| MTecknology | spiv: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 04:35 |
| MTecknology | it doesn't want to merge with the packaging branch, it wants to merge with the source branch | 04:36 |
| MTecknology | spiv: I 100% agree that nest-part shouldn't be used to copy files; but in this event, it doesn't seem to be possible | 04:40 |
| MTecknology | being unable to use run has kept me from using recipes other places too... | 04:40 |
| === jtv changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews | ||
| MTecknology | heck... even having to make the series stable is a work around hack that could be avoided by use of run.. | 04:43 |
| spiv | MTecknology: ah, of course, nest-part doesn't set a parent revision in the tree :( | 05:01 |
| spiv | MTecknology: I think that bzr-builder could be improved to make that case work | 05:01 |
| spiv | MTecknology: but that doesn't help you today, of course :/ | 05:01 |
| MTecknology | spiv: nah... I already accepted that it's not going to work today | 05:06 |
| MTecknology | probably not this week, or next month | 05:06 |
| MTecknology | but after that... i can hope :) | 05:06 |
| MTecknology | spiv: for a daily build.. this is probably the best option - http://dpaste.com/536138/ | 05:07 |
| spiv | MTecknology: one question I guess is why does upstream's vcs layout differ from the tarball layout like that. It seems a bit unnecessary. But how recipe builds can cope nicely with packaging designed for release tarballs rather than vcs snapshots is an interesting problem in general. | 05:12 |
| MTecknology | spiv: there's a makefil that makes the source ready for a release or snapshot - but it's not really feasible to try to call a makefile inside of a recipe - especially because they require other apps be installed | 05:14 |
| spiv | MTecknology: oh, one last trick | 05:27 |
| spiv | MTecknology: to workaround the “Branches have no common ancestor” | 05:27 |
| spiv | MTecknology: you could try appending something like "-2..-1" to merge line | 05:27 |
| MTecknology | hm? | 05:28 |
| spiv | This is for the "merge in a tweak to the debian/ dir added via nest-part" approach | 05:28 |
| MTecknology | what would the line look like for the merge? | 05:29 |
| spiv | What did you try that gave “Branches have no common ancestor…”? | 05:30 |
| spiv | I think just append “ -2..-1” for a crude workaround | 05:30 |
| spiv | (To say just take the changes in the newest revision of that branch) | 05:30 |
| spiv | So e.g. if you had “merge deb-tweak lp:blah/debian-tweaked" then “merge deb-tweak lp:blah/debian-tweaked -2..-1” | 05:31 |
| MTecknology | I had 'lp:nginx' 'nest packaging lp:nginx/debian debian' 'merge tweaks lp:nginx/debian-tweaks' | 05:33 |
| MTecknology | something close to that | 05:33 |
| spiv | Ok, so add ' -2..-1' to that tweaks line | 05:34 |
| MTecknology | k- i'll have to try that tomorrow.. it's getting too late for me | 05:34 |
| MTecknology | what's that do? | 05:35 |
| StevenK | Only merge changes from the latest revision | 05:35 |
| MTecknology | it was complaining about merging lp:nginx/debian-tweaks into lp:nginx | 05:35 |
| spiv | MTecknology: takes changes from the 2nd-last revision (-2) to the last revision (-1) | 05:36 |
| spiv | MTecknology: i.e. the changes in the most recent commit | 05:36 |
| spiv | MTecknology: It's actually merging into a tree, not a branch | 05:36 |
| spiv | MTecknology: a tree that already has the debian/ dir added | 05:37 |
| MTecknology | hm.. are commits made at every step of the recipe? | 05:37 |
| spiv | No, no commits at all | 05:37 |
| spiv | It's like using bzr merge --force, which allows doing a merge on a changed-but-uncommitted tree | 05:38 |
| MTecknology | oh | 05:39 |
| spiv | Hmm, you're using nest not nest-part to embed the debian/ dir, so really that merge ought to have just worked. I think I know why it didn't, I'll file a bug. | 05:40 |
| MTecknology | thanks, want to subscribe me to it? | 05:41 |
| wgrant | Bug #723417 | 05:44 |
| _mup_ | Bug #723417: Further information input area shrunk making it difficult to input and review details <bugs> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/723417 > | 05:44 |
| wgrant | 5 lines seems a bit short for most description fields. | 05:44 |
| wgrant | I think we should probably bump to 10/15. | 05:44 |
| wgrant | Any objections? | 05:44 |
| spiv | MTecknology: will do | 05:44 |
| wgrant | jtv: Hi. | 05:45 |
| MTecknology | spiv: thanks, i'm gonna try tofall asleep over the noise of my neighbors that need to be murdered.. | 05:45 |
| jtv | hi wgrant | 05:46 |
| wgrant | jtv: Nice short review for you: https://code.launchpad.net/~wgrant/launchpad/bug-751982/+merge/59162 | 05:46 |
| MTecknology | spiv: hopefully I wasn't too much of a pita | 05:46 |
| spiv | MTecknology: no, not at all | 05:47 |
| jtv | wgrant: I'm working on a big one, but if this one's short then I'll SJF. | 05:48 |
| wgrant | jtv: Diff against target:31 lines (+11/-0) 2 files modified | 05:50 |
| jtv | wgrant: that reply actually took longer than it did to read the diff. :) | 05:50 |
| jtv | wgrant: done | 05:52 |
| wgrant | Thanks. | 05:52 |
| spiv | MTecknology: oh, I'm being silly, merging into nested branches is already supported: | 05:57 |
| spiv | MTecknology: you just indent the 'merge' line under the 'nest' line. https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Nesting | 05:58 |
| MTecknology | heh... easy | 05:58 |
| MTecknology | makes sense too... | 05:58 |
| spiv | :) | 05:58 |
| MTecknology | I'll play with that tomorrow; then when the bug is taken care of, I should be able to make this work :) | 06:00 |
| MTecknology | although.. using 'run' would be a better solution to merging changes from another branch | 06:00 |
| MTecknology | but either way- it'd work :) | 06:01 |
| * MTecknology is going to sleep for real this time | 06:01 | |
| jtv | wgrant: I wonder if maybe you could review my branch for initializing distroseries indexes. The regular reviewer chickened out. | 06:31 |
| wgrant | jtv: So I saw. | 06:32 |
| wgrant | I will have a look. | 06:32 |
| jtv | Great, thanks. | 06:32 |
| jtv | He's right though: the reviewer I could otherwise get on my own squad hasn't just returned from two weeks' leave. Somehow that's not helping. :-) | 06:33 |
| wgrant | jtv: Reviewed. | 07:06 |
| wgrant | lifeless: Still around to mentor? | 07:06 |
| jtv | wgrant: that's fantastic, thanks. Didn't expect it so soon. | 07:07 |
| lifeless | fsvo | 07:07 |
| lifeless | I'm trying to finish these triggers off | 07:07 |
| lifeless | which is tricky | 07:07 |
| wgrant | Ah, right. | 07:07 |
| wgrant | Fun fun. | 07:07 |
| lifeless | so if its non trivial, not tonight. | 07:08 |
| wgrant | Sure. | 07:08 |
| wgrant | lifeless: Bug #771527 | 07:09 |
| _mup_ | Bug #771527: 'Answers' link greyed out on Ubuntu nattry translation page <Launchpad itself:Triaged> < https://launchpad.net/bugs/771527 > | 07:09 |
| wgrant | lifeless: DistroSerieses don't have Answers. | 07:09 |
| lifeless | wgrant: but distros do | 07:11 |
| wgrant | Sure. | 07:11 |
| lifeless | wgrant: so the link can sensibly and trivially go to the distro answers | 07:12 |
| wgrant | The header is already confusing enough :( | 07:12 |
| === almaisan-away is now known as al-maisan | ||
| StevenK | jtv: https://code.launchpad.net/~stevenk/launchpad/pdsd-cleanup/+merge/59172 when you're able | 07:46 |
| jtv | StevenK: up to my ears atm... maybe in half an hour? | 07:47 |
| StevenK | jtv: At some point before you EOD is perfectly fine. | 07:47 |
| jtv | StevenK: got you scribbled down. | 07:49 |
| jtv | Jotted. That's the word I was looking for. | 07:51 |
| wgrant | lifeless: Hi. | 08:22 |
| StevenK | jtv: I note it's been 45 minutes. | 08:31 |
| jtv | StevenK: I meant remind me in 30. :) I'll start right now. | 08:32 |
| jtv | StevenK: "don't have any special fields set" is a bit weird as a requirement... how about "don't have their details filled out"? | 08:33 |
| jtv | StevenK: reviewed. | 08:34 |
| StevenK | jtv: Thanks for the +1, I'll take your suggested wording | 08:35 |
| jtv | Cool. | 08:35 |
| lifeless | wgrant: hi | 08:36 |
| wgrant | lifeless: 11634.2.9 | 08:37 |
| jtv | wgrant: in your review of my branch, you say to say "careful indices mode." I note that the actual script doesn't have such a thing... shall I add the wording to the run_publisher option? | 08:37 |
| wgrant | lib/lp/bugs/model/bug.py | 08:37 |
| wgrant | lifeless: Second hunk of lib/lp/bugs/model/bug.py | 08:37 |
| wgrant | lifeless: Any ideas why you changed that? | 08:37 |
| lifeless | wgrant: isn't that just the bottom of linkAttachment ? | 08:40 |
| wgrant | lifeless: Yes, I am a fool. I mean lib/lp/bugs/browser/bugtarget.py instead. | 08:41 |
| lifeless | wgrant: + :param send_notifications: Control sending of notifications for this | 08:41 |
| lifeless | + attachment. This is disabled when adding attachments from 'extra | 08:41 |
| lifeless | + data' in the filebug form, because that triggered hundreds of DB | 08:41 |
| lifeless | + inserts and thus timeouts. Defaults to sending notifications. | 08:41 |
| wgrant | Well, *that*'s not in the commit message. | 08:42 |
| wgrant | I see. | 08:42 |
| lifeless | wgrant: so I think I had a dirty branch | 08:42 |
| wgrant | jtv: -A is careful indices. | 08:42 |
| jtv | wgrant: it'd be nice if the script called it that then! | 08:43 |
| wgrant | jtv: -P is careful file publishing, -A is careful index publishing -SOMETHING is careful domination, -C is all of the above. | 08:43 |
| lifeless | wgrant: but yeah the motivation was to stop sending a notification-per-attachment in apport bug filings | 08:43 |
| lifeless | wgrant: if it was a dirty branch this may have only been half realised | 08:43 |
| wgrant | lifeless: We have a critical regression bug on that now :( | 08:43 |
| jtv | wgrant: the script currently calls it "careful apt" and says it makes the apt-ftparchive run careful. | 08:44 |
| lifeless | wgrant: #? | 08:44 |
| wgrant | lifeless: Bug #667604 | 08:44 |
| _mup_ | Bug #667604: new bug reports with attachments added generate blank email instead of including links to attachments <lp-bugs> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/667604 > | 08:44 |
| wgrant | jtv: Right, and apt-ftparchive generates the indices. | 08:44 |
| wgrant | jtv: (it's still a bit wrong now, since NMAF is also an option) | 08:44 |
| jtv | NM? | 08:45 |
| wgrant | NoMoreAptFtparchive. | 08:45 |
| wgrant | Native index generation. | 08:45 |
| jtv | Argh that | 08:45 |
| jtv | Looks to me like it should be hidden in the publisher TBH | 08:45 |
| wgrant | It is. | 08:45 |
| wgrant | The docs of -A are wrong. | 08:45 |
| lifeless | wgrant: so, sucky fail. | 08:45 |
| wgrant | It will trigger index publication regardless of the used mechanism. | 08:46 |
| lifeless | wgrant: but yes, reverting that would just break apport bug filing | 08:46 |
| jtv | wgrant: I have no idea what that means, but it's obvious to me that it needs some updating. | 08:46 |
| lifeless | wgrant: you bisected to that rev? | 08:46 |
| wgrant | jtv: Index generation uses either a-f or NMAF. -A will trigger whichever one is appropriate, despite its description referring solely to a-f. | 08:46 |
| wgrant | lifeless: annotated to it. | 08:47 |
| lifeless | wgrant: I don't understand why it doesn't generate a notitifcation with the summary and description | 08:47 |
| wgrant | lifeless: Hm? | 08:47 |
| lifeless | wgrant: this doesn't suppress notifications for the bug/task creation | 08:47 |
| lifeless | wgrant: and is (IIRC) only in the apport bug filing form. | 08:47 |
| wgrant | lifeless: Two emails are sent. | 08:48 |
| wgrant | lifeless: One about the bug filing. | 08:48 |
| wgrant | And one about the subsequent comment and attachments. | 08:48 |
| lifeless | wgrant: oh and a stupid empty one ? | 08:48 |
| wgrant | Except the comment is empty, and the attachment notifications are suppressed. | 08:48 |
| wgrant | Right. | 08:48 |
| wgrant | I guess we could just suppress that email, but it would be nice to unbreak notifications. | 08:48 |
| lifeless | so, two bugs; shouldn't send mail if there is nothing to say. And separately tell folk about the attachments. | 08:48 |
| lifeless | I was intending to aggregate the warnings or something I think | 08:49 |
| lifeless | but the problem is that we use a bloody pub-sub mechanism for sending mail about bugs | 08:49 |
| jtv | wgrant: thanks for clarifying that. I'll update the help string. What I meant earlier is that the decision which index generation method to call looks as if it should be hidden inside a single method call. | 08:49 |
| wgrant | jtv: It is. | 08:49 |
| lifeless | which is a totally fine system *if* you have enough granular control | 08:49 |
| wgrant | lifeless: Yeah, ideally it would queue subscribers, I guess. | 08:49 |
| wgrant | Or queue the inerts. | 08:49 |
| lifeless | wgrant: IIRC this was when we had 17 second bug filings. | 08:50 |
| wgrant | Yeah. | 08:50 |
| wgrant | i recall. | 08:50 |
| wgrant | I just didn't see any relevant commits. | 08:50 |
| wgrant | And indeed there were not any :P | 08:50 |
| lifeless | yeah, sucks to be working with me :) | 08:50 |
| jtv | wgrant: not the way I mean -- I'm talking about the "if ...: publisher.C_doAptFTPArchive(...) ; else: publisher.C_writeIndexes(...) | 08:51 |
| wgrant | jtv: Ah, right. | 08:51 |
| wgrant | jtv: Well, it is encapsulated. At the wrong level, but meh. | 08:51 |
| jtv | shudder. | 08:51 |
| wgrant | This. Is. SOYUZ. and all that. | 08:51 |
| jtv | I noticed. | 08:51 |
| adeuring | good morning | 09:02 |
| LPCIBot | Project windmill build #222: STILL FAILING in 1 hr 13 min: https://lpci.wedontsleep.org/job/windmill/222/ | 09:12 |
| lifeless | stub: evening | 09:19 |
| stub | Morning | 09:20 |
| stub | I forgot I had to do a Visa run, so just back from Cambodia. | 09:20 |
| jtv | hey stub, all sorted? | 09:21 |
| jtv | Presumably you are now registered on both sides as a spy. | 09:21 |
| stub | Yup. new stamp | 09:21 |
| stub | Nah... at Poipet it would be compulsive gambler. Spys cross at Si Saket and now Surin. | 09:22 |
| jtv | Note the pattern by the way: the fighting starts in response to "possible" action from somewhere in the middle (last year the sound of smallarms fire, this year a flare)... around Chinese New Year. | 09:22 |
| jtv | Ah yes, I forgot about the spies who were actually caught. | 09:22 |
| lifeless | stub: I'm too lazy to do a trial run | 09:22 |
| lifeless | stub: what happens if you specify a row in an update WHERE clause and both the row and the constraint are NULL | 09:23 |
| lifeless | e.g. update bugsummary where .... and product=NULL and productseries=NULL | 09:23 |
| lifeless | stub: I'm guessing because null!=null it will update no rows. | 09:23 |
| jtv | stub: I think there's probably a single kid unknowingly starting wars every year by lighting fireworks outside his house. | 09:23 |
| stub | Nothing happens, because NULL=anything == NULL | 09:24 |
| stub | And null is equivalent to false when you end up with that in the WHERE clause. | 09:24 |
| jtv | lifeless: how can you update a null row? | 09:24 |
| lifeless | jtv: there is a row identified by a tuple (product, productseries, distro, distroseries, viewed_by, status, tag, milestone) | 09:25 |
| jtv | Nice key! | 09:25 |
| lifeless | jtv: adapting an UPSERT function for it, and of those tuples all but status are permitted to be NULL | 09:25 |
| stub | Unfortunately it isn't a key ;) | 09:26 |
| lifeless | if we coalesce them with -1 | 09:26 |
| lifeless | we could make it a key | 09:26 |
| lifeless | stub: so I had a ratsnest day | 09:27 |
| lifeless | stub: I've got the basic structure for triggers sketched | 09:27 |
| jtv | wgrant: don't know if I got around to mentioning it... followed up to your review. Now to find a mentor. | 09:28 |
| jtv | hey bigjools! | 09:28 |
| * bigjools is not really here | 09:28 | |
| jtv | good | 09:29 |
| wgrant | Morning bigjools. | 09:29 |
| wgrant | jtv: Let's see. | 09:29 |
| bigjools | hello wgrant | 09:29 |
| * stub pulls lifeless' branch | 09:31 | |
| wgrant | jtv: Looks good. And I agree with DISTROSERIES. | 09:33 |
| lifeless | stub: I've just pushed another rev | 09:36 |
| lifeless | stub: adding the sketched upsert and decrement functions | 09:37 |
| lifeless | stub: remaining bits are | 09:37 |
| lifeless | - tests | 09:37 |
| lifeless | - upsert handling for nulls | 09:37 |
| * stub pulls it again | 09:37 | |
| lifeless | - generating the vector of rows to increment or decrement in the various cases | 09:37 |
| stub | lifeless: I can fill in the blanks in the _inc and _dec methods easily enough | 09:41 |
| lifeless | stub: its late here, but I'm guessing you'd have to reengineer the bugs of the other functions. If I put some prose in them would that help with that process? | 09:42 |
| stub | And reasonably sure what needs to go into the other stubs | 09:42 |
| lifeless | s/bugs/guts/ | 09:42 |
| stub | Prose is good if you have time - no need to assume | 09:42 |
| lifeless | I'll do that now | 09:42 |
| stub | k | 09:43 |
| stub | My DB script is up for review so I can work on this now. | 09:43 |
| lifeless | stub: its reviewed | 09:44 |
| mrevell | Hello | 09:44 |
| stub | Just saw that | 09:44 |
| lifeless | stub: pushing | 09:59 |
| lifeless | stub: ok its up there | 10:00 |
| * stub pulls | 10:00 | |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| stub | jtv: I found a B250 tablet pc cover that makes a great Kindle cover in Fortune. I need to pick up another one for Kirsten - do you want one too? | 10:11 |
| jtv | stub: sure, thanks | 10:11 |
| jtv | wgrant: any objections on your end to my running populate-dsd on df's maverick? | 10:15 |
| stub | mthaddon: Just landing https://code.launchpad.net/~stub/launchpad/db-deploy/+merge/59065 | 10:17 |
| stub | mthaddon: This should improve Launchpad DB updates. | 10:17 |
| mthaddon | interesting... | 10:18 |
| stub | mthaddon: The preflight.py script does the painful checks for long running transactions, replication lag, sync working etc. for you. The full-update.py is just a wrapper around the 4 update scripts to run them in sequence for faster turnaround. | 10:18 |
| mthaddon | "One of the checks it makes is to confirm there are no non-system connections open to the active databases" \o/ | 10:18 |
| mthaddon | stub: how does full-update.py handle logging? we'd just output the logs for that to a single logfile rather than having separate logs for each step? | 10:19 |
| stub | mthaddon: Yes, it will log all the steps to a single log file. | 10:20 |
| mthaddon | k | 10:20 |
| lifeless | mthaddon: stub: there is an RT open to kill everything properly on staging | 10:20 |
| jtv | Any reviewers here who could mentor this review by wgrant? https://code.launchpad.net/~jtv/launchpad/db-bug-766807/+merge/59027 | 10:23 |
| wgrant | jtv: We tend to do that on staging now, but sure. | 10:27 |
| wgrant | jtv: Hmm. | 10:27 |
| wgrant | jtv: Although it's not going to work really well on DF. | 10:27 |
| jtv | Hmm? | 10:27 |
| wgrant | jtv: Since it doesn't have all the changelogs. | 10:27 |
| jtv | What isn't? | 10:27 |
| wgrant | populate-dsd | 10:27 |
| jtv | ah | 10:27 |
| wgrant | staging's all fine in that regard. | 10:27 |
| jtv | OK | 10:27 |
| wgrant | I'd suggest running it there, unless you have a good reason to not. | 10:27 |
| jtv | May be faster as well. | 10:27 |
| wgrant | Myes. | 10:27 |
| jtv | DB access. :) | 10:27 |
| wgrant | Yeah. | 10:28 |
| jtv | And most of all perhaps, less pain from figuring out whether it has your change or not! | 10:29 |
| wgrant | My change? | 10:30 |
| wgrant | Or perhaps your change. | 10:30 |
| wgrant | But staging should be rather up to date. | 10:30 |
| wgrant | Given that we are coming from a drought of failures. | 10:31 |
| wgrant | In fact we've not had a test failure in a week! | 10:32 |
| wgrant | This is unprecedented. | 10:32 |
| spiv | wgrant: it's an Easter miracle! | 10:35 |
| wgrant | spiv: Shh, don't spoil it. | 10:36 |
| === al-maisan is now known as almaisan-away | ||
| === Ursinha-afk is now known as Ursinha | ||
| LPCIBot | Project windmill build #223: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/223/ | 11:47 |
| jtv | wgrant: pushing fix, and thou-sands of bytes per second | 11:50 |
| === almaisan-away is now known as al-maisan | ||
| deryck | Morning, all. | 12:09 |
| jtv | hi deryck! Approved your branch. | 12:15 |
| deryck | jtv, hi. I had something up for review? | 12:16 |
| jtv | Any takes for a very simple review? https://code.launchpad.net/~jtv/launchpad/db-bug-771727/+merge/59203 | 12:17 |
| jtv | *takers | 12:17 |
| jtv | deryck: oops no, not you sorry | 12:20 |
| deryck | no worries | 12:21 |
| jtv | I'm in a jostling car on a 2G connection and it's distracting! | 12:21 |
| jtv | Reviewer needed! https://code.launchpad.net/~jtv/launchpad/db-bug-771727/+merge/59203 | 12:24 |
| jtv | Review mentor needed: https://code.launchpad.net/~jtv/launchpad/db-bug-766807/+merge/59027 - any takers? | 12:29 |
| === mrevell is now known as mrevell-lunch | ||
| gary_poster | stub, hey. I ran ec2 test on my branch and there is some code cleanup I need to try to do from fallout of those new constraints (particularly the unique index, it seems)...*if* we actually make those changes. Is it worth my time to try to clean things up, or should I wait for your review to see if I actually need to go another entirely different direction? | 12:57 |
| gary_poster | (This is re https://code.launchpad.net/~gary/launchpad/bug753000/+merge/59139) | 13:00 |
| stub | gary_poster: I need to rework your constraints. We should be using partial unique indexes to avoid NULL issues. | 13:14 |
| stub | gary_poster: So CREATE UNIQUE INDEX structuralsubscription__product__subscriber__key ON StructuralSubscription(product, subscriber) WHERE product IS NOT NULL | 13:16 |
| gary_poster | stub, ok, cool. I'd love to understand why (I thought constraints didn't have NULL issues since NULLs are considered non-equivalent) but understand if you don't have time | 13:17 |
| gary_poster | stub, and does that mean that my one UNIQUE INDEX I have already is OK, so I can fix code bugs related to it? | 13:17 |
| stub | gary_poster: it minimizes the size of the index. I think you are correct though that the indexes work as expected in this case. | 13:17 |
| gary_poster | stub, ah! I see | 13:17 |
| stub | So I would consider splitting that into two - one WHERE sourcepackagename IS NULL and another WHERE sourcepackagename IS NOT NULL | 13:18 |
| stub | But you can argue for your syntax too... | 13:18 |
| gary_poster | stub, I don't really care :-P | 13:18 |
| gary_poster | whichever you prefer is cool by me | 13:19 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews | ||
| adeuring1 | danilos: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-277118/+merge/59194 ? | 13:25 |
| danilos | adeuring1, sure thing, I'll do it after my call | 13:26 |
| adeuring1 | danilos: thanks! | 13:26 |
| === adeuring1 is now known as adeuring | ||
| stub | gary_poster: I think the new 'windowing function' stuff in 8.4 could make those deletions nicer, but no point changing what we have already if it is fast enough (should be - we don't have that many dupes) | 13:31 |
| gary_poster | stub, sounds cool, but yeah, the dupes are few | 13:32 |
| danilos | adeuring, hum, shouldn't the copyright be updated to state both years? eg. "2009, 2011" or "2009-2011" | 13:43 |
| adeuring | danilos: really? I thought we just mentioned tzhe year of the last change. But I am not 100% sure | 13:44 |
| === mrevell-lunch is now known as mrevlel | ||
| danilos | adeuring, that would be very weird, I've never seen it done like that as far as copyrights go (they should be the years of content creation) | 13:45 |
| * gary_poster wonders who mrevlel is and what he did with mrevell | 13:45 | |
| mrevlel | heh, I'm the bizarro mrevell | 13:45 |
| adeuring | danilos: ok, I'll change it | 13:45 |
| === mrevlel is now known as mrevell | ||
| danilos | gary_poster, that's called improvement (or evolution) | 13:45 |
| danilos | adeuring, thanks :) | 13:45 |
| gary_poster | :-) | 13:45 |
| danilos | adeuring, hum, dsp_url was not used anywhere at all? | 13:46 |
| adeuring | danilos: yes, lint reminded me about it | 13:46 |
| danilos | adeuring, cool | 13:46 |
| danilos | adeuring, I like the "no_bug_racking" test, but it still looks like a typo ;) | 13:47 |
| adeuring | danilos: argh... I'll fix it | 13:47 |
| danilos | adeuring, all else good, r=me | 13:48 |
| adeuring | danilos: cool, thanks. Just one question: I can't find "no_bug_racking" -- typo on your side? | 13:49 |
| danilos | adeuring, sorry, "bugracking", line ~108 of the diff | 13:49 |
| adeuring | danilos: ah, right! thanks again | 13:50 |
| danilos | adeuring, yw | 13:50 |
| stub | gary_poster: The 'subscriber IS NOT NULL' in the WHERE clause of the partial index was unnecessary as the column is NOT NULL (but I'm reworking it anyway, so don't mess with your copy) | 13:50 |
| gary_poster | stub, ack, thanks | 13:51 |
| stub | gary_poster: So you can't subscribe to a (distroseries, sourcepackagename) ? | 13:51 |
| gary_poster | stub, not ATM, according to the code patterns I'm looking at in structuralsubscription.py. Robert says we want to support this eventually, and I filed a bug for it, but AFAIK what I said is right. That said, I'm fine with the constraint allowing it now | 13:53 |
| === benji is now known as Guest41434 | ||
| stub | gary_poster: We allow people to be subscribed to a (distribution) as well as a (distribution, sourcepackagename) ? | 13:59 |
| gary_poster | stub, yes, the first is a subscription to an entire distribution; the second is a subscription to a package in that distribution. | 13:59 |
| stub | So the second is redundant, or can it have different settings? | 14:00 |
| stub | (or different notifications) | 14:00 |
| gary_poster | stub, it could have different settings | 14:00 |
| === benji____ is now known as benji | ||
| * coffeedude waves to deryck | 14:02 | |
| * deryck waves back | 14:02 | |
| stub | gary_poster: Reviewed. I think we need a BugTarget - this multiplexing of targets is irritating (lifeless has a patch like this too) | 14:06 |
| gary_poster | stub, thank you very much. Wouldn't a BugTarget have the same problem, just abstracted away one layer? It would only seem to be a win if we could share that abstraction across many uses--is that what you mean? I've wanted a way to reference targets generally in the past (Zope ObjectId sort of thing) so that would be cool. | 14:09 |
| deryck | so has *anyone* got Windmill running on Natty? maybe sinzui or wgrant? | 14:15 |
| deryck | with FF 4, I mean. | 14:15 |
| LPCIBot | Project windmill build #224: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/224/ | 14:17 |
| wgrant | deryck: wallyworld is the only success story I've heard of. | 14:19 |
| deryck | wgrant, ok, thanks. I'll just mail him then. | 14:19 |
| deryck | it's fixed in Windmill trunk, but I really don't want to upgrade windmill again at this point. | 14:20 |
| wallyworld | deryck: you need to create a symlink from something like /usr/lib/mozilla to the ff rofile | 14:20 |
| wallyworld | profile | 14:21 |
| wallyworld | let me find the exact details | 14:21 |
| deryck | hey there's wallyworld! | 14:21 |
| wallyworld | hiya | 14:21 |
| deryck | You Australians never sleep. | 14:21 |
| wallyworld | deryck: gotta get this %@%^!^ branch finished | 14:22 |
| deryck | ah, the love of the painful branch | 14:24 |
| deryck | I symlinked to FF 3 but still get "no local or global profile" or whatever the ff 4 error is. | 14:24 |
| deryck | wallyworld, ^^ | 14:24 |
| stub | gary_poster: Same problem, but in one place. | 14:24 |
| wallyworld | deryck: yeah, still looking trying to find what i did. one sec | 14:25 |
| gary_poster | stub, yeah, sounds good if it can be shared | 14:25 |
| stub | gary_poster: rather than the same problem, all over the place. | 14:25 |
| gary_poster | :-) | 14:25 |
| deryck | wallyworld, no worries. Thanks for the help! | 14:25 |
| wallyworld | deryck: make a directory /opt/firefox/defaults | 14:29 |
| wallyworld | deryck: then inside that dir symlink profile ->/etc/firefox/profile | 14:30 |
| wallyworld | deryck: i can't recall if ff4 puts that profile dir in /etc/firefox/profile or if i just copied a profile dir there | 14:30 |
| wallyworld | deryck: the windmill global_settings.py file looks for the profile dir in well known locations. /opt/firefox is the first place it tries | 14:31 |
| deryck | wallyworld, ok, thanks man. trying now..... | 14:31 |
| wallyworld | deryck: the tests pass except for a couple which rely on onkeyup handlers to do some work. these are never invoked | 14:32 |
| wallyworld | deryck: maybe fixed in trunk? i did try trunk a few weeks back and had no luck | 14:33 |
| jcsackett | danilos: any chance i could get a review on https://code.launchpad.net/~jcsackett/launchpad/comment-display-rules-questions/+merge/59104? | 14:34 |
| deryck | wallyworld, it is fixed in trunk. I saw the commit message. uses a different mechanism to create the windmill profile now. | 14:34 |
| wallyworld | deryck: i hadn't documented my workround since i was still experimenting and i thought it would be best to upgrade to trunk before natty released and save a lot of stuffing around | 14:34 |
| danilos | jcsackett, there is _some_ chance, let me calculate what it is for you :) | 14:34 |
| wallyworld | deryck: the startup maybe but not sure about the failing tests | 14:34 |
| jcsackett | danilos: anything greater than 50% works for me. :-) | 14:34 |
| danilos | jcsackett, I'll be back in 32h with the chance value :) | 14:34 |
| * jcsackett laughs. | 14:35 | |
| deryck | wallyworld, right | 14:35 |
| deryck | wallyworld, and we really need to decide if we fix windmill or move forward with something else. I'm honestly not sure at this point. | 14:36 |
| danilos | jcsackett, reviewing (fwiw :)) | 14:36 |
| jcsackett | danilos: thanks. :-) | 14:36 |
| wallyworld | deryck: pain either way. but we need the tests to stop bas shit reaching prod. surely it would be easier to tweak windmill than porting a shit load of tests to something else? | 14:37 |
| danilos | jcsackett, if the typos in the MP are to prove that a reviewer has read the MP, I did :) | 14:38 |
| deryck | wallyworld, yes, it is easier. definitely. but we've been doing this "crap it breaks, fix it" dance for two years now. At some point we have to move off, I think. | 14:38 |
| jcsackett | danilos: no, i can say with certainty the typos are to prove that i shouldn't code without ample supplies of coffee. :-) | 14:39 |
| deryck | wallyworld, but maybe not. maybe this is the last fix to it and it's stable going forward ;) | 14:39 |
| danilos | jcsackett, a question, we are not batching (visible) messages anywhere? | 14:39 |
| jcsackett | danilos: nope, prior to the visible_messages thing i added, we were just grabbing question.messages and rendering. | 14:40 |
| jcsackett | at least, i didn't see us doing anything else with them. | 14:40 |
| danilos | jcsackett, cool | 14:40 |
| danilos | jcsackett, just making sure we don't prefetch all messages if we only need a single batch of them, all is fine :) | 14:41 |
| wallyworld | deryck: we can only hope. maybe fix it and do a proof of concept with something else so we can move if/when it breaks again | 14:41 |
| jcsackett | danilos: actually, that reminds me that lifeless asked me to file a bug regarding some inefficiencies in both question and bug messages. | 14:41 |
| * jcsackett goes to file bug | 14:41 | |
| deryck | wallyworld, yeah, I think that's the right way. get it working now. but I would tweak that to say, proof to decide how to move off and plan to move, rather than wait til it break again. | 14:41 |
| deryck | wallyworld, I have some ideas about what is better actually. but we can take that up later. I'll let you get back to that branch you love :-) | 14:42 |
| wallyworld | deryck: yes, agreed. bad phrasing on my part | 14:42 |
| deryck | gotcha | 14:42 |
| rvba | danilos: Hi, could you take a look at this https://code.launchpad.net/~rvb/launchpad/dsd-api-bug-766158/+merge/59186 ? | 14:44 |
| danilos | jcsackett, r=me | 14:44 |
| danilos | rvba, sure thing :) | 14:45 |
| rvba | danilos: thanks. | 14:46 |
| jcsackett | danilos: thanks! | 14:46 |
| danilos | rvba, btw, perhaps you should have proposed the branch to be merged into devel/db-devel (whatever the target is) and used Steve's branch as a pre-requisite branch (there's a hidden option for that) | 14:46 |
| danilos | rvba, (mentioning this if you are unaware of it :)) | 14:47 |
| rvba | danilos: I'm not aware of this :) | 14:47 |
| rvba | danilos: ho ... wait, yes I am ... | 14:47 |
| rvba | danilos: let me correct that ... | 14:47 |
| danilos | rvba, heh, ok, so when you go to file a MP through the web UI, there's "extra options" or something, and you can put a prereq branch there as well | 14:47 |
| danilos | rvba, don't worry about it, it's just that MP won't show conflicts or such that might appear with the real target branch | 14:48 |
| danilos | rvba, (you can't change it once MP is up, so you'd have to create a new one I think) | 14:48 |
| rvba | danilos: yeah, looks like it ... | 14:48 |
| * rvba creates a new mp | 14:49 | |
| jelmer | "Resubmit this MP" allows you to create a new one based on the old one without having to discard comments, description, etc. | 14:50 |
| rvba | danilos: steven's branch targets db-devel but mine does not involves modifications to the db ... is that possible for me to target devel? | 14:51 |
| deryck | wallyworld, I got it working, thanks! I had downloaded ff 3, so had to link into that download dir, not /etc/, but otherwise worked fine. | 14:51 |
| danilos | rvba, btw, any reason you are not using assertContentEqual in assertSameDiffs? | 14:52 |
| rvba | jelmer: thans, I'll keep that in mind for next time (I already deleted my mp) | 14:52 |
| deryck | wallyworld, Now I can work on fixing windmill in my copious free time. :-) | 14:52 |
| danilos | rvba, it's possible, but the correct thing would be to target it to db-devel as well | 14:52 |
| rvba | danilos: ok | 14:52 |
| rvba | danilos: you're right, it probably could use assertContentEqual | 14:52 |
| wallyworld | deryck: excellent that it works. i know what you mean about free time. sure it's not worth seeing if trunk is any good? | 14:53 |
| danilos | rvba, you can at least get rid of the sorted() calls | 14:53 |
| rvba | danilos: that's right. Here is the new mp https://code.launchpad.net/~rvb/launchpad/dsd-api-bug-766158/+merge/59227 | 14:53 |
| deryck | wallyworld, oh, sure. I'd probably do that first. I have a patch in my branch that has to be applied, unless that is fixed now, too. | 14:53 |
| * deryck doesn't recall what the patch fixed now, though | 14:54 | |
| danilos | rvba, cool, will be commenting there | 14:54 |
| danilos | rvba, another tiny bit in that first test in the diff: "ds_diff_ws" should probably be "ds_ws" or "derived_ds_ws" | 14:55 |
| rvba | danilos: well spotted :) | 14:56 |
| danilos | rvba, shouldn't difference_type and status be `Choice`s instead of `TextLine`s? and child_version_higher could probably be a `Bool` | 15:01 |
| danilos | rvba, fwiw, I am not completely sure how important it is to be precise with operation_parameters, but when it's not hard, I'd go for it :) | 15:02 |
| danilos | rvba, and parent_series could probably be more specific as well (all in interfaces/distroseries.py) | 15:02 |
| rvba | danilos: you're definitely right. | 15:03 |
| rvba | danilos: I guess I was a little bit too quick to submit this one :) | 15:03 |
| danilos | rvba, well, considering the tests pass, this seems to be mostly related to annotations for wadl file generation, so probably not a big deal :) | 15:04 |
| rvba | danilos: yes, but the test is pretty minimal. I was advised not to duplicate all the tests for the api version of a function that is tested extensively elsewhere. | 15:06 |
| deryck | henninge, oops, I suck. I forgot our call. Two minutes to warm coffee and then meet you in mumble? | 15:06 |
| rvba | danilos: perhaps I could add one more test with parameters. Not to test the behaviour itself but parameter passing. | 15:07 |
| danilos | rvba, btw, you _do_ have a conflict now (line ~306) | 15:07 |
| danilos | rvba, yeah, that'd probably be good | 15:08 |
| rvba | danilos: this conflict just appeared! | 15:08 |
| rvba | easy to fix though. | 15:09 |
| danilos | rvba, yeah, though note that once you merge db-devel, your diff between Steve's branch will grow until he merges db-devel as well | 15:09 |
| rvba | danilos: right | 15:10 |
| danilos | rvba, marked it as needs-fixing (added a comment about what we discussed here, and one whitespace-in-a-string issue I noticed which I don't care about too much :) | 15:13 |
| rvba | danilos: thanks a lot for the review! | 15:14 |
| danilos | rvba, you are welcome, I'll be going off OCR now, but if you get this done in <1h, I might have a time to look at it again, so just ping me | 15:14 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| rvba | danilos: all right ... for the whitespace issue: if you took to time to mention it, I'll take the time to fix it :) | 15:15 |
| danilos | rvba, heh, thanks | 15:16 |
| === al-maisan is now known as almaisan-away | ||
| deryck | henninge, connection troubles? Shall we chat now? | 15:23 |
| === deryck is now known as deryck[lunch] | ||
| henninge | sinzui: Hi! | 16:21 |
| sinzui | hi henninge | 16:27 |
| henninge | sinzui: I want to move Authorization into lp.app.authorizationbase because I want to add a unit test and do not want to add a file to canonical.launchpad. | 16:29 |
| henninge | sinzui: would you agree with that course? | 16:29 |
| henninge | sinzui: sorry "AuthorizationBase" | 16:30 |
| henninge | sinzui: I am still wondering where IAuthorization should go in that case ... | 16:30 |
| sinzui | henninge: other apps have their ow security.py. I think I would expect to see the classes that I extend to be in the same module name | 16:31 |
| sinzui | eg I think lp.bugs.security will import from lp.app.security | 16:33 |
| henninge | sinzui: so you are saying I should use lp.app.security? I am fine with that, it was actually my first thought, too. | 16:33 |
| sinzui | henninge: Most importantly, I am happy to give you +1 to move those classes. | 16:34 |
| henninge | sinzui: thanks. The interface, too? | 16:35 |
| sinzui | yes please | 16:36 |
| henninge | cool | 16:37 |
| jcsackett | \o/ another thing gets moved into the lp tree! | 16:39 |
| === deryck[lunch] is now known as deryck | ||
| sinzui | jcsackett: do you have time to mumble? | 16:58 |
| jcsackett | sinzui: sure. | 16:59 |
| === beuno is now known as beuno-lunch | ||
| jcsackett | sinzui: https://code.launchpad.net/~jcsackett/launchpad/bloody-question-api-redirect/+merge/59248 | 17:29 |
| jcsackett | and if you have something you would like me to review, now is a good time for it. | 17:29 |
| sinzui | jcsackett: https://code.launchpad.net/~jcsackett/launchpad/bloody-question-api-redirect/+merge/59248 | 17:34 |
| jcsackett | sinzui: that's my MP. did you mean to paste in yours? | 17:35 |
| sinzui | jcsackett: I did. It is approved to land | 17:41 |
| sinzui | I will find my own | 17:41 |
| sinzui | jcsackett: https://code.launchpad.net/~sinzui/launchpad/question-email-0/+merge/59247 | 17:41 |
| jcsackett | sinzui: in IQuestionEmailJob i see body defined twice. based on description i think you mean subject for one? | 17:45 |
| * sinzui looks | 17:46 | |
| sinzui | oops | 17:47 |
| sinzui | I am incompetent. I do indeed mean subject | 17:47 |
| jcsackett | sinzui: r=me, assuming typo fix. I mentioned in the comment that you might prefer assertContentEqual over having to sort lists when doing assertEqual, but it's hardly a necessary change. | 18:02 |
| sinzui | jcsackett: thank you. Yes I think I do want assertContentEqual. I will certainly need it in my next branch/ | 18:07 |
| === beuno-lunch is now known as beuno | ||
| deryck | I have an easy 13 line diff for review. Who wants it? :-) | 18:16 |
| sinzui | me | 18:20 |
| deryck | sinzui, thanks so much for claiming my review! | 18:30 |
| deryck | sinzui, you're the perfect person for this actually. | 18:30 |
| sinzui | I am because there was a test and I think someone should remove the cache purge instructions | 18:31 |
| * sinzui is looking | 18:31 | |
| deryck | ah, cool | 18:32 |
| deryck | grep and test regex was complete fail for me | 18:32 |
| sinzui | Since i am not seeing it. I wonder if it was deleted. It was in a page test and I personally take every opportunity to delete them | 18:33 |
| jcsackett | sinzui: i'm pretty sure that's increasingly becoming the rule for everyone. | 18:34 |
| deryck | jcsackett, sinzui -- as it should be! Though hopefully with replaced coverage. ;) | 18:38 |
| ymail | who ymail | 18:42 |
| sinzui | jcsackett: I am suddenly feeling ill. I need to step away form my next for a few minutes. | 19:30 |
| jcsackett | sinzui: ok, i will try to keep an eye on #launchpad for a bit. | 19:31 |
| jtv | Any reviewers in today? Got a very simple one: https://code.launchpad.net/~jtv/launchpad/db-bug-771727/+merge/59203 | 19:45 |
| deryck | Later on, everyone. | 21:04 |
| sinzui | lifeless: flacoste: One approach to allowing mlist posting is to treat it as an entry point for registration. Send a reply to the user confirming the post, state it is queued, and the user can register at this link to forward it to the list's moderation queue | 21:23 |
| flacoste | sinzui: that doesn't avoid the spam backscatter | 21:23 |
| flacoste | which would make IS cringes | 21:23 |
| flacoste | we had that problem with launchpad registration | 21:23 |
| sinzui | I did not know that | 21:23 |
| flacoste | and it puts us on the 'spammers haven' list of big provider | 21:23 |
| lifeless | lp registration backscatter? | 21:23 |
| flacoste | yeah | 21:24 |
| lifeless | how did that work ? | 21:24 |
| flacoste | people complaining to google/yahoo that they get spam by launchpad | 21:24 |
| flacoste | because someone entered their email address on the registration page | 21:24 |
| sinzui | okay, now I connect the events | 21:24 |
| sinzui | That still happens though. Users do not know that registration is really with ubuntu? | 21:25 |
| lifeless | flacoste: ah | 21:25 |
| lifeless | flacoste: OTOH there is a robert collins who thinks my gmail address is his and signs up with hotels and banks and so on and I get all his mail. | 21:25 |
| lifeless | flacoste: *because* these folk don't do a handshake. | 21:26 |
| lifeless | If I wanted US credentials I could have had them several times over now | 21:26 |
| flacoste | lifeless: with a very bad credit score ;-) | 21:26 |
| flacoste | you probably don't want his credentials! | 21:27 |
| lifeless | :> | 21:27 |
| lifeless | well, he flys to london reasonably regularly | 21:27 |
| lifeless | so can't be too poor :> | 21:27 |
| flacoste | lifeless: should I tally up the /api/ requests with the api.launchpad.net ones (in ppr)? | 21:29 |
| lifeless | flacoste: no | 21:30 |
| flacoste | or have two api categories? | 21:30 |
| flacoste | so keep /api/ with the related web requests | 21:30 |
| lifeless | flacoste: /api is part of the user interactions | 21:30 |
| lifeless | api. is scripts | 21:30 |
| sinzui | flacoste: lifeless: I suppose the captcha is an effective barrier to users wanting accounts, and that addressed the spam backscatter. the captcha was not effective against spammer who want to directly exploit Lp | 21:30 |
| lifeless | I think its only slightly interesting to count /api as a breakout from web requests, and not useful to combine with api. | 21:30 |
| lifeless | sinzui: you'd send a mail once with a captcha link? | 21:31 |
| flacoste | lifeless: no, you need to file a captcha to register | 21:31 |
| lifeless | oh right | 21:31 |
| flacoste | which means that no email is sent unless a captcha is passed | 21:31 |
| lifeless | having uid 2 I haven't seen our rego process in a long long long time | 21:31 |
| lifeless | so, some options: | 21:37 |
| lifeless | - make a very clear page saying 'we discard mail from non LP users' | 21:37 |
| lifeless | - start sending backscatter *if* we think its not spam from a non-lp user | 21:38 |
| lifeless | - change nothing | 21:38 |
| lifeless | as sinzui says, things like dkim could aid in the 'we think its not spam' assessment, but the prevalence of spam from compromised accounts means that it won't be a very useful metric | 21:39 |
| flacoste | we should do a) for sure | 21:41 |
| lifeless | as a data point | 21:42 |
| lifeless | google groups have unmoderated groups which accept mail from anyone according to the docs (though there may be a rego-step in there, I can't tell without finding a random group and testing) | 21:42 |
| lifeless | my google friends are asleep atm sadly, or I would ask around | 21:42 |
| sinzui | I think google has a fantastic spam checker in front of its apps | 21:43 |
| flacoste | we could put spamasssassin in front of ours | 21:44 |
| flacoste | that would reduce it a bit | 21:44 |
| flacoste | probably not as good as google though | 21:44 |
| lifeless | we could run crossassassin too if we wanted | 21:44 |
| lifeless | though with only 2K mailing lists it may be too small to benefit yet. | 21:45 |
| lifeless | anyhow | 21:45 |
| lifeless | right now, the key thing is user surprise | 21:46 |
| lifeless | lets not give ourselfs months of speculative design | 21:46 |
| sinzui | This could be treated as a switch. I declare my list is open, and I am willing to moderate the queue. those I approve get Lp profiles. | 21:46 |
| lifeless | I'd like to reopen that bug though flacoste - I think there is /plenty/ of data that casual users sending mail in is important to communities | 21:46 |
| lifeless | and we are mandated with building communities | 21:47 |
| flacoste | lifeless: i say open a different bug: discarding email from non-LP users is surprising | 21:48 |
| sinzui | I think so to. We can mark it incomplete an then we have 60 days to conclude the the merit of the proposal | 21:48 |
| flacoste | i think Won't fix for that bug is the accurate current state | 21:48 |
| flacoste | the design constraints around spam still stand | 21:48 |
| flacoste | sinzui: given the Low priority this bug is going to expire | 21:48 |
| flacoste | no point discussing a design for it | 21:48 |
| lifeless | flacoste: I agree that there is no point discussing a design while its low pri | 21:49 |
| lifeless | I would like the bug open (phrased differently perhaps) because I think this will come back repeatedly over time, *particularly* once our docs are accurate. | 21:49 |
| lifeless | flacoste: I will also open a bug about the docs | 21:49 |
| lifeless | flacoste: if you feel very strongly about this, we can leave it closed | 21:50 |
| flacoste | what's another Low open bug :-) | 21:51 |
| flacoste | iow, i don't feel strongly about it :-) | 21:52 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/772016 | 21:55 |
| _mup_ | Bug #772016: users are surprised when mail from non-lp users is silently discarded by launchpad hosted mailing lists <Launchpad itself:Triaged> < https://launchpad.net/bugs/772016 > | 21:55 |
| lifeless | I've marked high | 21:55 |
| lifeless | but it should be easy | 21:55 |
| flacoste | thanks | 22:03 |
| lifeless | I have my monthly allergy shot today | 22:10 |
| lifeless | will be out middle of the day | 22:10 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | ok, time for injection... back in a few | 22:45 |
| huwshimi | Morning all | 23:02 |
| LPCIBot | Project windmill build #225: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/windmill/225/ | 23:31 |
| LPCIBot | Project devel build #681: FAILURE in 2 hr 12 min: https://lpci.wedontsleep.org/job/devel/681/ | 23:31 |
| sinzui | does anyone one know if the number of builders is low either for the release of because OEM wants them back? | 23:54 |
| elmo | sinzui: it's not OEM who own them, but rather Ubuntu Platform Services | 23:57 |
| elmo | sinzui: but the answer is both | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!