[02:13] <avoine> why its not all the package that are in the product list of launchpad? 
[02:13] <avoine> Because i want to report a bug on the new combiz package but the software is not register should i create it?
[02:16] <avoine> sorry, my mistake the software was there .
[02:59] <mpt> Gooooooooooooooooooood afternoon Launchpadders!
[03:16] <dilys> Merge to devel/launchpad/sourcecode/buildbot/: [trivial]  Fix or skip buildbot tests to be compatible with Twisted 2. (r158: Andrew Bennetts)
[03:18] <spiv> lifeless: we have a winner! :)
[03:18] <spiv> lifeless: Thanks for sorting that buildbot merge out.
[03:25] <jamesh> stub: could you delete bugtracker ID 33 (name = auto-bugs.gnome.org)?
[03:25] <jamesh> stub: it shouldn't have any bug watches on it now
[03:26] <stub> jamesh: Done
[03:26] <jamesh> thanks
[04:40] <spiv> stub: I'd like to make the librarian's Database-Name check compulsory, but that means updating remoteAddFile to send it.
[04:41] <stub> Yup
[04:41] <mpt> How do I get gpgme into my tree?
[04:41] <stub> spiv: Is that problematic?
[04:41] <spiv> stub: Which probably means updating logger.LibrarianFormatter...
[04:41] <spiv> Basically, I'm not sure that I can automatically figure out the right value to send.
[04:42] <stub> LibrarianFormatter just uses the api - only changes needed should be client.py
[04:43] <spiv> stub: I guess what I'm really asking is it safe to assume that all users of remoteAddFile (which I think is just the LibrarianFormatter) actually have database access?
[04:43] <stub> So the issue is that we might not be able to retrieve the database name at the point of sending
[04:43] <stub> So we need to retrieve the database name on connection and cache it
[04:44] <stub> It probably isn't an urgent fix - there has been no case where such a misconfiguration has actually occured.
[04:45] <spiv> Yeah.  If it was a near-trivial change, it would be worth doing, but this is requiring more thought and effort than I'd anticipated...
[04:45] <stub> spiv: Actually - it is trivial
[04:45] <stub> spiv: Just pull config.dbname
[04:46] <spiv> Ah, cool.
[04:46] <spiv> That will have the right value always?
[04:46] <stub> Unless someone has manually opened a database connection, yes. 
[04:46] <stub> (with their own connection string and everything)
[04:47] <spiv> Yeah, in that case they're on their own :)
[04:47] <stub> client.py likely wouldn't work anyway
[04:47] <stub> It would take a lot of work to break it all that badly anyway ;)
[04:50] <spiv> Well, tests seem to pass with that, so that'll do :)
[04:50] <mpt> spiv?
[04:51] <spiv> mpt: You mean sourcecode/pygpgme?
[04:52] <mpt> I mean whatever's absence is causing the error "Couldn't import canonical.launchpad.utilities, No module named gpgme"
[04:52] <mpt> after updating rocketfuel I have no sourcecode/gpgme directory
[04:52] <spiv> Hmm, I just rsynced rocketfuel-built as usual and I'm not getting that problem.
[04:53] <mpt> rsync -aP --delete chinstrap:/home/warthogs/archives/rocketfuel-built/ ~/hacking/lp/rocketfuel
[04:53] <mpt> that look correct?
[04:54] <spiv> mpt: lib/gpgme should be a symlink to ../sourcecode/pygpgme/gpgme
[04:54] <spiv> Looks ok to me.
[04:54] <mpt> lrwxrwxrwx   1 mpt mpt    27 2006-02-20 16:24 gpgme -> ../sourcecode/pygpgme/gpgme
[04:55] <jamesh> mpt: copy sourcecode/pygpgme from rocketfuel-built to the same location in your tree
[04:55] <spiv> Does sourcecode/pygpgme exist?
[04:55] <mpt> no
[04:55] <mpt> pyme does
[04:55] <mpt> but pygpgme does not
[04:56] <spiv> sourcecode/pygpgme should be in your rsynced copy of rocketfuel-built, copy it into the tree you're working on.
[04:56] <mpt> ok
[04:57] <spiv> You might need to "make build" again.
[04:57] <mpt> hmmm, now that directory's there and all the other's are symlinks
[04:57] <mpt> aha, I think I know what to do from here
[04:57] <mpt> others, rather
[04:58] <spiv> Yeah, you can probably symlink it to your rocketfuel-built copy, if you're doing that with the others.  Just so long as it's there in your tree, one way or another :)
[04:59] <mpt> ok, it's working
[04:59] <mpt> thanks spiv and jamesh 
[06:38] <SteveA> good morning
[06:38] <SteveA> lifeless: ping
[06:42] <lifeless> pong
[06:44] <dilys> Merge to devel/launchpad/: [trivial]  Make foaf-update-karma-cache friendlier and less likely to trigger deadlocks (r3162)
[06:44] <SteveA> dreadlocks?
[06:48] <lifeless> SteveA: ping
[06:48] <lifeless> nm
[07:08] <stub> I don't think rastas do karma
[07:32] <SteveA> spiv: hello
[07:38] <spiv> SteveA: Hi.
[07:39] <spiv> jamesh: Do you mind if I shift bjorn/launchpad/distro-launchpad-usage into my review queue?  It's merged into another branch in my queue.
[07:39] <jamesh> spiv: go ahead.
[07:39] <spiv> jamesh: Thanks
[07:40] <dilys> Merge to devel/launchpad/: [r=BjornT]  Fixes the error pages to suggest support requests rather than bug reports (bug 3578). Shortens text fields across Launchpad so they're not overlapping the right column (bug 28740). Finishes the GPG -> OpenPGP fixes (bug 30212). (r3163: Matthew Paul Thomas)
[07:43] <SteveA> spiv: voip call ?
[07:46] <spiv> SteveA: I haven't tried setting up voip on this laptop yet, because of the likely echo (the bug where I can't turn built-in speakers off)
[07:46] <jamesh> spiv: a USB headset avoids that sort of problem :)
[07:47] <spiv> jamesh: by being a seperate sound device?  I'd rather just have a fixed kernel ;)
[07:47] <jamesh> yeah
[07:48] <spiv> I'll try out dapper soon, apparently a new enough kernel should have the fix for this.
[07:49] <SteveA> spiv: nail scissors...
[07:49] <SteveA> you should be able to disable the speakers with those
[07:50] <spiv> SteveA: That's an option I suppose...
[07:51] <SteveA> or a large pillow to cover the speakers
[07:51] <SteveA> anyway, let's have a phone call
[07:51] <spiv> Let's.
[07:51] <spiv> My landline is preferred.
[08:00] <SteveA> ddaa: hello
[08:34] <ddaa> coffee pot, check
[08:34] <ddaa> cigarette, check
[08:34] <ddaa> SteveA: hello
[08:35] <SteveA> nice to see i'm next in line to your addictions
[08:35] <SteveA> we've a meeting in 1h25, is that right?
[08:35] <ddaa> Uh, well, I like you, but I did not actually mean it that way ;)
[08:36] <ddaa> SteveA: yes, though I think that one is going to have a pretty simple agenda.
[08:36] <ddaa> One item: "do everyone like the plan? yes? shall we start now?"
[08:36] <SteveA> i guess i should get up to date with the plan
[08:37] <ddaa> That would be nice.
[08:38] <ddaa> everything should be in your inbox
[08:41] <SteveA> that's the problem.  *Everything* is in my inbox!
[08:43] <ddaa> for the record, the hyperlinked version is there https://chinstrap.warthogs.hbd.com/~david/importd-bzr-plan/importd-bzr-plan.html#implementation-plan
[08:43] <ddaa> The mail version contains the source of the "implementation plan" section for easy commenting.
[08:44] <dilys> Merge to devel/launchpad/: [trivial]  Staging config updates (r3164: Stuart Bishop)
[08:44] <SteveA> ddaa: okay.  i'll read through the https version
[08:56] <carlos> morning
[09:03] <SteveA> hi carlos
[09:03] <SteveA> spiv has been adding an API to do more diagnostics with the librarian
[09:04] <SteveA> the patch is in the review queue, but it will be in production soon
[09:04] <SteveA> so, you should look at how to use this for rosetta.
[09:04] <spiv> carlos: The basic change is that you can do client.addFile(..., debugID='foo')
[09:05] <carlos> ok
[09:05] <spiv> carlos: And that will cause the server to log a bunch of debugging stuff for that request, and mark it with 'foo'
[09:05] <carlos> I will use the 'poexport' tag as that's what triggers the error
[09:05] <carlos> spiv: thanks!
[09:05] <SteveA> so the 'foo' should in fact be something unique to that particular request
[09:05] <spiv> carlos: You can even use a different tag for each request, if you like.
[09:05] <SteveA> so 'poexport-xxxx'
[09:06] <spiv> It will already have datestamps, but more information won't hurt.
[09:06] <SteveA> carlos: can more than one poexport run at once?
[09:06] <carlos> SteveA: no, the export is done by a script so it's a serial process
[09:07] <SteveA> carlos: how about if you get int(time.time()) at the script's start up
[09:07] <SteveA> and put that into a global called script_invokation_id
[09:07] <SteveA> and use that as part of the ID
[09:08] <SteveA> then we'll be sure about this
[09:08] <spiv> The infomration logged will include a timestamp, and the name and size of the file uploaded.
[09:08] <carlos> spiv: hmm, what about the fetch function?
[09:08] <carlos> spiv: did you update it?
[09:08] <carlos> to have the debugID argument
[09:09] <spiv> No; that already logs some basic information, and by the time the fetch occurs, it seems the damage has been done.
[09:10] <SteveA> spiv: my point is to group the actions from a single script invokation
[09:11] <carlos> ok
[09:11] <carlos> SteveA: the addFile can be executed more than once per time
[09:11] <carlos> I was thinking on the fetch method
[09:11] <spiv> SteveA: It's pretty clear already; aside from occuring shortly after the upload, the download includes the same IDs.
[09:12] <SteveA> ok
[09:12] <ddaa> spiv: yay! your buildbot patch is merged!
[09:12] <spiv> ddaa: Thank lifeless, all I had to do was hit the "submit" button repeatedly ;)
[09:12] <ddaa> spiv: as promised, I tentatively assigned a couple of items to you in the importd-bzr plan. You might want to check about that: https://chinstrap.warthogs.hbd.com/~david/importd-bzr-plan/importd-bzr-plan.html#implementation-plan
[09:13] <spiv> ddaa: Heh, ok.
[09:13] <ddaa> spiv: that's still a proposal, SteveA and lifeless have not approved it yet
[09:13] <carlos> spiv: do you think that with that tag we will be able to trace the problem? (we only see it when we try to fetch the files)
[09:13] <spiv> ddaa: I'm happy to be responsible for those tasks.
[09:14] <spiv> carlos: I think so.  The important part is to log more about those uploads, I think.
[09:14] <ddaa> spiv: that's cool, will keep you posted. Unless mgmt has objection with the plan, you should be able to start the first one RSN.
[09:15] <spiv> ddaa: No rush, I have plenty to keep me busy ;)
[09:15] <ddaa> (actually, It would be nice to start it soon because other tasks depend on the celebrity being available)
[09:15] <carlos> ok
[09:15] <ddaa> spiv: will keep you posted :)
[09:16] <SteveA> spiv, ddaa: these tasks are fine for spiv to do.
[09:16] <spiv> ddaa: Actually, one question
[09:16] <SteveA> ddaa: does anything need to be done before spiv could start on these?
[09:16] <ddaa> SteveA: I do not think anything blocks the first one
[09:16] <spiv> ddaa: I don't know much about baz2bzr
[09:16] <ddaa> spiv: don't be so tight, you have unlimited questions credit
[09:17] <SteveA> spiv: can you put the first one on your todo list, above the authserver cacheing work?  (that's "Add ``importd`` Celebrity to Launchpad and modify ``supermirror-pull-list.txt``")
[09:17] <ddaa> spiv: well, the baz2bzr thing this doc is talking about does not exist yet, it's the big piece that we will have to implement.
[09:17] <spiv> SteveA: Ok.
[09:17] <SteveA> thanks
[09:18] <SteveA> ddaa: for the second one, i think it will need a bit more explanation
[09:19] <ddaa> spiv: most of the document is about deciding how to implement it and why. Basicilly what the second task means is "modify all the bits that register new branches to set Branch.origin appropriately".
[09:19] <spiv> ddaa: Ah.  I understand what's required for Branch.origin with AuthServer and Launchpad.
[09:19] <spiv> Right.
[09:19] <ddaa> It should be usually trivial, it's just nasty to deploy.
[09:20] <spiv> And "baz2bzr" in this context means "whatever converts our exist baz imports to bzr"?
[09:20] <ddaa> specifically it means "the script we will run in buildbot to convert, register and internall publish bzr branches for rcs imports"
[09:20] <ddaa> where convert means "convert from baz"
[09:21] <spiv> Right.
[09:21] <spiv> Well, I won't worry about that bit until that script exists :)
[09:21] <ddaa> spiv: exactly :)
[09:21] <ddaa> it's  just a cleanup anyway, it's not critical to delivering
[09:32] <SteveA> ddaa: the importd celebrity
[09:32] <SteveA> what kind of object do you imagine this will be?
[09:33] <ddaa> SteveA: TBH I was a bit handwaving here...
[09:33] <SteveA> it needs to be an owner of some stuff
[09:33] <SteveA> so it needs to be from the Person table
[09:33] <SteveA> so it can be a Person or a Team
[09:34] <ddaa> I guess it could be a plain "dummy" person, or a team with buttsource as its admin.
[09:35] <SteveA> we really should change the name "buttsource" sometime
[09:35] <SteveA> seeing is there is no "buttress" any more
[09:35] <ddaa> Thinking of it, the main purpose of having something separate from buttsource is to avoid advertising the "buttsource" name in public URL.
[09:35] <SteveA> ok
[09:35] <SteveA> let's change it to rename "buttsource" to importd
[09:35] <jamesh> because it makes people giggle?
[09:35] <SteveA> then spiv need not do so much work?
[09:36] <SteveA> some people claim that it is simply not possible to say the word "butt" too often
[09:37] <ddaa> I'm happy with renaming buttsource to importd and using that as the owner of import branches. I'd like to hear lifeless about it.
[09:37] <ddaa> He might be aware of some nasty corner case were that would be problematic.
[09:37] <SteveA> to rename the 'buttsource' team, we'd need to have a change to the celebrities, and a database patch
[09:37] <SteveA> okay, so item for the meeting in 20 mins
[09:37] <spiv> ddaa, SteveA: Let me know what you decide, so I know what to implement :)
[09:38] <ddaa> anyway, the buttsource emblem sucks, dunno how I'm going to draw importd though :)
[09:39] <spiv> A big vacuum cleaner.
[09:39] <spiv> Because it sucks ;)
[09:39] <ddaa> spiv: that's a great idea!
[09:40] <ddaa> it's all about vacuum cleaners, Hoover, Roomba...
[09:40] <ddaa> CVS, SVN...
[09:40] <spiv> Thinking of which, when do I get a Twisted import? ;)
[09:40] <ddaa> spiv: though it's hard to make something look big in 16x16
[09:41] <SteveA> spiv: there will be a bug filed on you for it
[09:41] <ddaa> spiv: interesting question, after we are publishing bzr branches, there should probably be a balance between fixing bugs and cleaning up the code...
[09:42] <ddaa> there a very large amount of work to do on both fronts, and I do not think it would be wise to just serialise them.
[09:43] <spiv> ddaa: Ideally you fix bugs by cleaning up the code ;)
[09:43] <ddaa> (mostly because each task is basically a "can take forever" sort of task)
[09:43] <ddaa> spiv: either do functional changes, or refactoring, not both at the same time
[09:45] <spiv> ddaa: I was imagining a magical world where all bugs are simply the result of ugly code.  The sort of wishful thinking that comes from being a reviewer, maybe ;)
[09:45] <ddaa> spiv: well, maybe but you know, fixing deployed SVN and CVS out there is not really an option
[09:46] <ddaa> so we have to add ugliness in our code to match this external ugliness
[09:46] <spiv> But as far as cleaning vs. bug fixing, I guess it's just a matter of balancing priorities.
[09:47] <ddaa> spiv: yes, and that's a tricky problem, because most problems there are firmly in the "urgent and important" corner...
[09:48] <ddaa> I guess I should sit down again for a week and think about it after we have done phase 1 transition...
[09:49] <mpt> "Urgent and important corner"? Someone's been Covey-ing :-)
[09:51] <SteveA> what do you mean "what the point is" 
[09:51] <mpt> Why does it exist?
[09:51] <mpt> What can members of that team do that other people can't?
[09:51] <SteveA> you are talking about a specific team?
[09:51] <SteveA> or the concept in general?
[09:51] <mpt> The concept in general
[09:51] <SteveA> i can't say about that
[09:51] <mpt> (hence "a", not "the")
[09:52] <SteveA> ubuntu members can
[09:52] <SteveA>  - get an ubuntu.com email address
[09:52] <SteveA>  - have signed the CoC
[09:52] <SteveA>  - can get business cards
[09:52] <SteveA>  - have been voted in as members by the CC
[09:52] <SteveA>  - are identifiable in launchpad by having the ubuntu members team emblem
[09:53] <mpt> Pillars of Launchpad and pillars of salt?
[09:54] <SteveA> enough of this pillar-talk
[09:54] <mpt> SteveA, I was trying to come up with a sensible blurb for the +selectmemberteam page
[09:54] <mpt> At the moment it says "Select the Launchpad team that defines the members of <distro>"
[09:54] <mpt> it doesn't say *why*
[09:55] <SteveA> different distros will have their own concept of "membership"
[09:56] <mpt> hummm
[09:56] <SteveA> the other thing that ubuntu members get to do is to vote
[09:56] <SteveA> so maybe that's the defining thing for ubuntu members in launchpad
[09:57] <mpt> All those things could be done if "distribution members team" wasn't a special kind of team in Launchpad
[09:57] <SteveA> how do you mean "special kind of team" ?
[09:58] <mpt> a team that fills a special slot in a distro entity
[09:58] <SteveA> as a side note, people don't create distros all that often in launchpad.  so there are probably things you could work on that have a greater benefit.
[09:58] <mpt> distribution.members
[09:59] <SteveA> launchpad has a model of what makes up a distribution
[09:59] <mpt> Yeah, I know, I was just passing through that template
[09:59] <SteveA> this is modeled along the lines that ubuntu uses
[09:59] <SteveA> ubuntu has "ubuntu community members"
[09:59] <SteveA> there are reasons to want to be able to, in code, get to the "community members" team of a distro
[10:00] <SteveA> so that is why it is a special kind of team
[10:00] <SteveA> although, i wouldn't say "special kind of team"
[10:00] <SteveA> because that implies it works differently to other teams
[10:00] <SteveA> it is a team that is in a special relationship to a distro
[10:00] <mpt> I was wondering what those reasons were
[10:01] <mpt> I'll just XXX it
[10:02] <SteveA> for example, be able to display on a page "This distro's members are _The Ubuntu Members Team_."
[10:02] <SteveA> to say "in launchpad, Ubuntu has 6000000 members. Impi has 50000 members"
[10:02] <SteveA> or whatever numbers
[10:03] <mpt> That would be useful if it meant anything *else* -- but if it can mean "contributors" for one distro and "users" for another, not so much.
[10:05] <mpt> cf. https://launchpad.net/people/ubuntumembers
[10:09] <SteveA> stub: can you point staging's email to the imap box?
[10:09] <daf> morning
[10:17] <carlos> daf: morning
[10:37] <SteveA> daf: ddaa will shortly be filing an oops bug on an oops produced by a page related to bzr imports
[10:37] <SteveA> would you be able to look at it?
[10:37] <daf> yes
[10:38] <daf> though Launchpad is not responding for me right now
[10:39] <SteveA> works for me
[10:39] <SteveA> ddaa will assign the bug to you, when it is filed
[10:40] <stub> SteveA: Yup. config changes should have landed now.
[10:40] <SteveA> stub: cool, thanks
[10:41] <daf> it's odd; the HTTP service redirects me to the HTTPS one, but then the HTTPS one doesn't give me a response
[10:41] <SteveA> maybe you have a certificate-related window open somewhere?
[10:42] <daf> I don't think so, no
[10:42] <daf> I can access chinstrap https fine
[10:42] <daf> I'll try restarting Epiphany
[10:45] <daf> that didn't work
[10:46] <daf> using openssl -connect launchpad.net:https and issuing a GET request by hand works
[10:46] <daf> so it's Epiphany
[10:48] <daf> hmm, same happens with Firefox
[10:49] <mpt> so it's Necko
[10:49] <daf> is that like Gecko?
[10:49] <mpt> It's the networking library
[10:49] <mpt> Gecko's the layout engine
[10:49] <daf> I see
[11:04] <stub> SteveA: Should be running now
[11:24] <stub> Kinnison: ping
[11:26] <Kinnison> stub: pong
[11:26] <Kinnison> stub: what can I do for you sir?
[11:27] <stub> Kinnison: Are you still handling soyuz rollouts or has that been handed off to someone else (me?). There will be a rollout tomorrow.
[11:28] <Kinnison> stub: I can assist, or cprov can
[11:28] <Kinnison> stub: or, if you have permission, you can do it and I'll be here in case you get stuck
[11:29] <stub> ok.
[11:29] <Kinnison> stub: can you log into drescher?
[11:29] <papa_lic> hello nerds ;)
[11:29] <papa_lic> question
[11:29] <papa_lic> does anyone know about problems using live-cd?
[11:30] <papa_lic> I wanted to use live cd in estonian but got stuck in the login screen
[11:30] <ddaa> papa_lic: most likely, guys in #ubuntu would know
[11:30] <papa_lic> id wont log in under any circumstances
[11:30] <stub> Kinnison: Yes. I think I have access. It is more should code be updated, what branch needs to be rolled out, and all that stuff. I'm happy to leave the details to you and/or cprov
[11:30] <papa_lic> ok
[11:30] <ddaa> papa_lic: this channel is about the launchpad.net website
[11:30] <Kinnison> stub: I'd say you need to coordinate with cprov since he know the codeline more than I
[11:31] <stub> ok.
[11:31] <Kinnison> stub: I've been away from it for a week now
[11:42] <BjornT> stub: could you please run pending/reduce-support-tracker-statuses.sql on staging?
[11:42] <dilys> Merge to devel/launchpad/: [r=spiv]  add 'launchpad usage' flags to distributions, in the same way it's done for products. (r3165: Bjorn Tillenius)
[12:05] <SteveA> hi carlos 
[12:05] <carlos> SteveA: hi
[12:13] <cprov> good morning 
[12:13] <SteveA> hi cprov 
[12:14] <cprov> SteveA: hi, how was the weekend ?
[12:14] <SteveA> it was good.  i got my guitar out for the first time in months.
[12:16] <cprov> SteveA: hey, good Mr rock'n roll )
[12:16] <SteveA> mr scottish-folk-played-poorly in this case, but thanks :-)
[12:18] <BjornT> SteveA: pong
[12:18] <SteveA> thanks
[12:23] <carlos> cprov: hi
[12:23] <carlos> cprov: how was the testing?
[12:24] <cprov> carlos: hi, bad, lot of issues raised, from you part, still missing proper changesfiles (md5 collisions from the last)
[12:24] <cprov> carlos: haven't time to fix it myself, yet
[12:24] <carlos> cprov: ok, I will provide you with fixed packages
[12:25] <cprov> carlos: thanks dude
[12:27] <ddaa> SteveA: spiv: bug 32105, bug 32106
[12:27] <Ubugtu> malone bug 32105 in launchpad "Rename importd" [Normal,Confirmed]  http://launchpad.net/bugs/32105
[12:27] <Ubugtu> malone bug 32106 in launchpad "Extend supermirror-pull-list.txt for vcs-imports" [Normal,Confirmed]  http://launchpad.net/bugs/32106
[12:34] <dooglus> is there a guide somewhere as to what the different 'status' values mean in malone?
[12:40] <dooglus> particular 'fix released' and 'fix committed', and how either of those relates to users being able to check that the bug really is fixed, so the fix doesn't get lost.
[12:41] <LarstiQ> dooglus: the difference is between released versions, and fixes in the version control system
[12:42] <LarstiQ> dooglus: whilst some users might be able to checkout the most recent version from cvs (or whatever), most will not
[12:42] <LarstiQ> dooglus: but the actual work has been done at that point, other than waiting for a release to happen
[12:48] <dooglus> LarstiQ: sometimes I report a bug, it gets marked as "fix released" and then the bug hangs around for another few months with no visible change, other than that the bug no longer appears in malone when I search for it.
[12:49] <dooglus> LarstiQ: it's as if I had never reported the bug - it's not shown in search results, and isn't fixed, although it's marked as such.
[12:49] <LarstiQ> dooglus: do you have an example of such a bug?
[12:49] <dooglus> LarstiQ: there seems to be no way of distinguishing between "fix released" and "fix available on archive.ubuntu.com and available for installation"
[12:50] <dooglus> LarstiQ: I'm trying to find one.  Just a moment.
[12:50] <LarstiQ> dooglus: now you're entering into areas where my knowledge as a launchpad user falls short
[12:51] <dilys> Merge to devel/launchpad/: [r=salgado]  fix bug 6667, update more than one bug watch in a single request to a remote bugzilla instance. (r3166: Bjorn Tillenius)
[12:52] <dooglus> LarstiQ: https://launchpad.net/distros/ubuntu/+source/update-notifier/+bug/28672
[12:52] <Ubugtu> malone bug 28672 in update-notifier "text in pop-up bubble has odd capital 'U'" [Normal,Fix committed]  
[12:53] <dooglus> LarstiQ: that's "fix committed", not "fix released", but the patch hasn't made its way to the archives and it's had over a month to do so.
[12:55] <LarstiQ> dooglus: this looks to me as exactly what fix committed is for. I don't know why there hasn't bee a new upload yet, perhaps Michael has other changes he wants to roll in
[12:55] <LarstiQ> dooglus: you're running dapper?
[01:00] <dooglus> LarstiQ: yes.
[01:00] <dooglus> LarstiQ: Michael has made many uploads since marking that one "fix committed"
[01:00] <dooglus> LarstiQ: many uploads of update-notifier, that is
[01:01] <dooglus> LarstiQ: ten releases: 0.41.1, 0.41.2, 0.41.3, 0.41.4, 0.41.5, 0.41.6, 0.41.6, 0.41.6, 0.41.7, and 0.41.7.cln, were all uploaded *after* that bug was 'fix-committed'.
[01:02] <dooglus> LarstiQ: so I don't know whether the patch has got lost, or whether it's being held back for a different reason
[01:02] <dooglus> LarstiQ: now, this is just a typo bug, so I don't really care, but the same applies to any other bug.  shouldn't there be a 'status' value for "patch available in the archives", so that I can check that the bug really is fixed?
[01:02] <LarstiQ> dooglus: hmm, I don't know enough about update-notifier, I would need to look at the repository to see what is going on
[01:03] <LarstiQ> dooglus: afaiui, fix released would work for that
[01:03] <LarstiQ> dooglus: update-notifier seems to me a native package, so you have no problem with upstream interaction?
[01:04] <seb128> hi
[01:04] <dooglus> LarstiQ: that's right
[01:04] <dooglus> LarstiQ: "fix released" isn't the same.  https://launchpad.net/distros/ubuntu/+source/vnc/+bug/31296 is "fix released"
[01:04] <Ubugtu> malone bug 31296 in vnc vncserver "vncserver isn't installable" [Normal,Fix released]  
[01:05] <dooglus> LarstiQ: however, "The following packages have unmet dependencies. vncserver: Depends: xserver-common but it is not installable"
[01:06] <dooglus> hi seb
[01:06] <seb128> daf: interested by some oops today?
[01:06] <LarstiQ> dooglus: Fabio said he has uploaded the packages though
[01:06] <seb128> I'm trying to triage some of my bugs, but launchpad is still far to behave correctly
[01:06] <LarstiQ> dooglus: there is a delay between upload and being available on package mirrors, perhaps that is biting you?
[01:06] <dooglus> LarstiQ: that's right.  so maybe the status should be "fix uploaded" or something?
[01:07] <LarstiQ> dooglus: ah hmm, to me, upload == release in these cases. But I'm not an lp dev, so you could try asking for that (wiki, malone? not sure)
[01:07] <LarstiQ> dooglus: I do know there has been discussion on these 'fix something', so there must be documentation somewhere
[01:08] <stub> BjornT: Done
[01:08] <LarstiQ> dooglus: for your update-notifier, the communication with mvo seems the bottleneck to me
[01:09] <dooglus> LarstiQ: is malone the proper place to attempt communication about bugs?  Or should I hunt him down on IRC or email?
[01:10] <LarstiQ> dooglus: you have pinged the bug twice, in my eyes, communication there is proper, but irc/email looks more effective for this bug
[01:10] <LarstiQ> dooglus: I'll help hunt if needed ;)
[01:13] <dooglus> LarstiQ: the hunt isn't a very difficult one ( https://launchpad.net/people/mvo )
[01:14] <LarstiQ> ah no, that should be easy
[01:15] <ddaa> daf: bug 32117
[01:15] <Ubugtu> malone bug 32117 in launchpad "ProductSeries.branch OOPS" [Normal,Confirmed]  http://launchpad.net/bugs/32117
[01:43] <jbailey> Is it worth reporting source package timeout errors?  If there's already fixes in the queue, I'd hate to just be adding noise to your database.  (It's looking up source packages in Ubuntu)
[01:44] <kiko> there are bugs already, yes
[01:44] <SteveA> jbailey: you can search for 'oops' milestone bugs
[01:44] <SteveA> if you want to be subscribed to them or whatever
[01:45] <jbailey> SteveA: I'm not fussed about subscribing - I just don't want to create unnecessary work if there's already a bunch of optimisation stuff scheduled for tomorrow's rollout.
[01:45] <jbailey> I've gotten good at hitting the reload button until the page comes up
[01:49] <jbailey> How do I search for "9600" as text within a bug, rather than looking for a bug number?
[01:50] <carlos> kiko: hi
[01:50] <kiko> hey carlos, what's up?
[01:50] <jbailey> I'm filing a bug against X and am search for the card model number to check for dupes
[01:50] <carlos> kiko: I found the problem, I was too tired O:-)
[01:50] <kiko> aha
[01:50] <kiko> that's better
[01:50] <carlos> kiko: the error was a broken check
[01:50] <carlos> kiko: the tests are passing now
[01:51] <carlos> kiko: do you have time to take another look and approve it?
[01:51] <kiko> carlos, can you show the code to SteveA?
[01:51] <kiko> I'd rather he had a look
[01:51] <carlos> sure
[01:51] <carlos> let me prepare a new diff
[01:57] <carlos> SteveA: hi
[01:57] <seb128> kiko: who should I ping about launchpad oopsing all the time?
[01:58] <kiko> seb128, me :)
[01:58] <kiko> what  is bothering you today?
[01:58] <seb128> OOPS-51C130 OOPS-51C155 OOPS-51A147 OOPS-51D142 OOPS-51A157 OOPS-51D162 OOPS-51C188 OOPS-51A187 OOPS-51B195 OOPS-51B194 OOPS-51A194 OOPS-51D199 OOPS-51A218 OOPS-51A223 OOPS-51C235 OOPS-51B236 OOPS-51B237 OOPS-51C240 OOPS-51B247 OOPS-51A236 OOPS-51D238
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51C130
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51C155
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A147
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51D142
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A157
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51D162
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51C188
[01:58] <seb128> that's my collection of this morning
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A187
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B195
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B194
[01:58] <seb128> ups, flood, sorry
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A194
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51D199
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A218
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A223
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51C235
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B236
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B237
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51C240
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B247
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51A236
[01:58] <seb128> stupid bot :)
[01:58] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51D238
[01:58] <kiko> seb128, next time, msg me
[01:58] <seb128> yeah, I've noticed
[01:59] <carlos> seb128: spammer!!!
[01:59] <seb128> dunno if they are all the same etc, but since it oops quite a lot I've decided to note all of them for a day
[01:59] <carlos> :-P
[01:59] <seb128> and after 3 hours I figured I've enough, no need to wait a day
[02:02] <mpt> LarstiQ, dooglus, how long mirrors take to pick up a version with a bugfix is really out of the developer's control, so it's not really reasonable to expect them to keep a bug as Fix Committed until the last mirror has woken up
[02:04] <kiko> BjornT, ping?
[02:05] <BjornT> hi kiko 
[02:05] <kiko> BjornT, look at this traceback from seb128, it's interesting:
[02:05] <kiko> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B247
[02:05] <mpt> jbailey, there isn't a way of searching for a number at the moment, that's bug 5943
[02:05] <Ubugtu> malone bug 5943 in malone "can't search for numbers in Malone" [Normal,Unconfirmed]  http://launchpad.net/bugs/5943
[02:06] <kiko> salgado, might be time for us to do magic on the vocabularies.. 10 of seb128's timeouts were on the vocabs, and some queries took 60s :-/
[02:06] <jbailey> mpt: Thanks.  I discovered that if I add another word beside it, it's fine for now, so I did that.
[02:07] <seb128> kiko: what are vocabularies for launchpad?
[02:08] <kiko> seb128, the mechanism through which you select a person in +editstatus, for instance.
[02:08] <seb128> ah
[02:08] <seb128> I use nickname all the time
[02:09] <kiko> yeah, we could optimize for that
[02:09] <seb128> easier than trying to remember the exact email :)
[02:09] <salgado> kiko, that would require some serious magic, because in normal conditions that query takes at most a few seconds. IOW, I think the only solution is finding and fixing whatever is locking the tables used on that query
[02:09] <salgado> we already spent lots of time improving the performance in the vocabs, but the problem persists
[02:09] <kiko> salgado, still, we need to solve the problem, and if stub says he can't get us locking information..
[02:11] <kiko> BjornT, any clue?
[02:13] <BjornT> kiko: part of oops 51B247 is due to bug 4845. source package was set to None, and there is already a bugtask on ubuntu without a source package.
[02:13] <Ubugtu> malone bug 4845 in malone "assigning of package bug targets needs input validation" [Normal,In progress]  http://launchpad.net/bugs/4845
[02:13] <kiko> BjornT, but he's doing +editstatus..
[02:14] <BjornT> kiko: yes, but the same check of source package uniqueness has to be done there.
[02:20] <salgado> kiko, have you seen stub committed some changes to the karma-cache updater in a try to reduce contention in the person table?
[02:31] <kiko> BjornT, okay, but are you suggesting seb128 /cleared/ spn or bpn when doing +editstatus?
[02:33] <seb128> I did cleared the packages source binary
[02:33] <seb128> I've updated the desktop seed for that bug
[02:33] <seb128> but that's not really a package, so I cleared them to have the bug on Ubuntu
[02:34] <seb128> is that wrong?
[02:34] <kiko> no
[02:34] <kiko> but there was already an ubuntu task, no?
[02:34] <seb128> dunno
[02:35] <seb128> there was a rejected task, I didn't really took care of it
[02:35] <seb128> I didn't reject it so I just clicked on the open task
[02:35] <seb128> lemme have a look
[02:36] <seb128> right
[02:36] <LarstiQ> mpt: I very much agree, but the update-notfier bug looks like it might have fallen through the cracks
[02:37] <seb128> kiko: ok, so the issue is that there is no way to make the difference between a real bogus oops or something you have to retry ... this one worked without clearning the package :)
[02:38] <kiko> seb128, the problem there is a validation bug
[02:41] <seb128> kiko: is OOPS-51B301 another of those vocabularies issue?
[02:41] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51B301
[02:53] <kiko> seb128, yes! i have no clue why those queries are fucked today.
[02:53] <kiko> wtf is stub
[03:05] <kiko> salgado, oh, are you referring to stub's empty merge?
[03:06] <kiko> BjornT, congratulations on the bugwatches landing
[03:07] <salgado> kiko, no, I didn't see the merge, I just saw he marked a bug as fix committed
[03:07] <BjornT> kiko: it's only the first part, though, i'm currently working on making the bugtask fetch its status from the bug watch.
[03:07] <kiko> BjornT, I know, but it was good work
[03:11] <kiko> SteveA, matsubara won't be able to send incoming malone mail to staging, will he?
[03:12] <kiko> BjornT, might know the answer to that too
[03:12] <BjornT> kiko: atm no, but it would be nice to make it possible to send mail to staging.
[03:13] <kiko> yeah, indeed.
[03:13] <kiko> is elmo or Znarl around, I wonder, and is it an easy setup, BjornT?
[03:15] <BjornT> kiko: it's not too hard. need to set up a pop3 box for staging, and configure bugs and support email domains to have the mail going to that pop3 box. then stub has to configure staging to use the new domains and pop3 box.
[03:16] <kiko> I'll try and get that sorted.
[03:16] <BjornT> cool
[03:20] <doko_> SteveA: any reason not to update twisted to 2.2 in dapper?
[03:20] <SteveA> doko: i don't know particularly about twisted changes and all that
[03:20] <SteveA> spiv and radix are the best people to ask
[03:21] <doko> spiv: ^^^
[03:21] <doko> who's radix?
[03:22] <SteveA> radix is the twisted release manager
[03:44] <seb128> carlos: OOPS-51C310
[03:44] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/51C310
[03:44] <BjornT> hi matsubara. have you started working on bug 3796 yet?
[03:44] <Ubugtu> malone bug 3796 in malone "Duplicated bugs still show up as New in a list of bugs (also affects the Latest bugs portlet)" [Normal,Confirmed]  http://launchpad.net/bugs/3796
[03:50] <matsubara> hi BjornT, not yet.
[03:54] <BjornT> matsubara: ok, just wanted to let you know that i will implement part of the fix to that bug in my BugWatches-part-2 branch.
[03:55] <matsubara> BjornT: ok, I'll coordinate with you when I start it.
[04:04] <bradb> BjornT: Is https://wiki.launchpad.canonical.com/BugWatches considered the most up-to-date spec on Bugzilla/Debbugs importing? I'm replying to Mark's email, with links to the relevant specs.
[04:05] <kiko> bradb, which of mark  emails?
[04:05] <kiko> bradb, the priorities email?
[04:05] <bradb> yeah
[04:05] <kiko> if so, I'd suggest you don't answer it, but instead let me
[04:05] <bradb> sure, no prob
[04:05] <kiko> (and in the future don't reply to email from mark -- forward it to steve and I if we're not CCed)
[04:06] <bradb> heh, ok
[04:06] <kiko> one less problem for you :)
[04:08] <BjornT> bradb: anyway, the BugWatches spec doesn't cover the debbugs import. i don't think there is an up-to-date spec on that.
[04:09] <bradb> kiko: Are you going to handle the actions points in that email then? i.e. creating the specs and setting the priorities?
[04:09] <kiko> I am going to try and defuse the email first, and failing that, we'll see.
[04:09] <bradb> kiko: Ah, now that would be cool. ;)
[04:10] <kiko> bombs like that often blow up in your face though.
[04:14] <bradb> heh
[04:14] <bradb> kiko: Will you try diffusing the bugmail email also?
[04:14] <bradb> er, defusing, even
[04:14] <kiko> did I see that I wonder
[04:15] <kiko> hmmm
[04:15] <kiko> I think that's actually something we have filed as bugs already -- the only thing mark is suggesting is including the description in any bugmail we send out, right?
[04:16] <bradb> kiko: And the error messages, which seem hard to detect (at the bottom of the message) or make sense of to a less experienced user.
[04:16] <kiko> bradb, can you rephrase that?
[04:20] <bradb> kiko: He's proposing (I think) that if you send a bugmail to Malone, it will send back a notification email, and include any error output at the bottom of that email. That would be hard to detect, and hard to make sense of for a new Malone email user, I think.
[04:21] <kiko> how is that feedback provided today?
[04:21] <bradb> kiko: Separate error emails, AFAIK. Right BjornT?
[04:22] <BjornT> bradb, kiko: right, separate emails, and if an error is encountered, no changes are made to the bug.
[04:22] <kiko> I don't think that's too bad; I wonder what Mark's motivation for combining the two is. I will ask.
[04:23] <bradb> kiko: If you look at the "ERROR MESSAGES:" part of https://wiki.launchpad.canonical.com/MaloneEmailMessages, it seems hard to know what happened.
[04:23] <kiko> yeah
[04:23] <kiko> ok.
[04:23] <bradb> And hard to even notice that an error happened, if you don't know to look for it, etc. Anyway, </rambling>.
[04:54] <carlos> kiko: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-20/C310 <--- This OPPS says that we still need to improve the suggestions...
[04:56] <carlos> seb128: we are working on reduce the time needed to render that page. That's a really good query to see a concrete performance problem we have atm
[04:57] <seb128> carlos: seems so, it likes to oops when loading :p
[04:58] <carlos> seb128: that's a problem with suggestions, it takes a lot to get them for that concrete page
[04:58] <seb128> too many suggestions pending?
[05:01] <sivang> hi all
[05:02] <carlos> seb128: too many suggestions or translations elsewhere, our database is growing a lot and we need to improve the way that we render it
[05:02] <carlos> sivang: hi
[05:03] <sivang> hi carlos :)
[05:39] <kiko> carlos, yeah.
[05:42] <kiko> stub, note your empty merge
[05:44] <Kamion> um, the queue ftpmaster tool on drescher is exploding on me on stuff that worked (not on the same package, but similar invocations) earlier today
[05:44] <Kamion> is somebody working on drescher right now?
[05:44] <kiko> Kamion, if anyone, cprov -- you should coordinate with him, always.
[05:45] <Kamion> hmm, I suppose it's possible that it just can't handle unicode in .changes files when accepting out of NEW
[05:45] <Kamion> kiko: (I hope you don't mean I should coordinate with him when doing *anything* on drescher, e.g. processing the NEW queue)
[05:45] <Kamion> (because that would be impractical)
[05:46] <Kamion> I'll just file a bug for this one
[05:46] <cprov> Kamion: most of the things don't need coordination, I don't process NEW queue entries for instance 
[05:47] <Kamion> indeed, I didn't expect you to :)
[05:47] <cprov> Kamion: right, I'm checking mail for failures, one sec
[05:47] <Kamion> this one's bug 32148
[05:47] <Ubugtu> malone bug 32148 in launchpad-upload-and-queue "can't accept revu-tools (Unicode trouble?)" [Normal,Unconfirmed]  http://launchpad.net/bugs/32148
[05:47] <kiko> matsubara, bug 1281 is fix-released, right?
[05:47] <Ubugtu> malone bug 1281 in launchpad "Need some way to merge accounts without emailaddress or with only dead ones" [Normal,Fix committed]  http://launchpad.net/bugs/1281
[05:47] <kiko> update!
[05:49] <matsubara> kiko: done.
[05:49] <cprov> Kamion: uhm .. is it urgent ?
[05:51] <kiko> matsubara, got my email?
[05:51] <Kamion> cprov: well, it's been in NEW for 12 days, I don't want to delay it much longer
[05:51] <matsubara> kiko: yep.
[05:51] <Kamion> but not super-urgent world-ending
[05:52] <cprov> Kamion: right, so I will finish the rollout related issues and will address it porperly until today evening, is that okay ? 
[05:52] <Kamion> that's fine, thank
[05:52] <Kamion> s
[06:10] <SteveA> bradb: i went to change a bug task status.
[06:10] <SteveA> but, i realized it was already how i wanted it.  so i went to leave the comment anyway, but the page wouldn't let me leave a comment.
[06:11] <SteveA> it says (!) you provided a comment without changing anything.
[06:11] <SteveA> I know that!
[06:11] <bradb> Right. I could easily remove that constraint.
[06:34] <mdke> is dapper ready in rosetta yet?
[07:03] <sladen> I got utterly shocked by:  http://librarian.launchpad.net/1050471/HackergothciToes2.jpg
[07:04] <kiko> that's stub, sladen 
[07:04] <sladen> please instigate immediate filtering of all obscene images.  kthxbye
[07:04] <sladen> kiko: :)
[07:18] <carlos> SteveA: hi, around?
[07:24] <kiko> carlos, I think he's out for the day
[07:25] <carlos> kiko: I'm writing an email
[07:29] <carlos> email sent
[07:29] <carlos> see you later
[07:30] <ddaa> kiko: for baz2bzr tests I need to spawn a subprocess in a pty. Is it okay to add python2.4-pexpect to launchpad deps, or should I write the process spawning myself using pty.fork()?
[07:30] <kiko> do you really need pexpect?
[07:30] <ddaa> The functionaity I need i really pretty limited, spawn a suprocess, read all its output.
[07:31] <ddaa> so, I do not really need pexpect
[07:31] <kiko> doesn't the subprocess module do what you eed?
[07:31] <ddaa> no, it does not do pty spawning AFAICT
[07:31] <kiko> how hard is it to do the process spawning? how complicated is the code in -pexpect?
[07:32] <ddaa> not very hard, it's standard fork/exec stuff AFAICT
[07:32] <ddaa> except using pty.fork
[07:33] <kiko> 10 lines or 100 lines?
[07:33] <ddaa> probably around 25 lines, subprocess stuff tends to get more complicated than expected at first.
[07:34] <kiko> will it be useful elsewhere?
[07:34] <kiko> -pexpect?
[07:34] <ddaa> unlikely
[07:34] <ddaa> okay, will hack something from scratch
[07:34] <kiko> see if you can cargo-cult
[07:34] <kiko> that'd be ideal
[07:34] <ddaa> yeah, make sense
[07:35] <ddaa> ... and I'm only doing time estimates...
[08:39] <doko> spiv: ping
[08:45] <kiko> bradb, BjornT: is there any way to find out who the current user is in database code, or am I supposed to supply that via the view?
[08:45] <bradb> kiko: The current user should be passed as an arg to database methods.
[08:45] <kiko> I feared you would tell me that, grumble grumble
[08:47] <bradb> Otherwise, db code could be written to depend on the existence of a utility (like the launch bag), but SteveA doesn't want that.
[08:49] <kiko> I know, SteveA is right, but it would be convenient here. No mind.
[08:49] <kiko> bradb, have you ever seen projects/foo/+malone-index ?
[08:49] <kiko> for instance:
[08:49] <kiko> https://launchpad.net/projects/launchpad/+malone-index
[08:50] <kiko> (it oopses, but it is easy to get it to work)
[08:50] <bradb> Looks like driftwood. Is it linked from anywhere?
[08:50] <kiko> no
[08:50] <kiko> but it is interesting
[08:50] <kiko> want to see a screenshot?
[08:50] <bradb> sure
[08:52] <kiko> www.async.com.br/~kiko/project-bugs.png
[08:52] <kiko> bradb, if you keep that image, I will nuke out the code, because it's really the only thing worth keeping from the existing crap
[08:54] <kiko> it is of course untested
[08:54] <bradb> kiko: Do you want to drive-by my backport/milestone demystification fix
[08:54] <bradb> ?
[08:55] <bradb> Oh, yeah, that page seems a useful starting point.
[08:55] <kiko> bradb, sure, as soon as I've finished this crap.
[08:55] <bradb> ok
[08:55] <kiko> okay, I will nuke everything related to it away
[08:55] <bradb> sounds good
[08:56] <kiko> I dare you to bzr annotate that code!
[08:56] <bradb> no need :P
[08:58] <kiko> we really need to avoid places that query IBugTask directly
[09:00] <kiko> they bork security
[09:01] <bradb> indeed
[09:01] <kiko> they should DIE
[09:12] <kiko> come on dilys do your thing
[09:20] <SteveA> bradb / kiko: there is a pattern we can use if there's a lot of "user" required in the database code.
[09:21] <SteveA> but, i'd rather think of that as a refactoring, than do it up front.
[09:21] <kiko> nah, I nuked the page anyway :)
[09:22] <dilys> Merge to devel/launchpad/: rs=BjornT Attempt to remove IBugTarget.bugtasks, an evil attribute that doesn't take into account bug privacy (r3167: kiko)
[09:23] <kiko> DIE!
[09:23] <kiko> YES!
[09:23] <kiko> thank you dilys for assisting me
[09:23] <kiko> in MURDERING a bugtask method
[09:23] <kiko> I will do more of that now, encouraged by this success
[09:27] <bradb> kiko: The drive-by should fit nicely into your killing spree :P
[09:27] <kiko> I just control-Cd my commit that said "Kill unused and unreferenced ..." to say "Kill broken, untested, unused and unreferenced ..."
[09:27] <bradb> heh
[09:28] <bradb> i.e. shitty
[09:29] <bradb> Vulgarity is sometimes a useful crutch.
[09:29] <kiko> I try not to use crutches when removing the sab's code
[09:29] <kiko> (I often fail)
[09:30] <bradb> :)
[09:33] <kiko> I have a review for you bradb 
[09:34] <bradb> great
[09:35] <kiko> bradb, https://chinstrap.ubuntu.com/~dsilvers/paste/fileRN7fFZ.html fixes bug 32129
[09:35] <Ubugtu> malone bug 32129 in launchpad "OOPS-51A276: Not sure how to report this...." [Normal,Unconfirmed]  http://launchpad.net/bugs/32129
[09:35] <kiko> actually
[09:35] <kiko> bug 3139
[09:35] <Ubugtu> malone bug 3139 in malone "gentoo should not be the default upstream tracker" [Normal,Confirmed]  http://launchpad.net/bugs/3139
[09:36] <kiko> the first actual change orders malone/bugtrackers, the second orders the vocabularies
[09:37] <kiko> the lowercase success blesses my day
[09:37] <bradb> kiko: # XXX: no _orderBy? should probably be filed as a bug
[09:38] <kiko> there are actually other tables missing orderbys, but ok
[09:39] <bradb> kiko: Maybe the bug to be filed is that all vocabs in dbobjects.py should have an _orderyBy.
[09:39] <kiko> bradb, oh, making SQLObjectVocabularyBase blow up if no orderBy is provided?
[09:39] <kiko> I like that
[09:40] <salgado> why not make SQLBase blow up if no _defaultOrder is provided?
[09:40] <bradb> that could be a way to help solve the problem, yeah
[09:40] <kiko> salgado, I'm not sure though
[09:41] <bradb> kiko: Only one other thing: shouldn't the tracker selector default to Debian?
[09:41] <kiko> I won't answer any political questions tonight. Next?
[09:42] <kiko> bradb, when you send patches as attachments I can't comment on them
[09:44] <bradb> Oof, hang on, I'll resend.
[09:45] <bradb> kiko: resent
[09:46] <kiko> thank you
[09:46] <bradb> kiko: Maybe we could sort the trackers by those with the most bugs attached to them, to save clicks for the most common case?
[09:46] <bradb> seb's main issue seemed to be one of extra clicks, and not being confused about the sort order
[09:47] <kiko> that tends to be tricky
[09:47] <kiko> the ordering changing is something that disturbs people, I think
[09:47] <bradb> hm, true
[09:48] <kiko> because of you know, three clicks and you're at gnome, and oops, today it's 4 and I just added the task on freedesktop
[09:48] <bradb> kiko: Makes sense. I think the patch is good to go then.
[09:49] <kiko> note that that problem exists even with my patch, though
[09:49] <kiko> I don't care enough about the issue to try to improve it before somebody complaining though
[09:50] <bradb> Still exists, though it's a lot more predictable sorting by title, I think.
[09:50] <kiko> yeah.
[09:50] <kiko> thanks
[09:50] <bradb> no prob
[09:51] <kiko> bradb, now that CRAPPY mailer you use WRAPPED the patch
[09:51] <kiko> pastebin it
[09:51] <bradb> Mail.app rocks da boat.
[09:52] <kiko> Mail.app is totally unsuitable for developers
[09:52] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileNZV0sX.html
[09:53] <kiko> here comes the lowercase failure I so love!
[09:54] <kiko> it is a random failure!
[09:55] <kiko> PQM is making personal attacks against me!
[09:55] <kiko> I will resubmit in spite
[09:57] <cprov> kiko: would you like to quick review that safe_fix_maintainer patch ? ( https://chinstrap.ubuntu.com/~dsilvers/paste/file58uUe9.html)
[10:00] <doko> cprov: ping
[10:00] <cprov> doko: pong
[10:00] <doko> cprov: did you see my twisted question?
[10:01] <cprov> doko: no, sorry, where ?
[10:02] <kiko> bradb, replied.
[10:02] <doko> cprov: ouch, ... SteveA suggested to ask spiv, not you :-/
[10:04] <bradb> kiko: thanks, looking now
[10:04] <cprov> cprov: es tut mir sehr leid, Ich kann helfen ob du moechtest
[10:06] <doko> cprov: just wanted to know, if twisted 2.2 instead of 2.1 should be in dapper
[10:06] <kiko> cprov, it looks okay apart from using straight unicode (you should use a \x thingy) and fixing the wording
[10:07] <cprov> doko: I have not seen big changes from 2.1 to 2.2, should work and we only require 2.1, anyway spiv is the guy to ask about it 
[10:07] <cprov> kiko: ok will sort it out, thx
[10:17] <dilys> Merge to devel/launchpad/: r=bradb fix for bug 3139: gentoo should not be the default upstream tracker. Order bugtracker listing and vocabulary by title (r3168: kiko)
[10:17] <kiko> yes!
[10:19] <sivang> ohh cool :) funny to know gento was the default upstream tracker.
[10:38] <kiko> bradb, this looks okay. my concerns are whether a "grep target" still returns stuff we've not looked at
[10:38] <kiko> bradb, also, I wonder if you have a web site I can test on?
[10:40] <bradb> kiko: re: the "grep target" question: the tests will answer that question.
[10:42] <kiko> no, the UI isn't tested
[10:42] <kiko> you should grep target
[10:44] <bradb> kiko: The UI's tested.
[10:44] <kiko> not the wording that goes on the UI, bradb 
[10:44] <kiko> stop doing that
[10:51] <bradb> kiko: http://69.70.209.33:8086/distros/ubuntu/+source/mozilla-firefox/+bug/1 is that starting point
[10:52] <bradb> I don't see any other inappropriate use of the word "target" in the templates.
[10:54] <bradb> hm, there's one method I could probably rename. createTargetedTasks => createBackportTasks
[10:55] <kiko> bradb, it still says "Request fix: In distribution" in the main bug page
[10:56] <bradb> kiko: I didn't touch any of that; that's a whole different can of worms, unrelated to backports.
[10:56] <kiko> unfortunately, I disagree
[10:56] <kiko> it is the same issue.
[10:56] <kiko> to be honest
[10:56] <kiko> nobody ever uses the backport fix feature anyway
[10:57] <bradb> kiko: Are you sure?
[10:57] <kiko> do you have reports or evidence of use of it?
[10:57] <bradb> kiko: I was about to ask you that. :)
[10:58] <bradb> I make no claim as to how often people use it or not, though I've been asked about it before, and pointed people at that screen.
[10:58] <kiko> I've never seen any use, you can grep the server logs on chinstrap, in launchpad?.log
[10:58] <kiko> I'd be surprised if you found more than a few dozen hits
[11:00] <bradb> There are 29 tasks currently open on breezy, 8 on warty, and 2 on hoary. I believe those numbers refer to open tasks.
[11:01] <bradb> As for what the user's goal was when they opened those tasks, there's no way to know, really.
[11:01] <kiko> right
[11:01] <kiko> are there any openon dapper?
[11:01] <bradb> Yes, 43.
[11:02] <kiko> that is a horrible bug.
[11:02] <bradb> This patch fixes that.
[11:02] <kiko> actually
[11:02] <kiko> I guess you're right.
[11:03] <kiko> bradb, is the link inactive when there is no distribution task?
[11:04] <kiko> wtf
[11:04] <kiko> that makes no sense
[11:04] <kiko> is ubuntu hardcoded?
[11:04] <bradb> kiko: It's invisible when you're not in a distribution context
[11:04] <kiko> oh
[11:04] <kiko> I see
[11:04] <bradb> kiko: No, Ubuntu is not hardcoded.
[11:04] <kiko> http://69.70.209.33:8086/distros/ubuntu/+source/mozilla-firefox/+bug/6
[11:05] <kiko> that is very interesting
[11:05] <kiko> hah
[11:05] <kiko> why are dupes even editable? 
[11:06] <kiko> I guess I'm okay but I'd like us to change the text on +backport
[11:06] <kiko> to explain what a backport is
[11:06] <seb128> what page is that?
[11:06] <kiko> http://69.70.209.33:8086/distros/ubuntu/+source/mozilla-firefox/+bug/6/+backport
[11:06] <kiko> bradb, good idea, tell seb128 to check it out
[11:07] <bradb> yeah
[11:08] <bradb> kiko: Do you think that the current screen doesn't hint enough that backporting means fixing this bug in previous releases
[11:08] <seb128> I've no login on that launchpad
[11:08] <bradb> ?
[11:08] <bradb> seb128: foo.bar@canonical.com/test
[11:08] <seb128> the URL kiko just gave
[11:08] <seb128> ah
[11:10] <seb128> yeah, some explanation would be nice
[11:10] <bradb> ok
[11:10] <seb128> and some text indicating that's a tool for maintainers, not a way for users to specify what version of the distro they use :p
[11:11] <seb128> (though they tend to use the milestone for that rather)
[11:12] <bradb> Hm, I have a feeling it will be of only marginal help to expect people will read the instructions, let alone follow them.
[11:12] <seb128> kiko: you know, when you fix a bug you are authorized to put a comment saying how you fixed it :)
[11:13] <seb128> or what you did, or something like that ...
[11:13] <kiko> I am brief but effective!
[11:13] <mpt> kiko, in the DuplicateBugHandling spec I've written that duplicates shouldn't be editable
[11:13] <seb128> kiko: you are useless rather :)
[11:13] <seb128> not true since the bug is fixed
[11:13] <kiko> mpt, cool. now check out bradb's proposed backport change :-)
[11:13] <mpt> but enforced by JavaScript only
[11:13] <seb128> but there is no way to know if it's fixed in a correct way
[11:13] <mpt> so that you can (in the glorious future) reopen and change in one step
[11:14] <mpt> bbbbbbbbbbbbbbackports?
[11:16] <bradb> Let's not get too excited about this. This is, after all, the $0.50 solution.
[11:16] <SteveA> mpt: lots and lots of routers each containing a table to look up what addresses go in what direction.
[11:16] <mpt> Is it hierarchical?
[11:17] <mpt> Is there a server saying "I know all the children (but not the grandchildren) of 69."?
[11:17] <SteveA> sort of
[11:18] <mpt> ok
[11:18] <mpt> bradb, how come there's a backport link on bug 6 but not bug 5?
[11:18] <Ubugtu> malone bug 6 in rosetta ""next 10 entries" at bottom of page" [Normal,Rejected]  http://launchpad.net/bugs/6
[11:18] <Ubugtu> malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix committed]  http://launchpad.net/bugs/5
[11:18] <bradb> mpt: Because Malone doesn't know about product series yet.
[11:19] <mpt> oh
[11:19] <mpt> so you can backport only if you're in a distro (release) (package) context
[11:19] <kiko> correct
[11:20] <mpt> Heh, start at <http://69.70.209.33:8086/products/firefox/+bug/5> and try to figure out how to backport the Warty fix
[11:21] <bradb> mpt: My guess is that jumping from a product context, to backporting a fix to a DR is a highly improbable use case, but I could be wrong.
[11:22] <kiko> I guess bradb's right
[11:22] <mpt> bradb, for me just then it happened because I clicked on the "this bug is a duplicate of bug 5" link
[11:22] <Ubugtu> malone bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix committed]  http://launchpad.net/bugs/5
[11:23] <bradb> mpt: Yeah, all in upstream context though, right?
[11:23] <mpt> bradb, I *was* in the package context for bu.g 6, but clicking on the "this bug is a duplicate of bu.g 5" link took me to the product context because that was first in the list
[11:24] <bradb> oh, hm, that's a bug
[11:24] <bradb> It should have stayed in the same context.
[11:24] <mpt> yeah, that's probably the real bug
[11:24] <kiko> but I think fmt:url doesn't stick to the same context
[11:24] <kiko> it generates /malone/bugs/400-style URLs IIRC
[11:24] <mpt> yes, it does
[11:25] <kiko> which of the two?
[11:25] <mpt> the latter
[11:25] <kiko> yeah. that sucks.
[11:25] <kiko> it should use the launchbag
[11:26] <bradb> Argh, it's hard to add any text to this page without it swallowing up the useful part of the page.
[11:26] <mpt> bradb, on +backport when I click on "Previous Ubuntu releases:" it doesn't do anything
[11:26] <bradb> I had a feeling that might be an issue. :)
[11:26] <kiko> bradb, try using <ul>s to break up the text flow
[11:27] <mpt> Please to be using <p>foo</p> instead of foo<br /><br />
[11:27] <ddaa> lifeless: I checked and there are significant changes in that bzrtools branch
[11:27] <ddaa> for example, the special support for cscvs
[11:28] <ddaa> I do not know who are the "we" in "the base base  bzrtools we use is in rocketfuel"
[11:29] <mpt> bradb, I've added a backport and it looks just like a regular task. Is it supposed to look different or behave differently?
[11:29] <bradb> mpt: Not for this fix, no.
[11:30] <mpt> Is it going to in future?
[11:30] <kiko> I wonder if we should add an icon for a backport
[11:30] <kiko> what do you guys think
[11:31] <bradb> mpt: If this were a non-incremental fix, then yeah, it would be displayed in a very different way, and probably not in "Fix Requested In" (are we not human?) table.
[11:31] <mpt> bradb, I'm sorry, it's early in the morning (11.30am!) and I've forgotten what problem we're trying to solve here
[11:32] <mpt> Someone wants a Dapper bugfix backported to Breezy, so why not just open a Breezy task?
[11:32] <bradb> mpt: The original priority identified here was to forbid opening tasks on the current DR, and fix the wording on the backport page.
[11:32] <mpt> forbid opening tasks on already-released releases, you mean?
[11:33] <bradb> mpt: Nope, the current release. Opening tasks on already-released releases is exactly what we need for backporting.
[11:33] <mpt> wait, "fix the wording on the backport page", but we had no backport page until now
[11:34] <bradb> mpt: Yeah, we did, it was just unclear that we did. :)
[11:34] <bradb> mpt: Target Fix to Releases.
[11:34] <mpt> sorry, by "what problem we're trying to solve here" I meant "what problem we're trying to solve by recognizing backports at all"
[11:34] <bradb> It uses the word backport in the page, in fact.
[11:34] <mpt> oh
[11:35] <bradb> mpt: Ah. Being able to track the status of a bug fix in previous distro releases where we care to have a bug fixed (which is pretty rare.)
[11:35] <bradb> Except for pitti, who lives and breathes this workflow, but he won't be using Malone for a while yet, I don't think.
[11:36] <mpt> Did bugzilla.ubuntu.com recognize backported fixes at all?
[11:36] <bradb> (won't use it for his CVE stuff, i mean)
[11:36] <bradb> mpt: Nothing that I know of. At least pitti, for example, didn't use Bugzilla at all to track security fixes across releases.
[11:39] <lifeless> ddaa: what revno do you see ?
[11:39] <jbailey> bradb: I use it for tracking fixes that I'm backporting for customers.
[11:39] <ddaa> lifeless: 215
[11:40] <lifeless> ddaa: whats the revid of the tip ?
[11:40] <lifeless> I see pqm@pqm.ubuntu.com-20060217222419-fce99cb2743916db
[11:40] <bradb> jbailey: Ah, ok.
[11:42] <ddaa> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileDL620e.html
[11:43] <kiko-zzz> bradb, do you need more input from me?
[11:43] <bradb> kiko-zzz: Can I merge this?
[11:43] <kiko-zzz> if mpt is okay with it, yes.
[11:43] <bradb> mpt: Are you okay with this?
[11:43] <lifeless> ddaa: that means the only different commits are yours
[11:44] <ddaa> I'll look again tomorrow
[11:44] <lifeless> ddaa: so just put it up for review
[11:44] <lifeless> btw
[11:44] <ddaa> something must be broken here, because a merge gave me a lot of differences
[11:44] <lifeless> I get 'not a branch' on your url.
[11:45] <lifeless> https://chinstrap.ubuntu.com/~dsilvers/paste/filemjnKW1.html
[11:45] <ddaa> sftp://chinstrap.ubuntu.com/home/warthogs/archives/david/bzrtools/importd
[11:45] <lifeless> thats the tip of the log
[11:45] <ddaa> hu
[11:45] <ddaa> okay
[11:45] <lifeless> shows 1 missing revision
[11:46] <ddaa> the component between chair and keyboard was not working very well today
[11:46] <lifeless> ;)
[11:46] <lifeless> so yeah, just put it up for review please.
[11:46] <ddaa> will do
[11:46] <ddaa> need sleep, you know my new year's resolution is waking up early every day
[11:47] <ddaa> thank you for checking
[11:50] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug 28477: Merge text is confusing. Try to unconfuse the text that relates to merging (r3169: kiko)
[11:52] <mpt_> sorry, bradb, missed everything after "(won't use it for his CVE stuff, i mean)"