[12:05] <bradb> oh...for *the* entertainment
[02:13] <jordi> mdke: the Chinese is probably valid
[02:13] <mdke> heya
[02:13] <jordi> The Spanish variants aren't most probably
[02:13] <jordi> hey
[02:13] <jordi> just came back from the concert
[02:14] <jordi> tomorrow will be a loooong day I'm afraid
[02:14] <mdke> friday :)
[04:08] <jamesh> spiv: ping?
[04:31] <spiv> jamesh: pong
[04:32] <jamesh> 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] <jamesh> 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] <spiv> jamesh: http://www.python.org/moin/PythonSoftwareFoundationLicenseFaq
[04:34] <spiv> (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] <jamesh> okay, so search+replace is the answer
[04:36] <spiv> jamesh: Although as that FAQ mentions, the PSF licence is not actually an appropriate initial license for contributions to Python.
[04:36] <jamesh> yeah
[04:40] <jamesh> the legal opinions of the MIT license I've heard are that it includes a patent grant
[05:01] <jamesh> spiv: do you think bazaar.launchpad.net/~launchpad/tickcount/devel would be a good name for the branch on the supermirror?
[05:02] <spiv> jamesh: Seems ok.  I wonder if it's worth having a tickcout team to own it instead of launchpad?
[05:02] <spiv> tickcount, rather :)
[05:02] <spiv> Yeah, the thing about not accepting MIT licenses is interesting, I didn't know that.
[05:03] <jamesh> especially since both AFL and Apache licenses are GPL incompatible ...
[05:03] <spiv> Although does the MIT licence probably give you enough scope to relicense with one of the acceptable ones?
[05:06] <jamesh> 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] <jamesh> so it lets you do pretty much anything except claim you wrote it
[05:07] <jamesh> 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] <spiv> 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] <spiv> (which probably will never happen, but who knows...)
[05:15] <jamesh> 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
[05:19] <spiv> Yeah.
[05:20] <jamesh> hmm.  product registrants don't seem to be able to change the registrant anymore
[05:21] <spiv> I think there's a bug open on that.
[05:22] <jamesh> yeah.  Looks like carlos locked it down to protect a particular view
[05:25] <spiv> Well, if the tests passed... ;)
[08:00] <spiv> SteveA: ping... infrastructure voip call now?
[08:05] <stub> mmm
[08:06] <spiv> I have to go in about 25 minutes...
[08:10] <spiv> stub: did you get my cherrypick request for the authserver?
[08:11] <stub> spiv: yes. Distracted on other things atm though. Should go out later today.
[08:11] <spiv> stub: wonderful, thanks!
[08:28] <stub> Anything thrilling we should be discussing in the infrastructure call?
[08:28] <stub> I've got nothing to add except work on the test runner is in progress.
[08:29] <jamesh> 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] <spiv> Nothing springing to my mind.
[08:39] <stub> 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] <jamesh> stub: yeah, and the wiki says that the Python license is not the correct license.
[08:43] <stub> And it says what the correct license is?
[08:43] <jamesh> they list the AFL and Apache 2.0 public license
[08:43] <jamesh> as acceptable ones
[08:44] <stub> bad wiki
[08:45] <jamesh> http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq <- "Why can't I contribute code under the PSF License?"
[08:49] <stub> Bah. I don't like any licence longer than a paragraph. They just cause headaches and arguments.
[08:49] <jamesh> the choice of acceptable licenses seems to be constrained to those with an explicit patent grant
[08:55] <jamesh> stub: did you manage to solve the slowness with pushing to bazaar.launchpad.net?
[08:56] <jamesh> it seemed about as fast as I'd expect when I tested it
[08:57] <stub> 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] <jamesh> stub: the number of files you listed under .bzr sounded like a lot for weaves
[08:57] <stub> It was knit format
[08:57] <jamesh> stub: It should be 2*number of files in repo + constant
[08:58] <stub> Branch is here if you think you can make sense out of it: https://launchpad.net/people/stub/+branch/pytz/devel
[08:59] <sivang> morning
[09:02] <jamesh> stub: doing a "bzr branch" of that branch just gives 215 files, which seems reasonable
[09:02] <stub> Weird...
[09:03] <stub> They are almost all in .bzr/repository
[09:03] <jamesh> I wonder what else is in that repository?
[09:03] <stub> repository/knits in fact
[09:04] <jamesh> $ find .bzr/repository/knits -type f | wc -l
[09:04] <jamesh> 196
[09:04] <jamesh> so that's 98 files (since there is a knit and a knit index for each one)
[09:07] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/fileJIDj7e.html
[09:23] <jamesh> stub: here's the difference between your directory listing and what I saw: https://chinstrap.ubuntu.com/~dsilvers/paste/file99dQiu.html
[09:26] <stub> If I bzr push, I get a branch containing 1400+ knits. If I bzr branch, I get a branch containing 196 knits.
[09:26] <stub> mpool: Have I broken something again?
[09:28] <stub> I shouldn't be allowed near computers
[09:29] <jamesh> the real question is what is in those 1200 extra knits
[09:30] <stub> Are knits binary format or a text format compressed?
[09:31] <stub> Ahh... gzipped
[09:31] <SteveA> morning
[09:32] <SteveA> hi folks.  i overslept.  sorry bout that.
[09:32] <stub> Hmmm.... very weird. It looks like files from a different branch in the same old arch repository
[09:35] <stub> 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] <stub> And that information was even preserved when converting the weaves to knits using bog standard 'bzr update'
[09:36] <stub> SteveA: jamesh first time, me second time, so it looks like spiv is due to be late next ;)
[09:36] <stub> SteveA: We declared the call boring anyway
[09:37] <stub> And IRC chats are more productive because nobody knows you are drinking beer
[09:38] <SteveA> jamesh: please put the tickcount stuff under the LGPL.  We'll relicence it later if it gets into the standard library.
[09:41] <SteveA> although, the MIT would do just as well
[09:45] <jamesh> SteveA: done.  It is available here: https://launchpad.net/people/launchpad/+branch/tickcount/devel
[09:45] <SteveA> spiv: how's sftp stuff going?
[09:45] <jamesh> (hasn't been pulled from the SFTP server yet though
[09:46] <stub> So that error message actually means 'I haven't gotten around to mirroring this yet'? Is that an open bug anyone?
[09:47] <jamesh> I think it means "I tried to mirror it, but it hadn't been fully pushed to the supermirror at the time
[09:47] <jamesh> i.e. unfortunate timing
[10:02] <lifeless> moining
[10:15] <stub> spiv: authserver updated
[10:18] <lifeless> stub: its not a bug
[10:18] <lifeless> stub: it means what jamesh says and it will correct it self normally
[10:18] <lifeless> the inclusion of the local path in the error is a bug and there is one open on it
[10:19] <stub> lifeless: Any thoughts on the extra 1200 knits issue in your scrollback?
[10:20] <lifeless> what issue ?
[10:20] <lifeless> (scrollback is long, give me a time delta or a summary)
[10:22] <stub> 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] <stub> The extra knits appear to be from other branches in the old arch repository
[10:23] <stub> 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] <lifeless> bzr version ?
[10:24] <stub> 0.8.2
[10:24] <lifeless> fixed in .dev I believe
[10:24] <stub> The conversion from arch would have been an earlier version though
[10:24] <lifeless> https://launchpad.net/products/bzr/+bug/43713
[10:24] <Ubugtu> Malone bug 43713 in bzr "bzr branch clones too much" [High,Fix released]  
[10:25] <stub> This is not repositories
[10:25] <lifeless> it is under the hood
[10:25] <stub> ok
[10:26] <stub> branch seems to remove the surious knits, but push doesn't. Could it have been fixed for branch only?
[10:26] <lifeless> no
[10:27] <lifeless> this is the vlone logic:
[10:27] <lifeless>             dir_to = br_from.bzrdir.clone(location_url,
[10:27] <lifeless>                 revision_id=br_from.last_revision())
[10:27] <lifeless> the revision_id parameter is the key one to make this be fixed.
[10:27] <stub> ok
[11:32] <highvoltage> hi #launchpad
[11:33] <highvoltage> if i want to add myself to a meeting for in paris, do i subscribe to the meeting in launchpad?
[11:33] <highvoltage> or is there another way i should join?
[11:34] <SteveA> 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] <highvoltage> SteveA: thanks, will do.
[11:38] <highvoltage> i don't want to oversusbscribe to meetings right now, just to the meetings that i am very, very interested in.
[11:38] <highvoltage> if there's a gap on a day, can i attend a meeting?
[11:39] <highvoltage> or do i absolutely have to subscribe now in order to be able to attend?
[11:40] <SteveA> the conference organisers will use an automated scheduling program to schedule the meetings and attendees
[11:40] <SteveA> and each person will get an webpage with their own meetings on it for the day
[11:41] <SteveA> so, if you want to take advantage of this, you should subscribe
[11:41] <SteveA> if not, i expect you can just turn up to meetings, provided there is enough space around the table
[11:42] <highvoltage> ok, thanks for the tip.
[11:43] <lifeless> hmmm, the roadmap is a little borked
[11:45] <SteveA> lifeless: context-free non-sequiteur
[11:47] <lifeless> the roadmap in the sprint app within launchpad is not doing an effective sort
[11:51] <SteveA> lifeless: is it something we should get fixed before the paris meeting?
[11:52] <lifeless> probably not - its an implementation roadmap not a meeting scheduling map, AFAICT
[11:52] <lifeless> as long as the meeting scheduler takes priority into account it will be fine.
[11:52] <lifeless> but we should fix it before the sprint ends :)
[11:54] <SteveA> jamesh: ping
[11:55] <SteveA> lifeless: i don't have mental bandwidth to look into it / understand it right now.
[11:55] <SteveA> but maybe you and james can establish whether the scheduler will work as intended
[11:55] <SteveA> and file a bug for what should change
[11:55] <SteveA> the roadmap table is certainly meant to be about implementation
[11:58] <jamesh> SteveA: pong
[11:58] <jamesh> the scheduler algorithm uses the priorities
[11:58] <SteveA> jamesh: would you read the last 15 lines of scrollback, and see if we need to file a spec tracker UI bug?
[11:58] <Yannig> Hello everybody
[12:03] <LarstiQ> has anyone seen the python.org call for trackers? http://wiki.python.org/moin/CallForTrackers
[12:04] <SteveA> yes
[12:05] <SteveA> we'll be submitting an entry for launchpad
[12:05] <jamesh> 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] <jamesh> lifeless: it doesn't do anything with priorities
[12:06] <lifeless> jamesh: yes, I know :)
[12:06] <jamesh>         # XXX sabdfl 2006-04-07 this is incomplete and will not build a
[12:06] <jamesh>         # proper comprehensive roadmap
[12:06] <lifeless> jamesh: it should start with priorities, then backfile in the dependencies, traversing in priority order
[12:06] <lifeless> as a depth first search
[12:07] <jamesh> yep
[12:16] <adrighem> Hi all.
[12:17] <adrighem> I want to set up a "GNOME Translation group" in rosetta, but don't see how this can be done.
[12:18] <adrighem> The page says "Only Official coordinators will be able to add you to the GNOME teams in Rosetta."
[12:18] <LarstiQ> hey vincent
[12:18] <adrighem> ehhh, hi?
[12:18] <LarstiQ> adrighem: what, we visit the same faculty and you don't recognise me! ;)
[12:18] <adrighem> Oh, okay. 
[12:19] <LarstiQ> adrighem: you're part of the gnome nl translation team, right?
[12:19] <adrighem> LarstiQ: not only part, I'm the coordinator...but rosetta doesn't seem to agree.
[12:20] <LarstiQ> carlos: awake?
[12:20] <carlos> LarstiQ: hi
[12:20] <LarstiQ> carlos: can you help adrighem?
[12:20] <carlos> LarstiQ: sure, I didn't see his request ;-) Thanks
[12:20] <adrighem> Hi carlos. Can you create a dutch gnome team in rosetta?
[12:21] <adrighem> (nl)
[12:21] <carlos> adrighem: atm is a bit useless to do it because we are not importing GNOME's products
[12:21] <carlos> adrighem: but is ok to setup it now so you have it ready when we start doing those imports
[12:21] <LarstiQ> what are those imports waiting on?
[12:21] <adrighem> carlos: my thought exactly. ;)
[12:21] <carlos> adrighem: I guess you are the official coordinator in GNOME, right?
[12:21] <adrighem> carlos: yup
[12:22] <carlos> LarstiQ: having more time from me to expend on it...
[12:22] <LarstiQ> carlos: ah :)
[12:23] <carlos> adrighem: ok, confirmed that you are the coordinator
[12:23] <carlos> adrighem: did you create already a team in launchpad for that?
[12:23] <adrighem> carlos: no. I did not do that.
[12:23] <carlos> if the answer is no, please do it, naming it gnome-l10n-nl
[12:24] <carlos> so you are the owner of the team
[12:24] <carlos> and I will add it to the GNOME translation project group
[12:24] <adrighem> carlos: will do...one moment please.
[12:24] <carlos> adrighem: it should be a moderated team
[12:24] <carlos> so you only approve people that work with you in GNOME
[12:24] <carlos> and only those ones
[12:25] <carlos> 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] <carlos> so you have full control of that team
[12:26] <adrighem> carlos: that's nice to know.
[12:29] <adrighem> carlos: the team has been created.
[12:30] <carlos> just a secon
[12:35] <carlos> second ;-)
[12:35] <carlos> I had a phone call
[12:35] <carlos> adrighem: done
[12:39] <adrighem> Ooooh, lemme check...
[12:42] <adrighem> carlos: thanks.
[01:03] <adrighem> And I am gone...
[01:09] <Kinnison> SteveA: There are tests for bug 47770 on my branch now
[01:09] <Ubugtu> Malone bug 47770 in launchpad-publisher ""raw-dist-upgrade" target does not support pockets" [Medium,In progress]  http://launchpad.net/bugs/47770
[01:09] <Kinnison> SteveA: care to have a look?
[01:10] <Kinnison> https://chinstrap.ubuntu.com/~jamesh/pending-reviews/dsilvers/launchpad-repo/launchpad/bug-47770/full-diff
[01:10] <SteveA> Kinnison: yes, but not right now.  just off to lunch with bjorn
[01:11] <Kinnison> okay
[01:11] <Kinnison> thanks for the organisation yesterday btw
[01:11] <Kinnison> twas v. useful
[01:11] <SteveA> np
[01:58] <salgado> anybody up for a quick code review?
[02:01] <lifeless> sure
[02:05] <salgado> cool!
[02:05] <salgado> lifeless, https://chinstrap.ubuntu.com/~dsilvers/paste/fileFU4ZRj.html is to fix bug 48608 and a few other trivialities
[02:06] <salgado> (https://launchpad.net/products/shipit/+bug/48608)
[02:06] <LarstiQ> bogus product: https://launchpad.net/products/pssrajan
[02:07] <lifeless> salgado: 'for Macs' is a ittle misleading : it wont work on MacbookPlus
[02:09] <ddaa> "For Macs that are neither too new or too old, or for other computers that are like those Macs inside"?
[02:09] <salgado> 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] <lifeless> does dvds_portlet return an HTML fragment or a tal fragment ?
[02:12] <salgado> HTML
[02:17] <lifeless> mailed to lp-reviwes.
[02:17] <lifeless> meh, thingy
[02:17] <lifeless> basically good, but missing tests.
[02:17] <lifeless> and I *know* that *you* know better.
[02:19] <salgado> you mean, tests for the changes I've done?
[02:19] <lifeless> specifically the DVD portlet
[02:19] <lifeless> it could be broken and we'd never know
[02:20] <jelmer> Strange - if I'm logged in, I can't access bug 38801, but if I log out, I can.
[02:20] <Ubugtu> Malone bug 38801 in nunit "nunit broken when using .Net 2.0 library" [Unknown,Unknown]  http://launchpad.net/bugs/38801
[02:20] <salgado> 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] <lifeless> no, I mean, say the including template gets changed
[02:20] <lifeless> i.e. by a bad merge resolution.
[02:21] <lifeless> there are no tests that ensure the dvd templates are shown in the output for ubuntu/kubuntu and not for edubuntu.
[02:22] <salgado> 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] <lifeless> right
[02:22] <lifeless> this is our current style of testing.
[02:22] <lifeless> and as such its fine ;).
[02:23] <salgado> 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] <lifeless> sure. my main concern here is that there be a test which will fail if the new feature stops doing what its meant to
[02:49] <ddaa> lifeless: SteveA: can we have a quick meeting?
[02:49] <SteveA> ddaa: okay
[02:50] <ddaa> -> #launchpad-meeting
[02:59] <cprov> salgado: hi, will matsubara be around today or is he gone already ?
[03:00] <salgado> cprov, he's gone. he switched today with yesterday (which was a holiday)
[03:00] <cprov> salgado: uhm, okay. what about you ?
[03:00] <salgado> I switched monday with yesterday.
[03:02] <cprov> 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] <Ubugtu> Malone bug 49789 in xorg "Clicking on Codes of Conduct link in Launchpad crashes X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49789
[03:03] <salgado> sure
[03:04] <cprov> salgado: we don't have any nvidia card at office, do we ?
[03:05] <salgado> we do
[03:07] <SteveA> salgado: is kiko around?
[03:08] <salgado> SteveA, no
[03:09] <cprov> 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] <flacoste>  salgado: i see on PendingReviews that you have been assigned as my reviewer for my first bug patch!
[03:16] <flacoste> salgado: when do you think you will have time to take a look at it?
[03:18] <salgado> 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] <flacoste> thk! no its small, the biggest changes are to the tests that were modified to use testbrowser
[03:19] <salgado> 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] <cprov> salgado: okay, I'd do it myself if you have time for just confirming it.
[03:21] <salgado> 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] <salgado> anyway, I'm turning another box on because I don't want mine to crash
[03:27] <cprov> 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] <salgado> okay, so it doesn't crash my box with an nvidia card
[03:29] <cprov> salgado: but the pages still scrolling horizontally, doesn't it ?
[03:29] <salgado> yes, it does
[03:32] <cprov> salgado: do you think the <pre> idea would make it any better ?
[03:35] <salgado> cprov, probably, but I'm not sure it'd make it not crash
[03:35] <salgado> I'll try to test it with the proprietary nvidia driver
[03:37] <cprov> salgado: ahh, it might be the case of those guys, indeed
[03:45] <flacoste> who do I change the status of a bug in launchpad?
[03:46] <salgado> flacoste, you should have
[03:47] <flacoste> i thought too, maybe I'm just blind this morning, what is the GUI control that I should use?
[03:47] <salgado> flacoste, you have to click on the "Affects" column, to change its status
[03:47] <flacoste> wow! 
[03:47] <salgado> and it's not because you're blind. it's because it's well hidden. :/
[03:47] <flacoste> found it, thanks!
[03:48] <flacoste> indeed, i would never have guessed it!
[04:12] <bradb> 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] <bradb> bug 1095
[04:13] <Ubugtu> 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] <flacoste> what's the rationale for keeping it hidden?
[04:13] <bradb> flacoste: I'm not sure.
[04:14] <bradb> flacoste: cool!
[04:14] <flacoste> i'm installing it now
[04:14] <bradb> I'm switching my desktop to KDE right now, for kicks.
[04:14] <bradb> I installed kubuntu on another machine yesterday, for more kicks
[04:14] <flacoste> brabd: (the plugin not your switch)
[04:15] <SteveA> bradb: ping
[04:16] <lifeless> ddaa: there are many possible failure conditions for the branch scanner.
[04:16] <lifeless> using get_revision_reconcile is a bad idea. Its designed solely for reconcile to use.
[04:16] <ddaa> lifeless: so far I assumed there were none. If the data got through the branch puller, it was valid.
[04:16] <ddaa> BTW
[04:17] <lifeless> EBADASSUMPTION. The data will be valid. That does not mean the scanner cannot fail.
[04:17] <lifeless> 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] <ddaa> puller crash: I thought bzr was designed to keep data consistent at all times
[04:19] <ddaa> puller server crash: it's a transient failure mode, there's already a case in the code to handle connection failures.
[04:19] <ddaa> etc.
[04:19] <ddaa> lifeless: you are giving ways the code can fail because of deployment issues and bugs
[04:20] <ddaa> I was saying that the branch scanner should not normally fail.
[04:20] <ddaa> different issues
[04:20] <ddaa> 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] <flacoste> newbie question: how do I generate a TAGS file for the launchpad project?
[04:21] <ddaa> make tags
[04:21] <ddaa> hu, sorry: make TAGS
[04:21] <flacoste> right!
[04:21] <lifeless> ddaa: I think it is unwise to use unsupported apis in bzr in the branch scanner.
[04:21] <flacoste> thanks!
[04:22] <lifeless> beyond that its your call.
[04:23] <ddaa> sure, that sounds bad
[04:23] <lifeless> get_revision_reconcile is not a supported api.
[04:23] <ddaa> lifeless: is there a way to avoid putting corrupt data in the supermirror?
[04:23] <lifeless> its not corrupt.
[04:24] <lifeless> its almost certain that you are hitting those branches during the middle of a pull by the supermirror
[04:24] <ddaa> well, CorruptRepository make it sound like something is corrupt
[04:24] <ddaa> lifeless: no
[04:24] <ddaa> this is a repeatable error we have with several branches
[04:24] <lifeless> I suspect that nuking the mirrored copy will correct this
[04:24] <bradb> 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] <lifeless> or running bzr reconcile on them by hand
[04:25] <carlos> bradb: I only use mawson as a gateway to asuka and I'm using my own lp tree
[04:25] <carlos> bradb: so don't worry about my scripts
[04:25] <ddaa> lifeless: I guess so, but I'd rather not run bzr reconcile on vostok
[04:25] <SteveA> kiko-afk: ping
[04:25] <ddaa> lifeless: I'm interested in way to _prevent_ that situation from occuring
[04:26] <ddaa> lifeless: so it does not become yet another operational nightmare
[04:26] <lifeless> ddaa: bzr pull prevents it since 0.8
[04:26] <bradb> carlos: cool
[04:26] <cprov> bradb: there is a RF HEAD work tree there, have fun, I'm not using it right now
[04:27] <ddaa> lifeless: ah, nice. I'll give you a command line to run on vostok to clear the data
[04:36] <bradb> cprov: thanks
[04:54] <BjornT> SteveA, kiko-afk: https://chinstrap.ubuntu.com/~dsilvers/paste/filehugREW.html
[05:04] <BjornT> kiko-afk: the issued sql queries: https://chinstrap.ubuntu.com/~dsilvers/paste/filerhVQre.html
[05:12] <flacoste> bradb_: the CTAGS plugin isn't up to date with the latest kate API -> doesn't compile :-(
[05:14] <bradb_> flacoste: bummer
[05:24] <salgado> flacoste, BjornT, I have a question about the support tracker:
[05:24] <salgado> can I link more than one bug to a single ticket?
[05:24] <flacoste> you should be able to yes
[05:25] <flacoste> the bugs attribute is a list
[05:25] <flacoste> so if the interface doesn't let you, it's a bug
[05:25] <flacoste> you can only create one bug from a support request though
[05:26] <salgado> right, and this is because the bug is created using the ticket's title and subject, verbatim?
[05:26] <salgado> then it wouldn't make sense to create two identical bugs
[05:37] <jordi> carlos?
[05:37] <carlos> jordi: ?
[05:38] <kiko-afk> salgado, can't you edit them?
[05:38] <kiko-afk> BjornT, looking
[05:39] <salgado> kiko, not when filing the bug from a ticket
[05:39] <kiko> salgado, flacoste: that sounds wrong to me!
[05:39] <BjornT> kiko: the problem seems to be caused by the owner being None for the missing message
[05:40] <kiko> BjornT, is message.owner not null?
[05:40] <flacoste> kiko: file a bug on launchpad-support-tracker :-)
[05:40] <kiko> flacoste, doing so as we speak
[05:41] <kiko> BjornT, so message.owner is not null in message.py
[05:41] <kiko> BjornT, that's why a regular join is emitted
[05:41] <kiko> instead of a left outer join
[05:41] <kiko> BjornT, can you change that and try again?
[05:41] <kiko> BjornT, alternatively, enforce message.owner is not null in the database!
[05:42] <BjornT> kiko: ok, i'll try to change that.
[05:42] <kiko> BjornT, do you know if message.owner is really nullable?
[05:44] <BjornT> 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] <kiko> will do so now.
[05:45] <SteveA> even so, it is surely a bug that foo.count() differs from len(list(foo))
[05:46] <kiko> SteveA, do you understand why it happens?
[05:46] <BjornT> removing notNull=True fixes the problem.
[05:46] <kiko> BjornT, sure.
[05:48] <kiko> SteveA?
[05:49] <SteveA> what?
[05:49] <kiko> do you understand why it happens?
[05:49] <SteveA> no
[05:49] <SteveA> i can look at the code
[05:49] <kiko> ok. do you want to call me to follow up on other stuff as well?
[05:50] <kiko> SteveA?
[05:50] <SteveA> sure, we can have a call
[05:50] <kiko> ring rin
[05:52] <SteveA> kiko: looks like a prejoin bug
[05:52] <kiko> SteveA, not necessarily, but maybe.
[05:52] <SteveA> it's sticking WHERE terms where they don't belong
[05:52] <kiko> what?
[05:53] <SteveA> (Pdb) bug_two.messages.count()
[05:53] <SteveA> 3
[05:53] <SteveA> WHERE Message.id = BugMessage.message and
[05:53] <SteveA>     BugMessage.bug = Bug.id and
[05:53] <SteveA>         Bug.id = 2
[05:53] <SteveA> 
[05:53] <SteveA> (Pdb) len(list(bug_two.messages))
[05:53] <SteveA> 2
[05:53] <SteveA> WHERE
[05:53] <SteveA> _prejoin0.id = Message.owner AND  Message.id = BugMessage.message and
[05:53] <SteveA> BugMessage.bug = Bug.id and
[05:53] <SteveA> Bug.id = 2
[05:53] <SteveA> 
[05:53] <kiko> SteveA, as I told BjornT, the database schema is wrong
[05:54] <kiko> BjornT, there are no messages with null owners in the database.
[05:54] <SteveA> the prejoin stuff should barf rather than give incorrect results, then
[05:54] <kiko> SteveA, let me think about this for a second.
[05:54] <SteveA> kiko: office or mofo?
[05:54] <kiko> office
[05:54] <kiko> BjornT, you can add the not null constraint.
[05:57] <BjornT> 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.
[06:06] <doko> carlos: ping
[06:07] <carlos> doko: pong
[06:09] <doko> carlos: about the helpcontent2 statistics, did people translate any significant part?
[06:10] <carlos> 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] <carlos> doko: I would say... Ignore the updates from Rosetta and build new language packs now and we will include them later
[06:11] <doko> ok
[06:32] <bradb> 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] <lifeless> rockin
[06:37] <ddaa> bradb: embrace the love of Thunderbird
[06:37] <ddaa> least aggravating GUI mail client I have tried so far
[06:37] <bradb> phew, restarting kmail brought them back
[06:38] <bradb> applying filters on all messages in kmail over imap makes it behave in ways i've never seen any mail app behave before
[06:39] <ddaa> some mail client seem to have trouble with the notion that IMAP is meant to be _online_
[06:45] <kiko> offline imap is scary
[06:45] <sivang> ddaa: problems with evo?
[06:46] <ddaa> 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] <ddaa> leaving around spamd instances when crashing
[06:47] <ddaa> incredibly slow when processing massive numbers of messages
[06:48] <ddaa> storing state outside of the IMAP data
[06:48] <ddaa> (and losing it sometimes)
[06:52] <bradb_> 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] <lifeless> ddaa: I have few problems but they annoy the heck out of me when they happen
[06:56] <lifeless> ddaa: Ihave 47K messages in INBOX
[06:56] <ddaa> lifeless: evo is fast when it has generated its caches
[06:57] <ddaa> but some operations (e.g. setting the label on several thousand messages) and building the caches take forever
[06:58] <kiko> bradb, BjornT, for the record, fixed bug 1555; just submitted off to spiv for review.
[06:58] <Ubugtu> Malone bug 1555 in launchpad "BugMessage.selectOneBy doesn't work as expected" [Medium,Confirmed]  http://launchpad.net/bugs/1555
[06:58] <ddaa> 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] <lifeless> I'm offline until paris, phone/sms me in emergencies and I'll arrange 'net.
[07:16] <sivang> lifeless: have a nice trip, see you there :)
[07:46] <SteveA> carlos: ping
[07:47] <carlos> SteveA: pong
[07:47] <SteveA> kiko: ping
[07:54] <SteveA> kiko: ping
[08:03] <kiko> SteveA, pong
[08:03] <kiko> what's up?
[08:19] <Ubugtu> Malone bug 45310 in bzr "Branching large repository uses a ridiculous amount of RAM" [High,Unconfirmed]  http://launchpad.net/bugs/45310
[08:19] <flacoste> s/gives/gives up/
[08:40] <bradb_> now kmail is turning my messages into zombies!
[08:40] <bradb_> I click on a message, and suddenly it says "No Subject" and "Unknown" sender
[08:42] <flacoste> bradb_: what is your IMAP server?
[08:42] <bradb_> pobox
[08:42] <flacoste> hmm, i don't know about that one
[08:42] <bradb_> this is a disaster
[08:43] <flacoste> bradb_: look into the the server settings, there might be an option in there to tweak the protocol usage...
[08:43] <flacoste> (in kmail, i mean)
[08:44] <bradb_> flacoste: have you ever seen this kind of thing?
[08:45] <flacoste> i have seen messages "disappearing" from the inbox with UW-Imap when a mailbox was accessed from two clients
[08:45] <flacoste> (it only disappeard in the GUI though)
[08:47] <kiko> I use mbox and mutt
[08:47] <kiko> 1970s technology that WORKS
[08:48] <bradb> kiko: i need imap though
[08:49] <kiko> "need"
[08:49] <bradb> soho business owner, on the go, etc.
[08:49] <kiko> as I said "need"!
[08:49] <SteveA> bradb: soho business owner?
[08:49] <SteveA> like a strip-club magnate?
[08:49] <bradb> i hope nobody took that last statement seriously :P
[08:49] <kiko> poker table enterpreneur
[08:50] <bradb> heh
[08:50] <bradb> i haven't played in too long
[08:50] <bradb> NO SUBJEFAT GAH
[08:52] <kiko> less pitiful than mine with 500 incoming
[08:53] <bradb> kiko: KMail will make your problems go away
[08:54] <kiko> yeah I believe you
[09:05] <kiko_bsb> salgado, yes, correct.
[09:14] <salgado> what beneffits would we have by doing that?
[09:14] <salgado> kiko_bsb, ^
[09:14] <salgado> benefits too
[09:16] <kiko_bsb> salgado, doing it in the same way as everybody else does?
[09:20] <salgado> 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] <kiko_bsb> salgado, well, I don't know about "every callsite"
[09:22] <kiko_bsb> how many callsites would you have to change?
[09:22] <kiko_bsb> I think it makes the distribution nicer to set up
[09:22] <kiko_bsb> no need to worry about this stuff until it becomes necessary
[09:23] <kiko_bsb> anyway, that's just a fluff comment
[09:23] <kiko_bsb> but you /are/ being inconsistent from bug and security contact
[09:23] <kiko_bsb> fwiw
[09:23] <kiko_bsb> IMNBWAGD though
[09:24] <salgado> there's at least three callsites, as we're doing the permission check manually
[09:24] <flacoste> salgado: regarding the warning message to the user accessing the +makebug page when there are already bugs linked to it
[09:25] <flacoste> I place the message in a div with class="warning message" ?
[09:27] <salgado> maybe just informational message
[09:27] <salgado> hmmm. I'm not sure
[09:28] <salgado> that's a question for the great mpt!
[09:28] <flacoste> he's in a sprint now
[09:28] <kiko_bsb> well
[09:28] <kiko_bsb> think about it
[09:28] <kiko_bsb> is it a warning
[09:28] <kiko_bsb> or is it something normal?
[09:29] <flacoste> it's an error
[09:29] <kiko_bsb> there's also error message
[09:29] <kiko_bsb> I believe.
[09:29] <flacoste> 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] <salgado> or a bookmark
[09:30] <flacoste> bookmark a form?
[09:30] <kiko_bsb> just send him to jail, do not pass GO, do not collect R$200
[09:30] <flacoste> 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] <flacoste> so in that case either error or informational should be used, i think
[09:32] <kiko_bsb> I say it's an error
[09:32] <flacoste> fine, I'll use error
[09:33] <salgado> 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
[09:40] <flacoste> 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] <flacoste> 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] <flacoste> bradb: is there a mail interface to Malone?
[09:49] <flacoste> (like debbugs)?
[09:50] <bradb> flacoste: yeah
[09:51] <bradb> flacoste: https://help.launchpad.net/UsingMaloneEmail
[09:52] <flacoste> great!
[09:54] <flacoste> 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] <flacoste> Where should I put my tests: in a `test_foo.py` module, or a `foo.txt` doctest file?
[09:54] <flacoste>     *
[09:54] <flacoste>       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] <flacoste>       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] <flacoste> 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] <bradb> 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] <flacoste> we could added that to a tests/test_malone_bugs.py file
[09:59] <flacoste> def test_bug49891
[10:02] <bradb> 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] <bradb> I think a convention that links the test name to a bug is interesting
[10:11] <salgado> flacoste, yeah, that's a good idea. :)
[10:12] <flacoste> which one: putting the guard in the view or the naming convention for tests covering corner case bug report?
[10:13] <flacoste> bradb: the email interface seems very cool!
[10:14] <bradb> flacoste: it's one of the better parts of Malone, yeah. :)
[10:14] <salgado> flacoste, the guard in the view
[10:14] <flacoste> glad you like it, because it's done :-)
[10:15] <salgado> hmmm. the naming convention sounds nice too. although it may be a problem if you're working offline
[10:16] <flacoste> putting in comments the summary of the bug would probably be appropriate
[10:16] <salgado> if we could make sure every test had at least a very basic docstring, it won't be a problem
[10:16] <salgado> yeah, agreed
[10:19] <bradb> when i said "linking" i didn't mean URLs :)
[10:19] <bradb> i mean using names to describe things clearly
[10:19] <bradb> 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] <bradb> s/"linking"/"links"/
[10:46] <flacoste> salgado-brb: do you what to take a look at the new branch or should I submit it to PQM?
[11:01] <flacoste> where do I find the documentation on how to submit a request to PQM?
[11:02] <flacoste> https://launchpad.canonical.com/PQMInstructions seems not up to date
[11:02] <carlos> flacoste: The best way to do it is to use pqm-submit plugin for bzr
[11:03] <flacoste> tnx!
[11:03] <salgado> flacoste, sure, I can have a quick look
[11:03] <flacoste> carlos: where do I find this plugin?
[11:03] <flacoste> do you want me to send you the diff? 
[11:04] <salgado> flacoste, http://bzr.arbash-meinel.com/plugins/pqm-submit/
[11:04] <salgado> flacoste, or just paste it on chinstrap
[11:04] <flacoste> salgado: how does pasting chinstrap work?
[11:05] <salgado> 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] <salgado> flacoste, otherwise you can just use https://chinstrap.ubuntu.com/~dsilvers/paste/
[11:08] <flacoste> salgado: do you prefer a diff to what you saw or the complete diff?
[11:09] <salgado> I guess just a diff from what I saw
[11:09] <salgado> whatever is easier
[11:10] <flacoste> it will be the complete diff
[11:10] <flacoste> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filedDDF8X.html
[11:15] <salgado> flacoste, I think the check would be better done inside the view's initialize() method
[11:16] <flacoste> does a LaunchpadView has a initialize method?
[11:16] <salgado> yes
[11:16] <salgado> lib/canonical/launchpad/webapp/publisher.py
[11:16] <flacoste> ok, can be done
[11:18] <salgado> 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] <flacoste> indeed
[11:19] <flacoste> i'll move it to a initialize method
[11:19] <bradb> slightly cleaner might be to have a process_form method, which calls a validate and process method
[11:19] <bradb> because intialize isn't really any better a place for validation code, IMHO
[11:20] <bradb> (and at least it would smell more like a GeneralFormView)
[11:20] <salgado> 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] <salgado> bradb, that's not really validation of the form, the check we're talking about
[11:21] <salgado> it checks if the page should be rendered or if the user should be redirected
[11:21] <flacoste> salgado: yes, the space is a mess up caused by adding a conditional and then removing it
[11:22] <flacoste> i should have reverted before putting my changes in
[11:23] <bradb> salgado: ah, ok
[11:26] <flacoste> salgado: thanks for the review! i'll implement those changes and submit it to PQM on monday
[11:26] <salgado> flacoste, you're welcome! nice work, btw. :)
[11:26] <flacoste> tnx! pair programming with bradb yesterday jumpstarted the whole thing!
[11:27] <bradb> we were agile
[11:27] <bradb> (tm)
[11:27] <flacoste> good week-end everybody!
[11:28] <flacoste> bradb: have a nice trip to Paris and see you in London!
[11:28] <bradb> flacoste: thanks, see you there :)
[11:29] <salgado> see ya!
[11:29] <Keybuk> znarl, elmo: ping
[11:29] <Keybuk> uh, ww
[11:33] <ddaa> Keybuk: what is that mail you sent me about?
[11:33] <Keybuk> no idea, something about bzrk it looked like
[11:34] <ddaa> it looks like nothing to me, there's no attachement to your mail