[12:14] yeah. very strange. [12:15] anyway, thanks for the offer to help manage the mailing list. I think we're doing okay at the moment, but you can ask Kiko if you see him around on irc. === luisbg [n=d33p@87.217.145.211] has left #launchpad [""Pulp!""] === SteveA -> sleep etc. [12:22] nope, no spam [12:22] sorry for the false "accusation" [12:24] jamesh: or spiv: either of you around ? === AlinuxOS [n=AlinuxOS@d81-211-222-42.cust.tele2.it] has joined #launchpad === raphink [n=raphink@raphink.net] has joined #launchpad === spiv is now known as spiv__ === spiv [n=andrew@218-214-66-203.people.net.au] has joined #launchpad [12:48] lifeless: pong [12:57] spiv: never mind, was going to ask for a pqm check, but I've since found we need an upgrade to dapper first [12:57] spiv: btw, hows the sci-fi ? [01:01] lifeless: working on splitting up smart.py atm [01:01] excellent === _mholthaus [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === mholthaus_ [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === jinty [n=jinty@137.Red-83-50-216.dynamicIP.rima-tde.net] has joined #launchpad === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] === Fujitsu [n=Fujitsu@ubuntu/member/fujitsu] has joined #launchpad [02:20] New bug: #69988 in launchpad "UnicodeDecodeError crack in doctest" [Undecided,Unconfirmed] http://launchpad.net/bugs/69988 === Mez -> bed === mpt [n=mpt@121-72-130-207.dsl.telstraclear.net] has joined #launchpad === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad [02:30] Goooooooooooooooood afternoon Launchpadders! [02:30] hey mpt :) [03:15] New bug: #69995 in blueprint "/sprints/X/+specs and /sprints/X/+assignments pages are almost identical" [Undecided,Unconfirmed] http://launchpad.net/bugs/69995 === mpt [n=mpt@121-72-130-207.dsl.telstraclear.net] has joined #launchpad === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === Jozo- [i=jozo@viola.uninea.fi] has joined #launchpad [04:30] jamesh: can we have a phone call ? I've got some OOSP questions [04:36] lifeless: okay. Do you want to try voip? [04:37] skype ? [04:37] sure [04:39] lifeless: sftp://devpad.canonical.com/code/jamesh/oops-tools/devel === stub [n=stub@ppp-58.8.14.164.revip2.asianet.co.th] has joined #launchpad [05:01] stub, have you deactivated "shoes order"? [05:01] yes [05:02] oh, the person page even says so [05:02] well... as close to deactivated as we can [05:02] though in a rather clumsy way [05:02] spiv has a merge-conditional branch to add support for deactivating users [05:02] ok [05:02] Will that remove the "Hey, I'm shoes order" link? [05:02] don't know [05:16] Receiving spam is a sign of a useful Web service [05:21] it means we must have good googlejuice [05:25] New bug: #70010 in malone "Resummarized bug report is mailed with old summary" [Undecided,Unconfirmed] http://launchpad.net/bugs/70010 [05:48] mpt: I did that at 10am :) [05:48] stub: you were a little late to the spam-finding party :) - you should read the launchpad list more ;) [05:51] Just because I read my inbox before launchpad! [05:52] :] - === stub [n=stub@ppp-58.8.14.164.revip2.asianet.co.th] has joined #launchpad === stu1 [n=stub@ppp-58.8.14.254.revip2.asianet.co.th] has joined #launchpad === MaSa69 [n=MaSa69@dsl-jklbrasgw1-fe1cfb00-100.dhcp.inet.fi] has joined #launchpad === raphink [n=raphink@82.234.166.84] has joined #launchpad === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad === mpt [n=mpt@121-72-130-207.dsl.telstraclear.net] has joined #launchpad [08:19] jamesh or spiv, a 1-minute review please: https://devpad.canonical.com/~andrew/paste/fileCaNp9y.html [08:20] ( https://launchpad.net/distros/+bugs shouldn't exist, but currently is identical to https://launchpad.net/distros ) === niru [n=niru@203.129.255.178] has joined #launchpad === niru [n=niru@203.129.255.178] has joined #launchpad [08:23] mpt: I think the point of that code was for https://launchpad.net/malone/distros [08:24] so that it would show a list of distros and the links would take you to e.g. https://launchpad.net/malone/distros/ubuntu (which would show a bug listing) [08:24] however, the links on that index page don't actually do that ... [08:25] do it is probably worth removing [08:25] s/do/so/ [08:26] mpt: probably also get rid of the for IDistributionSet/MaloneLayer too [08:27] ok [08:29] Does a defaultView element make "view/*" expressions work? [08:29] no [08:29] darn [08:30] means that if I go to the URL for a distribution (e.g. https://launchpad.net/distros/ubuntu), it will display its "+index" view (e.g. https://launchpad.net/distros/ubuntu/+index) [08:30] oh [08:31] (In another branch, I need to make view/searchtext_widget work in a custom bugs template) [08:31] in a page template, "view" is the instance of the view class [08:32] i.e. the class referenced in the class attribute of the element [08:33] Meanwhile, do you want me to remove /malone/distros as well, or is that change ok by itself? [08:33] should be alright by itself [08:33] ok, thanks [08:33] /malone/distros should pick up the default defaultView (+index) and display exactly the same thing [08:35] jamesh, on a completely different subject, what is the name of the package that puts up the graphical password prompt in bzr commit? [08:35] mpt: gnome-gpg (assuming that's what you've selected in ~/.bazaar/bazaar.conf) [08:37] thanks === niru [n=niru@203.129.255.178] has left #launchpad ["Leaving"] [08:39] any particular problem with it? === jamesh is the current maintainer of gnome-gpg [08:39] Yes, whenever the password prompt window opens, it is focused but looks like it isn't [08:41] and the "Authorize Password Access" can't decide whether it's talking about passphrases (which I'd prefer) or passwords [08:41] that's weird. It has a focused window border for me. [08:41] Should I report bugs? [08:42] sure. [08:42] https://launchpad.net/products/gnome-gpg [08:44] mpt: The "Authorize Password Access" dialog sounds like it comes from gnome-keyring-daemon [08:44] oh dear [08:44] I was going to request that it be exactly the same as the other prompt, but with the text field pre-filled :-) [08:45] so that if you instinctively start typing the passphrase it will Just Work [08:45] Is the window you see one like "The application 'gnome-gpg [08:45] ' wants to access the password for ..." [08:48] no [08:48] It's "You need a passphrase to unlock the secret key for user ... The passphrase is cached in memory." [08:48] So the first part is just the same as the one that asks for the passphrase [08:49] Is that gnome-gpg, or gnome-keyring-daemon? [08:49] That doesn't sound like gnome-gpg [08:50] what is the title on the dialog? [08:50] "Authorize Password Access" [08:50] gnome-gpg uses the title "GNU Privacy Guard passphrase" [08:50] sounds like you're using something else [08:50] Yes, that's the title of the alert I see normally [08:51] when I do commits more than X minutes apart, I guess [08:52] if you can bring the dialog up, in another terminal, try running "xprop", then click on the dialog [08:52] ah, xprop! [08:52] That's the command whose name I was trying to remember when I first saw this bug [08:53] seahorse-daemon [08:54] now you know where the dialog came from ... [08:54] yes === carlos [n=carlos@101.Red-88-17-196.staticIP.rima-tde.net] has joined #launchpad [09:07] morning [09:08] reported bug 70025 and bug 70028 [09:08] Malone bug 70025 in gnome-gpg "Passphrase prompt is focused but looks like it isn't" [Undecided,Unconfirmed] http://launchpad.net/bugs/70025 [09:08] Malone bug 70028 in gnome-gpg "Passphrase prompt mixes "passphrase" and "password"" [Undecided,Unconfirmed] http://launchpad.net/bugs/70028 === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === malcc [n=malcolm@host86-135-237-55.range86-135.btcentralplus.com] has joined #launchpad === LaserJock [n=mantha@ubuntu/member/laserjock] has joined #launchpad [10:27] mpt: morning [10:27] hi SteveA === janneke-lily [i=jantien@xs2.xs4all.nl] has joined #launchpad [10:32] I've registered LilyPond's CVS branch. The status now says: Auto Tested, Date last sync finished: 2006-10-31. [10:32] But there's nothing but ~janneke/+junk when I login on sftp? [10:35] spiv: still around? [10:36] janneke-lily: the import will be made available when ddaa checks it over [10:37] spiv: I see you are the assigned reviewer for carlos/launchpad/bug-68014-step2 [10:37] janneke-lily: but when it does get published, you still won't see it via SFTP -- it'd be published via HTTP [10:37] spiv: I was going to request an urgent review today, will you be able to do it? [10:37] what's the best way to do a request ticket for LP? I need my @ubuntu.com redirect changed [10:39] LaserJock: I think it's enough changing your preferred email address in Launchpad [10:40] carlos: hmm, last time it didn't work [10:40] LaserJock: it has a delay [10:40] I can wait for a few days to see if it works this time [10:40] well, I don't think it should take much more than a single day [10:40] last time I waited at least 1 week and kiko did a RT for me [10:41] I thought that was the last time I'd have to do it [10:41] LaserJock: are you changing it again? [10:41] or it's still that other change that is not yet done? [10:41] but then the department server blew up and I got an email saying my main email address was being removed soonish [10:41] it was changed after the RT [10:42] ok [10:42] I just need to move it again unfortunately [10:42] try to change it in launchpad [10:42] I'll keep an eye on it then [10:43] last time LP mail was fine but @ubuntu.com redirected to the old address [10:45] and if it's not changed tomorrow, you can file a new RT ticket sending an email to rt@admin.canonical.com [10:45] Ok, it will be a one-way gateway. When will will it be published, or where [10:45] do i have to look? [10:46] carlos: ok, thanks [10:46] LaserJock: your are welcome === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === jinty [n=jinty@137.Red-83-50-216.dynamicIP.rima-tde.net] has joined #launchpad [11:37] meh [11:37] SteveA, +icing doesn't support subdirectories. Should it? [11:46] danilos: ping [11:54] mpt: no [11:54] ok [11:54] I've given all the app graphics prefixes instead === fabbione [n=fabbione@vpn-nat.fabbione.net] has joined #launchpad === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === jordi [n=jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #launchpad [12:45] carlos: pong [12:45] hi jordi ;) [12:46] hello [12:46] so I think I dropped off opn yesterday or so [12:59] jordi, yes, there was a netsplit [01:03] aha [01:03] danilos: any concern re: sr team? [01:03] if not, we can tell carlos to do the magic [01:04] actually, carlos is right [01:04] jordi: well, apart from the lack of quality of translations they have done so far, no ;) but I'll email them about it anyway :) [01:04] iirc, the team already existed [01:05] hmm [01:05] no it didn't [01:05] well, I know the team ubuntu-l10n-sr existed for quite some time [01:05] the sr translations have been "freestyle" until now :) [01:05] since I've been a member long time ago (and now my membership expired) [01:05] it's not in the list though [01:05] ah, maybe that explains the "quality"? :) [01:05] right [01:06] btw, what would be the procedure if I wanted to take over ownership of the team? :P [01:06] you have more chances than other people: [01:07] 1) talk to them politely [01:07] 2) use your SUPERPOWERS and take over. :) [01:07] jordi: we don't have such superpowers... [01:07] haha, not planning on doing 2) :) [01:07] you need to be an admin [01:07] but we're good friends of Mr. Kiko, who has them. :) [01:08] jordi: right :) [01:08] yeah :-P [01:09] btw, the reasons I am even thinking about this is not because I'd like to have another duty for myself, but rather, because I've never heard of those guys, and the current owner, Ljubisa, has only been a bit vocal on some l10n lists (never seen him do anything, even if he claims to be part of Gnome, KDE teams) [01:10] right [01:11] you can try to coordinate a little at the beginning [01:11] not do translations [01:12] I guess he didn't hear of Serbian Fedora translation team (which is pretty active; I know because I am hosting a mailing list for them :), or he'd put that in his "CV" as well :) [01:12] well, one of the reasons to lose the ownership of the team [01:12] is bad translations or low quality work [01:12] being nice, of course [01:13] but is the a good reason to ask for the ownership [01:13] s/the a/a/ [01:14] I'd rather wait and see if Nikola can resurrect things first (as I said, I don't need another responsibility :) [01:15] but Ljubisa's "included in several teams" actually means "I am subscribed to their mailing lists" === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [01:36] hmm === Mez growls [01:36] any LP admins around? [01:37] someone called Stuart apparently should be deailing with this [01:37] https://launchpad.net/products/launchpad/+ticket/1576 [01:37] ah - stub :D === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [01:44] Mez: there's also an "Assignee: Stuart Bishop" field on the right side; btw, I think only stub can help you if this requires DB hackery [01:44] ;) [01:44] yeah i nticed that after ;)O === niru [n=niru@203.129.255.178] has joined #launchpad === niru [n=niru@203.129.255.178] has joined #launchpad === Spads [n=spacehob@217.205.109.249] has joined #launchpad === azeem [n=mbanck@host109.natpool.mwn.de] has joined #launchpad [02:13] is anyone working on bug 57394 / bug 55795 ? [02:13] Malone bug 57394 in soyuz "Ubuntu replaces Debian maintainer by Ubuntu maintainer in changelog" [Undecided,Unconfirmed] http://launchpad.net/bugs/57394 [02:13] Malone bug 55795 in soyuz "+changelog includes misleading information related to package versions and authors" [Medium,Confirmed] http://launchpad.net/bugs/55795 [02:13] there is no assigned at the moment === azeem [n=mbanck@host109.natpool.mwn.de] has left #launchpad [] [02:15] New bug: #70067 in blueprint "Specification tracker should make it clearer when to file a bug" [Undecided,Unconfirmed] http://launchpad.net/bugs/70067 === SteveA [n=steve@costello.z3u.com] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === raraavis [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad [03:01] New bug: #70074 in rosetta "Add direct link downloads" [Low,Confirmed] http://launchpad.net/bugs/70074 === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === carlos -> lunch === danilos [n=danilo@adsl-229-165.eunet.yu] has joined #launchpad === carlos [n=carlos@101.Red-88-17-196.staticIP.rima-tde.net] has joined #launchpad [03:43] carlos: french translators have a good point about the translator-credits issue. They translate it correct, then come a new package version, the strings are imported, if there is new contributors they don't know about it and rosetta keeps using the previous translation (there is no fuzzy indicating it's to update) [03:50] New bug: #70080 in blueprint "Supersede list box is excessively wide; use name instead?" [Undecided,Unconfirmed] http://launchpad.net/bugs/70080 === lamont [i=lamont@nat/hp/x-8fe3ca663e2e23a9] has joined #launchpad [04:38] seb128: is that an argument to demostrate that it should be handled automatically? [04:39] hello [04:39] carlos: no, that's their reply to "translators should fix those" [04:40] carlos: they say that's not a matter to fix but to know what change and is to fix [04:40] I see [04:40] carlos: they say they can't control them after every upload to see if the list of contributors changed [04:40] that's too much work for them [04:41] sure [04:41] the point to 'they should fix it' was about changes to put there 'Ubuntu French translators' [04:42] anyway, as we agreed yesterday, we are going to revert it automatically [04:43] ok, good [04:43] I was just forwarded info they sent me by mail :) [04:43] I told them I would let you know about what they have to say [04:44] anyway, I'm away 10 min, bbl [04:44] ok [04:44] seb128: thanks === mholthaus_ [n=mholthau@johnny33.dersbach.ch] has joined #launchpad [05:02] wow, the latency to devpad is really high [05:04] bzr push bzr+ssh: has been started for 5 minutes and no progress bar appeared yet [05:04] :-( [05:04] got good latency here [05:05] rtt min/avg/max/mdev = 14.181/16.402/33.680/3.891 ms [05:25] kiko: I'm up to date with rosetta-users mailing list === mpt [n=mpt@121-72-130-207.dsl.telstraclear.net] has joined #launchpad === AlinuxOS [n=AlinuxOS@d83-176-108-99.cust.tele2.it] has joined #launchpad [06:06] random reviewer: ping [06:06] flacoste: ping? [06:07] ddaa: pong [06:07] looking for suggestions for the tests cases of importd-cscvs-import [06:08] https://devpad.canonical.com/~jamesh/pending-reviews/david/launchpad/importd-cscvs-import/full-diff [06:08] that's assigned to salgado, but he's not around [06:08] got the time to talk this through? [06:09] yeah, i got a few minutes before lunch [06:09] so... the patch fixes import so it drives cscvs correctly [06:09] the previous code was correct for cvs imports, but not for svn imports [06:10] while I experimented with fixes, I encountered various corner cases [06:10] they translated into import failures because of limitations of cscvs [06:10] one problem we have here is that the svn support of importd is not tested at all === carlos -> out [06:11] see you next week at UDS or IRC! [06:11] one approach to test the fix is to make a svn repository that exercises the various corner cases I encountered [06:11] that's good because it records the experience [06:12] that's bad because the correctness of the tests is based on some idiosyncrasies of cscvs [06:12] another approach to test the fix is to stub out cscvs entirely [06:12] and check that importd gives cscvs the right messages [06:12] that would be a more unit-test approach [06:13] that's good because it does not depend of cscvs internals [06:13] that's bad because it does actually test that the messages deliver the intended result [06:13] doesn't you meant? [06:13] meant what? [06:14] "that's bad because it /doesn't/ actually test that the messages deliver the intended result" [06:14] right, I meant doesn't [06:14] and did not meant does [06:14] does I? [06:14] :-) [06:15] how do I did? [06:16] i think the first approach is more useful in this case, since from what you report we don't have any integration tests of a svn import [06:16] so adding that would be a definitive plus [06:16] yep, that's what i started doing [06:16] until I started describing _why_ we are setting up this particular weird svn repo [06:17] then I thought "this is too clever for its own good" [06:17] well, i see you stated that these "corner cases" were more common nowadays [06:17] so they should be documented [06:17] well, they are also corner cases in cscvs [06:18] for example the fact that full-tree import does not do deletes [06:18] ok, this I'm not sure i see [06:18] or the fact that changes above the branch root are completely ignored, even if they involve the creation of the branch [06:18] those are arguably bugs [06:19] low-priority, but still bugs [06:19] well, whatever is used to do the import, it needs to be able to handle the svn repo anyway? [06:19] exactly! [06:19] and it's the presence of those bugs that made the bug in how importd drives cscvs apparent [06:20] LarstiQ: flacoste: sure, but I can test that with a plain simple svn repo [06:20] instead of a particularly contrived repo invented to exercise several corner cases at the same time [06:20] but we need to handle those contrived repo [06:20] so it's useful to document them [06:20] ddaa: rule 0, those contrived repos exist in the wild, no? [06:21] Yes, but this test would not prove that we Do The Right Thing, just that this particular repo happens to import [06:21] i wouldn't state in the documentation that it's setup that way because of details in cscvs implementation [06:21] but it's start to prevent regression [06:22] which is a good thing [06:22] ddaa: aye, both looks to be the best solution [06:22] and what is Do The Right Thing in this case? stating that wouuld give an idea of the test you should write [06:23] The right thing is "do a full tree import for the first revision, then do an incremental import starting on the following revision" === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [06:24] how can you show that you did an incremental import? [06:24] mostly, because deletes are effective, because cscvs does not currently do deletes in full-tree imports. [06:24] but the intention is to avoid senseless traffic to the svn server [06:25] hmm, i see what you meant by cscvs details [06:25] the corner cases also involve non-obvious values of "first" and "following" [06:26] which are due to the way the svn revision range parser works [06:27] also, we _need_ full-tree import for the first revision because cscvs currently ignores changes above the branch root... [06:27] (when doing incremental import) [06:28] could you instrument cscvs to log the command it is executing? [06:28] not really... since it's calling into libsvn [06:28] I could monkey patch pysvn, but that's would be massively inappropriate intimacy [06:29] esp knowing that I plan to replace pysvn by custom pyrex bindings soon [06:29] cscvs doesn't do any logging? [06:29] the cscvs logging is a horrible mess [06:29] I do not even want to start on this [06:30] Well, I _could_ monkey patch the thing it uses to give "heartbeat" signals to buildbot [06:30] ok [06:30] so we would get different number of heartbeats for incremental and full-tree imports [06:31] that's thin [06:31] and I could record the logging it produces when importing individual revisions [06:31] what would be great would be to see what SVN protocols command are issued [06:31] way too much ATM [06:32] it's using the svn_client API and that's massively inefficient, that's one of the reasons to switch to custom pyrex bindings [06:32] (because pysvn does not give us access to the low-level APIs we need, and the upstream swig bindings are like pepper in the eyes" [06:33] ddaa: you've talked to jelmer about this? [06:33] jelmer has put some fixes into the swig bindings [06:34] and got them included in edgy (althought they are not in a released version of svn) [06:34] but nevertheless, the swig bindings do waaaay too much black magic for me [06:34] the fact that they have been pretty much useless up to now gives me zero confidence in their reliability [06:34] jelmer will likely disagree, but it's an argument I do not wish to have with him. [06:35] ok [06:35] ddaa: would it be simpler to do both what you proposed: contrived repository + checking that cscvs is called appopriately? [06:35] two wrongs do not make one right... [06:36] it's not completely the 'Righ Thing'(tm) but it would be a base to build on [06:36] I think it's better to actually use the logging [06:36] we have an integration test to prevent regression [06:36] since it gives us a window into what we actually care about [06:36] well, you're the judge here [06:36] well... === ddaa ponders... [06:37] nah, contrived repos should live in the cscvs test suite [06:37] i really think the contrived repository is a good thing to have [06:38] in cscvs or importd === ddaa ponders again... [06:38] well, if cscvs was tested correctly, showing that importd called cscvs correctly would be enough [06:38] well no, because the way cscvs needs to be called is a bug on many levels... [06:39] the thing is that the showing the logging is again pretty cscvs specific [06:39] the API we use is ugly and the UI it is a backed of makes baby jesus cry [06:39] so it's not something that is meaningful or likely to be stable [06:40] would the logging strategy be? [06:40] pass a collecting logger object to cscvs [06:40] look for lines that look like "WARNING: changeset N" [06:40] and "change X" [06:41] filter out the rest [06:41] i mean when you switch to pyrex binding would the logging-based test code require change? [06:41] so we can check that we import the right revisions, only once, and that we do not process too many changes (which happens if we are not incremental) [06:41] nope [06:41] the logging happens way up the stack [06:42] it's susceptible to change too, but the changes should be easy to understand when they happen [06:42] and the contrived repo test, would it require change? [06:43] forget that last question [06:43] i misread your reply [06:43] nope, the pyrex transition should be pretty much feature-invariant as far as impord is concerned [06:43] so, the logging testing seems like a good choice [06:43] Thanks for talking this through with me. [06:44] and like you said, the contrived repo should be added to cscvs [06:44] my pleasure, ddaa! [06:44] i'm sure working on that section of code can be painful at times [06:44] flacoste: actually the contrived repo needs not be added to cscvs [06:45] instead, the individual corner cases should be unit-tested in the appropriate places [06:45] indeed, that's the best [06:46] flacoste: it's especially painful when reviewers ask questions whose answer is "because it needs to be that way to work" ;) [06:46] but putting one contrived repo test is probably less work than retro-fitting unit tests and gives a good safety net against regression [06:46] lol [06:47] Yeah, the contrived repo test would be useful... depends on how much work it would take... [06:47] it's hard to decide these matters... [06:48] it may not necessarily needed to be added now, but before switching to pyrex bindings would probably be a good idea [06:48] TBH, i'll probably never get around to it [06:49] again, i would be the judge on this, i'm not familiar enough with these parts to have a judgement on that [06:49] sorry [06:49] the specific patches to merge can be tested without having to [06:49] and I need to keep focus to make progress [06:49] i meant "i would let you be the judge" [06:49] fine [06:49] Thank you. [06:50] and I need food to make progress ;-) [06:50] so, i'm off to lunch === AlinuxOS2 [n=AlinuxOS@d83-176-12-167.cust.tele2.it] has joined #launchpad === Kuhrscher [n=jannick@91.64.1.199] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === stub [n=stub@ppp-58.8.14.254.revip2.asianet.co.th] has joined #launchpad === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad [08:51] morning === laszlok [n=laszlo@CPE0015e976f21f-CM0017ee427a40.cpe.net.cable.rogers.com] has joined #launchpad [08:54] for some reason rosetta won't send me an email to download any translations? Bug maybe? [09:06] OOPS-307S6 [09:06] https://devpad.canonical.com/~jamesh/oops.cgi/307S6 [09:07] thx, ubugtu! [09:07] lifeless: do you have staging access? [09:14] yes [09:14] whats up ? [09:15] flacoste: do you work in the same office as matsubara ? [09:15] nope, i'm the other side of the equator [09:16] lifeless: the support tracker is broken on staging [09:16] I need an instant review for a quasi-trivial cscvs patch [09:16] https://devpad.canonical.com/~andrew/paste/file7ILMmC.html [09:16] flacoste: that's a patch to allow doing the stuff we just discussed [09:16] it needs some data migration script to be run, and I think the automatic staging migration procedure doesn't run them [09:16] ddaa: i'll review it in a moment [09:17] lifeless: i've sent a message to stuart Cc launchpad about that === AlinuxOS [n=AlinuxOS@d81-211-221-244.cust.tele2.it] has joined #launchpad [09:17] i can also paste the script names here if you prefer [09:19] ddaa: r=flacoste, it's a basic extract class refactoring [09:20] *nod* I mostly wanted to get an okay for the docstring, since it looks like the bar has been set a bit higher recently. [09:22] flacoste: if I run those now, I presume it will fix it. However the next update is in not too many hours, so I'm inclined to just let stub get to it, as I fly to UDS in 3 hours [09:22] flacoste: is that ok ? [09:23] lifeless: ok, it's better if it is fixed permanently [09:23] lifeless: have a nice fly! [09:23] thanks === mirak [n=mirak@ip-41.net-81-220-108.rev.numericable.fr] has joined #launchpad [09:45] hi [09:45] New bug: #70141 in rosetta "ubuntu-docs templates are gone" [Undecided,Unconfirmed] http://launchpad.net/bugs/70141 === AlinuxOS [n=AlinuxOS@d83-176-8-202.cust.tele2.it] has joined #launchpad === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === claud1 [n=claude@254.93.79.83.cust.bluewin.ch] has joined #launchpad === claud1 [n=claude@254.93.79.83.cust.bluewin.ch] has left #launchpad [] === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === Spads [n=spacehob@host-84-9-50-138.bulldogdsl.com] has joined #launchpad === doko__ [n=doko@dslb-088-073-105-224.pools.arcor-ip.net] has joined #launchpad === xenru [n=Miranda@85.192.13.50] has joined #launchpad === kjcole [n=kjcole@ubuntu/member/kjcole] has joined #launchpad === ryanakca [n=ryan@unaffiliated/ryanakca] has joined #launchpad === jdong [n=jdong@ubuntu/member/jdong] has joined #launchpad [11:57] is there someway/someone to debug when launchpad VCS imports don't work? [11:58] namely for https://launchpad.net/products/ktorrent/2.0 [11:58] every time I register VCS details (KDE SVN), it reverts to blank after 24 hours [11:59] hmm [11:59] reverting to blank is bong [11:59] ddaa is the king of imports [11:59] hu [11:59] jdong: I plead guilty [12:00] ddaa: any ideas on what could be going on? [12:00] absolutely [12:00] love to hear that [12:01] So, the UI sucks on many levels [12:01] one of the suckage is that VCS details look like "informational vcs details" [12:01] while actually it's input for our vcs-imports system [12:01] another suckage is that we only support import from trunk branches [12:02] oh [12:02] but it's not actually said anywhere in the UI [12:02] so it's not possible to import a svn branch then? [12:02]