[12:05] oh...for *the* entertainment === LarstiQ giggles === bradb heads off, later all === jinty [n=jinty@15.Red-83-50-220.dynamicIP.rima-tde.net] has joined #launchpad === flacoste [n=francis@209.217.74.66] has left #launchpad ["Bye"] === Doctor_PK [n=aa@203.130.9.181] has joined #launchpad === FreePBX7888 [i=PJirc@lgb-cust-208.57.69.229.mpowercom.net] has joined #launchpad === FreePBX7888 [i=PJirc@lgb-cust-208.57.69.229.mpowercom.net] has left #launchpad [] [02:13] mdke: the Chinese is probably valid [02:13] heya [02:13] The Spanish variants aren't most probably [02:13] hey [02:13] just came back from the concert [02:14] tomorrow will be a loooong day I'm afraid [02:14] friday :) === cprov [i=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === stub [n=stub@ppp-58.8.1.159.revip2.asianet.co.th] has joined #launchpad === rpedro [n=rpedro@87-196-69-5.net.novis.pt] has joined #launchpad === jelmer [n=jelmer@dsl16-123.fastxdsl.nl] has joined #launchpad === stub [n=stub@ppp-58.8.1.159.revip2.asianet.co.th] has joined #launchpad [04:08] spiv: ping? === cprov [i=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [04:31] jamesh: pong [04:32] spiv: SteveA said to add the Python license to the tickcount code, however the Python license seems very specific to Python and the PSF [04:32] spiv: I was wondering if you knew what sort of text people used when they wanted to apply the license to other code? [04:34] jamesh: http://www.python.org/moin/PythonSoftwareFoundationLicenseFaq [04:34] (although it isn't responding for me, so here's the google cache http://72.14.209.104/search?q=cache:Po4ZYunZLYAJ:www.python.org/moin/PythonSoftwareFoundationLicenseFaq+psf+license+faq&hl=en&ct=clnk&cd=1) [04:34] okay, so search+replace is the answer [04:36] jamesh: Although as that FAQ mentions, the PSF licence is not actually an appropriate initial license for contributions to Python. [04:36] yeah === jamesh is surprised that the PSF won't accept the MIT license for contributions to the standard library [04:40] the legal opinions of the MIT license I've heard are that it includes a patent grant === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #launchpad [05:01] spiv: do you think bazaar.launchpad.net/~launchpad/tickcount/devel would be a good name for the branch on the supermirror? [05:02] jamesh: Seems ok. I wonder if it's worth having a tickcout team to own it instead of launchpad? [05:02] tickcount, rather :) [05:02] Yeah, the thing about not accepting MIT licenses is interesting, I didn't know that. [05:03] especially since both AFL and Apache licenses are GPL incompatible ... [05:03] Although does the MIT licence probably give you enough scope to relicense with one of the acceptable ones? [05:06] the MIT license says you can "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software" provided the copyright notice is preserved [05:06] so it lets you do pretty much anything except claim you wrote it [05:07] the legal opinion I heard was that it would be impossible to grant the rights in the MIT license without licensing the applicable patents [05:08] I'm mainly curious because Twisted is MIT licensed, and there's periodically talk of including parts of it in the standard library. [05:09] (which probably will never happen, but who knows...) [05:15] as for branch naming, I guess I'll make it owned by launchpad for now -- we can always change the branch owner at a later date === mpt [n=mpt@wm1214qm.195.ADSL.NetSurf.Net] has joined #launchpad [05:19] Yeah. [05:20] hmm. product registrants don't seem to be able to change the registrant anymore [05:21] I think there's a bug open on that. [05:22] yeah. Looks like carlos locked it down to protect a particular view [05:25] Well, if the tests passed... ;) === ajmitch__ [n=ajmitch@203.89.166.123] has joined #launchpad === ajmitch__ [n=ajmitch@203.89.166.123] has joined #launchpad === ajmitch__ is now known as ajmitch === ajmitch__ [n=ajmitch@203.89.166.123] has joined #launchpad === ajmitch__ is now known as ajmitch === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [08:00] SteveA: ping... infrastructure voip call now? [08:05] mmm [08:06] I have to go in about 25 minutes... === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [08:10] stub: did you get my cherrypick request for the authserver? [08:11] spiv: yes. Distracted on other things atm though. Should go out later today. [08:11] stub: wonderful, thanks! [08:28] Anything thrilling we should be discussing in the infrastructure call? [08:28] I've got nothing to add except work on the test runner is in progress. [08:29] not directly related to infrastructure, but I wanted to ask SteveA about the tickcount licensing (given what the faq on the Python wiki says) [08:32] Nothing springing to my mind. === spiv -> out [08:39] jamesh: SteveA wants tickcount to go into a future Python release and one step of that involves putting the correct licence on it as per the Python wiki. [08:42] stub: yeah, and the wiki says that the Python license is not the correct license. [08:43] And it says what the correct license is? [08:43] they list the AFL and Apache 2.0 public license [08:43] as acceptable ones [08:44] bad wiki [08:45] http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq <- "Why can't I contribute code under the PSF License?" [08:49] Bah. I don't like any licence longer than a paragraph. They just cause headaches and arguments. [08:49] the choice of acceptable licenses seems to be constrained to those with an explicit patent grant [08:55] stub: did you manage to solve the slowness with pushing to bazaar.launchpad.net? === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad [08:56] it seemed about as fast as I'd expect when I tested it [08:57] jamesh: It finished eventually. Just slow. No idea if it is something magic about that particular branch or if it is purely network related meaning it is slower here. [08:57] stub: the number of files you listed under .bzr sounded like a lot for weaves [08:57] It was knit format [08:57] stub: It should be 2*number of files in repo + constant [08:58] Branch is here if you think you can make sense out of it: https://launchpad.net/people/stub/+branch/pytz/devel [08:59] morning [09:02] stub: doing a "bzr branch" of that branch just gives 215 files, which seems reasonable [09:02] Weird... [09:03] They are almost all in .bzr/repository [09:03] I wonder what else is in that repository? [09:03] repository/knits in fact === rpedro [n=rpedro@87-196-46-161.net.novis.pt] has joined #launchpad [09:04] $ find .bzr/repository/knits -type f | wc -l [09:04] 196 [09:04] so that's 98 files (since there is a knit and a knit index for each one) [09:07] https://chinstrap.ubuntu.com/~dsilvers/paste/fileJIDj7e.html === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [09:23] stub: here's the difference between your directory listing and what I saw: https://chinstrap.ubuntu.com/~dsilvers/paste/file99dQiu.html [09:26] If I bzr push, I get a branch containing 1400+ knits. If I bzr branch, I get a branch containing 196 knits. [09:26] mpool: Have I broken something again? [09:28] I shouldn't be allowed near computers [09:29] the real question is what is in those 1200 extra knits [09:30] Are knits binary format or a text format compressed? [09:31] Ahh... gzipped [09:31] morning [09:32] hi folks. i overslept. sorry bout that. [09:32] Hmmm.... very weird. It looks like files from a different branch in the same old arch repository [09:35] So it looks like my pytz branch ended up with a load of history from other branches in the same archive that is preserved when pushed but ignored when branched. There are cases where this would be a security bug (thankfully I kept my public and private archives seperate). [09:35] And that information was even preserved when converting the weaves to knits using bog standard 'bzr update' [09:36] SteveA: jamesh first time, me second time, so it looks like spiv is due to be late next ;) [09:36] SteveA: We declared the call boring anyway [09:37] And IRC chats are more productive because nobody knows you are drinking beer [09:38] jamesh: please put the tickcount stuff under the LGPL. We'll relicence it later if it gets into the standard library. [09:41] although, the MIT would do just as well === stub disables pqm and runs tests for spiv's cherry pick [09:45] SteveA: done. It is available here: https://launchpad.net/people/launchpad/+branch/tickcount/devel [09:45] spiv: how's sftp stuff going? [09:45] (hasn't been pulled from the SFTP server yet though [09:46] So that error message actually means 'I haven't gotten around to mirroring this yet'? Is that an open bug anyone? [09:47] I think it means "I tried to mirror it, but it hadn't been fully pushed to the supermirror at the time [09:47] i.e. unfortunate timing === carlos [n=carlos@13.Red-88-15-198.dynamicIP.rima-tde.net] has joined #launchpad [10:02] moining [10:15] spiv: authserver updated === doko_ [n=doko@dslb-088-073-096-168.pools.arcor-ip.net] has joined #launchpad [10:18] stub: its not a bug [10:18] stub: it means what jamesh says and it will correct it self normally [10:18] the inclusion of the local path in the error is a bug and there is one open on it [10:19] lifeless: Any thoughts on the extra 1200 knits issue in your scrollback? [10:20] what issue ? [10:20] (scrollback is long, give me a time delta or a summary) [10:22] I have a branch that was converted from arch and subsequently converted from weave to knits that contains about 1440 knits. There are only a dozen or so files under rcs though. If I push, the knits are propogated to the new branch. If I branch, the number of knits drops to 196. [10:22] The extra knits appear to be from other branches in the old arch repository [10:23] I can fix it obviously enough just by branching, but it might be a symptom of something you need to worry about. Possibly a security issue as private data may accidently end up getting pushed when not intended. [10:23] bzr version ? [10:24] 0.8.2 [10:24] fixed in .dev I believe [10:24] The conversion from arch would have been an earlier version though [10:24] https://launchpad.net/products/bzr/+bug/43713 [10:24] Malone bug 43713 in bzr "bzr branch clones too much" [High,Fix released] [10:25] This is not repositories [10:25] it is under the hood === erdalronahi [n=erdal@p50876814.dip.t-dialin.net] has joined #launchpad [10:25] ok [10:26] branch seems to remove the surious knits, but push doesn't. Could it have been fixed for branch only? [10:26] no [10:27] this is the vlone logic: [10:27] dir_to = br_from.bzrdir.clone(location_url, [10:27] revision_id=br_from.last_revision()) [10:27] the revision_id parameter is the key one to make this be fixed. [10:27] ok === erdalronahi [n=erdal@p50876814.dip.t-dialin.net] has joined #launchpad === jinty [n=jinty@15.Red-83-50-220.dynamicIP.rima-tde.net] has joined #launchpad === highvoltage [n=jono@ubuntu/member/highvoltage] has joined #launchpad [11:32] hi #launchpad [11:33] if i want to add myself to a meeting for in paris, do i subscribe to the meeting in launchpad? [11:33] or is there another way i should join? [11:34] highvoltage: make sure the dates you'll attend the meeting are set in launchpad, and then subscribe to the meetings in launchpad, as you say [11:34] SteveA: thanks, will do. [11:38] i don't want to oversusbscribe to meetings right now, just to the meetings that i am very, very interested in. [11:38] if there's a gap on a day, can i attend a meeting? [11:39] or do i absolutely have to subscribe now in order to be able to attend? [11:40] the conference organisers will use an automated scheduling program to schedule the meetings and attendees [11:40] and each person will get an webpage with their own meetings on it for the day [11:41] so, if you want to take advantage of this, you should subscribe [11:41] if not, i expect you can just turn up to meetings, provided there is enough space around the table [11:42] ok, thanks for the tip. [11:43] hmmm, the roadmap is a little borked [11:45] lifeless: context-free non-sequiteur [11:47] the roadmap in the sprint app within launchpad is not doing an effective sort === Kinnison heads to the doctor, back in a bit [11:51] lifeless: is it something we should get fixed before the paris meeting? [11:52] probably not - its an implementation roadmap not a meeting scheduling map, AFAICT [11:52] as long as the meeting scheduler takes priority into account it will be fine. [11:52] but we should fix it before the sprint ends :) === Yannig [n=yannick@AToulouse-254-1-30-218.w81-250.abo.wanadoo.fr] has joined #launchpad [11:54] jamesh: ping [11:55] lifeless: i don't have mental bandwidth to look into it / understand it right now. [11:55] but maybe you and james can establish whether the scheduler will work as intended [11:55] and file a bug for what should change [11:55] the roadmap table is certainly meant to be about implementation [11:58] SteveA: pong [11:58] the scheduler algorithm uses the priorities [11:58] jamesh: would you read the last 15 lines of scrollback, and see if we need to file a spec tracker UI bug? [11:58] Hello everybody [12:03] has anyone seen the python.org call for trackers? http://wiki.python.org/moin/CallForTrackers [12:04] yes [12:05] we'll be submitting an entry for launchpad [12:05] lifeless: it looks like the code that drives that page tries to apply a partial ordering to the incomplete specs based on dependencies [12:06] lifeless: it doesn't do anything with priorities [12:06] jamesh: yes, I know :) [12:06] # XXX sabdfl 2006-04-07 this is incomplete and will not build a [12:06] # proper comprehensive roadmap [12:06] jamesh: it should start with priorities, then backfile in the dependencies, traversing in priority order [12:06] as a depth first search [12:07] yep === adrighem [n=adrighem@e169118.upc-e.chello.nl] has joined #launchpad [12:16] Hi all. [12:17] I want to set up a "GNOME Translation group" in rosetta, but don't see how this can be done. [12:18] The page says "Only Official coordinators will be able to add you to the GNOME teams in Rosetta." [12:18] hey vincent [12:18] ehhh, hi? [12:18] adrighem: what, we visit the same faculty and you don't recognise me! ;) [12:18] Oh, okay. [12:19] adrighem: you're part of the gnome nl translation team, right? [12:19] LarstiQ: not only part, I'm the coordinator...but rosetta doesn't seem to agree. [12:20] carlos: awake? [12:20] LarstiQ: hi [12:20] carlos: can you help adrighem? [12:20] LarstiQ: sure, I didn't see his request ;-) Thanks [12:20] Hi carlos. Can you create a dutch gnome team in rosetta? [12:21] (nl) [12:21] adrighem: atm is a bit useless to do it because we are not importing GNOME's products [12:21] adrighem: but is ok to setup it now so you have it ready when we start doing those imports [12:21] what are those imports waiting on? [12:21] carlos: my thought exactly. ;) [12:21] adrighem: I guess you are the official coordinator in GNOME, right? [12:21] carlos: yup [12:22] LarstiQ: having more time from me to expend on it... [12:22] carlos: ah :) [12:23] adrighem: ok, confirmed that you are the coordinator [12:23] adrighem: did you create already a team in launchpad for that? [12:23] carlos: no. I did not do that. [12:23] if the answer is no, please do it, naming it gnome-l10n-nl [12:24] so you are the owner of the team [12:24] and I will add it to the GNOME translation project group [12:24] carlos: will do...one moment please. [12:24] adrighem: it should be a moderated team [12:24] so you only approve people that work with you in GNOME [12:24] and only those ones [12:25] I will not add anyone there, even If i'm asked to do it (In fact, I don't have rights to do it) [12:25] so you have full control of that team [12:26] carlos: that's nice to know. === BjornT -> lunch [12:29] carlos: the team has been created. [12:30] just a secon [12:35] second ;-) === erdalronahi [n=erdal@p50876814.dip.t-dialin.net] has joined #launchpad [12:35] I had a phone call [12:35] adrighem: done [12:39] Ooooh, lemme check... [12:42] carlos: thanks. === adrighem is adding group members [01:03] And I am gone... === adrighem [n=adrighem@e169118.upc-e.chello.nl] has left #launchpad ["Come] [01:09] SteveA: There are tests for bug 47770 on my branch now [01:09] Malone bug 47770 in launchpad-publisher ""raw-dist-upgrade" target does not support pockets" [Medium,In progress] http://launchpad.net/bugs/47770 [01:09] SteveA: care to have a look? [01:10] https://chinstrap.ubuntu.com/~jamesh/pending-reviews/dsilvers/launchpad-repo/launchpad/bug-47770/full-diff [01:10] Kinnison: yes, but not right now. just off to lunch with bjorn [01:11] okay [01:11] thanks for the organisation yesterday btw [01:11] twas v. useful [01:11] np === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === carlos -> lunch [01:58] anybody up for a quick code review? [02:01] sure === Kinnison -> lunch [02:05] cool! [02:05] lifeless, https://chinstrap.ubuntu.com/~dsilvers/paste/fileFU4ZRj.html is to fix bug 48608 and a few other trivialities [02:06] (https://launchpad.net/products/shipit/+bug/48608) [02:06] bogus product: https://launchpad.net/products/pssrajan [02:07] salgado: 'for Macs' is a ittle misleading : it wont work on MacbookPlus [02:09] "For Macs that are neither too new or too old, or for other computers that are like those Macs inside"? [02:09] lifeless, I agree, but this is what we're using everywhere --not only shipit. the DVDs and CD images for download are labeled like this [02:11] does dvds_portlet return an HTML fragment or a tal fragment ? [02:12] HTML [02:17] mailed to lp-reviwes. [02:17] meh, thingy [02:17] basically good, but missing tests. [02:17] and I *know* that *you* know better. [02:19] you mean, tests for the changes I've done? [02:19] specifically the DVD portlet [02:19] it could be broken and we'd never know [02:20] Strange - if I'm logged in, I can't access bug 38801, but if I log out, I can. [02:20] Malone bug 38801 in nunit "nunit broken when using .Net 2.0 library" [Unknown,Unknown] http://launchpad.net/bugs/38801 [02:20] well, if by broken you mean some broken tal inside it, then we'd know because the pagetests for the /myrequest page would fail [02:20] no, I mean, say the including template gets changed [02:20] i.e. by a bad merge resolution. [02:21] there are no tests that ensure the dvd templates are shown in the output for ubuntu/kubuntu and not for edubuntu. [02:22] yeah, that's right. so I guess it's better to test that the pages contain (or don't contain) some things from the portlet, right? [02:22] right [02:22] this is our current style of testing. [02:22] and as such its fine ;). [02:23] btw, I'm filing a bug explaining why I didn't convert that pagetest to a new-style one. I wanted to and spent a good time on it, but there are some issues that I don't think are going to be easy to solve, so I'm leaving this for another merge [02:24] sure. my main concern here is that there be a test which will fail if the new feature stops doing what its meant to === mpt [n=mpt@209.217.74.66] has joined #launchpad === WaterSevenUb [n=WaterSev@195-23-238-209.nr.ip.pt] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad [02:49] lifeless: SteveA: can we have a quick meeting? [02:49] ddaa: okay [02:50] -> #launchpad-meeting === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad === bradb wakes up [02:59] salgado: hi, will matsubara be around today or is he gone already ? [03:00] cprov, he's gone. he switched today with yesterday (which was a holiday) [03:00] salgado: uhm, okay. what about you ? [03:00] I switched monday with yesterday. [03:02] salgado: right, can you give a second oppinion about my last comment in bug #49789 ? I think it's worth to fix it ASAP ... [03:02] Malone bug 49789 in xorg "Clicking on Codes of Conduct link in Launchpad crashes X" [Untriaged,Unconfirmed] http://launchpad.net/bugs/49789 [03:03] sure === salgado looks [03:04] salgado: we don't have any nvidia card at office, do we ? [03:05] we do [03:07] salgado: is kiko around? [03:08] SteveA, no [03:09] salgado: good, can you aditionally check what I suggested ? if you have time ... nonetheless I think we should fix the horizontal scroll evilness, don't you think ? [03:16] salgado: i see on PendingReviews that you have been assigned as my reviewer for my first bug patch! [03:16] salgado: when do you think you will have time to take a look at it? [03:18] flacoste, I didn't see that. thanks for pinging me. if it's not too big I'll do it today, for sure [03:18] thk! no its small, the biggest changes are to the tests that were modified to use testbrowser [03:19] cprov, I'll have a look, but I'm afraid I won't have time to fix it, so better wait for matsubara [03:20] salgado: okay, I'd do it myself if you have time for just confirming it. [03:21] cprov, well, at most I'd be able to confirm that it crash, but I wouldn't be able to tell for sure if what you suggest will avoid the crash [03:22] anyway, I'm turning another box on because I don't want mine to crash [03:27] salgado: ehe, good point, if the br-crew bug exists at all. It's amazing how popular nvidia is here, in br, everyone in ubuntu-br team uses it. I'm still in savage 4 age, yet [03:29] okay, so it doesn't crash my box with an nvidia card [03:29] salgado: but the pages still scrolling horizontally, doesn't it ? [03:29] yes, it does [03:32] salgado: do you think the
 idea would make it any better ?
[03:35]  cprov, probably, but I'm not sure it'd make it not crash
[03:35]  I'll try to test it with the proprietary nvidia driver
[03:37]  salgado: ahh, it might be the case of those guys, indeed
=== Kinnison -> paint a wall before the light fades
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
[03:45]  who do I change the status of a bug in launchpad?
=== flacoste guesses he just doesn't have permission...
[03:46]  flacoste, you should have
[03:47]  i thought too, maybe I'm just blind this morning, what is the GUI control that I should use?
[03:47]  flacoste, you have to click on the "Affects" column, to change its status
[03:47]  wow! 
[03:47]  and it's not because you're blind. it's because it's well hidden. :/
[03:47]  found it, thanks!
[03:48]  indeed, i would never have guessed it!
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt]  has joined #launchpad
=== jd_ [n=jd@wikipedia/Meanos]  has joined #launchpad
=== rpedro [n=rpedro@87-196-46-161.net.novis.pt]  has joined #launchpad
[04:12]  flacoste: That is one of Malone's bigger usability problems. We haven't yet managed to convinced the sab that changing bug status should be made visible.
[04:13]  bug 1095
[04:13]  Malone bug 1095 in malone "Unnecessarily difficult to find how to change status or reassign a bug" [Medium,Confirmed]  http://launchpad.net/bugs/1095
[04:13]  what's the rationale for keeping it hidden?
=== flacoste found a CTAGS plugin for kate
[04:13]  flacoste: I'm not sure.
[04:14]  flacoste: cool!
[04:14]  i'm installing it now
[04:14]  I'm switching my desktop to KDE right now, for kicks.
=== flacoste hope it works...
[04:14]  I installed kubuntu on another machine yesterday, for more kicks
[04:14]  brabd: (the plugin not your switch)
[04:15]  bradb: ping
[04:16]  ddaa: there are many possible failure conditions for the branch scanner.
[04:16]  using get_revision_reconcile is a bad idea. Its designed solely for reconcile to use.
[04:16]  lifeless: so far I assumed there were none. If the data got through the branch puller, it was valid.
[04:16]  BTW
[04:17]  EBADASSUMPTION. The data will be valid. That does not mean the scanner cannot fail.
[04:17]  the puller could crash partway through a pull for instance; the puller server  can die during a scan run; the puller bzr version can be out of sync with the scanner version; the scanner can have bugs;
[04:18]  puller crash: I thought bzr was designed to keep data consistent at all times
[04:19]  puller server crash: it's a transient failure mode, there's already a case in the code to handle connection failures.
[04:19]  etc.
[04:19]  lifeless: you are giving ways the code can fail because of deployment issues and bugs
[04:20]  I was saying that the branch scanner should not normally fail.
[04:20]  different issues
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
[04:20]  at the moment, those CorruptRepository errors are situation where the branch scanner _cannot_ complete its job regardless of bugs, just because the data is bad.
[04:21]  newbie question: how do I generate a TAGS file for the launchpad project?
[04:21]  make tags
[04:21]  hu, sorry: make TAGS
[04:21]  right!
[04:21]  ddaa: I think it is unwise to use unsupported apis in bzr in the branch scanner.
[04:21]  thanks!
[04:22]  beyond that its your call.
[04:23]  sure, that sounds bad
[04:23]  get_revision_reconcile is not a supported api.
[04:23]  lifeless: is there a way to avoid putting corrupt data in the supermirror?
[04:23]  its not corrupt.
[04:24]  its almost certain that you are hitting those branches during the middle of a pull by the supermirror
[04:24]  well, CorruptRepository make it sound like something is corrupt
[04:24]  lifeless: no
[04:24]  this is a repeatable error we have with several branches
[04:24]  I suspect that nuking the mirrored copy will correct this
[04:24]  cprov, carlos: I want to set up an xmlrpc playground on mawson. Are you doing on LP work on mawson that I might conflict with?
[04:25]  or running bzr reconcile on them by hand
[04:25]  bradb: I only use mawson as a gateway to asuka and I'm using my own lp tree
[04:25]  bradb: so don't worry about my scripts
[04:25]  lifeless: I guess so, but I'd rather not run bzr reconcile on vostok
[04:25]  kiko-afk: ping
[04:25]  lifeless: I'm interested in way to _prevent_ that situation from occuring
[04:26]  lifeless: so it does not become yet another operational nightmare
[04:26]  ddaa: bzr pull prevents it since 0.8
[04:26]  carlos: cool
[04:26]  bradb: there is a RF HEAD work tree there, have fun, I'm not using it right now
[04:27]  lifeless: ah, nice. I'll give you a command line to run on vostok to clear the data
[04:36]  cprov: thanks
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
=== jsgotangco [n=jsg123@ubuntu/member/jsgotangco]  has joined #launchpad
=== rpedro [n=rpedro@87-196-46-161.net.novis.pt]  has joined #launchpad
=== bradb_ [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
=== Keybuk [n=scott@quest.netsplit.com]  has joined #launchpad
[04:54]  SteveA, kiko-afk: https://chinstrap.ubuntu.com/~dsilvers/paste/filehugREW.html
=== jd_ [n=jd@wikipedia/Meanos]  has joined #launchpad
[05:04]  kiko-afk: the issued sql queries: https://chinstrap.ubuntu.com/~dsilvers/paste/filerhVQre.html
[05:12]  bradb_: the CTAGS plugin isn't up to date with the latest kate API -> doesn't compile :-(
[05:14]  flacoste: bummer
=== marcin_ant [n=marcin@194.114.146.122]  has joined #launchpad
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #launchpad
[05:24]  flacoste, BjornT, I have a question about the support tracker:
[05:24]  can I link more than one bug to a single ticket?
[05:24]  you should be able to yes
[05:25]  the bugs attribute is a list
[05:25]  so if the interface doesn't let you, it's a bug
[05:25]  you can only create one bug from a support request though
[05:26]  right, and this is because the bug is created using the ticket's title and subject, verbatim?
[05:26]  then it wouldn't make sense to create two identical bugs
[05:37]  carlos?
[05:37]  jordi: ?
[05:38]  salgado, can't you edit them?
[05:38]  BjornT, looking
[05:39]  kiko, not when filing the bug from a ticket
[05:39]  salgado, flacoste: that sounds wrong to me!
[05:39]  kiko: the problem seems to be caused by the owner being None for the missing message
[05:40]  BjornT, is message.owner not null?
[05:40]  kiko: file a bug on launchpad-support-tracker :-)
[05:40]  flacoste, doing so as we speak
[05:41]  BjornT, so message.owner is not null in message.py
[05:41]  BjornT, that's why a regular join is emitted
[05:41]  instead of a left outer join
[05:41]  BjornT, can you change that and try again?
[05:41]  BjornT, alternatively, enforce message.owner is not null in the database!
[05:42]  kiko: ok, i'll try to change that.
[05:42]  BjornT, do you know if message.owner is really nullable?
=== mpt [n=mpt@209.217.74.66]  has joined #launchpad
[05:44]  kiko: i can't see why message.owner should be nullable. can you check if we have any messages in production with a null owner?
[05:44]  will do so now.
[05:45]  even so, it is surely a bug that foo.count() differs from len(list(foo))
=== rpedro [n=rpedro@87-196-46-161.net.novis.pt]  has joined #launchpad
[05:46]  SteveA, do you understand why it happens?
[05:46]  removing notNull=True fixes the problem.
[05:46]  BjornT, sure.
[05:48]  SteveA?
[05:49]  what?
[05:49]  do you understand why it happens?
[05:49]  no
[05:49]  i can look at the code
[05:49]  ok. do you want to call me to follow up on other stuff as well?
[05:50]  SteveA?
[05:50]  sure, we can have a call
[05:50]  ring rin
[05:52]  kiko: looks like a prejoin bug
[05:52]  SteveA, not necessarily, but maybe.
[05:52]  it's sticking WHERE terms where they don't belong
[05:52]  what?
[05:53]  (Pdb) bug_two.messages.count()
[05:53]  3
[05:53]  WHERE Message.id = BugMessage.message and
[05:53]      BugMessage.bug = Bug.id and
[05:53]          Bug.id = 2
[05:53]  
[05:53]  (Pdb) len(list(bug_two.messages))
[05:53]  2
[05:53]  WHERE
[05:53]  _prejoin0.id = Message.owner AND  Message.id = BugMessage.message and
[05:53]  BugMessage.bug = Bug.id and
[05:53]  Bug.id = 2
[05:53]  
[05:53]  SteveA, as I told BjornT, the database schema is wrong
[05:54]  BjornT, there are no messages with null owners in the database.
[05:54]  the prejoin stuff should barf rather than give incorrect results, then
[05:54]  SteveA, let me think about this for a second.
[05:54]  kiko: office or mofo?
[05:54]  office
[05:54]  BjornT, you can add the not null constraint.
[05:57]  kiko: yeah, i'll do that later. for this patch i'll simply set an owner in sampledata, since stub isn't around to approve the db patch.
=== jd_ is now known as jd_away
[06:06]  carlos: ping
[06:07]  doko: pong
[06:09]  carlos: about the helpcontent2 statistics, did people translate any significant part?
[06:10]  doko: sorry, I hadn't time to look at it. I'm finishing some open branches that I would want to have merged before Paris and I need to write down a spec for next week...
[06:10]  doko: I would say... Ignore the updates from Rosetta and build new language packs now and we will include them later
[06:11]  ok
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
[06:32]  hey cool. i clicked on a message in my inbox in kmail, dragged it to a folder, clicked "Move Here", and all my Inbox messages seem to have disappeared
[06:33]  rockin
=== bradb feels mild nausea
[06:37]  bradb: embrace the love of Thunderbird
[06:37]  least aggravating GUI mail client I have tried so far
[06:37]  phew, restarting kmail brought them back
=== ddaa switched away from Evolution a couple of weeks ago
[06:38]  applying filters on all messages in kmail over imap makes it behave in ways i've never seen any mail app behave before
=== bradb uses tbird for rss sometimes
[06:39]  some mail client seem to have trouble with the notion that IMAP is meant to be _online_
=== Kinnison hugs offline imap
[06:45]  offline imap is scary
[06:45]  ddaa: problems with evo?
[06:46]  unchecked memory consumption, sigsev almost every time when quitting (and losing recent change in message status), insufficient ability to walk and chew gum, sluggish response
[06:47]  leaving around spamd instances when crashing
[06:47]  incredibly slow when processing massive numbers of messages
[06:48]  storing state outside of the IMAP data
[06:48]  (and losing it sometimes)
=== bradb switches to a wired link for pushing his branch up to mawson
=== bradb_ [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
[06:52]  hm, apparently there are tools for compressing the contents of a directory before sending them over the wire. perhaps i'll use those instead.
[06:56]  ddaa: I have few problems but they annoy the heck out of me when they happen
[06:56]  ddaa: Ihave 47K messages in INBOX
[06:56]  lifeless: evo is fast when it has generated its caches
[06:57]  but some operations (e.g. setting the label on several thousand messages) and building the caches take forever
[06:58]  bradb, BjornT, for the record, fixed bug 1555; just submitted off to spiv for review.
[06:58]  Malone bug 1555 in launchpad "BugMessage.selectOneBy doesn't work as expected" [Medium,Confirmed]  http://launchpad.net/bugs/1555
[06:58]  also, it has sometimes trouble figuring out that other clients have modified the IMAP boxes, and then I need to remove the cache...
[07:12]  I'm offline until paris, phone/sms me in emergencies and I'll arrange 'net.
[07:16]  lifeless: have a nice trip, see you there :)
=== bradb & # lunch
=== jd_away is now known as jd_miam
[07:46]  carlos: ping
[07:47]  SteveA: pong
[07:47]  kiko: ping
=== flacoste is very happy, he should receive new RAM on monday
[07:54]  kiko: ping
=== jd_miam is now known as jd_
[08:03]  SteveA, pong
[08:03]  what's up?
=== flacoste curses against bug 45310 and gives hope of setting up shared repository
[08:19]  Malone bug 45310 in bzr "Branching large repository uses a ridiculous amount of RAM" [High,Unconfirmed]  http://launchpad.net/bugs/45310
[08:19]  s/gives/gives up/
=== jd_ is now known as jd_away
=== bradb_ [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
[08:40]  now kmail is turning my messages into zombies!
[08:40]  I click on a message, and suddenly it says "No Subject" and "Unknown" sender
[08:42]  bradb_: what is your IMAP server?
[08:42]  pobox
=== flacoste has use UW-Imapd and courier without problems
[08:42]  hmm, i don't know about that one
[08:42]  this is a disaster
=== bradb_ sees if evo does the same
[08:43]  bradb_: look into the the server settings, there might be an option in there to tweak the protocol usage...
[08:43]  (in kmail, i mean)
[08:44]  flacoste: have you ever seen this kind of thing?
[08:45]  i have seen messages "disappearing" from the inbox with UW-Imap when a mailbox was accessed from two clients
[08:45]  (it only disappeard in the GUI though)
=== bradb checks server-side
[08:47]  I use mbox and mutt
[08:47]  1970s technology that WORKS
[08:48]  kiko: i need imap though
[08:49]  "need"
[08:49]  soho business owner, on the go, etc.
[08:49]  as I said "need"!
[08:49]  bradb: soho business owner?
[08:49]  like a strip-club magnate?
[08:49]  i hope nobody took that last statement seriously :P
[08:49]  poker table enterpreneur
[08:50]  heh
[08:50]  i haven't played in too long
[08:50]  NO SUBJEFAT GAH
=== bradb looks at his pitiful Inbox
[08:52]  less pitiful than mine with 500 incoming
[08:53]  kiko: KMail will make your problems go away
=== bradb restarts into GNOME
[08:54]  yeah I believe you
=== raphink [n=raphink@ubuntu/member/raphink]  has joined #launchpad
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
=== mgalvin [n=mgalvin@ubuntu/member/mgalvin]  has joined #launchpad
[09:05]  salgado, yes, correct.
[09:14]  what beneffits would we have by doing that?
[09:14]  kiko_bsb, ^
[09:14]  benefits too
=== BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt]  has joined #launchpad
[09:16]  salgado, doing it in the same way as everybody else does?
[09:20]  hmmm. don't you think having to check whether mirror_admins is None in every callsite, or having a getMirrorAdmins() method to do that is enough reason to do it differently?
[09:22]  salgado, well, I don't know about "every callsite"
[09:22]  how many callsites would you have to change?
[09:22]  I think it makes the distribution nicer to set up
[09:22]  no need to worry about this stuff until it becomes necessary
[09:23]  anyway, that's just a fluff comment
[09:23]  but you /are/ being inconsistent from bug and security contact
[09:23]  fwiw
[09:23]  IMNBWAGD though
[09:24]  there's at least three callsites, as we're doing the permission check manually
[09:24]  salgado: regarding the warning message to the user accessing the +makebug page when there are already bugs linked to it
[09:25]  I place the message in a div with class="warning message" ?
[09:27]  maybe just informational message
[09:27]  hmmm. I'm not sure
[09:28]  that's a question for the great mpt!
[09:28]  he's in a sprint now
[09:28]  well
[09:28]  think about it
[09:28]  is it a warning
[09:28]  or is it something normal?
[09:29]  it's an error
[09:29]  there's also error message
[09:29]  I believe.
[09:29]  well, it depends how you view it because the only way the user is going to get there is if he enters the url himself
[09:30]  or a bookmark
[09:30]  bookmark a form?
[09:30]  just send him to jail, do not pass GO, do not collect R$200
[09:30]  anyway, I think that a concept in Launchpad is that the URL is part of the GUI? so, in that case, we should consider it a normal action then
[09:31]  so in that case either error or informational should be used, i think
[09:32]  I say it's an error
[09:32]  fine, I'll use error
[09:33]  yeah, I was concerned that we could be presenting an error for a user who actually clicked on the link (suppose he had a stale ticket page), but the chance of it happening is too small for us to consider it, I think
=== bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
=== Ubugtu [n=bugbot@ubuntu/bot/ubugtu]  has joined #launchpad
[09:40]  salgado: what do you think if I implement the check in the view, that way the user would be redirected to the ticket page with the error message
[09:40]  instead of having a blank page with the error message (the related bug portlets doesn't appear in that page which would be kind of helpful)?
[09:49]  bradb: is there a mail interface to Malone?
[09:49]  (like debbugs)?
[09:50]  flacoste: yeah
[09:51]  flacoste: https://help.launchpad.net/UsingMaloneEmail
[09:52]  great!
[09:54]  bradb: about there is entry in the LauncpadHackingFAQ which is relevant to yesterday's question about where to put tests relevant to corner-case bug:
[09:54]  Where should I put my tests: in a `test_foo.py` module, or a `foo.txt` doctest file?
[09:54]      *
[09:54]        You should prefer doctests. A good rule of thumb is that test_*.py modules are best for tests that aren't useful for documentation, but instead for increasing test coverage to obscure or hard-to-reach code paths.
[09:54]        It is very easy to write test code that says "check foo does bar", without explaining why. Doctests tend to trick the author into explaining why.
[09:55]  I guess that yesterday's error +editstatus oopses when a product uses malone and has a support contact would qualify for a test_*.py module
[09:55]  true. it seems people rarely write tests other than doc or pagetests these days, though maybe i haven't been watching enough TV
[09:57]  we could added that to a tests/test_malone_bugs.py file
[09:59]  def test_bug49891
[10:02]  flacoste: you should ask SteveA or lifeless where exactly to put tests for corner case bugs that don't fit in doc or pagetests
[10:02]  I think a convention that links the test name to a bug is interesting
[10:11]  flacoste, yeah, that's a good idea. :)
[10:12]  which one: putting the guard in the view or the naming convention for tests covering corner case bug report?
[10:13]  bradb: the email interface seems very cool!
[10:14]  flacoste: it's one of the better parts of Malone, yeah. :)
[10:14]  flacoste, the guard in the view
[10:14]  glad you like it, because it's done :-)
=== salgado reads backlog to know about the other idea
[10:15]  hmmm. the naming convention sounds nice too. although it may be a problem if you're working offline
[10:16]  putting in comments the summary of the bug would probably be appropriate
[10:16]  if we could make sure every test had at least a very basic docstring, it won't be a problem
[10:16]  yeah, agreed
[10:19]  when i said "linking" i didn't mean URLs :)
[10:19]  i mean using names to describe things clearly
[10:19]  it's useful, IMHO, to be able to know what regression, e.g., which bug, a test is preventing by reading its name
[10:20]  s/"linking"/"links"/
[10:46]  salgado-brb: do you what to take a look at the new branch or should I submit it to PQM?
=== bradb_ [n=bradb@modemcable092.66-130-66.mc.videotron.ca]  has joined #launchpad
=== ploum [n=Ploum@ubuntu/member/ploum]  has joined #launchpad
[11:01]  where do I find the documentation on how to submit a request to PQM?
=== cprov [i=cprov@200-171-140-32.dsl.telesp.net.br]  has joined #launchpad
[11:02]  https://launchpad.canonical.com/PQMInstructions seems not up to date
[11:02]  flacoste: The best way to do it is to use pqm-submit plugin for bzr
[11:03]  tnx!
[11:03]  flacoste, sure, I can have a quick look
[11:03]  carlos: where do I find this plugin?
[11:03]  do you want me to send you the diff? 
[11:04]  flacoste, http://bzr.arbash-meinel.com/plugins/pqm-submit/
[11:04]  flacoste, or just paste it on chinstrap
[11:04]  salgado: how does pasting chinstrap work?
[11:05]  flacoste, you can do a bzr diff | utilities/paste (if you've already read that script and have a file with the user/password)
[11:05]  flacoste, otherwise you can just use https://chinstrap.ubuntu.com/~dsilvers/paste/
=== ploum [n=Ploum@ubuntu/member/ploum]  has joined #launchpad
[11:08]  salgado: do you prefer a diff to what you saw or the complete diff?
[11:09]  I guess just a diff from what I saw
[11:09]  whatever is easier
[11:10]  it will be the complete diff
[11:10]  salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filedDDF8X.html
[11:15]  flacoste, I think the check would be better done inside the view's initialize() method
[11:16]  does a LaunchpadView has a initialize method?
[11:16]  yes
[11:16]  lib/canonical/launchpad/webapp/publisher.py
[11:16]  ok, can be done
[11:18]  because I think what's expected from a process() method is to actually process the submitted data, while the check would be something that always needs to be performed
[11:19]  indeed
[11:19]  i'll move it to a initialize method
[11:19]  slightly cleaner might be to have a process_form method, which calls a validate and process method
[11:19]  because intialize isn't really any better a place for validation code, IMHO
[11:20]  (and at least it would smell more like a GeneralFormView)
[11:20]  another thing... you've changed ticket-makebug.pt to use 4 spaces of indentation. although we definitely have lots of templates using 4 spaces of indentation, I think we're only using 2 spaces now
[11:21]  bradb, that's not really validation of the form, the check we're talking about
[11:21]  it checks if the page should be rendered or if the user should be redirected
[11:21]  salgado: yes, the space is a mess up caused by adding a conditional and then removing it
[11:22]  i should have reverted before putting my changes in
[11:23]  salgado: ah, ok
=== scott [n=scott@syndicate.netsplit.com]  has joined #launchpad
[11:26]  salgado: thanks for the review! i'll implement those changes and submit it to PQM on monday
=== flacoste got to run now
[11:26]  flacoste, you're welcome! nice work, btw. :)
[11:26]  tnx! pair programming with bradb yesterday jumpstarted the whole thing!
=== Keybuk [n=scott@syndicate.netsplit.com]  has joined #launchpad
[11:27]  we were agile
[11:27]  (tm)
[11:27]  good week-end everybody!
[11:28]  bradb: have a nice trip to Paris and see you in London!
[11:28]  flacoste: thanks, see you there :)
=== salgado is leaving too
[11:29]  see ya!
[11:29]  znarl, elmo: ping
[11:29]  uh, ww
=== flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca]  has left #launchpad ["Bye"] 
[11:33]  Keybuk: what is that mail you sent me about?
[11:33]  no idea, something about bzrk it looked like
[11:34]  it looks like nothing to me, there's no attachement to your mail
=== scott [n=scott@syndicate.netsplit.com]  has joined #launchpad
=== kjcole [n=kjcole@ubuntu/member/kjcole]  has joined #launchpad
=== Seveas [n=seveas@ubuntu/member/seveas]  has joined #launchpad