[12:10] lifeless: could you tell me why I am getting bzr: ERROR: Revision {pqm@pqm.ubuntu.com-20060507115829-e0e65b77a04377e6} not present in inventory. [12:10] lifeless: when I do bzr st ? [12:10] lifeless: (acutally that also happend with rocketfuel-refresh) [12:10] lifeless: still due to the broken slinks in lib/zope ? [12:12] you took your rsync late last week [12:12] at just the wrong time. Like elmo says, update your rsynced copy. [12:14] lifeless: okay, I just thought to try and use bzr to recreate the symlinks :) === sivang regets RF [12:35] lifeless: if the importd key is no longer neccessary (there is not explenation why it was mentioned in the RFS doc) can we rmeove it from the document instructions and leave the pqm bit only? [12:37] I'll have a look at the page later === mpt [n=mpt@203.109.220.214] has joined #launchpad [12:39] lifeless: okay, thanks. === alexandros_se [n=alex@2-1-1-18a.spa.sth.bostream.se] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad [12:59] well, I found on the Ubuntu wiki the idea of a gnome launchpad front-end as a google SoC [12:59] great idea [12:59] I really like it [01:00] I submitted a SoC proposition about it [01:00] if anyone want to mentor it === daq4th [n=darkness@netstation-005.cafe.zSeries.org] has joined #launchpad [01:01] hey [01:01] that is very cool ploum [01:01] I'd be happy to mentor it [01:01] cool :-) [01:02] I you are already a registered mentor, you can read it [01:02] pygtk? [01:02] indeed [01:02] I am no such thing [01:02] but I can become one [01:02] I was thinking about it p [01:02] will the licensing work? [01:02] it's just a front-end, right? [01:03] kiko: here's the submission (sorry for the formating) : http://ploum.fritalk.com/soc4.txt [01:03] ploum: I am also willing to help, I worked on LaunchpadIntegration previously, and they seem to have some in common :) [01:03] great :-) [01:03] ploum: what a great idea [01:04] mdke: I stole it on the wiki ;-) [01:04] but I found it so great, I couldn't resist to propose myself ;-) [01:04] I'm sure you can do it proud [01:05] ploum, okay, so it's a front-end only to the bug part of launchpad [01:05] so gmalone? [01:05] kiko: I was thinking to extend it also for specifications, support and translations [01:05] ah [01:05] I see [01:05] that I'm not so sure about [01:05] but the bug part is the most important IMHO [01:05] becomes fuzzier in intent [01:05] indeed [01:06] in particular because a single UI that covers translations and specs, well... it's like emacs :) [01:06] heh [01:06] kiko: that's why I wrote that it will not be a monolithic application [01:06] but you are right [01:06] the first and important part is malone [01:07] others are bonus [01:07] kiko: emacs is not _that_ bad :) [01:07] emacs is a disaster [01:08] emacs is the "thing" [01:08] there's no other word [01:09] like john carpenter's thing? [01:09] like it [01:09] :-) [01:09] I control-X control C you! [01:09] argh ! [01:10] :wq! [01:10] (that my shield) [01:10] :x! is for the eleet [01:10] :wq is so old-skool === ploum must be old school === mpt_ [n=mpt@203.109.220.214] has joined #launchpad [01:11] I always say : emacs is really faster than vim.... if you have more than 17 fingers per hand [01:11] kiko: what are you saying? emacs is the one true OS [01:11] :-D [01:11] ajmitch, obviously! === mdke prefers gedit [01:11] ajmitch: I don't agree. It lacks of a text editor [01:12] hah [01:12] doesn't it have something called viper? [01:12] I thought it did [01:12] ajmitch++ === ajmitch thinks a decent frontend to launchpad, even for malone, may work best with the xml-rpc interface [01:13] ajmitch: is there any documentation about this interface ? [01:13] I don't think the interface is really done yet :) [01:14] ploum: dig around on the LP wiki [01:14] https://wiki.launchpad.canonical.com/MaloneXmlRpcInterface [01:14] there is something about it, even if just a spec [01:16] well, now I hope that the project will be selected.. [01:16] ploum: why is that? [01:16] all the SoC code has to be for free software, too [01:16] indeed.. [01:17] ajmitch, really? [01:17] kiko: yep [01:17] -- /for/ free software? [01:17] the code *produced* has to be free software [01:18] that's what I understood too [01:18] that is what I meant [01:18] then I didn't understand your comment at all :) [01:18] ok :) [01:19] kiko: you get a t-shirt for being a mentor... [01:19] I didn't mean that they'd necessarily exclude writing an app to interface with an evil, proprietary, RMS-hating web app [01:19] oh good! [01:19] can't believe the t-shirt thing is so low down the faq [01:20] mdke, yeah, I mean, I /really/ need an extra t-shirt! [01:20] you should mentor a few projects then [01:20] mdke: I should have signed up to be a mentor then [01:21] ajmitch, are you in need of extra clothing [01:21] of course [01:21] I live in freezing dunedin [01:21] I could do with a google tie [01:21] there are other places that are inhabitable on the planet I believe [01:21] there are [01:21] dunedin isn't so bad [01:21] dunedin rocks [01:22] I'm torn between my brain telling me that dunedin must be in australia, and some kind of instinct shouting "Scotland!" [01:22] it's in middle-earth. [01:22] ah, neither [01:22] mdke: its a little bit of scotland in New Zealand [01:23] legend has it the street map is a clone of edinborough [01:23] without regarding hills at all [01:23] ah, there is one in scotland too, phew [01:23] complete with cul de sacs that in edinborough butted up against cliffs, but in new zealand make no sense [01:23] sounds cool [01:24] I wonder if lifeless meant edimburgh [01:24] err [01:24] edinburgh [01:24] or if that is the old spelling [01:25] kiko: my bad [01:25] even mpt_ decided that dunedin was the place to be [01:26] lifeless: btw I'll be in sydney for a week or so in early july [01:27] sweet [01:30] thanks mdke. kiko : in order to become a mentor, I think you just have to ask JaneW === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [01:35] (or sivang too . There must be plenty of projects ;-) ) [01:35] (and a need for a lot of mentors) [01:52] good night all [01:52] ploum: already signed, and emailed pygi where I think I can mentor :) [01:52] night ploum :-) [01:52] :-) [01:54] elmo: fresh checkout, 'make schema' works beautifully. [02:12] night all [02:34] Merge to devel/launchpad/: [r=lifeless] Fix 'make importdcheck' by using the same path hack as test.py. Made the 'importdcheck' make rule a little more consistent with others, too. (r3542: Andrew Bennetts) [02:35] Good grief. I sent that merge request almost 12 hours ago. [02:35] I asked lifeless about this and yet... no change [02:41] kiko: ? [02:41] PQM slowness? [02:41] kiko: I answered you [02:42] its reweaving on every merge, there is inconsistent data in the cloud of branches [02:42] you answered, but no change has happened yet. :) [02:42] it will be fixes by moving to knits [02:42] and that is in progress [02:42] *fixed* [02:42] I have a test knit branch up. Have you played with it ? [02:42] I emailed launchpad@ about this [02:42] I haven't had the guts but I might tomorrow [02:43] this week is review week though -- no time for anything extra [02:43] so, if you want a smooth transition, dont nag :) [02:43] knit conversions take > 24 hours and 2 gbs of RAM [02:44] I don't think I have the hardware either! [02:44] I want to be 100% sure that I have a smoother path for the devs, with no mistakes, before we move. Or nothing will get done for a week [02:44] I will have the key data preconverted, and instructions on how to use it to make your conversions much faster [02:44] (minutes or hours rather than days) [02:55] lifeless, well, I really wish we didn't take 8h to merge; could better testing on the LP tree when releasing new public versions [02:55] have helped? [02:55] no.. its a pathological behaviour in weaves [02:55] to repair all the data into canonical form is ~ 24 hours per branch [02:56] knits avoid needing to repair it [02:56] -> knits are important. === stub [n=stub@ppp-58.8.3.250.revip2.asianet.co.th] has joined #launchpad === jinty [n=jinty@94.Red-83-49-50.dynamicIP.rima-tde.net] has joined #launchpad === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad === sfllaw_ [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [05:35] I'm out phone shopping and stuff - probably 4 hours [06:24] Merge to test/launchpad/sourcecode/sqlobject/: [trivial] Make test_enum expect IntegrityError as an alternative to ProgrammingError, and disable test_mxDateTime. (r56: Andrew Bennetts) [06:25] Excellent... maybe the buildbot merge will actually work *finally*. [06:25] I guess I'll know in about 4 hours :( [06:26] lifeless: I don't understand why a merge to non-launchpad branch should still be so slow... is it re-weaving even if the launchpad branch hasn't changed? [06:30] Gooooooooooood afternoon Launchpadders! [06:38] spiv: shouldn't be. === fabbione [i=fabbione@gordian.fabbione.net] has joined #launchpad [06:40] lifeless: Hmm, that merge to sqlobject took several hours, just a merge to rocketfuel. [06:40] s/just/just like/ [06:44] lifeless: It's currently doing a buildbot merge request, so if you want to, you could take a peek and see what balleny is doing with non-launchpad merge requests. === dsas [n=dean@host86-129-8-7.range86-129.btcentralplus.com] has joined #launchpad [07:03] where does launchpad's morgue live? [07:06] lamont: You mean old packages? [07:07] spiv: yeah - packages that say "removed" but that I need the debs for. specifically linux-image-2.6.15-*-{itanium,mckinley}-smp.deb [07:07] lamont: If you look at a source package in launchpad, it has links to old versions, which have links to downloads. [07:07] https://launchpad.net/distros/ubuntu/dapper/+package/linux-image-2.6.15-19-mckinley-smp [07:07] is not helping me... === mpt_ [n=mpt@203.109.220.214] has joined #launchpad [07:07] That is a spectacularly unhelpful page :) [07:08] mpt_: lamont found this rather uninformative page https://launchpad.net/distros/ubuntu/dapper/+package/linux-image-2.6.15-19-mckinley-smp [07:09] spiv: what I want is the .deb.... clues? [07:10] lamont: https://launchpad.net/+builds/+build/178649 ? [07:11] (from the "dapper ia64" link on https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/2.6.15-19.29) [07:11] lamont: which links to https://launchpad.net/+builds/+build/178649/linux-image-2.6.15-19-mckinley [07:12] Extremely convoluted, but it appears to all be there. [07:12] so how did you get there? [07:14] https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/2.6.15-19.29 "dapper ia64" -> https://launchpad.net/+builds/+build/178649 "linux-image-2.6.15-19-mckinley-smp 2.6.15-19.29" -> https://launchpad.net/+builds/+build/178649/linux-image-2.6.15-19-mckinley === mpt [n=mpt@203.109.220.214] has joined #launchpad [07:52] jamesh: ping - review for you to do [07:53] stub: theres a review for you to do === ShadowSyntax [i=ShadowSy@219-88-18-166.dialup.xtra.co.nz] has joined #launchpad [08:50] morning [08:52] spiv: ping [08:52] SteveA: pong [08:52] let's voip [08:53] sure, just plugging in. === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === mpt [n=mpt@203.109.220.214] has joined #launchpad [09:17] spiv, yes, I showed that page to sabdfl in London [09:18] or one of its siblings, anyway [09:18] it's bug 32241 === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:44] jamesh: spiv: mpool: SteveA: lifeless: meeting in 16 mins [09:44] ddaa: thanks [09:44] where is my mind... where is my mind? === ddaa looks in the coffee pot, just to be sure [09:45] okay [09:45] way out in the water, see it swimming [09:47] SteveA: http://hg.thinkmo.de/moin/1.5?f=2d62b4450b70;file=MoinMoin/parser/wiki.py === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [09:59] jamesh: spiv: -> #launchpad-meeting === carlos [n=carlos@175.Red-88-9-38.dynamicIP.rima-tde.net] has joined #launchpad [10:10] morning [10:11] hi carlos === doko [n=doko@dslb-088-073-082-103.pools.arcor-ip.net] has joined #launchpad === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [10:30] hey guys [10:30] i have a simple question [10:31] ubuntu-x-swat has been subscribed to a bunch of bugs.. [10:31] some of these were bugs in other packages [10:31] like package foo [10:31] and ubuntu-x-swat (as team) doesn't give a shit^W^W^Wcare about foo [10:31] how do i unsubscribe the team from that bug? [10:35] fabbione: please tell me an actual package (or a URL to a package) that is subscribed, that you want to unsubscribe [10:35] SteveA: several.. how do i that? [10:36] i don't know much about bug subscription UIs, but if you give me a URL, i'll have a better chance of seeing what's going on [10:36] https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/36511 [10:36] this one for example [10:36] that's nvidia binary driver issue [10:36] and infinity takes care of them manually.. originally reported against xorg [10:37] and as swat i don't care to be subscribed to them [10:37] so i want to avoid getting extra emails etc. [10:37] and in the menu, top left, you just have [10:37] "subscribe" and "subscribe someone else"? [10:37] yes [10:37] no "unsubscribe team" [10:37] exactly [10:37] okay, that feature hasn't landed yet :-( it's being coded right now [10:37] at least make that available to the team owners [10:37] so, answer is... ask stub [10:37] oh meh dude === fabbione sighs [10:38] it's on it's way man [10:38] SteveA: i am going to add you to the kernel team and x-team just to let you understand the spam :D [10:38] or better [10:38] i will add launchpad mailing lists :P === SteveA pings stub [10:39] Yo [10:40] hi stub [10:40] so, the "unsubscribe team" UI hasn't landed in production yet [10:40] don't know if it's landed in RF [10:40] fabbione has a team he wants unsubscribed from various bugs [10:41] would you help him identify those bugs, then do it on production? [10:42] SteveA: i need to do it bit by bit [10:42] there are about 420 bugs to parse [10:42] well, stub could give you a table of subscribed bugs with some information [10:42] then you could mark that table with the ones you want unsubscribed, perhaps [10:43] or, maybe you can just give a list of bug numbers to stub [10:43] SteveA: it will still requires me to go and read all the bug... [10:43] just let me know when i can do it [10:43] so that i can avoid getting 340839483947 extra emails [10:43] bradb or kiko will be able to say when the actual UI will land [10:43] they'll be around in a few hours [10:43] Yup. I can generate reports, or if you can give me some rules I might be able to bulk unsubscribe the worst offenders (eg. all bugs targetted to package foo you don't care about) [10:45] ok i will wait for kiko and bradb and bitch them :) === sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad [10:59] sabdfl: bzr conf call? [11:03] SteveA: i'm in [11:22] ddaa: hi, around? [11:24] carlos: i expect he'll be back in 15-20 mins [11:25] SteveA: ok, thanks === Russell [n=Russell@203.190.1.180] has joined #launchpad [11:34] i have +spec question [11:36] i have a "Specification" question... after someone set new specification, who can set the Definition Status? [11:37] the registrant, or an admin? [11:41] hey carlos [11:42] ddaa: hi [11:42] ddaa: I registered the product gettext some time ago to get a bzr mirror of its cvs [11:42] right [11:42] but I detected that they moved the server to another place [11:42] how should we handle that? [11:42] there's a bug filed somewhere about that being brainded [11:42] update the information on launchpad and your scripts will handle it? [11:43] but basically you have to tell me [11:43] can someone plz answer my question? [11:44] Russell: I don't know the answer for sure, but I think the owner of the product where the spec is stored [11:44] ddaa: ok, I just told you it, what information do you need? [11:45] carlos: ok thanks a lot [11:49] carlos: the updated cvs details, as you would enter them in the form [11:49] ATM, I think you need admin to do that. [11:50] numerous historical and bad reason why this is that way [11:50] lot of hard work to fix properly [11:51] ddaa: ok, I will send you an email with that information === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad [12:19] morning all === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === mpt [n=mpt@203.109.220.214] has joined #launchpad === Russell [n=Russell@203.190.1.180] has left #launchpad ["Leaving"] === mpt_ [n=mpt@203.109.220.214] has joined #launchpad [12:48] sivang: morning [12:49] sivang: is your launchpad tree working now? [12:50] mornign carlos ! [12:50] carlos: indeed :) [12:50] spiv: ping [12:50] carlos: elmo helped me to find out that my zope/lib had been deprived of its symlinks, and became real duplicated files. [12:51] carlos: which caused the whole trouble. [12:51] lifeless: pong [12:51] what do you want done with your current reviews [12:51] will you do them in evenings? or should I reallocate now [12:51] Reallocate, please. [12:53] sivang: oh, I see [12:53] jamesh: around ? [12:53] lifeless: yeah [12:54] I've given you the branch of bjorns that was merge-conditional [12:54] hopefully you will have nothing to do there [12:54] its because andrew is on jury duty now [12:55] There shouldn't be much to worry about with that branch. [12:55] also, bradb/launchpad/malone-smallfixes/ is coming up to 4 days, can you do it today ? [12:56] I've got it open in an editor window. Will finish it off [12:56] jamesh: great, thanks === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad [01:08] BjornT: With the new pagetest infrastructure, could we move the new tests with the doctests? The new system makes really simple the mix of http tests with usual python tests so we could test a view class and at the same time, how it renders [01:08] SteveA: ^^^ [01:09] carlos: i would say, no. page tests are used to test the page on a much higher level than normal doctests do. if the view class is complex, doctests still serve a purpose. [01:09] BjornT: I'm not talking about not doing doctests [01:09] but to mix both kind of tests [01:10] so we have a single place with all tests for the same context [01:11] carlos: will it improve or reduce clarity though [01:11] carlos: in bzr we have very clear separation of 'internals' and 'rendering' issues in the test suite. [01:11] lifeless: I'm talking about the view classes testing [01:11] carlos: I think it helps myself, because its very clear where to go to analyse a internal or rendering issue, and where to put the tests. [01:11] perhaps we should move the view classes with the pagetests, don't know [01:12] carlos: yes, I know you are. [01:12] lifeless: you are right that database tests should not be mixed with the render part === ploum [n=ploum@ubuntu/member/ploum] has joined #launchpad [01:13] but a view class is part of the rendering, isn't it? [01:13] carlos: i'm not sure it will help much. the new page test system doesn't give you access to view class. [01:13] carlos: mmm, maybe [01:14] carlos: well, the view class is used to render the page, so is the database class. [01:14] BjornT: I know, but the same way I create the view class inside doctests, I could do it inside the same testing files for pagetests [01:15] BjornT: but the view class is a direct part of the way the page renders [01:15] carlos: lets ask this a different way [01:15] carlos: testing the rendering tests the page template. Testing the view tests form processing, testing the db class tests core business logic. [01:16] carlos: is it helpful to have page template tests and form logic tests in the same place ? [what does it help, what does it make easier? will it improve narrative tests?] [01:17] I think the answer is yes, you have methods there that populate the form, so you could test first the view class output and later teh rendering, if the first works and the second fails, you know the bug is with the template [01:18] if both fail, you know that the problem is in the way you process the form or you prepare the data to be rendered [01:18] s/or you prepare/or the way you prepare/ [01:19] BjornT: what do you think? [01:19] if you change the view class, sometimes, you need to fix the template [01:19] if you have both together, you can do it more easy IMHO [01:19] the database code changes is different as you are changing a public API [01:21] the view class is a public api too [01:21] (many templates to one view, many views to one content class) [01:22] lifeless, carlos: well, a view class is often used in more than one page, so the view class tests will be scattered around in pagetests/ somewhere. i think it's valuable to have specific tests for the view class in a single place, in doc/. [01:22] BjornT: I agree with you. [01:23] in fact its this Many-1, Many-1 groupings that drive the separation IMO. [01:23] BjornT: hmm, that's a good point [01:24] this drives me to the my next question, should we use the same file to document/test view and database code? [01:24] Rosetta does it, for instance, doc/pofile.txt tests both, the view and the database [01:24] definately not [01:25] IMNSHO [01:25] should we use pofile.txt and pofile-view.txt then? [01:25] for the same reason - there can be more than one view per content class [01:26] so we should ensure that tests for the content class are in one place, not scattered with each view [01:26] well, pofile.txt tests all objects defined at interfaces/pofile.py and the same for the view [01:27] that said, if there is only one view, I think its ok to put the view tests with the content class tests. [01:27] because we dont want to make the common case difficult [01:27] so you want one test file per view class? [01:28] except for the cases where we just have one single view class? === doggy [n=doggy@59.93.212.186] has joined #launchpad [01:29] carlos: what do you think, does it make sense? or is it going to make it harder to work with ? [01:30] well, I would prefer to have one single file for database code and one single file for all view testing [01:30] but I also understand that multiple views is the same use case that requires multiple files for the pagetests [01:31] lifeless: if we do such split, I would prefer to have something like doc/views/ to store the view tests [01:31] instead of having all together in a single directory [01:32] carlos: we already have doc/foo-pages.txt [01:34] BjornT: but if we should create one file per each view class we have, that list would explode, right? [01:36] BjornT: btw, I just saw on those files you pointed to me, that we have a TestRequest class, I will be able to kill a dummy one that daf had to create for our tests :-D [01:37] carlos: not really. it's not one file per view class, it's one file (sometimes more) per 'foo', for example product-pages.txt, bug-pages.txt. [01:39] BjornT: ok [01:51] carlos: how is it possible that you have so much karma in translations only ! it's incredible ! [01:52] ploum: I'm a cheater [01:52] ;-) [01:52] ploum: it's due some admin tasks I did [01:52] I need to figure a way to prevent this to happen [01:52] ah ! Ok... It seems so huge ;-) [01:55] ploum: I had to import manually all OpenOffice translations and the .po files lack the translator credits and my account was used as the author of those translations [01:55] ehe :-) [01:55] Funny :-) [02:13] jamesh: ping? [02:15] mpt_: ping === carlos -> lunch === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:27] Mh... moving a bunch of bugs from launchpad to launchpad-bazaar [02:27] bradb: do you think it would be useful to have project milestones? [02:28] I created 1.0, 1.1, future, oops, and oops-timeout milestones on launchpad-bazaar to preserve the milestone information when moving bugs, but it strikes me that this loses the ability of seeing the milestone information for a whole project in a synthetic way. [02:43] ddaa: It could be useful for Launchpad, but I'm not sure about other projects. [02:43] If it's useful for us, it's at least useful to one project :) [02:44] might be useful for other ones... though I admit that large projects tend to be highly idiosyncrasic [02:44] No use comparing Apache and Gcc... === cprov [n=cprov@201-42-135-102.dsl.telesp.net.br] has joined #launchpad [02:57] ddaa: (Sorry, making breakfast, doing email, etc.) If we can think of a few other examples than LP--which often takes to be an exception to its own rules--it could be interesting to explore further. [02:57] s/takes to be/tends to be/ === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === niemeyer [n=niemeyer@200-181-138-226.ctame7012.dsl.brasiltelecom.net.br] has joined #launchpad === bradb [n=bradb@modemcable092.66-130-66.mc.videotron.ca] has joined #launchpad === niemeyer [n=niemeyer@201.11.38.108] has joined #launchpad [03:34] yo kiko [03:34] what about the review of that mirror prober changes I did? [03:35] did you send me a link or heckle me for it? [03:35] I sent you the link, but didn't heckle you, no [03:35] no heckling [03:35] I'll mail you the diff now, so you don't forget it. :) [03:35] no review [03:36] :-P === salgado should know that already [03:36] it's better to wait for me to have a free slot [03:36] than to make my inbox situation even worse :) [03:36] I will have a free slot in an hour [03:36] that's great === niemeyer_ [n=niemeyer@200.138.53.70] has joined #launchpad [03:57] salgado, hande's email suggests we need to get shipit in the next rollout. will that happen? [03:58] I need to coordinate with a reviewer [04:00] you'll be dead! [04:00] salgado, what was the bug number for the .manifest [04:02] don't remember [04:02] I'll find it [04:03] bug 43652 [04:03] Malone bug 43652 in ubuntu-cdimage "Need a text file containing the list of ISO images that releases.ubuntu.com (and all its mirrors) should have" [Normal,Fix released] http://launchpad.net/bugs/43652 [04:03] erk [04:03] who is test@canonical.com and how is (s)he landing code in Launchpad? [04:03] landing code? [04:04] i just saw this in pending merges: [04:04] test@canonical.com 2006-03-23 add IBranchSetAPI.link_branch_to_bug() [04:04] after a merge from RF to al old branch [04:06] merged: test@canonical.com-20060323072900-b13ed1f4113f7958 [04:06] committer: test@canonical.com [04:06]