[12:45] <mdz> cprov: I have an upload which has built successfully, but the binaries are not in the queue or in the archive as far as I can see
[12:45] <cprov> mdz: which one ?
[12:45] <mdz> cprov: https://launchpad.net/+builds/+build/347371
[12:46] <cprov> mdz: https://launchpad.net/ubuntu/+source/haf-marketing-release/0.3.4ubuntu1
[12:47] <mdz> cprov: no binaries on that page
[12:50] <cprov> mdz: I'm checking
[12:54] <cprov> mdz: should it build 'hildon-*' binaries, is that correct on 'Resulting Binaries' portlet ?
[12:54] <mdz> cprov: correct
[12:55] <mdz> those look like the correct names
[12:56] <mdz> do they only show up on the source package page when they have been published?
[12:56] <mdz> anyway, I don't see why they aren't published
[12:57] <cprov> mdz: no, resulting binaries doesn't have to be published
[12:59] <mdz> cprov: source package page
[01:00] <cprov> mdz: yes, in source package page they have to be published
[01:00] <cprov> mdz: https://launchpad.net/ubuntu/gutsy/+queue?queue_state=2&queue_text=hildon
[01:00] <mdz> cprov: i.e., https://launchpad.net/ubuntu/gutsy/+source/hello shows (published) binaries, but https://launchpad.net/ubuntu/gutsy/+source/haf-marketing-release says "No binaries have been generated for this release."
[01:00] <mdz> cprov: aha, thank you. I looked in output from the 'queue' tool and in /srv/launchpad.net/ubuntu-queue but found nothing
[01:01] <cprov> mdz: it's in accepted queue, will be published in a bit (~ 5 min)
[01:01] <mdz> cprov: so it will be published in this next run?
[01:01] <mdz> cprov: so I must wait for that to finish, then retry the hildon-desktop build, then wait for that, approve the binaries, then wait for next publisher run
[01:03] <cprov> mdz: `LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/queue -Q accepted info hildon` shows it 
[01:04] <mdz> cprov: queue -Q accepted info | grep hildon as lp_archive@drescher shows nothing
[01:04] <mdz> cprov: ah, looks like it was just processed
[01:05] <mdz> it is pretty difficult to follow an upload all the way through the process from upload to binary publishing
[01:08] <cprov> mdz: yes, links are messy and sourcepackage page doesn't present overall information 
[01:23] <cprov> lfittl: I have disable 'auto-overrides' for PPAs (yes, they were enabled for testing). IFW, now it will respect expanded Section: syntax ('[component/] <section>')
[01:24] <lfittl> cprov: ok, thanks, will try another upload then :)
[01:24] <cprov> lfittl: you can blame *me* for passing wrong information, sorry.
[01:24] <lfittl> heh, no problem
[08:17] <BjornT> lifeless: is there no reviewer meeting today?
[08:22] <lifeless> BjornT: there is, at 1600
[08:22] <lifeless> thats 22 minutes ago, sorry!
[08:22] <lifeless> man I'm freezing here
[08:23] <lifeless> spiv: ping
[08:23] <lifeless> jamesh: ping
[08:23] <lifeless> thumper: ping
[08:23] <lifeless> awww, how sweet
[08:23] <lifeless> if a little... permanent
[08:24] <spiv> pong
[08:24] <lifeless> == Agenda ==
[08:24] <lifeless>  * Roll call
[08:24] <lifeless>  * Next meeting
[08:24] <lifeless>  * Queue status.
[08:24] <lifeless>  * Are reviews fair/balanced?
[08:25] <lifeless>  * Preimplementation call status
[08:26] <lifeless> jamesh: ping
[08:26] <lifeless> thumper: ping
[08:26] <jamesh> pong
[08:26] <lifeless> its 0600 UTC now right ?
[08:26] <spiv> lifeless: 0626, yeah.
[08:26] <lifeless> well yeah
[08:27] <jamesh> "date -u" says 06:26
[08:27] <lifeless> thumper: last call for .nz
[08:28] <lifeless> BjornT: you talked about review fairness last week in .eu right ?
[08:29] <BjornT> lifeless: yeah (or a couple of weeks ago)
[08:30] <lifeless> we haven't talked about it in .au though IIRC?
[08:30] <spiv> Not that I am aware of.
[08:30] <lifeless> ok
[08:30] <lifeless> final agenda
[08:30] <lifeless> == Agenda ==
[08:30] <lifeless>  * Roll call
[08:30] <lifeless>  * Next meeting
[08:30] <lifeless>  * Queue status.
[08:30] <lifeless>  * Are reviews fair/balanced?
[08:30] <lifeless>  * Preimplementation call status
[08:31] <lifeless>  * Meta review duration
[08:31] <lifeless> lets do this
[08:31] <lifeless> == Next meeting ==
[08:31] <lifeless> 2007-06-19 at 0600 UTC
[08:31] <lifeless> all in favour interrupt the next point
[08:31] <lifeless> all *not* in favour ...
[08:31] <spiv> That's also a Tuesday?
[08:32] <lifeless> same bat time
[08:32] <lifeless> same bat channel
[08:32] <spiv> Is the plan to switch to Tuesdays permanently?
[08:32] <lifeless> I thought thats what you had voted to do. I was surprised that you did that in the convenors absence but still :)
[08:33] <spiv> IIRC, I didn't express an opinion either way ;)
[08:33] <lifeless> heh
[08:33] <lifeless> are you fine with this time?
[08:33] <spiv> Yeah, this time is ok with me.
[08:34] <spiv> I was just asking to make sure there's no confusion.
[08:34] <lifeless> ok
[08:34] <lifeless> so pending-reviews looks like a bomb dropped on it
[08:35] <lifeless> thats at least partly my fault - I find the incremental branches hell to allocate - and partly the Queens birthday here.
[08:35] <spiv> A bomb called "first round of a time-based release cycle" :)
[08:35] <lifeless> quick count
[08:36] <lifeless> 32 branches
[08:36] <lifeless> one at 54 days? 
[08:36] <spiv> I have reviews for my two in progress, should be done tonight.
[08:37] <lifeless> reviewer workload is sneaking up
[08:37] <lifeless> statik has 5K to review - but these figures are bogus aren't they ?
[08:38] <spiv> Yeah, incremental diffs.
[08:38] <BjornT> yeah. bug-workflow-3 depends on two other branches, and the first one is really big.
[08:39] <lifeless> so we can't really tell a) how many 'units of work' are blocked on review or b) how much review work really is involved.
[08:39] <lifeless> I've asked SteveA to allocate time to jamesh to implement this.
[08:40] <BjornT> that would be nice, i've wanted that functionality for a long time.
[08:41] <lifeless> well the developer workflow appears to have changed. So I think its critical now rather than optional.
[08:41] <lifeless> SteveA: ^
[08:41] <lifeless>  * Are reviews fair/balanced?
[08:41] <lifeless> BjornT: what did the .eu meeting conclude, for anyone at this one that hasn't read the minutes.
[08:41] <spiv> Is there a record of the .eu team discussion on this?  I couldn't find the relevant minutes.
[08:41] <lifeless> (which btw are not linked on the wiki)
[08:42] <BjornT> well, it's in https://launchpad.canonical.com/ReviewerMeeting20070523, "if overwhelmed, push back to general queue"
[08:42] <lifeless> nor AFAICT on the launchpad or lp-reviews list.
[08:43] <lifeless> oh, that far back. Ok
[08:43] <lifeless> are you sure thats the same discussion?
[08:43] <BjornT> the main idea was that every reviewer should be expected to spend a more or less equal amount of time reviewing.
[08:43] <spiv> Oh, I did see that one.  I didn't realise it was the same topic.
[08:43] <lifeless> no this is not the same topic
[08:43] <lifeless> let me introduce this topic
[08:43] <BjornT> oh, then what's this about? :)
[08:44] <lifeless> Theres been a concern raised that developers that have been around longer are having their code put under substantially less scrutiny than new developers regardless of their development experience.
[08:46] <lifeless> now, this may simply be that the folk who have been around longer are passing through the same checks and balances more easily
[08:46] <lifeless> or it may be that we are not actually being as thorough.
[08:46] <lifeless> I've had a look myself and it didn't seem biased to me.
[08:47] <lifeless> but I think its important that a topic like this get talked about openly and clearly.
[08:47] <lifeless> because the review process is a key one, and one that could easily demoralise developers if they felt it was unfair.
[08:48] <lifeless> any comment, or stunned silence?
[08:49] <spiv> I agree with what you've said.
[08:49] <BjornT> it would be good if the people that are complaining would point out a few examples
[08:50] <lifeless> so r 4236 was pointed out as a case where someone felt this may have happened.
[08:50] <spiv> Reviewers can make mistakes, and developers should feel free to disagree with a comment made by a reviewer.
[08:52] <lifeless> now if you look at that review there are plenty of things jamesh said
[08:52] <lifeless> he missed one minor thing which is import alpha-sorting
[08:53] <jamesh> for r4236 (and related commits), we have been working under time pressure
[08:53] <lifeless> > +        stepthrough, Navigation, RedirectionView,
[08:53] <spiv> import alphabetising is hardly showstopper.
[08:54] <lifeless> Oh, I agree. But if a new developer is called on it, its fair for them to expect senior developers to be held to the same or even a higher standard.
[08:54] <jamesh> there were definitely some issues with the branch that could have been done better, but I made the call to get it in so we could fix them and do further work in parallel
[08:55] <lifeless> right
[08:55] <lifeless> so we don't aim for perfection on every merge; we're aiming to balance:
[08:55] <BjornT> and considering the diff for r4236 is 6314 lines, it's easy to miss a few minor things.
[08:55] <lifeless>  - branch size
[08:55] <lifeless>  - urgency of delivery
[08:55] <lifeless>  - overall importance
[08:56] <lifeless> and
[08:56] <lifeless> we have an already agreed process for merging things we've decided 'will happen' with fixups later.
[08:56] <lifeless> AIUI openid was one of those things?
[08:58] <lifeless> jamesh: ?
[08:58] <jamesh> lifeless: yeah.  We are dealing with an external contractor for some of this, so it is not workable to keep things out of tree til perfect
[08:58] <lifeless> ok
[08:59] <lifeless> then I'd like to say in reply to this concern, something like:
[08:59] <jamesh> that's probably the biggest difference between it and other similar cases
[08:59] <lifeless> We're not aware of a bias to senior/long service developers. 
[09:00] <thumper> lifeless: sorry, was having dinner
[09:00] <lifeless> The given example went in under the 'its going to happen' policy where the code is polished further after it lands, and this has in fact happened/is happening.
[09:01] <lifeless> all in favour?
[09:01] <lifeless> thumper: no prob
[09:01] <spiv> lifeless: sounds good.  But maybe it could have been clearer that that landing happened under that policy?
[09:02] <lifeless> I think thats a good point.
[09:03] <lifeless> I can't remember if we ended up documenting the process, I think the discussion about that got sidelined into 'what wiki page it should go on' when Bjorn was talking with Joey.
[09:03] <lifeless> but the policy was clear in our minutes :)
[09:04] <lifeless> BjornT: happy with that response? jamesh ?
[09:04] <jamesh> sure.
[09:04] <BjornT> yeah. although, it would be good to make it more clear.
[09:05] <lifeless> BjornT: which 'it'
[09:05] <BjornT> to make it more clear, that the branch needs to be landed quickly, and will be polished later.
[09:06] <lifeless> BjornT: I agree with that. However this branch *was* landed quickly, and *is* being polished. (jamesh <- is that right)
[09:07] <BjornT> when we discussed it a while a go, i think we talked about adding a [fasttrack]  tag to pqm, or something like that.
[09:07] <BjornT> having the policy documented somewhere would be nice :)
[09:07] <lifeless> right. So I'm separating out the reponse about bias, and the making the policy clear discussion.
[09:07] <lifeless> on the former I want consensus
[09:08] <lifeless> on the latter I know we already have it.
[09:08] <BjornT> there should also be a way of tracking the work to polish the branch.
[09:08] <lifeless> can you add that to the agenda for .eu and next week's .au? We are about to run out of time.
[09:08] <BjornT> sure
[09:09] <lifeless> thanks
[09:09] <lifeless>  * Preimplementation call status
[09:09] <lifeless> Barry brought this up
[09:09] <lifeless> are you doing pre-imp calls? Are you nagging when you get a branch that didn't have one? Are they useful? Are pre-imp-called branches better?
[09:10] <thumper> I think it is handy to have so the reviewer knows that it has been talked about
[09:10] <thumper> I haven't really been nagging, but then most have some entry now
[09:10] <lifeless> mmm, thats really just an appeal to authority though.
[09:11] <BjornT> i didn't have any last week (except for a few in-person ones with gavin), since i was on a sprint.
[09:11] <spiv> I've had some calls with jml, and I think they've been useful.
[09:11] <lifeless> ok
[09:11] <lifeless>  * Meta review duration
[09:11] <lifeless> This was in the minutes 
[09:11] <lifeless> and I'm back
[09:11] <lifeless> so - 
[09:12] <lifeless> I think the meta-review should stop when the meta-reviewer is satisfied that the reviewer knows the ropes
[09:12] <thumper> sounds fair
[09:12] <lifeless> just like a branch is let through when the reviewer is happy with the branch
[09:13] <spiv> Sounds reasonable.  As a data point, I'm happy with thumper's reviewing, so I'd expect the other new reviewers are probably doing equally well.
[09:13] <lifeless> right
[09:13] <lifeless> ok.
[09:13] <lifeless> any other business?
[09:13] <thumper> just to clarify
[09:14] <thumper> am I still sending reviews pending spiv's approval?
[09:14] <lifeless> ask spiv :)
[09:14] <thumper> spiv: ?
[09:14] <spiv> thumper: as of right now, you're on your own ;)
[09:14] <thumper> w00t
[09:14] <spiv> thumper: I'll review the reviews you've already sent me.
[09:14] <thumper> ok
[09:15] <lifeless> ok
[09:16] <lifeless> welcome to the non-provisional status thumper !
[09:16] <lifeless> 5
[09:16] <lifeless> 4
[09:16] <thumper> thanks
[09:16] <lifeless> 3
[09:16] <lifeless> 2
[09:16] <lifeless> 1
[09:16] <lifeless> 0
[09:16] <lifeless> meeting over
[09:16] <spiv> lifeless: thanks
[09:29] <mpt> Thwarted by my past self!
[10:17] <SteveA> lifeless: hello
[10:18] <lifeless> hi
[10:19] <lifeless> SteveA: hi
[10:34] <SteveA> lifeless: in my "away" scrollback, I had some ^^^^ from you.
[10:35] <lifeless> right
[10:35] <lifeless> I was giving you hopefully more context than I put in the email you should have gotten overnight
[10:37] <SteveA> so, it's worth the effort for me to look through the scrollback?
[10:39] <lifeless> let me recap
[10:39] <lifeless> reviews are very hard to allocate at the moment because of the use of incremental branches
[10:39] <SteveA> lifeless: joey and thumper had a suggestion about having more than one person allocate reviews, concurrently, to take some load from you
[10:40] <lifeless> all the statistics that had made it relatively straight forward are broken, and the number of branches is high
[10:40] <SteveA> because we're comparing the work to mainline?
[10:40] <lifeless> I'm more than happy to have multiple people allocating, that won't solve the root problem though
[10:40] <lifeless> which is that you cannot use the numbers as guidance now
[10:40] <lifeless> yes because of that
[10:41] <lifeless> So I think its very important to either stop doing incremental branches (which has its own costs) or fix the current tool (which requires developer effort)
[10:41] <lifeless> I don't have the time to fix it myself right now unfortunately.
[10:41] <SteveA> can you sketch out what the fix would look like?
[10:42] <lifeless> theres a header in the wiki page saying what branch the diff should be like. the cronscript would be changed to diff against that when its present.
[10:42] <lifeless> should be very straightforward for someone familiar with the code (and there are two such people that I know of - me and jamesh)
[10:43] <SteveA> ok.  and we need to make sure that forthcoming launchpad features in this area
[10:43] <SteveA> can cope with the same kind of branch
[10:43] <lifeless> thats the core of it; theres more that could be done, but thats the key item.
[10:43] <lifeless> I'm aware we dont want to invest heavily in the non-launchpad solution
[10:43] <lifeless> and yes the lp integrated reviews will need to handle this situation.
[10:45] <SteveA> ok, thanks
[10:45] <SteveA> who can we ask to be a second allocator of reviews?
[10:45] <lifeless> I suggest bjornt or salgado
[10:45] <lifeless> because they are familar and in a different timezone
[10:45] <lifeless> and different country
[10:45] <SteveA> once we have the single sign on stuff done, I'd like to ask jamesh to improve the review cron script
[10:45] <lifeless> so they won't typically hit the same holidays
[10:45] <SteveA> sure, let's ask salgado
[10:46] <SteveA> would you mail him?
[10:46] <SteveA> as the coordinator of reviews etc.
[10:46] <lifeless> and if they do it in their morning we get 12-hour latency rather than 23:55 as at the moment, so its more than just a load sharing win.
[10:46] <lifeless> naturally.
[10:46] <SteveA> thanks
[10:49] <lifeless> the SSO stuff, is that days/weeks/months away? The key tweak is probably under a days work for jamesh.
[10:50] <lifeless> SteveA: ^
[10:51] <SteveA> days/weeks
[10:52] <lifeless> ok
[10:52] <lifeless> if it looks like stretching out, please consider giving him a morning to see what he can do.
[10:52] <SteveA> is there a bug on this?
[10:53] <lifeless> I believe so
[10:53] <SteveA> the question is, to what release do we target the bug
[10:53] <lifeless> but with the deprecation of lp-development-infrastructure I'm not sure where to find it
[10:54] <SteveA> if jamesh has finished his single sign on work, then 1.1.6 is possible
[10:54] <SteveA> otherwise, we can shoot for 1.1.7
[10:54] <lifeless> for single sign on?
[11:10] <carlos__> morning
[11:46] <Hobbsee> morning carlos 
[02:13] <cprov> good morning
[02:13] <Hobbsee> morning cprov!
[02:13] <cprov> Hobbsee: hi there (note that I'm not mentioning any names today)
[02:15] <Hobbsee> hehe
[02:29] <j^> how can i delete a branch?
[02:29] <j^> i wanted to add another svn mirror and it ended up trying to mirror a bzr branch
[02:30] <j^> now i can not delete it
[02:32] <mwhudson> j^: you can't delete a branch
[02:32] <mwhudson> j^: you can mark it obsolete though
[02:33] <mwhudson> j^: can you give some details?
[02:33] <j^> what i wanted to do was to register another django svn branch to merge them using bzr
[02:34] <j^> ended up to create a bzr branch https://code.launchpad.net/~j/django/multiple-db-support
[02:34] <j^> which is wrong
[02:34] <j^> why does launchpad add a bzr branch if it can not import it from the url provided?
[02:34] <j^> would want to delete that now
[02:34] <cate> I've some problem on log in.  I've no error, but I'm alway "not logged". Some hits?
[02:35] <oojah> cate: Are you sure that you have allowed cookies for launchpad?
[02:39] <cate> oojah: thanks. It seems I clicked the wrong cookies' button.  BTW firefox should have a search function
[02:40] <oojah> cate: Search for what?
[02:41] <cate> for the coockies in the allow and block windows (as in the stored cookies list)
[02:41] <oojah> Ah, ok.
[02:42] <oojah> Yeah, that would make things easier.
[02:42] <cate> yes, because they are not ordered by second level domain
[03:00] <mwhudson> oops, i shouldn't ask for more info then have lunch
[03:01] <cate> is it possible to close o change status of a bug?
[03:02] <j^> is it possible to add another vcs-import to a project? or is vcs-import no longer provided? fail to find a way to add branches other than bzr
[03:02] <mwhudson> j^: you can only have one vcs-import per project
[03:03] <mwhudson> because of the way the importer works, if you imported from both svn.example.org/trunk and svn.example.org/branches/foo you'd get two (as far as bzr could tell) unrelated branches
[03:04] <j^> ah ok, in that case i can not use launchpad for what i thought i could
[03:04] <mwhudson> what are you trying to do?
[03:05] <j^> i wanted to merge two svn branches i do not have write access to
[03:07] <mwhudson> ah hm
[03:07] <mwhudson> you could try bzr-svn for that
[03:08] <j^> requires svn 1.5-trunk
[03:16] <mwhudson> or a patched svn
[03:16] <mwhudson> yes, the installation is a pain
[03:16] <mwhudson> the svn in feisty is good enough :)
[03:17] <Theuni> howdi
[03:18] <mrevell> Theuni: hi
[03:18] <Theuni> I'm wondering how to deal with upgrading a bzr branch that is hosted on launchpad so it becomes usable for tags
[03:18] <Theuni> Should I just delete that branch and push it again? 
[03:18] <Theuni> When I try upgrading it gives me this error:
[03:18] <Theuni> bzr: ERROR: Permission denied: u'/~alphaflowforms/alphaflowforms/trunk_ctheune/.bzr.backup': [Errno 13]  Can only create .bzr directories in branch directories: .bzr.backup
[03:18] <mrevell> mwhudson: Is that something you can help Theuni with?
[03:26] <mwhudson> Theuni: log in with lftp or something, delete the .bzr directory and push again (with --use-existing-dir)
[03:26] <mwhudson> there's a bug somewhere about this
[03:27] <mwhudson> https://bugs.launchpad.net/launchpad-bazaar/+bug/118653
[03:27] <ubotu> Launchpad bug 118653 in launchpad-bazaar "Need --no-backup flag or similar to upgrade remote repos on launchpad" [High,Confirmed]   - Assigned to Jonathan Lange (jml)
[03:36] <beuno> where can someone suscribe to a package to recieve email notifications on pathces and bugs  (think, debian maintainer)
[03:42] <Fujitsu> beuno: Heh, that'd be too good to be true. You can get notification on bugs by heading to the bugs page for the source package and finding the right Actions link, but that's all.
[03:48] <beuno> sorry, got disconnected
[03:48] <beuno> where can someone suscribe to a package to recieve email notifications on pathces and bugs  (think, debian maintainer)
[03:50] <Hobbsee> subscribe to ubuntu-bugs mailing list?
[03:50] <Hobbsee> not sure apart from that
[03:50] <beuno> Hobbsee: but he just wants to be notified for a specific package (his packages)
[03:50] <beuno> I thought you could dothat in Launchpad
[03:51] <Hobbsee> you can subscribe to all bugs and such on a package (bugmail settings from the bugs page) but not patches as well, iirc.
[04:26] <ubotu> New bug: #120037 in launchpad "Action reported in email as done by owner rather than administrator" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120037
[04:51] <shirish> guys can somebody help me, I filed a bug in launchpad & also got acknowledgement for upstream debian bug no. how do I enter it in launchpad?
[04:55] <shirish> BjornT: do you have any idea how to do that?
[04:56] <jamesh> shirish: you want to link the Launchpad bug to the debian bug?
[04:58] <shirish> jamesh: right
[04:58] <jamesh> shirish: on the bug page, there is some text like "Also affects:  +   Upstream    +   Distribution"
[04:59] <jamesh> if you click on the "Distribution..." link, you can pick Debian from the distribution list and enter the URL of the Debian bug report
[04:59] <jamesh> submit that form and you're done
[05:00] <shirish> jamesh: how do I find the url, I got the bug no.  I used submit@bugs.debian.org to submit the bug, got an acknowledgement there with the bug no. 
[05:01] <kiko> he ll o
[05:01] <jamesh> shirish: go to http://bugs.debian.org/NNNN (where NNNN is the bug number)
[05:01] <jamesh> shirish: it will redirect you to the bug's URL
[05:01] <shirish> ah ok that's cool
[05:02] <shirish> yippee, task completed
[05:03] <shirish> I gotta write that whole thing down somewhere
[05:03] <shirish> I mean the whole process.
[05:04] <jamesh> shirish: the Debian task on the bug should now get updated as the remote Debian bug's status changes
[05:09] <shirish> jamesh: thanx
[06:05] <ubotu> New bug: #120052 in soyuz "Component mapping for new source packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120052
[06:07] <Hobbsee> any LP admisn around?
[06:12] <Hobbsee> matsubara: doesnt seem alive, either
[06:12] <matsubara> hello Hobbsee 
[06:12] <matsubara> Hobbsee: how can I help you?
[06:12] <Hobbsee> matsubara: ooh, you are here.  https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/119467
[06:13] <ubotu> Launchpad bug 119467 in kubuntu-meta "make non-essential packages Recommends and not Depends" [Undecided,Unconfirmed]  
[06:13] <Hobbsee> matsubara: last comment.
[06:14] <Hobbsee> matsubara: seeing that, fairly easy as to how to help :)
[06:15] <matsubara> Hobbsee: thanks for bringing that up. I've requested deletion.
[06:16] <cate> with a nice username ;-) https://bugs.launchpad.net/~hahahahaha/ 
[06:16] <Hobbsee> matsubara: thanks
[06:16] <Hobbsee> indeed.  pity it came up in my inbox, as i'm subscribed to teh bug
[06:16] <Hobbsee> it's pretty impressive - the LP message ended up coming up as possible spam
[06:20] <ubotu> New bug: #120053 in rosetta "upstream translation of digikam not imported (once again)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120053
[08:07] <Thangalin> Hello.
[08:07] <Thangalin> Anyone know who runs this site: https://answers.launchpad.net/azureus ?
[08:08] <Thangalin> Is anyone here alive?
[08:08] <kiko-fud> NO
[08:09] <Thangalin> So, kiko ... Do you know who is in charge of the answers.launchpad.net/azureus site? :-)
[08:09] <kiko> that's a question with two answers
[08:09] <Thangalin> I don't mind people raising from the dead to answer questions.
[08:09] <kiko> answers.launchpad.net
[08:09] <kiko> is run by us, of course
[08:09] <kiko> I'm not sure what azureus is.
[08:09] <Thangalin> Azureus is a bittorrent client.
[08:10] <Hobbsee> yay, kiko!
[08:10] <Thangalin> So how do I find out who can change something at the azureus part of the website?
[08:10] <kiko> Thangalin, okay so far. so why do you want to know? :)
[08:11] <Thangalin> Two reasons.
[08:11] <Thangalin> 1. There is a spelling boo-boo.
[08:11] <Thangalin> 2. I'd like to get an e-mail address removed from the website.
[08:12] <Thangalin> Any ideas on how to go about this?
[08:12] <kiko> I see
[08:12] <kiko> what e-mail address?
[08:12] <kiko> and why's the spello?
[08:12] <Thangalin> https://bugs.launchpad.net/azureus/+bug/83594
[08:12] <ubotu> Launchpad bug 83594 in azureus "[feisty] azureus wont open after update of java" [Undecided,Unconfirmed]  
[08:13] <Thangalin> That's the one, ubotu.
[08:13] <Thangalin> And this page: https://answers.launchpad.net/azureus/
[08:13] <Thangalin> "Azreus BitTorrent Client"
[08:13] <Thangalin> Should really be "Azureus BitTorrent Client"
[08:14] <Thangalin> For some reason when BUGabundo quoted me, it included my e-mail address.
[08:16] <Thangalin> That was some serious quick finding, ubotu. :-)
[08:16] <mwhudson> huh, whoever registered the azureus project typoed the name
[08:16] <Thangalin> Well that was silly of them.
[08:16] <mwhudson> it was
[08:16] <Thangalin> No way to change it, eh?
[08:16] <mwhudson> not for me
[08:17] <mwhudson> you need an admin
[08:17] <mwhudson> like kiko, for example
[08:17] <Thangalin> I really don't care about the typo; but I'd really like the e-mail address removed. :-)
[08:19] <Thangalin> Is that going to be an issue?
[08:22] <Thangalin> Allo? Is this thing still on? ;-)
[08:24] <kiko> I'll fix it. I'm very busy right now.
[08:24] <Thangalin> Thanks, Kiko. I appreciate it.
[08:24] <Thangalin> Take it easy, eh? :-)
[08:24] <kiko> typo fixed.
[08:25] <kiko> as for your email address
[08:25] <kiko> I can't help you directly
[08:25] <Thangalin> Yes?
[08:25] <Thangalin> Oh.
[08:25] <Thangalin> Anyone in particular I should pester/
[08:25] <kiko> and I honestly think it's a wasted effort to even try to protect it
[08:25] <kiko> if you don't want your email address cited on the internet, you can't use it publically
[08:25] <kiko> but ANYWAY
[08:25] <kiko> I will talk to an admin to see what we can do about it.
[08:26] <Thangalin> Gracias. And I agree with you completely. I have a secondary e-mail address I use for public stuff -- I forgot to use it when signing up at Launchpad.
[10:33] <superm1_> Hi guys, How do you add a task for a bug?  Say it affects several ubuntu packages, and I want to notate that as 2 tasks to fix on the bug?
[11:02] <crimsun> superm1_: Also affects distribution
[11:02] <gnomefreak> superm1_: click on distribution
[11:33] <superm1_> thanks crimsun & gnomefreak.  got that bug cleaned up now