[12:04] <kiko> but hey, you can be creating, and add source packages to distributions:-)
[12:04] <bradb> why can't I have a distro-wide sourcepackage page?
[12:05] <bradb> (among the problems created by not having one is that the canonical URL of a distro sp bug is non-obvious [to me, at least] )
[12:06] <kiko> you can
[12:06] <kiko> have /distros/ubuntu/+sources/foo
[12:07] <kiko> and /distros/ubuntu/hoary/+sources/foo
[12:07] <kiko> both should work, don't you feel?
[12:07] <bradb> i think so, yes
[12:07] <kiko> I'm not surprised you're running into this..
[12:08] <bradb> the alternative, perhaps, is that i default to the "current release" (i've never liked that name, because to me "current release" means the "currently released" version of the distribution, which right now would be Hoary to me, not Breezy.)
[12:10] <bradb> but every issue keeps raising other issues though too. it's entirely feasible, basic on previous discussions, to have an "open" distro bug task, and also one specifically filed on the .currentrelease. if both have a canonical URL of /distros/foo/bar/+sources/baz/+bugs/42/+editstatus, there appears to be no way to distinguish which one you really mean to be editing.
[12:10] <bradb> s/basic on/based on/
[12:15] <lifeless> jblack: I cant see the 'simple proofreading roadmap
[12:16] <jblack> You can't?
[12:16] <lifeless> its not in my INBOX
[12:16] <lifeless> there is the one that you rewrote, but not the simple proof-read
[12:16] <jblack> Message-ID<EMAIL_ADDRESS>[12:16] <jblack> That has two attachments. A proof of the one I rewrote, and a proof of the one you wrote.
[12:16] <jblack> I'll track the mail
[12:17] <jblack> To<EMAIL_ADDRESS>[12:17] <jblack> No need.
[12:17] <jblack> resending.
[12:19] <jblack> You should have it
[12:19] <lifeless> it takes a bit to bounce via cygwin.com. It would be faster to send to my actual address ;0
[12:20] <jblack> Heh.  Whats your preference?
[12:20] <lifeless><EMAIL_ADDRESS>[12:20] <jblack><EMAIL_ADDRESS>perhapps?
[12:21] <jblack> Ok. I'll try to use that. Polite reminders are in order if I degrade back to old state =)
[12:21] <lifeless> thanks
[12:22] <jblack> did you read the one you got, though?
[12:22] <lifeless> yes.
[12:22] <lifeless> I don't want to use it for the roadmap for a couple of reasons.
[12:22] <lifeless> The first one is that martin and I were both happy with the prior one.
[12:23] <lifeless> The second reason is that its very flamboyant and personal in style.
[12:23] <lifeless> I find those characteristics extremely annoying when reading roadmaps
[12:23] <jblack> The first one is a good reason. The second one I'm not so sure of. People don't buy ideas from robots.
[12:24] <lifeless> the draft I did is clearly written by a person on the team - its not a robot.
[12:25] <jblack> And yes, its written in a non-direct personal manner. That was intentional.  =)
[12:26] <jblack> I believe that people get invested in their tools. Theres just as much (if not more) faith in a tool as there is of practical considerations. See: emacs vs. vi, linux vs. xbsd, windows vs. unix...
[12:26] <jblack> Good writing doesn't speak to a group; it speaks to the reader. Its a conversation.
[12:27] <lifeless> good writing is usually targeted to the audience, and the audience is often different for each piece.
[12:28] <lifeless> there is a third aspect to this, which is that the draft you did headed back in the direction of the first ones - becoming a why-you-should-use-what-we-are-doing document, rather than a roadmap.
[12:28] <jblack> Exactly. Thats why I asked those questions last night. I verified the targets. There should be thing there to appeal to people (Theres good feeling for bzr developers/users "YES! You DID make the right choice!", comfort for gnuarch users "You're not screwed, we didn't abandon you"
[12:28] <lifeless> there is a time and place for advocacy, a roadmap to the community isn't it.
[12:30] <lifeless> bzr developers get their good feelings by the fact its slated to be bazaar-2 when it releases - thats about the strongest statement of confidence we can make, and thats where the meaning is.
[12:32] <lifeless> baz 1.x users get comfort from several sources - we've had 'guarateed upgrade path' on the bazaar.canonical.com pages for many many months; the roadmap talks about testing conversion tools and ensuring bazaar-ng has everything they will need to use it as they do bazaar.
[12:32] <jblack> I want you to be happy with the one thats released, so go with the one that you believe in.
[12:32] <lifeless> the former.
[12:33] <lifeless> important note - the writing in the new one you sent me is good - its just not what I'm looking for in a roadmap.
[12:33] <lifeless> can you resend that proof direct to me, looks like its queued at cygwin.com
[12:33] <jblack> sure
[12:34] <lifeless> thanks
[12:34] <jblack> If you're looking for my advice though, I wouldn't go with that one.
[12:35] <lifeless> I understand that.
[12:35] <jblack> I just sent you the wrong one
[12:35] <jblack> Thats yours
[12:35] <jblack> Let me send yours with the fixes. :)
[12:36] <lifeless> lol
[12:36] <lifeless> it came through fine though - much faster ;0
[12:38] <jblack> Also, there's two more grammer problems.
[12:38] <jblack> line 11, you need a comma after 'production readiness'. Line 17 should read:
[12:38] <jblack> actively improving, Bazaar 1. Bazaar 1 will have one or two more releases
[12:40] <jblack> The "we" on 16 is ambigious (bazaar team? canonical employed bazaar developers? canonical?)
[12:41] <jblack> Probably people will just assume who the we in the document is, and it probably won't cause any problems regardless of which of the three groups they're in.
[12:41] <lifeless> ok, lets walk through this
[12:42] <jblack> These are just things I noticed. I'll shut up now. :)
[12:42] <lifeless> nono its good
[12:51] <jblack> I see your point about roadmap-jblack though. It does go overboard a little  on over-advocacy.
[01:13] <lifeless> jblack: so, I've mailed you back an updated draft.
[01:13] <lifeless> can you do a final check for errors and if there are any correct and mail it back to me ?
[01:13] <jblack> ok
[01:13] <lifeless> thanks
[01:13] <lifeless> I'm going to grab breakfast, bbs
[01:36] <jblack> lifeless: Sent. You should have it by the time you get back.
[02:10] <lifeless> jblack: thanks, incorporated the changes and sent it back
[02:12] <jblack> ping pong ping pong
[02:12] <lifeless> ;)
[02:13] <jblack> Thats all I see. Anything left would be subtle that only a suffield would whine.
[02:14] <jblack> one very minor
[02:14] <jblack> "This is anticipated..."
[02:14] <jblack> That what?
[02:14] <jblack> (this is like it. The word need to refer to a noun). How about "This process" ?
[02:15] <jblack> I'm sorry. found a second.
[02:15] <lifeless> strike the sentence, replace with 'We expect to release Bazaar 2 in in the first quarter of 2006.
[02:17] <jblack> Ok.
[02:18] <jblack> Thats good. There's an awkward stentence left ("Before Bazaar-NG is released..."). I can't seem to make that sentence work.
[02:18] <lifeless> delete the 'Before Bazaar-NG is released ' And it works for me
[02:19] <jblack> I guess. The problem I'm having with the sentence is that it states that we'll be supporting improvements but we don't be doing improvements.
[02:20] <jblack> I suggest:\
[02:20] <jblack> Canonical will continue to support Bazaar during the Bazaar-NG development
[02:20] <jblack> process. Future releases of Bazaar will contain fixes for security and
[02:20] <jblack> other bugs but will not generally contain improvements.
[02:20] <lifeless> sure
[02:21] <jblack> Thats it. there's nothing else, as I've managed to bruise every surface inch of your baby.
[02:22] <lifeless> ;0
[02:23] <lifeless> what do you think about keeping in the [02:24] <lifeless> I felt that the document was changing track and they would help clarify it for readers.
[02:24] <jblack> I don't think you'll go to writer's jail for it. Its a bit outlinish for a something in literary form.
[02:24] <jblack> outline-ish, that is.
[02:24] <lifeless> ok, lets put them in then ;0
[02:25] <lifeless> other than that, I'm stoked, thank you !
[02:25] <jblack> Then I've done a good job.
[02:25] <jblack> That pleases me. =)
[02:25] <lifeless> lets put it up on the wiki, and mail g-a-u<EMAIL_ADDRESS><EMAIL_ADDRESS>[02:25] <lifeless> yes you have.
[02:26] <jblack> Ok. Signed as.... "The bazaar team at canonical" strike you well?
[02:28] <lifeless> just 'The Bazaar Team'
[02:29] <lifeless> erm
[02:29] <lifeless> for completeness, send it once to<EMAIL_ADDRESS>first
[02:29] <lifeless> let aaron/matthieu chime in, so we can sign it 'The Bazaar Team' truely.
[02:31] <jblack> excellent idea
[02:54] <lifeless> stub: gangotri is spewing 200k errors again
[02:54] <stub> Rosetta?
[02:55] <lifeless> WARNING:root:No header found in this pofile
[02:55] <lifeless> 00:25:03 ERROR   Got an unexpected exception while importing Template "review-breezy-kdeartwork-1" in Ubuntu Breezy Badger package "kdeartwork"
[02:55] <lifeless> Traceback (most recent call last):
[02:55] <lifeless>   File "/srv/launchpad.net/production/l
[03:04] <lifeless> jamesh: http://www.advogato.org/person/robertc/diary.html?start=42
[03:05] <jamesh> lifeless: yeah.  I know of it, but haven't used it.
[03:07] <lifeless> jamesh: point is, that configs/aliases/externals shouldn't be part of a vcs system :0
[03:08] <jamesh> lifeless: having them handled automatically by "cvs checkout" or similar is nice though
[03:08] <lifeless> well, when you can go 'cm build http://....
[03:09] <lifeless> I'm not sure that having the VCS tied to a specific method is good at all.
[03:09] <jamesh> yeah
[03:09] <jamesh> I hadn't looked at the SVN externals stuff much before writing that article
[03:09] <lifeless> scarey huh
[03:10] <jamesh> hadn't noticed the problems it had if committers used a different repository URI to anonymous users
[03:24] <stub> I'm more concerned with creating snapshots - if the vcs make it pretty transparent to checkout multiple trees, then if I checkout a particular revision one day, and then checkout that same revision the next day, I might end up with two different trees because the externals have changed.
[03:27] <stub> I think the best way of fixing this is to generate a report at the end of the checkout listing the trees and the revisions that were checked out/updated/whatever. Unlike everything I'm currently aware of where the revisions checked out are buried in the several pages of output
[03:28] <stub> lifeless: We have a rollout today - I think there are more rosetta fixes for these spamming scripts.
[03:34] <lifeless> stub: when I get around to implementing 'examine' for config-manager python-version, then it will be easy.
[03:37] <jamesh> for things like CVS though, it is a bit difficult to identify a checkout with anything other than a date
[03:38] <lifeless> well, within cvs's limits ;.. you can list all the files and their versions
[03:39] <stub> Just 'cvs tag 65423' after every commit and you can ;)
[03:39] <lifeless> it will just be .. rather verbose
[03:40] <stub> I never needed config like stuff in CVS anyway - just always arranged stuff in a tree that let you checkout the part you were interested in, or the entire thing.
[04:55] <jblack> I seem to be having difficulty getting an import going on roomba.
[04:59] <stub> Lunch and then rollout. Do you think anyone will notice if I take things down for a couple of hours for a full vacuum?
[05:02] <lifeless> yes I think they will
[05:02] <lifeless> jblack: care to enlarge on that? or was it just a random statement ?
[05:03] <jblack> Well, its been awhile since I've done imports... but I did a sourceadmin on abiword's MAIN branch, added cvs and arch coordinates, left enable unenabled. Went to roomba, did reload, and no abiword.
[05:05] <jblack> the first time i tried, I had set enabled, but went back and turned it off and reloaded on roomba
[05:06] <lifeless> you can't turn enable off once its set
[05:06] <lifeless> hang on, I'll go poke the db.
[05:06] <jblack> Whoops.
[05:09] <lifeless> ok, go edit the source again.
[05:09] <lifeless> check that enabled is _off_
[05:09] <lifeless> then reload roomba
[05:11] <jblack> Still not there
[05:21] <lifeless> stub: are you updating at the moment ?
[05:21] <stub> Nope
[05:21] <lifeless> https://launchpad.net/products/abiword
[05:21] <lifeless> ^^ bustified for me
[05:22] <lifeless> nmm bug with importstatus processing
[05:22] <lifeless> though I cant edit the series head
[05:23] <lifeless> launchpad1.log
[05:23] <stub> I just accessed that page...
[05:24] <lifeless> https://launchpad.net/products/abiword/+series/head
[05:24] <stub> Yup - that is dead
[05:25] <lifeless> renamed it to trunk, no change
[05:25] <lifeless> the error is '  File "/srv/launchpad.net/production/launchpad/utilities/../lib/zope/app/traversing/adapters.py", line 52, in traverse
[05:25] <lifeless>     raise NotFoundError(subject, name)
[05:25] <lifeless> NotFoundError: (None, 'title')
[05:25] <stub> No the template assumes there is a 'title' property on context/importstatus, and there isn't one
[05:25] <stub> (or security declarations were forgotten)
[05:25] <lifeless> aw man.
[05:26] <stub> Should we add one now and cherry pick it ;)
[05:26] <stub> What sort of object would context/importstatus be?
[05:26] <lifeless> importstatus is a dbschema
[05:27] <lifeless> NULL breaks it.
[05:27] <lifeless> 5 works
[05:27] <lifeless> jblack: try a reload of roomba now
[05:28] <stub> Hmm... in general we shouldn't allow NULL for enums, and instead have an UNKNOWN value or similar.
[05:28] <jblack> There
[05:28] <jblack> Something I did?
[05:28] <lifeless> yes, you selected enable.
[05:29] <lifeless> I suggest you pickup the doco you wrote before doing an import - you have super-secret-powers in launchpad;0
[05:29] <spiv> stub: Hmm.
[05:29] <lifeless> btw you need to resend the oadmap to the team@ address.
[05:29] <lifeless> as you didn't attach it.
[05:29] <jblack> oh for crying out loud. Is anything going to work right tonight?
[05:29] <spiv> stub: It shouldn't be hard to make EnumCol assert, or at least warn, if self.notNull == False.
[05:29] <stub> lifeless: So is this a bug we need to fix now, or is it only triggered by.... erm... user error (for lack of a less abusive term)
[05:30] <lifeless> its only triggered by something not even god should attempt error.
[05:30] <jblack> as a matter of fact, yes. Martin took comand --
[05:30] <jblack> pardon? I exceeded god powers?
[05:31] <lifeless> you me bob2, ddaa keybuk all exceed god powers in launchpad
[05:31] <stub> spiv: Or I just fix the database constraints - I wouldn't hack it into EnumCol because I don't know if that rule will hold everywhere.
[05:31] <lifeless> for the import area
[05:31] <lifeless> stub: one way to be sure that it will ;0
[05:31] <stub> spiv: In fact, I think we have enumcols that will be NULL if other columns are not filled out.
[05:31] <spiv> stub: Fair enough.
[05:32] <jblack> That reminds me of the god/devil mode that I wrote into linuxguru.net
[05:33] <stub> jblack: How much longer are you going to be on Launchpad for?  I can go back to it later.
[05:38] <jblack> stub: iow, I'm off
[05:38] <stub> jblack: ok ;)
[07:02] <stub> Hehehe.... css caching bugs ;)
[07:03] <stub> Have a look at launchpad.net - I had invisible tabs until I shift-reloaded ;)
[07:04] <lifeless> specs doesn't work
[07:05] <lifeless> https://launchpad.net/products/abiword/+specs
[07:05] <spiv> stub, lifeless: looks like a db permission error?
[07:06] <stub> Yer - me stuffed up.
[07:15] <stub> Working now. I just updated the documentation for that process but neglected to actually perform it ;)
[07:16] <spiv> Woo, and we already have an error from googlebot ;)
[08:06] <robitaille> is it a known problem that an user cannot access his email page using the link/action in the right-hand column of an user page ?  (https://launchpad.net/people/robitaille/+emails)
[08:09] <jamesh> robitaille: looks like a bug.  Go "Edit Details" then "E-mail addresses"
[08:11] <jamesh> that is weird
[08:11] <robitaille> yes saw that.  An user can also click on "Manage" email address on the left-hand side column of that same user page.
[08:16] <stub> jamesh: Just someone changed the URLs and forgot to update the actions. There are other actions broken too :-(
[08:17] <stub> Which means I need to sort out some primitive spidering tests
[08:17] <lifeless> did we rollout anything done post-meeting ?
[08:18] <stub> Yes
[08:20] <stub> Yes - needed to wait for Marks specs branch to land.
[08:21] <jamesh> stub: I think someone screwed up a merge conflict -- iirc salgado moved those entries to a different portlet (the person "edit details" one)
[08:22] <jamesh> that's a guess though
[08:24] <jamesh> everything below "Show Subscribed Specs" looks suspect
[08:29] <jamesh> looks like they were added back with the specs merge (patch-2314)
[08:30] <stub> Mark strikes again ;-(
[08:53] <SteveA> morning
[09:26] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Update production database update docs (patch-2325<EMAIL_ADDRESS>[09:55] <Kinnison> morning launchpadders
[10:39] <stub> cprov: Morning. Just found a present from you in rocketfuel (patch-25-66-0.sql)
[10:46] <cprov> stub: what do you mean by "a present" ?
[10:47] <stub> A database patch that didn't get reviewed (hence the odd number)
[10:48] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Add a missing import and add an __all__ tuple (patch-2326<EMAIL_ADDRESS>[10:48] <carlos> morning
[10:49] <cprov> stub: it's still surprising me, I don't remember from where does it comes
[10:49] <stub> http://lists.canonical.com/mailman/private/arch-commits/2005-August/004336.html
[10:49] <stub> (poor mans annotate, but I've never actually seen baz annotate finish ;) )
[10:50] <stub> Its just work on one of the views. If it is needed it will affect a patch in Kinnisons branch (pending review).
[10:50] <cprov> stub: just update RF and saw, it is the repaired pgview.... ohh sorry man,
[10:50] <stub> No worries. Do you now if it is a needed change?
[10:51] <cprov> stub: it affects the soyuz UI for sure, unfortunatelly tests are missing yet
[10:51] <stub> Ok.
[10:52] <Kinnison> I'll take a look
[10:52] <cprov> stub: how does it pass through review process ?
[10:53] <stub> cprov: BjornT would have assumed it still needed to go through my queue. I wouldn't worry about it - it hasn't been a regular occurance.
[10:57] <stub> Kinnison: I can't see a difference between cprov's rewrite of the view and yours (well - the order of two columns is swapped, but that doesn't matter)
[10:58] <Kinnison> stub: Once baz has finished I'll look and confirm that
[10:58] <Kinnison> stub: I'll update my branch to remove his patch when mine gets applied?
[11:05] <stub> Kinnison: Hmm.... yes. That would be simplest. Your branch should land soon, or does it still need to run the review gauntlet?
[11:06] <stub> Soon as in before next launchpad meeting and the production tagging
[11:07] <Kinnison> stub: I'm hoping it'll land fairly damned soon
[11:07] <Kinnison> stub: It needs to run the review gauntlet and I'm unsure how that is progressing
[11:08] <Kinnison> but since it contains only those changes necessary to get it working again with the renames, it should be fairly fast to review
[11:09] <stub> Kinnison: Ok. I'll rename it to patch-25-18-0.sql, which also means I won't acidently forget about it. It looks like there is no clash.
[11:10] <Kinnison> If there's no clash, there's no particular need for me to remove it is there?
[11:10] <Kinnison> it's just a redundant but non-dangerous patch
[11:12] <stub> Yup.
[11:12] <stub> So no need for you to do anything
[11:13] <Kinnison> coolio
[11:25] <Keybuk> where are you sprinting too?
[11:27] <Kinnison> soyuz readiness
[11:28] <Kinnison> The new olympic sport: 45 mile sprint
[12:12] <WaterSevenUb> Carlos, do you know why Synaptic is not yet ready for translation?
[12:12] <carlos> WaterSevenUb, is not?
[12:13] <carlos> hmmm
[12:13] <WaterSevenUb> carlos, embarrassment :) I can't find it :)
[12:13] <carlos> you are right
[12:20] <carlos> WaterSevenUb, it should be fixed soon, we need a small change in synaptic
[12:21] <WaterSevenUb> carlos, if you remember me afterwards... let me know.
[12:22] <carlos> WaterSevenUb, will try to, but my mind is not so good and it does not depend on me, it depends on synaptic maintainer...
[01:00] <Nafallo> thanx! I love this new gpg system :-).
[01:00] <Nafallo> who should I thank for this? cprov?
[01:11] <cprov> Nafallo: the LP team, lot of people is releated to this improvement, specially mpt for the new UI style
[01:11] <Nafallo> oki, thanx all then! :-)
[01:37] <Kinnison> I am about to update dogfood, anyone have a problem with that?
[01:57] <Kinnison> updated
[01:59] <Kinnison> anyone know what's happened with https://dogfood.ubuntu.com/ ?
[02:01] <Kinnison> mpt: know what's happening to cause the brokenness on https://dogfood.ubuntu.com/
[02:01] <Kinnison> ?
[02:03] <mpt> Kinnison: Not offhand, though I can probably do a temp fix once I update from rocketfuel
[02:03] <Kinnison> mpt: thanks
[02:03] <mpt> It looks like something carlos would understand
[02:04] <mpt> https://dogfood.ubuntu.com/distros/ubuntu/+translations is broken too
[02:04] <mpt> but https://dogfood.ubuntu.com/rosetta isn't
[02:04] <mpt> AttributeError: 'DistroRelease' object has no attribute 'datecreated'
[02:05] <mpt> Hrmm, maybe the dogfood database hasn't been remade?
[02:05] <mpt> Or is that automatic?
[02:05] <Kinnison> It's automatic
[02:10] <carlos> hmmm
[02:10] <mpt> carlos, you may have noticed that on productoin, the portlet dogfood is complaining about until recently said "Just for fun, here's the overall translation status of Ubuntu", and then didn't have any stats
[02:11] <mpt> Now production is fixed (it doesn't claim to have Ubuntu translation stats any more), and dogfood is broken
[02:11] <carlos> hmmm
[02:11] <carlos> mpt, didn't know that problem on production...
[02:12] <mpt> I was going to fix that today for Rosetta 1.0, but someone already fixed it :-)
[02:12] <mpt> otherwise we'd have had slashdotters laughing at it
[02:12] <carlos> mpt, the URL you pasted does not exists on production
[02:13] <carlos> you pasted it linked to dogfood
[02:13] <carlos> mpt, the link is broken on production...
[02:13] <Kinnison> dogfood just got updated to latest rocketfuel
[02:13] <Kinnison> and now it doesn't work
[02:13] <mpt> carlos, the page I'm talking about on production is https://launchpad.net/
[02:13] <Kinnison> it seems to be a rosetta related issue
[02:13] <carlos> mpt, https://launchpad.net/distros/ubuntu/
[02:13] <carlos> mpt, click over "translations" and you get a 404 error
[02:14] <mpt> yikes!
[02:14] <mpt> how did that happen?
[02:14] <mpt> oh, breezy and hoary have translations pages, but ubuntu itself doesn't
[02:15] <mpt> but that's a separate problem, I think, carlos
[02:15] <carlos> mpt, I know, but just found it :-)
[02:16] <mpt> I need to fix that "System error" text somehow so that people stop pasting it into bug reports
[02:17] <carlos> Kinnison, I'm not ignoring you, just checking my current tree
[02:18] <mpt> should be finished in mere hours!
[02:18] <Kinnison> carlos: thanks
[02:19] <mpt> gets me every time
[02:20] <carlos> mpt, or ask mark to change his name... :-P
[02:24] <cprov> mpt: did you have a look on me/launchpad--builddUI--0 ?
[02:30] <mpt> cprov: No, I got that message yesterday afternoon, anthem wasn't working, and this local machine doesn't have enough RAM for baz
[02:30] <mpt> I'll look at it once I'm done looking at this dogfood bug
[02:30] <cprov> mpt: I understand you reasons, don't need further explanations ;)
[02:32] <cprov> mpt: I was just wondering if we can have a short ETA for it, you can answer it later after look on that code
[02:33] <cprov> mpt: anthem env seems to be very sensible to upgrades, still causing trobles until today ... don't forget I read email in the same place you do ;)
[02:36] <carlos> Kinnison, how could I see the main page used on dogfood/production?
[02:36] <carlos> my local branch has another one
[02:36] <mpt> cprov: well, at least ssh and baz are working now, that's enough for me :-)
[02:37] <mpt> carlos: /real-index.html
[02:37] <mpt> iirc
[02:37] <carlos> mpt, thanks
[02:37] <mpt> I think the development home page even links to it :-)
[02:37] <cprov> mpt: does the situation still so critical like that ?
[02:37] <carlos> mpt, could be O:-)
[02:37] <carlos> Kinnison, I don't see any problem here
[02:38] <Kinnison> carlos: if you log into mawson and look in /srv/launchpad.ubuntu.com/dogfood/launchpad
[02:38] <carlos> Kinnison, the error I see from dogfood does not happens here and the missing method is not missing here
[02:38] <carlos> sure
[02:40] <carlos> Kinnison, that's not latest rocketfuel code
[02:41] <Kinnison> carlos: really?
[02:41] <carlos> hmm
[02:41] <carlos> it is...
[02:41] <carlos> the patchset is the same
[02:41] <carlos> but the code is different :-?
[02:41] <Kinnison> odd
[02:41] <mpt> all that bazzing for nothing? alack
[02:42] <carlos> Kinnison, I didn't touch that code so it's a bit difficult that it comes from my local branch...
[02:42] <carlos> but I cannot do a baz diff on mawson :-(
[02:43] <carlos> doing it with my local branch...
[02:43] <Kinnison> Should I be merging from you or something?
[02:44] <carlos> Kinnison, don't think so
[02:44] <carlos> I'm using my devel--0 branch that should not have any change
[02:44] <Kinnison> okay, just let me know when you work out what's up
[02:44] <Kinnison> it is confusing me lotsly
[02:52] <carlos> Kinnison, my local branch does not have any change checking against rocketfuel
[02:53] <carlos> Kinnison, getting a fresh rocketfuel checkout atm to be 100% sure
[02:53] <Kinnison> okay thanks
[03:01] <kiko> stub, hadn't we agreed not to place mark's landing in production?
[03:02] <carlos> Kinnison, is a problem with your tree
[03:02] <stub> not that I recall. I recall not tagging on Thursday because it needed to land.
[03:02] <carlos> Kinnison, a fresh checkout has it
[03:02] <carlos> Kinnison, just remove it and get a fresh version
[03:02] <kiko> stub, shucks. I convinced mark that he shouldn't land it in production, but I guess you went with his initial "wait for landing" request.
[03:03] <kiko> my fault, sorry.
[03:06] <mpt> Kinnison: fresh rocketfuel worksforme
[03:06] <mpt> ... too
[03:07] <carlos> mpt, ;-)
[03:07] <mpt> He with the most RAM wins
[03:08] <carlos> mpt, the fresh checkout was don on mawson, without any cache revision....
[03:08] <carlos> s/don/done/
[03:09] <mpt> kiko: If you have some spare time today from fixing anthem, it's be great if you could look at the SimplifyingMalone spec
[03:11] <carlos> and lunch
[03:11] <carlos> see you!
[03:12] <mpt> SteveA: menus?
[03:21] <BjornT> stub: can you please check, in production, if there are any bugs that don't have any comments?
[03:26] <stub> BjornT: There are none. Every bug has one or more comments.
[03:26] <BjornT> stub: ok, thanks
[03:38] <bradb> morning all
[03:46] <cprov> mpt: I've gots same problem once .. you probably have the same match twice in the page content .. test-suite gets lost
[03:48] <bradb> Don't trust the failure output. Figuring out doctest/pagetest failures takes a sixth sense.
[03:56] <mpt> (apart from the fact that Gaim decided to trim the HTML tags from what I just wrote)
[03:56] <salgado> elmo, pqm seems to be stuck again
[03:57] <elmo> salgado: kicked
[03:57] <salgado> elmo, ta ;)
[04:00] <SteveA> mpt: yeah, can we meet in say 20 mins?
[04:00] <Kinnison> carlos: I've just done a fresh checkout of dogfood and it still gives the error
[04:00] <mpt> SteveA: ok
[04:10] <Kinnison> when was staging last updated?
[04:39] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Bless accidently applied db patch (patch-2327<EMAIL_ADDRESS>[04:40] <Keybuk> ok, this is just freaky ... test cases fail which I swear worked on Friday
[04:40] <Keybuk> and I haven't touched it since then, honest 'guv
[04:47] <Kinnison> Well, I have a situation where a fresh checkout has a / page which crashes on dogfood, but works on staging
[05:06] <dilys> Merge to<EMAIL_ADDRESS>Cherry pick patch-2326 into production (patch-2<EMAIL_ADDRESS><EMAIL_ADDRESS>[05:17] <bradb> "* Applying 157 revisions ..."
[05:31] <kiko> bradb, are you running out of memory?
[05:31] <bradb> * Applying 157 revisions ......................................................................................................................................baz: uncaught exception: -1:(unable to fork for patch)
[05:31] <bradb>   please report this as a bug to<EMAIL_ADDRESS>[05:31] <bradb> yu
[05:31] <bradb> p
[05:31] <bradb> needless to say, on all five tries gnome terminal is all i have open
[05:32] <Kinnison> bradb: is this preparing the library?
[05:32] <bradb> with two tabs, one of which is IRC
[05:32] <kiko> bradb, do you have 1gig?
[05:32] <kiko> that's the minimum required for current baz + lp
[05:32] <Kinnison> bradb: I.E. is this preparing the revision library cache ready for merging?
[05:32] <bradb> kiko: no, 512 megs
[05:32] <kiko> 1.5 is usually required.
[05:32] <kiko> bradb, go out and buy some memory.
[05:32] <Kinnison> kiko: I survive very well on 768M
[05:33] <kiko> Kinnison, obviously you're not a golfer
[05:33] <Kinnison> golfer?
[05:33] <kiko> never mind
[05:33] <kiko> but at async we find we can't really merge with less than 1gig
[05:33] <kiko> ask mpt...
[05:33] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Fix https://launchpad.net/malone/bugs/1962 (patch-2328<EMAIL_ADDRESS>[05:33] <Kinnison> bradb: try: baz library-add<EMAIL_ADDRESS>where <foo> is somewhere around 70 revisions after the one it finds in your library
[05:34] <Kinnison> bradb: if that succeeds, then re-try your merge
[05:35] <bradb> BjornT: "without much problem" eh? heh heh.
[05:35] <kiko> there's something magical about that to me
[05:35] <kiko> because I have never managed a merge with 512mb
[05:37] <BjornT> bradb: well, i've never ran out of memory. the only problem i have is that it might be slow some times. but since i've started using hard links it's actuall quite fast most of the time.
[05:37] <salgado> kiko, I think our problem here is that we don't have swap.
[05:37] <bradb> BjornT: if fl-cow were packaged on ubuntu, i might use hard links too
[05:38] <bradb> i'll have to wait until baz is done using me before opening my browser to do some memory shopping
[06:02] <elmo> err, guys
[06:02] <elmo> launchpad-error-reports is .5Gb A MONTH
[06:02] <elmo> and it's a mailing list
[06:03] <elmo> we need to do something to reduce that
[06:03] <SteveA> it's internal isn't it?
[06:03] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  some small packaging fixes to the launchpad buildd (patch-2329<EMAIL_ADDRESS>[06:03] <SteveA> i mean, the bandwidth
[06:03] <SteveA> i'll mail stu.  he's the custodian of it.
[06:04] <SteveA> elmo: is it the disk space that is a problem?
[06:05] <elmo> SteveA: more the bandwidth
[06:05] <elmo> it's the size of the archive x the number of subscribers
[06:05] <SteveA> is it internal?
[06:05] <elmo> I'm trying to move it internal, and having problems copying that much data off of rince
[06:05] <SteveA> there shouldn't be many subscribers for it all
[06:05] <SteveA> it is heavily based on topics
[06:06] <SteveA> a lot of the history can probably be junked
[06:06] <SteveA> i'll check with stu
[06:06] <SteveA> and get back to you
[06:19] <elmo> thanks
[06:42] <bradb> BjornT: If I try to use getUtility in the tests, it causes other breakage as well (in addition to the task != self breakage)
[06:42] <bradb> Failed example:
[06:42] <bradb>     related_task.status = ORIGINAL_STATUS
[06:42] <bradb> Exception raised:
[06:42] <bradb>     ...
[06:43] <bradb>       File "/home/bradb/launchpad-two/lib/canonical/lp/dbschema.py", line 152, in fromPython
[06:43] <bradb>         raise TypeError('DBSchema Item from wrong class')
[06:43] <bradb>     TypeError: DBSchema Item from wrong class
[06:43] <bradb> Should I put the task back to not using getUtility and file two bugs?
[06:43] <bradb> s/task/test/
[06:46] <SteveA> that'll be a bug
[06:46] <SteveA> dbschema is comparing by identity
[06:46] <SteveA> when it shouldn't be
[06:50] <SteveA> thanks brad
[06:51] <SteveA> bradb: what's the number?
[06:53] <BjornT> bradb: hmm. yeah, bugs should be filed. i guess you could either not use getUtility, or use removeSecurityProxy to make the test pass. i'd prefer the latter, since you're testing code that should be able to handle security proxied objects.
[06:53] <BjornT> bradb: of course with an XXX pointing to the bug number
[06:55] <Kinnison> bradb: so my suggestion of an intermediate library-add worked?
[06:58] <bradb> SteveA: https://launchpad.net/malone/bugs/1971
[06:58] <bradb> BjornT: ok, I'll use removeSecurityProxy
[06:58] <BjornT> bradb: to clarify, removeSecurityProxy for the dbitem bug. self.id != task.id is nicer
[06:58] <bradb> Kinnison: kind of. I still ended up getting one more unable to fork error
[06:58] <bradb> BjornT: ah, ok
[06:58] <Kinnison> :-(
[07:02] <SteveA> bradb: i see the problem.  it is an easy fix, but writing the test is more difficult.
[07:21] <jordi> carlos: did you se Steve Michael's mail about zwiki?
[07:25] <SteveA> simon
[07:25] <SteveA> not steve
[07:27] <jordi> carlos: err
[07:28] <jordi> yeah
[07:28] <jordi> doh, steve, not carlos :P
[07:28] <bradb> BjornT: You've got mail. Can you confirm that it's ok to merge?
[07:29] <BjornT> bradb: yeah, it's ok
[07:29] <bradb> great, thanks
[07:32] <Keybuk> I get it all working, shiny, just right
[07:32] <Keybuk> AND I FIND ANOTHER CRITICAL BUG
[07:32] <Keybuk> Gnaaaaaaaaaaaaaaaaaaaaaaah
[07:44] <SteveA> INVALID SIGNATURE ON REVISION!
[07:44] <SteveA>   archive<EMAIL_ADDRESS>[07:44] <SteveA>   revision launchpad--devel--0--patch-2329
[07:44] <SteveA>   checksum file: checksum
[07:44] <SteveA>
[07:44] <SteveA> any idea what to do?
[07:52] <jordi> SteveA: when someone requests the addition of an app to rosetta, and a product for it doesn't exist, should I create it straight away?
[07:53] <jordi> false alarm, I see it now
[08:18] <jordi> gah
[08:18] <jordi> the launchpad update removed the handy "my bugs" link from /people/foo
[08:27] <salgado> jordi, really?
[08:28] <Kinnison> ciao
[08:28] <jordi> salgado: do you have it?
[08:28] <jordi> and I can't remember the url
[08:29] <jordi> damn shit
[08:29] <jordi> so I find vandalism in a product, and I can't fix it myself.
[08:29] <bradb> jordi: click on the Bugs tab dude
[08:29] <jordi> https://launchpad.net/products/gtweakui
[08:29] <jordi> bradb: those are assigned to me
[08:29] <jordi> I want the bugs I've filed
[08:29] <salgado> jordi, I can see the links in /people/salgado (the assigned and reported bugs)
[08:29] <jordi> hmm, I don't see reported.
[08:30] <salgado> jordi, the ones you filled are in the actions portlet, in the right side
[08:30] <salgado> s/filled/filed
[08:30] <jordi> oh, bah
[08:30] <jordi> I must be blind
[08:30] <bradb> jordi: You want to see reported and assigned all in the same page?
[08:30] <jordi> sorry, bradb & salgado :)
[08:30] <bradb> oh
[08:30] <jordi> I should get a pair of glasses
[08:31] <jordi> can anyone have a look at gtweakui and fix it somehow?
[08:31] <jordi> I still think I could use access to those edits just in case I find vandalism
[08:32] <bradb> jordi: What do you want changed?
[08:32] <jordi> bradb: descriptions
[08:32] <jordi> have a look
[08:32] <jordi> it's not even funny
[08:32] <bradb> If you can tell me what fields you want changed, with the exact text to put in there, I can change it.
[08:33] <bradb> Sure, I can see the problem, but I can't write anything much better for gtweakui :P
[08:33] <jordi> lol
[08:33] <jordi> well I made something up based on "
[08:33] <jordi> This is a fairly simple project. A collection of simple dialogues as a front end to GConf. We will provide extra configuration settings for GNOME that 'power users' have been requesting since the release of GNOME 2.0. We will adhere to the GNOME HIG"
[08:33] <jordi> ie "Simple GConf editor"
[08:33] <jordi> etc
[08:34] <jordi> carlos, is adding the gnome-glossary a good idea?
[08:36] <bradb> jordi: I've made it a little better, but the summary and description are the same. If you want to improve the text, just let me know what text you want in what fields (because I know nothing about gtweakui.)
[08:39] <jordi> oh my, brad. Summary: "gTweakUI is a simple configuration editor for advanced GNOME features."
[08:40] <bradb> I was thinking more of a longer description, but hey, I guess less is more.
[08:41] <jordi> Description: gTweakUI is a GConf editor that provides a user interface for some of the advanced GNOME configurations. On GNOME 2.0, some of these configurations are hidden in GConf, and are only available using a GConf editor. gTweakUI provides a friendly and HIG compliant interface to access them."
[08:41] <jordi> or something like this.
[08:44] <mpt> bradb: What's the ETA on MaloneBugSubscriptions?
[08:45] <bradb> mpt: A couple months, at the earliest, I'd imagine.
[08:45] <bradb> First there's 1.0, then there's a month of bugfixing/firefighting that follows that. The latter ends up turning into 2-3 months, etc.
[08:46] <bradb> (It's possible that it might fit in as part of the firefighting, depending on what the users are saying, I guess.)
[08:49] <bradb> "Sorry, a system error occurred"?
[08:49] <mpt> yeah, that too :-)
[08:50] <mpt> but mostly the idea that that should be on a separate page in the first place
[08:52] <bradb> I'm noticing that I'm often using status notes instead of what I should really be doing, which is adding a comment.
[08:52] <bradb> Er, I think that's what I should really be doing.
[08:54] <bradb> e.g. adding a note giving some context for why I'm marking it "Fixed", which is really a piece of information that in no way needs to be limited to just the task
[08:55] <mpt> I like that the description is now on the task page
[08:56] <mpt> bradb: Perhaps your explanation does indeed belong as a status note. If you were mistaken and the bug still exists, the explanation is no longer relevant, so it's right for it to be blown away.
[08:57] <mpt> Launchpad is perhaps an unusual case, because it's a single upstream with no distro packages
[08:57] <mpt> Imagine that you were a developer of a product that is packaged in several distros
[08:58] <mpt> That you had fixed a bug wouldn't make it fixed everywhere else.
[09:01] <bradb> mpt: If, for example, the bug were rejected, and the reason for that rejection explained by the status notes (because it was the easiest place to write the information), what is the reason for that be a "local" piece of data, rather than global to the bug report?
[09:19] <mpt> bradb: Because it's not (very) relevant to other distros
[09:19] <mpt> Maybe upstream should be a special case
[09:35] <bradb> Sorry, phone. /me ponders
[09:37] <bradb> Yes, perhaps upstream could be a special case. Perhaps it's not a significant enough problem to worry about right now.
[09:45] <mpt> cprov: Is there a permission set up for people who are allowed to edit the build farm?
[09:46] <cprov> mpt: soon we will have a LP celebrite, I think ... now I require lp.Admin
[09:47] <mpt> ok
[10:06] <bradb> mpt: https://launchpad.net/malone/bugs/691 -- is this fixed?
[10:22] <jordi> shouldn't we kind of avoid stuff like this?
[10:22] <jordi> https://launchpad.net/products/dialogs
[10:23] <jordi> isn't "dialogs" namespace pollution?
[10:23] <jordi> bradb: thanks for the gtweakup update
[10:23] <bradb> no prob
[10:24] <jordi> hmm
[10:24] <jordi> setting up plone for translation might take me like 2 weeks
[10:29] <bradb> Matthieu Moy's merge request has been churning for over an hour. Presumably pqm's hanging?
[10:33] <jordi> hmm
[10:34] <jordi> can anyone search for "plone" on launchpad to see how many results they get?
[10:34] <jordi> I only get one, and it's not plone itself
[10:35] <jordi> doh, I really need sleep. projects != products.
[10:35] <jordi> plone desktop is registered as a project. weird
[10:36] <bradb> elmo: Can you kick pqm please?
[10:46] <bradb> lifeless_: ping
[10:46] <elmo> kicked
[10:47] <elmo> for once it wasn't pqm's fault
[10:50] <sabdfl> hey guys, i'm BACK
[10:50] <sabdfl> kiko: any further review comments on the specmachine?
[10:50] <bradb> elmo: thanks
[10:54] <jordi> hey sabdfl
[10:54] <jordi> damn, where is carlos.
[10:54] <sabdfl> hey jordi, how's it going
[10:54] <jordi> I'm dealing with the zillion po and pot files for plone
[10:55] <jordi> they have a "Chinese" (no country) file which is the same as the Chinese (China). I think I should omit it.
[10:55] <jordi> But wanted to check with Carlos first.
[10:55] <jordi> oh well, they can always add it later.
[10:56] <sabdfl> jordi: yes, we should have one or the other, not both
[10:57] <jordi> zh_CN is the standard, so that goes in
[11:01] <sabdfl> jordi: nice progress on zope3 translations at https://launchpad.net/products/zope/+series/zope3.1/+pots/zope
[11:01] <jordi> wow
[11:01] <jordi> lots of purple
[11:01] <sabdfl> jordi: have you seen the breezy launchpad integration?
[11:01] <sabdfl> help -> translate this app?
[11:02] <jordi> not yet, I haven't tried a breezy CD yet
[11:02] <jordi> I've seen that in screenshots though
[11:03] <sabdfl> i think it's going to be a big driver
[11:03] <jordi> yeah, it solves the "where and who to file bugs against" very trivially
[11:06] <jordi> sabdfl: I haven't been able to contact the xfce guys yet. What should I do abotu that request (one language team wants to import it all to translate xfce to their language)
[11:06] <jordi> I wanted to tell the xfce guys in advance, just in case they have something to say
[11:06] <sabdfl> jordi: always a good idea to let them know that we are importing, and to import everything that's been done upstream
[11:08] <kiko> sabdfl, I do have some; I'll mail them out tomorrow; we migrated our server, anthem, to hoary and I'm still picking up the pieces
[11:08] <kiko> should be wrapped up shortly though
[11:09] <kiko> what an upgrade
[11:10] <jordi> yay, plone done
[11:10] <jordi> that took a while
[11:11] <jordi> too fast
[11:11] <jordi> I'm getting a system error with plone
[11:11] <jordi> doh
[11:11] <jordi> I'm a dork
[11:12] <jordi> rosetta didn't like a bzipped tar named tar.gz :)
[11:13] <jordi> sabdfl: the last pending request I can see in the list archive is gnome-glossary, which I'm not sure about
[11:13] <jordi> sabdfl: do we want to import that?
[11:14] <jordi> kiko: can you have a look at the error log for me?
[11:14] <jordi> https://launchpad.net/products/cmfplone/+series/main/+pots/plone/+upload is erroring when I upload a big tarball
[11:14] <jordi> a .tar.bz2 nearly 2megs big
[11:15] <jordi> is there a size limit or something?
[11:17] <kiko> sure
[11:17] <dilys> Merge to<EMAIL_ADDRESS>[r=BjornT]  implement MaloneSearchResults (currently exposed only on the sp bug listing) (patch-2330<EMAIL_ADDRESS><EMAIL_ADDRESS>[11:17] <lifeless> bradb: pong
[11:17] <jordi> kiko: upload went ok with a (much bigger) tar.gz. Something's wrong with tar.bz2 I guess.
[11:17] <sabdfl> anybody running lp on breezy?
[11:17] <sabdfl> any issues to know about?
[11:17] <sabdfl> version management?
[11:18] <bradb> lifeless: n/m, elmo kicked pqm for us ;)
[11:18] <jordi> kiko: if you can confirm it's related, I'll file a bug
[11:18] <kiko> sabdfl, mpt's trying at least
[11:18] <kiko> jordi, it's a bug
[11:18] <sabdfl> jordi: there's no size limit
[11:18] <kiko> jordi, file it and I'll paste in a traceback
[11:18] <jordi> k
[11:18] <kiko> it's  a pretty weird one
[11:18] <kiko>     *  Module tarfile, line 916, in open
[11:18] <kiko>       return func(name, "r", fileobj)
[11:18] <kiko>     * Module tarfile, line 996, in bz2open
[11:18] <kiko>       raise ValueError, "no support for external file objects"
[11:18] <kiko> ValueError: no support for external file objects
[11:19] <jordi> while I do: can anyone tell me what's the active tab for https://launchpad.net/products/cmfplone/+series/main/+pots/plone/+upload ?
[11:19] <jordi> if it's "Bugs" too, I have another bug to file. Sigh :)
[11:20] <jordi> kiko: https://launchpad.net/malone/bugs/1982
[11:21] <jordi> 1982, the Spanish Football Championship :)
[11:21] <kiko> jordi, it is bugs
[11:21] <jordi> kiko: ie, bug?
[11:22] <kiko> its.
[11:22] <kiko> yes.
[11:23] <jordi> there goes 1983
[11:23] <jordi> ok. So now I need 3 more bugs to get 1986.
[11:23] <bradb> salgado: you might find https://launchpad.net/malone/bugs/1981 interesting
[11:25] <salgado> bradb, I saw it already. thanks for reporting. :)
[11:25] <bradb> no prob
[11:25] <salgado> I'll talk to mpt to see what we can do. that team page really needs some love
[11:27] <jordi> kiko: just wondering, what's in that bug that makes it priv?
[11:27] <salgado> cprov, have you seen https://launchpad.net/malone/bugs/1979 ?
[11:28] <cprov> salgado: yes I have, no clue atm
[11:28] <sabdfl> stub: is name required to be ascii?
[11:28] <salgado> sabdfl, yes, the valid_name() function enforces that, IIRC
[11:29] <bradb> def valid_name(name):
[11:29] <bradb>     pat = r"^[a-z0-9] [a-z0-9\\+\\.\\-] +$"
[11:32] <ivoks> salgado: ping
[11:33] <salgado> ivoks, pong
[11:34] <ivoks> salgado: i reported #1979
[11:34] <ivoks> so if you have any questions, i would be glad to help
[11:38] <zyga> hello
[11:38] <salgado> oh, the gpg key problem.
[11:38] <zyga> are there any problems with lanuchpad?
[11:39] <zyga> I've uploaded several translations two days ago and they were not commited yet
[11:39] <ivoks> right
[11:39] <salgado> ivoks, let's see if cprov can help us
[11:39] <zyga> no notification, no nothing
[11:40] <salgado> cprov, about that bug I pinged you, is there anything else that you want to know?
[11:40] <cprov> ivoks: your GPG key id ?
[11:40] <ivoks> yes
[11:40] <ivoks> 0xD3BDA225
[11:45] <jordi> kiko-phone: now it's failing with a tar.gz apparently
[11:49] <dilys> Merge to<EMAIL_ADDRESS>Get read of **kw magic in PersonSet.newTeam(), some other tweaks in browser/team.py, fix https://launchpad.net/malone/bugs/1902. r=kiko (patch-2331<EMAIL_ADDRESS>[11:49] <jordi> kiko-phone: fuck... I didn't notice the plone data I was given included an en.po. Can those 4 en.po's get removed?
[11:51] <kiko-phone> jordi, hmm, you'll need to ask carlos/stub for that part.
[11:51] <jordi> k
[11:51] <jordi> carlos: I'd like to remove en.po from the 4 cmfplone templates.
[11:51] <ivoks> salgado cprov bye... i need some sleep :/
[11:51] <cprov> ivoks: so do I, I'm utc
[11:52] <ivoks> cprov: utc+2 here :)
[11:53] <cprov> ivoks: it's probably in you key, missed subkey
[11:54] <ivoks> eh?
[11:54] <cprov> ivoks: I will discuss your situation with the gpg gurus, perhaps they will have a solution
[11:54] <ivoks> ok
[11:54] <ivoks> thanks