=== doko_ [n=doko@dslb-088-073-078-218.pools.arcor-ip.net] has joined #launchpad === mdz_ [n=mdz@87-194-36-33.bethere.co.uk] has joined #launchpad === jml [n=jml@ppp105-240.lns1.hba1.internode.on.net] has joined #launchpad === marcus_notebook [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === mholthaus [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === mdz [n=mdz@george.kkhotels.co.uk] has joined #launchpad === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #launchpad [] [01:34] kiko: back. did you get the branch? last time i tried to show you a live instance it all went wrong. [01:35] bradb_, I could just hand-hack the URLs [01:35] the branch did not arrive yet, no [01:35] !! [01:35] give me a live demo tomorrow post-meeting ok? [01:35] kiko: sure [01:36] time to go bother malcc === mholthaus_ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === mholthaus_ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad [02:00] Goooooooooooooooooood afternoon Launchpadders! [02:15] New bug: #66838 in soyuz "please review/merge James' rf-dak branch" [Undecided,Unconfirmed] http://launchpad.net/bugs/66838 === MagicFab is now known as MagicFab-downtow [02:20] New bug: #66839 in malone "Should be able to include one or more tags in search" [Undecided,Unconfirmed] http://launchpad.net/bugs/66839 === mdz [n=mdz@george.kkhotels.co.uk] has joined #launchpad [02:30] New bug: #66842 in malone "Allow people to have lists of favorite tags" [Undecided,Unconfirmed] http://launchpad.net/bugs/66842 === mholthaus_ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === belito [n=user@190.40.25.240] has joined #launchpad === malex [n=malex@mrb319.cvmbs.colostate.edu] has joined #launchpad === jamey [n=jamey@38.99.207.90] has joined #launchpad === Ng [n=cmsj@mairukipa.tenshu.net] has joined #launchpad === sivang [i=sivan@ubuntu/member/sivang] has joined #launchpad === mdz [n=mdz@george.kkhotels.co.uk] has joined #launchpad === AstralJava [n=jaska@cm-083-102-068-117.lohjanpuhelin.fi] has joined #launchpad === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === MagicFab-downtow [n=fabian@modemcable035.165-57-74.mc.videotron.ca] has joined #launchpad === ryanakca [n=ryan@unaffiliated/ryanakca] has joined #launchpad === Jozo- [i=jozo@viola.uninea.fi] has joined #launchpad === bradb_ [n=bradb@modemcable077.58-130-66.mc.videotron.ca] has joined #launchpad === predius_ [i=predius@knd.org.uk] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === lamont [i=lamont@nat/hp/x-78d00e40e5484748] has joined #launchpad === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad [04:07] lifeless: I added an alternative db schema for https://launchpad.canonical.com/CompleteBranchRevision -- it is slightly more complex than your one, but would result in a lot less data === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #launchpad === quail [n=quail@unaffiliated/quaillinux/x-000001] has joined #launchpad === mholthaus [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad === WaterSevenUb [n=WaterSev@c-65-96-188-198.hsd1.ma.comcast.net] has joined #launchpad === stub [n=stub@ppp-58.8.15.123.revip2.asianet.co.th] has joined #launchpad === mholthaus__ [n=mholthau@65.193.63.81.fix.bluewin.ch] has joined #launchpad [06:55] New bug: #66861 in blueprint ""Approved (Needs guidance)" should not be possible" [Undecided,Unconfirmed] http://launchpad.net/bugs/66861 === MagicFab-downtow is now known as MagicFab === stu1 [n=stub@ppp-58.8.14.92.revip2.asianet.co.th] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === minghua [n=minghua@ppp-70-251-19-77.dsl.hstntx.swbell.net] has joined #launchpad [07:45] hi, I just got a spam email from malone, is there a place to report such things (maybe to disable the user)? [07:45] it's bug #36505 [07:45] Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,In progress] http://launchpad.net/bugs/36505 [07:47] minghua: weird. That user appears to have made non-spam comments previously [07:48] e.g. https://launchpad.net/distros/ubuntu/+bug/32157 [07:48] Malone bug 32157 in Ubuntu "Doesn't recognize my Linksys WiFi" [Medium,Needs info] [07:49] yea, but a long time ago. [07:49] probably a hijacked account [07:49] or automatic mail from virus infected mail client? [07:49] stu1: are you able to tell if https://launchpad.net/distros/ubuntu/+source/lintian/+bug/36505/comments/9 came in via the web or email? [07:49] Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,In progress] [07:50] minghua: an email with a forged from address could easily add a comment [07:50] I see [07:50] provided the from address belonged to a registered LP account [07:51] aha [07:56] if it came in via email (as I suspect), we should have a copy of the original message, which would help indicate whether it was forged or not [07:57] jamesh: It was an email [07:58] stub: got a librarian URL for it? [07:58] jamesh: Probably an infected computer spamming local address book [07:59] High probability since it claims to be from outlook.... [07:59] yep. And not from gmail ... [08:00] stub: I wonder how much it would hurt to require some token be maintained in the subject line for comment emails to be accepted? [08:00] I am thinking of the "[Bug NNNN] " bit [08:01] Swings and roundabouts [08:01] it won't prevent someone who is determined to spam LP [08:01] but cases like this clearly aren't targetting us in particular [08:02] If we go with the token, might as well drop the nnn@bugs.launchpad.net email address and go with bugs@launchpad.net or something. [08:03] well, using both requires that they match [08:03] For what gain? [08:04] I suppose non-targetted spam isn't likely to produce a correctly formatted subject line to start with, so not much gain [08:04] Don't know if the error checking would be worth needing to enter the information twice (for new emails rather than replies). It might catch some, but I think it is diminishing returns. [08:05] (catch some human errors that is) [08:07] jamesh: I think it's likely that there is or will be spam viruses that not just use the address book of a victim, but send fake replies to received messages, i.e. harvest addresses and subject lines from the victim. [08:08] I admit that I'm speculating wildly here :) [08:09] spiv: but how many actually do? [08:09] jamesh: I have no idea... as I say, I'm speculating :) === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad [08:10] currently the only filter we have in place is "the from: address belong to a valid LP account", which is going to lose effectiveness as more people register accounts [08:12] stub: the weird thing about that spam email is that it lacks any hyperlinks, even in the HTML version [08:13] how do you know where to send money for the viagra? [08:13] I've started getting spam that says "don't click, type www.somespammysite.example into your browser" [08:13] mpt: nothing like that either [08:14] the HTML just has Viagra Soft Tabs and similar [08:14] with no URL [08:15] Sometimes spammers make mistakes [08:15] Like when they send spam with the subject line "${subject}" [08:15] jamesh: I've seen some really broken spam - they lusers who do it seem to test by sending a few thousand from their botnet rather than actually check to see if they have, for example, replaced all their %name% variables with text [08:16] No misspelling of Viagra is also odd - trivial for spam traps to catch. === stub wonders if we got around to requesting inbound email to go through the spam filters [08:18] I also wonder how the spam sender got the target bug address, as the victim LP user is not involved with this bug [08:18] (if we go by the local address book spam theory) [08:20] oh. I suppose a second user that received mails from this bug and also got some comments from another bug the victim user commented would explain it === mholthaus [n=mholthau@212.28.62.81.cust.bluewin.ch] has joined #launchpad [08:32] jamesh: yes, but it also fails to do subgraph queries, and to represent graphs accurately for branches with ghosts [08:33] jamesh: these may not be fatal, but I feel that its better to start with something precise and work back from that [08:33] lifeless: subgraph queries? [08:34] your compressed notation is dependent on knowing the revnos for revisions ids you want to examine [08:34] i.e. ggetting it to answer 'branches which contain revision id X' requires more work [08:35] that would be Revision -> IntroducedRevision -> RevisionNumber -> Branch join [08:35] instead of Revision -> BranchRevision -> Branch [08:37] also, in terms of 'much less data', I'm not convinced its that big a win - have you done some stats ? [08:38] we see 3:1 ratio in bzr of 'introduced' to 'mainline revs' [08:38] provided the ghost issues can be sorted out (I am not sure whether they can be reliably though), you can also answer the question of "in which revno did the revision get introduced?" [08:38] sure. That doesn't help with dotted decimal notation though AFAICT [08:38] as merge into is irrelevant for that [08:39] lifeless: say I branch bzr.dev at r2000 [08:39] lifeless: then the IntroducedRevision rows for all revisions up to r2000 will be shared between bzr.dev and my new branch [08:41] the bit about dotted revision numbers was that if two branches have $REVID as a mainline revision that all revisions in the ancestry of $REVID would have identical revision numbers on both branches [08:41] unless I am mistaken [08:41] in the absence of ghosts this is true === minghua [n=minghua@ppp-70-251-19-77.dsl.hstntx.swbell.net] has left #launchpad ["Leaving"] [08:41] we chose number-from-branch-point because of this property in fact [08:42] because its possible to cache to some degree === carlos [n=carlos@67.Red-81-39-33.dynamicIP.rima-tde.net] has joined #launchpad [08:43] morning [08:44] lifeless: anyway, if ghosts make the idea unworkable, I guess we can't use it. [08:46] we'd need to address ghosts somehow [08:46] not sure if its 'unworkable' at this point [08:46] I'd like concrete data - say we have 10^5 branches, 10^6 total revisions, what is the performance like in both cases [08:48] for the bzr.dev case, there are approximately 7500 revisions in the ancestry at r2000 [08:49] morning! [08:49] so if I create a branch of bzr, that would involve adding 2000 RevisionNumber records (and sharing the existing IntroducedRevisions) vs. adding 7500 new BranchRevision records [08:49] jamesh: so a 4 fold decrease in the total records [08:49] jamesh: for an extra indirection [08:50] on the one hand its cute [08:50] on the other, I want sabdfl to sign off on anything [08:50] so we can JFDI [08:50] I guess it really depends on the shape of the ancestry of the branches we have registered [08:50] this is a major aspect [08:51] one thing to consider is that sql == set, this data == graph [08:51] yep === marcus_notebook [n=mholthau@212.28.62.81.cust.bluewin.ch] has joined #launchpad [08:51] so, we can reduce it to minimal overhead, by storing just the basic data [08:51] but we have that [08:52] the other thing to consider is if the extra questions you can answer with the IntroducedRevision data model are worth answering in the context of Launchpad [08:52] so this is about useful caching [08:52] what extra questions does it give ? [08:52] [answers to] [08:52] "what revisions were merged in this revno?" [08:52] "which revno was this revision merged into branch X?" [08:52] those sort of things [08:53] hmm [08:54] I think that the first is possibly useful (and doing it without pull the whole graph is good) - but we can do that without trying to share data [which is where ghosts are a problem] [08:54] the second I think is less useful at that precision, but very useful at 'has the revision been merged into branch X' [08:55] (and more generally, 'have these revisions been merged into those branches' [08:55] to generate things like 'branch freshness' [08:55] ideally in a 4 queries for an entire web page [08:59] so for bzr.dev, the len(ancestry)/len(revision_history) ratio is close to 4, while for Launchpad it is around 3 === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === quail is now known as quail_testing === quail_testing is now known as quail === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [09:23] jamesh: hi, did you see my email about the core dump while running tests? [09:25] <_thumper_> morning all [09:26] morning [09:26] lifeless: are you able to restore a production DB mirror in carbon? [09:27] lifeless: seems like langpackdb mirror failed today and we need it working to prepare final language packs for Edgy [09:31] carlos: hi. Could you look what is going on with gnome-app-install template for edgy on rosetta? A new template has been built some days ago, I've asked to danilo to get it out of the queue tuesday and it's still not imported [09:31] did you change the name? [09:31] it should be imported automatically [09:31] let me check... [09:32] I don't see it as pending to be approved or imported... [09:32] In fact, it's already imported [09:32] seb128: https://launchpad.net/rosetta/imports/+index?target=all&status=IMPORTED&type=pot [09:34] carlos: I can look into it, but I'm not familiar enough with the processes to do it fast-fast-fast. I suggest rining stub is better [09:34] *ringing* [09:34] carlos: https://launchpad.net/distros/ubuntu/edgy/+source/gnome-app-install/+pots/gnome-app-install/ [09:34] lifeless: well, I know the command that executes the mirror process [09:34] carlos: it still has "Created: 2006-08-22" [09:35] lifeless: https://devpad.canonical.com/~andrew/paste/fileBSCtey.html [09:36] seb128: because it was created on that date, it doesn't note when it was 'updated' [09:36] carlos: graaa [09:36] carlos: [09:36] gnome-app-install (0.2.21) edgy; urgency=low [09:36] * fixed vanished intltool-update -p [09:36] -- Michael Vogt Mon, 16 Oct 2006 17:19:38 +0200 [09:36] [09:37] carlos: it's supposed to have been created on that date [09:37] carlos: and I think pitti confirmed the pot got built during the package build [09:37] seb128: sorry, let me explain it better [09:37] carlos: could you have a look on why it's not updated please? language packs for edgy have to be rolled tomorrow and I would like gnome-app-install translated correctly for edgy [09:37] that field notes when that .pot file was created in launchpad [09:37] not when latest .pot file was created [09:37] ah k [09:37] still [09:38] the french page has 0 untranslated string [09:38] and translation has not changed since 2006-10-11 [09:38] which means it didn't get the new strings it's supposed to have [09:38] that's a problem then with the .pot file creation [09:39] seb128: http://librarian.launchpad.net/4861317/gnome-app-install.pot [09:39] that's the .pot file that was imported [09:39] and I can assure you that it's imported without problem [09:39] carlos: thats jubany, not carbon [09:40] do you want the equivalent on carbon run ? [09:40] lifeless: seems like it works using push from jubany [09:40] carlos: so, I'll need to verify thats what it does [09:40] carlos: that pot is correct [09:40] at least the only language pack db that I'm aware of is in carbon [09:40] carlos: which is my point about not knowing it well enough to do fast fast fast [09:40] ok [09:40] carlos: please ring stub! [09:40] I will call stuart [09:40] lifeless: thanks [09:41] if hes not available, I will proceed, with due caution, to get it to happen, but I'm not about to run random scripts on jubany. [09:41] seb128: then it should be correct. I'm downloading the .pot file we have in launchpad to get a diff [09:42] carlos: thank you [09:42] carlos: example of not translated text: [09:42] hum [09:42] seb128: wouldn't be possible that new strings are already part of our suggestion database? (strings that were there sometime ago, were removed later and now added again) [09:42] the rosetta page seems to be fine [09:43] carlos: looks like that's the case, I found the string as translated [09:43] :-) [09:43] ok, goo [09:43] good [09:43] I didn't know rosetta kept old strings translations [09:43] we keep everything ;-) [09:43] :) === seb128 hugs carlos [09:43] brb === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === highvoltage [n=jonathan@196.1.61.12] has joined #launchpad [09:52] hi. how do I link a specification to the MV summit? [09:54] highvoltage: in the spec page, click over 'Propose for meeting agenda' in the actions menu [09:54] it should be a link like: https://features.launchpad.net/products/rosetta/+spec/translation-review/+linksprint [09:59] aaah, there it is. thanks carlos. [09:59] you are welcome === seb128_ [n=seb128@ANancy-151-1-33-92.w83-196.abo.wanadoo.fr] has joined #launchpad [10:04] <_thumper_> ping jamesh === mpt [n=mpt@121-72-131-100.dsl.telstraclear.net] has joined #launchpad [10:11] New bug: #66877 in malone "Not able to attach CVE any more" [Undecided,Unconfirmed] http://launchpad.net/bugs/66877 [10:14] _thumper_: pong [10:15] <_thumper_> jamesh: I'm having a few permission problems with some work I'm doing and ddaa suggested talking to you [10:15] okay [10:17] jamesh: how's it going with the review of my branch? it's been unreviewed for almost a week and a half now. [10:18] spiv: ping === mholthaus [n=mholthau@212.28.62.81.cust.bluewin.ch] has joined #launchpad [10:24] BjornT: I'm part way through it. Will email the review soon. [10:24] cool === Samyak [n=root@219.64.84.252] has joined #launchpad [10:26] Hi All, [10:28] Wanted to know if launch pad supports RSS feeds ? [10:29] poolie: call soon I think [10:31] Oh, I just saw it has been there with high priority on the site === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === stub [n=stub@ppp-58.8.14.92.revip2.asianet.co.th] has joined #launchpad === Samyak [n=root@219.64.84.252] has left #launchpad [] === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === jinty [n=jinty@127.Red-83-50-221.dynamicIP.rima-tde.net] has joined #launchpad === Spads [n=spacehob@217.205.109.249] has joined #launchpad === tonyyarusso [n=anthony@d235-240-148.home1.cgocable.net] has joined #launchpad [11:09] Is it possible to remove a spec from a sprint? I had proposed one for paris, but didn't have all of the writeup that it should have had. Now I've figured that out and written the more complete description on the wiki and submitted for mtv, but it still has paris (proposed) listed, which isn't a huge problem, but just seems out of place. === indu [n=indraven@203.129.255.178] has joined #launchpad === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad [11:20] tonyyarusso: I don't think so; probably the organizers can only decline it [11:20] but it doesn't hurt to leave it there [11:20] All right. I guess that's what'll happen unless someone from paris feels like cleaning house. [11:45] New bug: #66886 in malone "double attaching problem in malone bug report" [Undecided,Unconfirmed] http://launchpad.net/bugs/66886 [11:50] poolie: ping [11:55] New bug: #66887 in launchpad "Make reporters life easier when he is searching for an already reported bug" [Undecided,Unconfirmed] http://launchpad.net/bugs/66887 [12:09] <_thumper_> hmm... it seems that I am missing a dependancy for launchpad development [12:10] <_thumper_> ProblemRenderingGraph: ... /bin/sh: unflatten: command no found [12:10] <_thumper_> missing package? [12:14] <_thumper_> ddaa, know the answer? [12:14] graphviz? [12:14] apt-file knows it all [12:15] yup, graphviz [12:15] <_thumper_> yep, didn't have that [12:15] <_thumper_> should be added to the launchpad dependancy meta package [12:16] probably a bug if the launchpad development metapackages do not have that [12:16] yeah launchpad-dependencies should depend on graphviz [12:17] _thumper_: please file a bug https://launchpad.net/distros/ubuntu/+source/launchpad-dependencies/+bugs [12:18] <_thumper_> ok [12:19] ddaa: not there [12:19] _thumper_: not there [12:19] <_thumper_> lifeless, ok, where? [12:19] its no longer in the distro [12:20] https://launchpad.net/products/launchpad-development-infrastructure [12:23] _thumper_: also, do you have scratchy in your apt list ? [12:23] <_thumper_> yep === geser [n=michael@dialin109019.justdsl.de] has joined #launchpad [12:29] Can anyone think why we might still need to set PYTHONPATH in the main Launchpad Makefile? [12:30] New bug: #66894 in launchpad-development-infrastructure "missing dependancy graphviz" [Undecided,Unconfirmed] http://launchpad.net/bugs/66894 === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad [12:31] _thumper_: is something blocking your landing of the "fix" to "prevent" timeout errors on branch listings? [12:31] stub: hi, do you know how's going the mirror? seems like it's taking too long [12:32] <_thumper_> ddaa, just me getting back to spiv about naming stuff, slipped my mind [12:32] <_thumper_> ddaa, doing now [12:32] thanks [12:34] carlos: still running. It is building indexes, so the data is all loaded. [12:34] stub: ok [12:34] thanks [12:36] mdke: ping === sivang [i=sivan@ubuntu/member/sivang] has left #launchpad [] === eleusis [n=eleusis@l3-202-89-191-233.arach.net.au] has joined #launchpad === mdz [n=mdz@217.205.109.249] has joined #launchpad [01:12] spiv: when you get back, do you want to hack at my place on SS tomorrow? I'm crashing - tired - but ping me tomorrow about it ok? (Last chance before I'm off to singapore) [01:14] lifeless: back === malcc [n=malcolm@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:15] lifeless: sounds good. [01:16] stub: the mirror is ready now. Thanks! [01:17] Yup. No glitches at this end. [01:19] lifeless, I've sent a request to PQM twice in the past few hours and got a response neither time. It is requesting to merge to /code/, not /home/warthogs/archives/. What else could be wrong? [01:19] stub: could you confirm to me that the update-statistics script is still being run daily? [01:19] It is still being run daily. [01:19] hmmm [01:19] then we have a bug [01:19] https://launchpad.net/distros/ubuntu/edgy/+lang/en_GB/+index?start=827&batch=1 [01:19] shows no translation at all [01:20] but following the link === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:20] https://launchpad.net/distros/ubuntu/edgy/+source/moin/+pots/moinmoin/en_GB/+translate [01:20] it's full translated... === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad [01:24] ddaa: that's a weird branch scanner error message [01:24] looks like bzrlib gave something that the branch scanner cannot feed to datetime [01:25] might be anything from a weird edge case in date handling to genuine invalid data... [01:25] The code in Python does this: [01:26] timet = _PyTime_DoubleToTimet(timestamp); [01:26] ... [01:26] fraction = timestamp - (double)timet; [01:26] us = (int)round_to_long(fraction * 1e6); [01:26] hi [01:26] The check that triggers the ValueError is: [01:26] if (us < 0 || us > 999999) { [01:26] was is the actual value of us there? [01:27] might be something like -1, or some weird value that reflects leap seconds, or whatever... [01:28] >>> revision.timestamp [01:28] 1161204240.098 [01:28] not particularly special [01:28] floating point rounding error? [01:28] cosmic ray? [01:28] a rounding error isn't going to push the value that far out ... [01:29] and we're talking about 64-bit precision here. [01:29] fraction = timestamp - (double)timet [01:30] floating point substraction is not a particularly safe operation [01:30] that's my best guess so far... [01:31] it isn't that inaccurate [01:33] the _PyTime_DoubleToTimet() routine does a C cast of timestamp down to time_t (which will be rounding down in this instance, then checks that the difference between the result and the original value is reasonable (between -1 and 1) [01:34] between 0 and 1-epsilon that is... [01:34] truly weird indeed [01:34] we aren't talking about tiny quantities here though [01:35] could that be a case of flaky FPU? [01:35] there is plenty of precision here [01:35] don't know [01:35] see if the error persists ... [01:35] going to lunch [01:36] always though the idea of floating-point timestamps was distasteful... === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:40] New bug: #66906 in rosetta "Rosetta lists moinmoin as being untranslated in en_GB" [Undecided,Unconfirmed] http://launchpad.net/bugs/66906 === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:51] ++++++++++++++++++6666666666666666666 [01:51] <_thumper_> ddaa: cat? [01:52] That's quite a lot of unary plus operators.... [01:56] double plus good [01:56] of course, the increment operator can't be applied to a constant ... [01:57] Launchpad meeting in 3 or so minutes. [01:57] yeah... cat... [01:58] was lunching [01:58] just found the culprit, hiding behind a curtain [01:58] me === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [01:59] no kiko, you're not my cat [01:59] rats [02:00] MEETING TIME [02:00] <_thumper_> yay [02:00] woo [02:00] == Agenda == [02:00] * Roll call [02:00] * Agenda [02:00] * Next meeting [02:00] * Activity reports [02:00] * Actions from last meeting [02:00] * Oops report (Matsubara) [02:00] * Bug report report (mpt) [02:00] * Production and staging (Stuart) [02:01] * Launchpad 1.0 status reports + updating spec status [02:01] * Sysadmin requests [02:01] ---- [02:01] * Writing help text (mpt) [02:01] * Moin-style markup in doctests and docs (SteveA) [02:01] * Terminology: Structural, immediate, application objects (SteveA) [02:01] * Moving standalone pagetests into domain areas (mpt) [02:01] * (other items) [02:01] ---- [02:01] * Keep, Bag, Change [02:01] * Three sentences [02:01] Who's here? [02:01] I welcome spiv as today's special guest chair of the launchpad development meeting. [02:01] me [02:01] me [02:01] me [02:01] me [02:01] me [02:01] <_thumper_> me [02:01] me [02:01] me [02:01] me [02:01] me [02:01] me [02:01] me [02:02] me [02:02] stub: ? [02:02] me === sivang [i=sivan@ubuntu/member/sivang] has joined #launchpad [02:02] carlos: hi [02:02] carlos: ? [02:02] Anyone else missing? [02:03] * Agenda [02:03] jordi: around? [02:03] carlos: if I approve someone, and he then goes and spamms translations, is there any way to revert back to what was before his did that? [02:03] I already pasted that. [02:03] privmsg me late additions. [02:03] * Next meeting [02:03] For a change, how about same time next week? [02:03] <_thumper_> I'll be in singapore next week... 8pm is dinner time :) but could probably make it if necessary [02:03] me [02:03] sorry [02:03] Next week, same bat time, same bat channel? [02:04] I was on the phone [02:04] _thumper_: don't worry about coming next week, if it is difficult to do from singapore. [02:04] woops, sorry for interrupting in the middle of the meeting. [02:04] sivang: using some DBA magic, yes [02:04] stub: same for you, but please mail me production/staging report before hand. [02:04] ok [02:05] Developer meeting: Thu 26 Oct, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 === ..[topic/#launchpad:spiv] : Developer meeting: Thu 26 Oct, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 [02:05] Ahem. [02:05] * Activity reports [02:05] Who's naughty and who's nice? [02:05] nice [02:05] nice [02:05] <_thumper_> nice [02:05] nice [02:05] I'm on a sprint, but it's hardly any excuse, as I was already behind from last week [02:05] nice [02:05] up to date, sent filler mail for the sprint [02:05] nice [02:05] up to date [02:05] bad [02:05] not up to date [02:05] I'm on sprint, will send summary [02:05] I'll send a sprint summary and then be nicer next week === mpt is making a list and checking it twice [02:05] up to date. (will send yesterday's today) [02:05] not up to date [02:05] nice === kiko fires up gtimelog [02:06] Naughty people, take inspiration from kiko. [02:06] == Actions from last meeting == [02:07] * SteveA to write up what needs doing to implement `__eq__`, `__ne__`, and `__hash__` for database objects [02:07] Naughty people have been taking inspiration from kiko for years [02:07] SteveA: Any progress? === kiko sniffles [02:07] no. [02:07] it wasn't even on my todo list [02:07] SteveA, spiv: maybe we should take a moment to clarify that point [02:07] and see if it's still worth doing === SteveA adds it on my todo list [02:08] Yeah, I can barely even remember what that's about. [02:08] has it been proven that those methods are actually missing? [02:08] and/or relevant? [02:08] kiko: it's a matter of writing a braindump spec from what was agreed in a meeting N weeks ago [02:08] so that the decision is effectively captured [02:09] to do that I'll check the logs of that meeting [02:09] what spawned this discussion was the fact that malcc ended up encountering a situation in which objects in sets were not considered the same even though they really were [02:09] and then register a spec [02:09] We found we had a number of callsites using == and getting random results depending on what mood SQLObject was in [02:09] So we need to ban == or make it work [02:09] or maybe a bug [02:09] malcc, do we have a testcase? [02:09] depending [02:09] that's what I want to know. [02:09] up to now all is speculation [02:09] It's not hard to replicate and I think I have code kicking around which does it [02:09] Obviously we don't have a test case in rf, as it would fail :) === sivang [i=sivan@ubuntu/member/sivang] has left #launchpad [] [02:10] spiv: seeing as I'm not getting around to this... [02:10] malcc, if you have a short testcase we will shower you with gifts [02:10] would you take responsibility for getting malc's testcase [02:10] and checking the meeting logs === carlos sucks... gets distracted... sorry [02:10] and writing up a sensible thing we should do? [02:10] Ok. [02:10] I'm up to date with activity reports [02:10] I'll review it for you [02:10] sucks not to have ExpectedFailure support [02:11] given the way sqlobject's cache works and the fact that we blow the cache after each request, I wonder if this means that objects from a previous request are being used? [02:11] ddaa: was that a random interjection? [02:11] jamesh: Where we saw the problem was outside the webapp === _thumper_ faintly hears "stay on target" ??? [02:11] SteveA: if the test framework supported "expected failure", malcc could merge his test case to rocketfuel [02:11]