[01:15] <pdenapo>  I have a question: how may I change the e-mail address asociated to a Launchpad account? I see that I can add another but not replace the existing one
[01:15] <Fujitsu> pdenapo: Once you add another, you should be able to remove the old one.
[01:16] <pdenapo> doesn't seem to be the case...
[01:16] <pdenapo> there is no option for removing the old one...
[01:16] <Fujitsu> You might have to set the new one as primary first.
[01:19] <pdenapo> Now, I've succeeded. Thanks
[01:19] <pdenapo> it seems that it was a matter of first replying an e-mail confirmation
[01:32] <lamont> cprov-out: squawk if you happen to be around, eh?
[01:47] <Fujitsu> Yay, I like the new ordering of the buildd listing, though it seems the archs are ordered by some internal ID.
[01:51] <lamont> Fujitsu: yeah.. I was wondering what the sort key was.
[01:51] <lamont> since one would think that amd64 should land above ppc... or some scuh
[01:52]  * lamont debates whether to hug Hobbsee, or aim the water cannon
[01:53] <Hobbsee> lamont: what have i done?
[01:53] <Hobbsee> lamont: you could just be nice and kill me.
[01:53] <Hobbsee> so make sure it's got something else apart from water
[01:53] <Fujitsu> lamont: I presume it's their serial primary key, what with hppa then lpia being last.
[01:55] <lamont> Hobbsee: who says I need a reason to drench you?
[01:55]  * Fujitsu throws waterbombs at lamont.
[01:55] <Hobbsee> lamont: ah right
[01:56]  * Fujitsu is glad to see that the assigning stuff should be fixed by next edge rollout.
[01:58]  * Fujitsu doesn't like kiko's latest email to launchpad-users... LP shouldn't be filing bugs upstream itself. That will infuriate them. Particularly Debian.
[02:00] <Hobbsee> Fujitsu: if they were actually to do it sanely....
[02:00] <Hobbsee> Fujitsu: having said that, i'm thinking of the current mess with assignees and such.
[02:01] <Fujitsu> We'll see how they've fixed that tomorrow.
[02:14] <lamont> Fujitsu: it depends on the package, actually.
[02:14] <lamont> for example, I would have no issue with LP filing bugs against my debian packages
[02:14] <Fujitsu> lamont: Of course.
[02:14] <lamont> with luck, hppa should be making better time now
[02:15] <Fujitsu> What has changed?
[02:15] <lamont> 50% increase in the number of buildds building hardy
[02:15] <Hobbsee> nice!
[02:15] <Fujitsu> You got more hardware, or somehow got the security buildd to do it too?
[02:15]  * Fujitsu checks.
[02:15] <lamont> I, uh, talked the security buildd into sharing
[02:16] <lamont> and I owe elmo a patch.
[02:16] <Fujitsu> Yay, castilla is back.
[02:16] <Fujitsu> I suppose it doesn't get too much load.
[02:16] <Fujitsu> With only two supported releases.
[02:16] <lamont> castilla has always been the security buildd, never been launchpad buildd until just a few min ago
[02:16] <Fujitsu> ANd no livefses.
[02:17] <lamont> yeah - I need to fix livefs on both ia64 and hppa
[02:17] <lamont> ia64 has livefs, but the boot block believes that all 3 cds are alternate.
[02:17] <lamont> makes desktop/server kinda boring
[02:17] <lamont> and hppa needs some real love (options file, anyone? > 120 characters of commandline?) before it'll do non-alternate
[02:19] <Fujitsu> I'm not sure there'd be much of a market for live hppa, really.
[02:19] <lamont> building:   13:23:40     7.97%
[02:19] <lamont> install :   00:00:00     0.00%
[02:19] <lamont> removing:   00:00:00     0.00%
[02:19] <lamont> idle    :  148:21:10    88.30%
[02:19] <lamont> total   :  168:00:02
[02:19] <lamont> so, yeah.  mostly kinda idle.
[02:19] <lamont> wow.  2 leap seconds last week. :-)
[02:19] <lamont> a base-livecd has some real potential.  desktop live, not so much
[02:20] <lamont> that is, at some point, we start making server-live for all architectures, right?
[02:20]  * Fujitsu didn't know of any leap seconds last week, let alone a double one.
[02:20] <Fujitsu> server-live sounds a while off.
[02:20] <lamont> cronjob ran 2 seconds later this week than last... :-)
[02:20] <Fujitsu> Ah.
[02:20] <lamont> so there were 168:00:02 hours in the week... must be leap seconds... FTW!!! :)
[02:21] <Fujitsu> Ohh, I see. Yes.
[02:21] <Fujitsu> What was it doing the other 5%?
[02:23] <lamont> being lots.
[02:23] <lamont> lost, even
[02:23] <lamont> hrm.. it's been up 42 days, so it wasn't crashed.
[02:31] <Fujitsu> Are those stats from buildd?
[02:31] <lamont> DAK buildd, yes
[02:32] <Fujitsu> That's what I thought.
[02:35] <Fujitsu> lamont: How much longer do you expect hppa to take to catch up?
[02:36] <lamont> that depends entirely on how frequently kde, gcc*, python, and glibc get uploaded.
[02:36] <lamont> kde builds are _SLOW_
[02:36] <Hobbsee> i'm sure we can help that along a bit
[02:36] <lamont> something to do with having huge monolithic packages
[02:36]  * Hobbsee uploads more of it, then
[02:37] <Hobbsee> lamont: yeah, just the ones we *odnt* want to be uploaded repeatedly
[02:37] <Fujitsu> I was horrified to see that they merged dolphin into kdebase recently. I *really* don't see the benefit.
[02:37] <lamont> Fujitsu: because then it all builds together.
[02:38] <Hobbsee> apparnetly 4 isn't as bad as 3
[02:38] <lamont> they merged it in for the same reason that they merged everything else in
[02:38] <Fujitsu> lamont: And takes hours and hours and hours and all has to rebuilt every time there is a tiny bug in kdepim.
[02:38] <Fujitsu> Or whatever else there are regularly tiny bugs in.
[02:38] <lamont> Fujitsu: sadly, such arguments have historically fallen on deaf ears.
[02:39]  * Hobbsee had taht argument with them too
[02:39] <Hobbsee> Fujitsu: it's -base, mainly.
[02:39] <Fujitsu> Hobbsee: Are you still on the right side?
[02:39] <Hobbsee> depending on what you define the right side, yes
[02:40] <Hobbsee> the stuff doesn't get test built, as it's so big, and doesn't get tested, so it needs multiple uploads
[02:40] <Fujitsu> It has more than 35 binaries, damnit.
[02:40] <lamont> I'm not _saying_ that was a factor in ubuntu choosing to go with gnome...
[02:40] <Fujitsu> Haha.
[02:40] <Hobbsee> this was one of my reasons for stepping down from it
[02:40] <Hobbsee> lamont: sure sure
[02:41] <Fujitsu> Oops.
[02:41]  * Fujitsu notes that one should check which audio output one has selected when using PulseAudio.
[02:46] <Hobbsee> mmm...spaghetti makes good breakfast
[02:47] <lifeless> mmm
[02:47] <Fujitsu> Breakfast at 2pm? Sounds rather odd.
[02:47] <Fujitsu> (as does the spaghettiness)
[02:48] <Hobbsee> lunch at 4.30 or so, dinner at 11.
[02:48] <Hobbsee> now that sounds odd :)
[02:48] <Fujitsu> It does.
[02:51] <lamont> if breakfast is at 2PM, then lunch is 8PM.
[02:51] <lamont> and dinner is after work, so after 11:30. :-)
[02:51] <lamont> and welcome to swing shift
[02:51] <ajmitch> hello Hobbsee 
[02:51] <Fujitsu> Evening, ajmitch.
[02:52] <ajmitch> evening? it's getting close, but not quite
[02:52] <Hobbsee> hi ajmitch 
[02:52]  * ajmitch is still at work, having fun with zope & plone
[02:52] <Fujitsu> Zope 2, then?
[02:52] <Hobbsee> lamont: lunch would be later, except htat i can't take a risk of being off the floor for that long, that late.
[02:52] <ajmitch> of course, with some zope 3 stuff mixed in
[02:52] <lamont> oh, right.
[02:53] <lamont> retail makes for strange schedules
[02:53] <Fujitsu> ajmitch: Fun, fun.
[02:53]  * Fujitsu likes his position, with no customer interaction.
[02:53] <ajmitch> lucky you
[02:53] <Hobbsee> although, if they've given me someoen with a clue tonight, i might be able to have a later dinner
[02:53] <Fujitsu> Although there is a bit too much PHP interaction.
[02:53]  * ajmitch is in a small enough company that customer interaction is required
[03:21] <lamont> there is a part of me that would really love to be able to specify regexps that affected default build-priority for packages.
[03:21] <lamont> then I could just demote all of kde for the moment. :)
[03:21] <lamont> just on hppa, of coures.
[03:21]  * Hobbsee could just demote lamont
[03:22] <Fujitsu> lamont: You should be able to mark them as failed and eventually give them back soon, no?
[03:22] <lamont> I can mark them as failed?
[03:22] <lamont> how:?
[03:22] <Fujitsu> `soon'
[03:22] <lamont> oh, ok
[03:22] <Fujitsu> Because dropping the priority only works for so long.
[03:22] <lamont> and I want one that I can feed a regexp to... :-)
[03:23] <lamont> nah - I don't mind them building once universe is done... :)
[03:23] <Fujitsu> Convince one of the DBAs that you need access to the DB. That shouldn't be hard... much... no, of course not.
[03:24] <Hobbsee> he was a canonical employee.  he should be able to get it
[03:24] <lamont> no.
[03:24] <lamont> he doesn't _WANT_ it.
[03:25]  * Fujitsu turns lamont into a duck.
[03:25] <lamont> heh
[03:26]  * Hobbsee turns Fujitsu into a pigeon
[03:26]  * Fujitsu doesn't know of an pidgeon-emblemed teams.
[03:27] <Fujitsu> Er, pigeon
[03:27] <Hobbsee> then you don't get a team
[03:27]  * Fujitsu recalls the days when launchpad-beta-testers was the upside-down duck.
[03:32] <lamont> Hobbsee: I just want to let universe catch up.... I promise to build kde before they upload it more than 5 or 6 times
[03:32] <Hobbsee> lamont: *g*
[03:33] <Hobbsee> lamont: fair enoough.  i doubt anyone on hppa actually uses kde anyway
[03:33]  * lamont figures a couple weeks tops, if kde/toolchain/python/glibc don't upload too often
[03:50] <ubotu> New bug: #173812 in malone "Remerge the enable bug expiration per project branch changes" [High,Fix committed] https://launchpad.net/bugs/173812
[05:23] <lamont> dear launchpad.  it'd be nice if the dep-wait release code knew about ogre-model.
[05:23] <lamont> (see hardy curl for an example.  and tuxtype and...
[05:23] <lamont> )
[05:24] <lamont> on the bright side, it tells us when queue-builder finishes... :-)
[05:25] <lamont> and gnome-games
[06:06] <jamesh> thumper, jml, spiv, BjornT: reviewer meeting
[06:06]  * jml is here
[06:06] <BjornT> hi
[06:06] <jamesh> == Agenda ==
[06:06] <jamesh>  * Roll call
[06:06] <jamesh>  * Next meeting
[06:06] <jamesh>  * Action items
[06:06] <jamesh>  * Queue status
[06:07] <jamesh>  * Graduations (and recruiting?)
[06:07] <jamesh>  * Mentoring update
[06:07] <jamesh>  * Review process changes
[06:07] <jamesh>    * On-call reviewer
[06:07] <jamesh>    * Cover letter
[06:07] <jamesh>    * Death to [trivial]
[06:07] <jamesh>    * Tool update
[06:07] <jamesh> Is the same time next week okay for everyone?
[06:08] <spiv> Sure.
[06:08] <thumper> yeah
[06:08] <BjornT> yes
[06:08] <jamesh> did we have any action items from last week?
[06:08] <jml> No.
[06:08] <jamesh> * Queue status
[06:09] <jamesh> the queue is pretty short, with only two branches past the due date
[06:09] <jamesh> BjornT: how is your one going?
[06:09] <BjornT> been quite busy, sorry, but i'll get it done today.
[06:10] <jamesh> If you are too busy, you can reject it
[06:11] <BjornT> yeah, i know
[06:11] <jamesh> three of the remaining branches are stub's
[06:11] <jamesh> I'm not sure what sort of response time we're expecting on those
[06:12] <jamesh> I don't think we have any mentored reviewers at this meeting, so I'll skip that
[06:12] <jamesh> * Review process changes * On-call reviewer
[06:13] <jml> I've signed up to be on call on Fridays.
[06:13] <jamesh> I haven't signed up for on call review yet
[06:13] <jamesh> and I guess BjornT and thumper shouldn't
[06:13] <jml> It went well, and it seems the system is helping.
[06:13] <thumper> it's been suggested that team leads don't
[06:13] <thumper> so I removed myself
[06:13] <thumper> however
[06:13] <spiv> Neither have I, but then I'm another special case...
[06:14] <thumper> I've found it helpful to me
[06:14] <jamesh> for the asia-pacific timeslot, we don't have many reviewers
[06:14] <thumper> mwhudson will be moving into this slot
[06:14] <thumper> in jan
[06:15] <jml> jamesh: but we have a high percentage of reviewers :)
[06:15] <jamesh> I wonder if it'd be worth removing the "don't work on any of your own code" bit and roster people on more frequently?
[06:15] <jml> jamesh: tbh, I think it would diminish the value of being on call
[06:16] <thumper> jml: I think it is reasonable to work on your own code as long as reviews take priority
[06:16] <thumper> if you are on call
[06:16] <thumper> especially for Monday morning (a slot now available)
[06:16] <jml> thumper: I guess what I mean is, the sort of work I'll be doing while on call would be pretty light.
[06:16] <jml> otherwise too many interruptions.
[06:16] <thumper> jml: right
[06:16] <spiv> The trick is making sure you don't get lost in your own code for 40 minutes while a dev is waiting for you to respond to a review request.
[06:16] <thumper> simple bug fix et al
[06:17] <jml> thumper: I guess I could take on Monday morning -- it's a quiet time anyway.
[06:17] <thumper> jml: don't you have a slot?
[06:17] <jamesh> jml: well, the value of an on-call reviewer is pretty low if there is no on-call reviewer
[06:17] <jml> I do.
[06:17] <jml> jamesh: good point.
[06:18] <jamesh> and rostering one person on multiple days will reduce their effectiveness as a developer if they can't work on their own stuff
[06:18] <thumper> jamesh: right
[06:18] <thumper> there are 15 slots
[06:18] <thumper> how many available reviewers are there?
[06:18] <jml> jamesh: It will reduce their effectiveness full stop.
[06:18] <thumper> I count 10
[06:19] <thumper> so I'd suggest we try to get 5 more
[06:20] <jamesh> thumper: one point is that we've got a fairly high reviewer:developer ratio for this time zone
[06:20] <jamesh> so the fact that we can't fill all the slots indicates that an on-call reviewer probably won't be doing a full day's reviewing
[06:20] <jamesh> (in the expected case)
[06:21] <thumper> for the asia-pac slots we only really have 3 people and 5 slots
[06:21] <thumper> (3 when mwhudson gets here)
[06:21] <jamesh> and how many people would they be doing reviews for usually?
[06:21] <jml> jamesh: Last Friday I did 5 reviews for 3 or 4 people. None of them asiapac
[06:22] <thumper> jml: I take it you got the americans at the end of their day
[06:22] <jamesh> my guess is that there will be less interruptions for review than in other slots
[06:22] <jml> thumper: pretty much
[06:23] <thumper> I suggest we force some europeans to shift to NZ/Aus
[06:24] <thumper> It's nicer here anyway
[06:24] <jamesh> should we move on?
[06:24] <jml> jamesh: yes
[06:24] <thumper> please
[06:24] <jamesh> * Cover letter
[06:24] <jml> thumper: relocate everyone to a pacific island :)
[06:24] <jamesh> I think these have been quite useful
[06:24] <jml> jamesh: definitely.
[06:24] <jamesh> better than the 1-line descriptions we had previously
[06:24] <jml> even if it's just 2 paragraphs on the wiki page rather than one.
[06:25] <thumper> +1
[06:25] <jamesh> * Death to [trivial]
[06:25] <thumper> +n
[06:25] <thumper> (where n > 1)
[06:25] <jamesh> So SteveA wants [trivial] turned off
[06:26]  * thumper agrees
[06:26] <jamesh> this pretty much requires attentive reviewers for small branches
[06:26]  * jml too
[06:26] <jml> jamesh: right. on call should balance it out.
[06:26] <thumper> for trivial changes it should be easy for a reviewer to OK it
[06:26] <jamesh> yes
[06:26] <thumper> jamesh: I'd suggest the normal - who can look at a trivial change
[06:26] <thumper> even if I'm not on call, I'm happy to look at those
[06:27] <jamesh> yep.
[06:27] <jamesh> if it is quick and easy to get a second set of eyes to look at small changes, then there is less excuse not to
[06:28] <thumper> right
[06:28] <jamesh> * Tool update
[06:28] <jamesh> Is anyone here actively involved in this?
[06:28] <jamesh> or is it more of an AMEU item?
[06:29] <jml> only indirectly.
[06:29] <jml> move on :)
[06:29] <jamesh> * Other business
[06:29] <thumper> pressups?
[06:29] <thumper> :)
[06:30] <jml> thumper: slow but steady progress
[06:30] <jml> jamesh: none from me.
[06:30] <jamesh> okay.  Meeting ends
[06:30] <jml> jamesh: thanks!
[06:30] <jamesh> thanks everyone.
[08:18] <Fujitsu> Yay, bugwatch flood.
[08:24] <ddaa> oh, the patch to make bug expiration optional per project landed yesterday
[08:24] <ddaa> (will probably only really matter on the next release though)
[08:45] <distatica> For my SSH keys, I'm asked to insert the contents of a id_dsa.pub or id_rsa.pub which is obviously from the example on a linux system. However I am on windows, do I need to install cygwin for this or do I have another option?
[08:46] <soren> distatica: Which ssh client are you using?
[08:47] <distatica> I haven't installed one yet, I've used putty usually on windows, but I wasn't sure if I would need to install cygwin so I haven't bothered to download it.
[08:47] <Amaranth> Is there some way to close a project?
[08:48] <Amaranth> https://edge.launchpad.net/compizsettings/ is dead, I want to get rid of it
[08:48] <Amaranth> or at least make launchpad stop trying to file compiz bugs against it
[08:48] <jamesh> Amaranth: https://answers.launchpad.net/launchpad
[08:49] <soren> distatica: That really depends on what you want to do with your ssh key. putty supports key authentication.
[08:49] <Amaranth> ah, goody, maybe now launchpad still stop messing up when i try to upstream bugs
[08:49] <jamesh> distatica: does this help? http://bazaar-vcs.org/Bzr_and_SSH
[08:50] <distatica> jamesh: reading now, bzr is the reason I need it..
[08:50] <jamesh> I guessed :)
[08:50] <jamesh> the SSH keys in Launchpad aren't used for anything else at present
[08:50] <distatica> oh, hehe
[08:51] <distatica> yes, this will work fine, I'll follow the windows instructions and check back if I encounter problems, thank you.
[08:51] <Amaranth> alrighty then, question aksed: https://answers.edge.launchpad.net/launchpad/+question/19312
[08:52] <jamesh> Amaranth: in the mean time, you can disable filing of new bugs by saying that the project does not use Launchpad for bug tracking ...
[08:53] <Amaranth> awesome, now when i try to upstream compiz bugs it still says it's for the compiz-settings project but lets me put in a url
[08:54] <jamesh> Amaranth: ah.  The problem seems to be the invalid packaging links
[08:55] <jamesh> Amaranth: "compizsettings" says it is packaged as "compiz" in Ubuntu
[08:55] <jamesh> I take it that this is not the case
[08:57] <Amaranth> jamesh: nope
[08:57] <jamesh> no?
[08:58] <Amaranth> Who is allowed to do that?
[08:58] <jamesh> Amaranth: I don't think it is easy to do that through the UI at present
[08:58] <Amaranth> You can link things but you can't unlink them
[08:58] <Amaranth> But who is allowed to link them?
[08:59] <jamesh> Amaranth: perhaps update the ticket to ask for the packaging links to be removed rather than deactivating the project
[08:59] <Amaranth> And why is a random project allowed to break package->upstream connections for ubuntu?
[08:59] <Amaranth> No, the project is dead anyway
[09:00] <Amaranth> So if I create a project, set it to use launchpad for bugs, and say it's packaged as gnome-screensaver in ubuntu then ubuntu people won't be able to link to gnome bugzilla bugs anymore?
[09:00] <Fujitsu> Amaranth: No, you can say the bug belongs to another project.
[09:01] <Amaranth> I see no way to do that in the UI
[09:01] <Amaranth> Otherwise I wouldn't be here
[09:01] <Fujitsu> Amaranth: When you say that it affects a project in the first place, there is an option to say that it's not the one linked to the package.
[09:01] <Amaranth> But you have to choose one that is in launchpad
[09:01] <Fujitsu> Once the task is created, you're stuffed, due to a bug which means you can't reassign tasks for projects that use LP.
[09:02] <Fujitsu> Right, but that doesn't mean it uses Launchpad for bug tracking.
[09:02] <distatica> jamesh, or anyone really. Ok, I got all the putty stuff, I generated private and public keys, I opened my private key here, with my password, it's running in pageant, I copied and pasted the contents from my public key file to the launchpad edit ssh keys page, and it says invalid key. I even tried removing all line breaks to make sure it was all one line. Any thoughts?
[09:02] <Amaranth> So I have to find a project that doesn't use launchpad for bugs and reassign to that just so I can then link to a completely unrelated bugzilla from another project?
[09:02] <distatica> I tried with and without the BEGIN SSH2 PUBLIC KEY part.
[09:03] <jamesh> distatica: the format it expects is the one-line form that openssh uses
[09:03] <Fujitsu> Amaranth: No, you should have a project representing the real upstream project.
[09:03] <distatica> jamesh: hmmmm.. that's what I tried to do..
[09:03] <jamesh> distatica: something like "ssh-rsa $lots-of-chars $comment"
[09:03] <Amaranth> Oh, right, this is "everything is in launchpad"
[09:03] <Fujitsu> Amaranth: It's the only way to model it properly.
[09:04] <Amaranth> Or you could not allow projects to screw with distros
[09:04] <Fujitsu> (you don't see me defending Launchpad often, but this is somewhere I will)
[09:04] <jamesh> distatica: iirc Launchpad does not accept a key without a comment at the end.  You can put whatever you want there though
[09:04] <Amaranth> The connection should be the other way, someone managing the package in Ubuntu should say "this package comes from this project"
[09:05] <Fujitsu> You can do it from either end at the moment, and cannot currently delete links. I believe the eletion feature has been deferred a number of times, and is still coming RSN.
[09:05] <jamesh> Amaranth: for a long time we've talked about automating the linking process
[09:05] <jamesh> just haven't gotten round to implementing it
[09:05] <distatica> jamesh: hmm.. my comment comes before, maybe that's it.
[09:06] <distatica> nope
[09:06] <jamesh> Amaranth: if we have the release tarball for the project and the pristine source tarball for the package we can infer a link if they are identical
[09:06] <distatica> jamesh: may I quick PM you?
[09:06] <jamesh> distatica: sure
[09:06] <ddaa> Fujitsu: I actually have written some stuff for the deletion feature last week.
[09:07] <Fujitsu> ddaa: Ah, very good.
[09:07] <Fujitsu> So it's finally happenign?
[09:07] <ddaa> it needs a bit more polish to be release-worthy, and even then it will be a transitional hack
[09:07] <ddaa> until we re-do the whole upstream association ui
[09:07] <ddaa> but it will address the critical "cannot delete link" issue in the short term
[09:07] <Amaranth> This is probably the 100th time I've hit this
[09:07] <Amaranth> And why I don't upstream bugs much, which upstream doesn't like
[09:08] <ddaa> we realise it's a nuisance
[09:08] <Fujitsu> It is ridiculous that they weren't either restricted or deletable in the first place, but it is being resolved.
[09:08] <ddaa> but this is the sort of thing that are tricky to get done, for organisational reasons
[09:09] <Fujitsu> What reasons would those be?
[09:09] <ddaa> it is not within the core responsibility for any team
[09:09] <kiko-zzz> or didn't use to be, until we invented foundations. :)
[09:10] <ddaa> launchpad is all about linking things toghether, but that means that there's a lot of things which lies in the cracks between dimensions, to borrow from Dan Simmons.
[09:10] <Fujitsu> ddaa: Isn't it Soyuz?
[09:10] <Fujitsu> I would have thought it would come under that, really.
[09:10] <Amaranth> I thought it was malone
[09:10] <Fujitsu> But I guess it is sort of more general and Foundations-ish.
[09:10] <ddaa> other people would think it's Translations
[09:11] <ddaa> Strictly speaking, it's part of "registry".
[09:11] <Fujitsu> I guess that bits of Soyuz are Registryish... but the distinction looks very blurry.
[09:12] <Fujitsu> Anyway, good to see it finally being sorted out!
[09:12] <ddaa> Fujitsu: I think you starting to put your finger on why it's organisationally tricky :)
[09:13] <Fujitsu> ddaa: I always thought some things were blurry, and wondered how they were handled.
[09:13] <ddaa> "not as well as they should"
[09:13] <Fujitsu> kiko-zzz: Thanks for the dgetting ability! I'll be watching for the edge rollout tomorrow.
[09:14] <ddaa> Though we're getting better at it.
[09:14] <Fujitsu> Wait, kiko-zzz, what are you doing up?
[09:14] <Fujitsu> ddaa: Good to hear.
[09:27] <Amaranth> heh, could have fixed my problem anyway
[09:27] <Amaranth> found the place to change a link in the package side
[09:27] <Amaranth> and there is a compiz project in launchpad already
[09:35] <ubotu> New bug: #173853 in launchpad "Validation problem while choosing package" [Undecided,New] https://launchpad.net/bugs/173853
[09:40] <Kmos> there is a server for sparc ppa ?
[09:41] <elmo> no, PPA only supports i386 and amd64 due to it's reliance on secure virtualization
[09:42] <Kmos> elmo: thanks for the info :)
[09:42] <Kmos> i've sent a package to ppa with architecture: sparc
[09:42] <Kmos> and it's accepted :(
[09:42] <Kmos> and published
[09:42] <elmo> Kmos: the Architecture in the .dsc is 'sparc' only?
[09:56] <Kmos> elmo: yes
[09:56] <Kmos> elmo: it's afbinit package
[09:57] <jamesh> Kmos: what is the URL of your PPA?
[09:57] <elmo> Kmos: please file a bug on soyuz - it should reject such packages, I think
[09:57] <Kmos> elmo: I think so
[09:57] <Kmos> jamesh: 2 sec
[09:57] <Kmos> jamesh: https://edge.launchpad.net/~gothicx/+archive
[09:58] <jamesh> Kmos: I only see a source package published
[09:59] <Kmos> i've 8 packages in ppa
[09:59] <jamesh> I mean for the afbinit package
[09:59] <Kmos> jamesh: but it shouldn't be rejected?
[10:00] <Kmos> and even not published
[10:00] <jamesh> well, there isn't anything inherently bad about publishing the source package
[10:00] <jamesh> although rejecting it would stop you from expecting it to be built :)
[10:00] <Kmos> exactly
[10:00] <Kmos> i think it would be built, because it was accepted
[10:01] <Kmos> jamesh: you report the bug, or I do it ?
[10:02] <jamesh> Kmos: you probably have more information on what you did and what you expected to happen
[10:02] <Kmos> jamesh: ok =) i'll do it
[10:11] <Kmos> done
[10:20] <ubotu> New bug: #173866 in soyuz "When specific arch is not available at PPA, it should reject" [Undecided,New] https://launchpad.net/bugs/173866
[11:40] <mpt> hiya Hobbsee 
[11:40] <Hobbsee> heya mpt!
[11:43] <Hobbsee> hi BjornT 
[11:45] <BjornT> hi Hobbsee 
[12:04] <kiko> Fujitsu, I was up but then I went to sleep! this patch ate my dinner
[12:05] <Fujitsu> kiko: A...ha.
[12:06] <Hobbsee> mmm...hungry patches.
[12:23] <frenchy> Is there a way to upload a file directly to "Download project files" on LP without using the web interface?
[12:25] <frenchy> While I'm uploading my PPA via script, it would be great if I just updated the upstream tar.gz at the same time.  I use the "Download project file" page for hosting.
[12:47] <kiko> frenchy, well, not right now, but it's very easy to script a web upload using something like zope's testbrowser
[12:50] <frenchy> kiko: Thank you.  I'll have a read about that.
[12:50] <kiko> frenchy, I actually have sort of an example script I can show you when you've done some reading of it
[12:51] <kiko> it won't work for you because it requires some horrible hacks in testbrowser itself to make it simpler (I think)
[12:51] <kiko> but the code is a good example
[12:53] <frenchy> kiko: Sure, that sounds great.  At the moment it seems like any solution is a good solution.
[13:35] <ubotu> New bug: #173899 in malone "E-mail interface isn't advertised" [Undecided,New] https://launchpad.net/bugs/173899
[13:37] <kiko> bug 173670
[13:37] <ubotu> Launchpad bug 173670 in rosetta "IndexError on pluralforms during import" [Critical,In progress] https://launchpad.net/bugs/173670 - Assigned to Jeroen T. Vermeulen (jtv)
[13:46] <kervala> hi there :)
[13:47] <kervala> i have some problems with my PPA (related to missing .mo files in generated .deb) :) who could help me please ? :)
[13:47] <kervala> my PPA is located at : https://edge.launchpad.net/~kervala/+archive
[13:49] <kervala> the .deb was build successfully but all .mo were removed :(
[13:50] <kervala> in the log, i can see .mo were put in wxmtpchat_0.12-1_lpia_translations.tar.gz
[13:50] <kervala> bu i can't find this file anywhere
[13:55] <frenchy> kervala: Hi there, are you saying that when you build the deb yourself that the mo files are in there?
[13:56] <ubotu> New bug: #173902 in soyuz "PPA "Activate" button is available even if I haven't accepted the terms of service" [Undecided,New] https://launchpad.net/bugs/173902
[13:56] <kervala> frenchy: yes :)
[13:57] <kervala> all is correct when i build it locally
[13:57] <kervala> .mo files are installed in /usr/share/locale/...
[13:57] <kervala> but they disappears in .deb created by PPA
[13:58] <frenchy> kervala: What command are you using to create your local deb?
[14:01] <kervala> hum i will paste it :)
[14:01] <kervala> dpkg-buildpackage -rfakeroot
[14:01] <kervala> my debian folder seems ok
[14:02] <Hobbsee> cprov: can you give input into this?
[14:03] <cprov> Hobbsee: we are still stripping translations in buildd, isn't it the expected effect ?
[14:05] <Hobbsee> cprov: presumably not for those who want translations in their ppa
[14:06] <cprov> Hobbsee: then the solution is https://bugs.edge.launchpad.net/soyuz/+bug/136399, right ?
[14:06] <ubotu> Launchpad bug 136399 in soyuz "PPA builders performing normal Ubuntu binary mangling" [High,Confirmed]  - Assigned to Adam Conrad (adconrad)
[14:06] <Hobbsee> cprov: where do the translations debs get published?
[14:07] <Hobbsee> cprov: ah, /dev/null
[14:07] <cprov> Hobbsee: :( yes
[14:08] <frenchy> Yeah, mine are the same, never noticed before.
[14:08] <Hobbsee> cprov: without knowing the soyuz codebase from the inside, i would think so - assuming that the translations could be used, if they were not stripped.
[14:09] <cprov> Hobbsee: the point is, they are stripped during the build, but they are not sent back to soyuz as the primary-archive uploads
[14:10] <cprov> Hobbsee: so, the swallowing is done in the buildd itself
[14:11] <kervala> ok thanks, so have i to create a new issue, add another comment or just wait ? :p
[14:11] <Hobbsee> cprov: which means i'ts infinity's place to fix, presumably.
[14:11] <cprov> Hobbsee: check you PPA binary changefiles (in +build/<1234> page)
[14:11] <Hobbsee> cprov: i presume that lamont can't fix it?
[14:11] <Hobbsee> cprov: it's not mine.  it's kervala 
[14:12] <kervala> :)
[14:12] <cprov> Hobbsee: yes, lamont could do some investigation on this
[14:12] <kervala> and i have another question : does PPA can sign .deb it build ?
[14:13] <cprov> Hobbsee: well, you can also check yours and compare with the the same build happening in primary archive, you will see that the custom-translation tarball will be missing from the PPA binary upload.
[14:13] <Hobbsee> cprov: it would be good to get this fixed.  however, you'll need to harass infinity, or lamont, from the inside.
[14:13] <Hobbsee> kervala: would you be willing to hand over your bank card, and pin, to someone else, to make a purchase for you, where you could not see it?
[14:14] <lamont> translation stripping is part of the normal build process for main
[14:14] <lamont> pitti would be the one who understands it
[14:16] <kervala> Hobbsee: i'm talking about "NOT AUTHORIZED" message when using Synaptic to download from PPA :) how i fix it ? (if it is possible)
[14:17] <Hobbsee> kervala: you can't.  yet.
[14:17] <Hobbsee> kervala: but, my question to you was related.
[14:18] <kervala> ah ok, thanks a lot :)
[14:19] <Hobbsee> kervala: if they were to be signed with your own key, it would be like the bankcard example above.
[14:19] <kervala> ok i see :)
[14:19] <Hobbsee> kervala: i don't think you want to do that :)
[14:19] <kervala> hehe :p
[14:20] <kervala> so i think .deb will be signed with a generic Ubuntu key... :p
[14:20] <kervala> or a key especially for PPA
[14:20] <Hobbsee> yeah
[14:20] <Hobbsee> ppa key
[14:20] <kervala> ok thanks :)
[14:33] <lamont> kervala: the way you fix the lack of a sig on PPA right now is to mirror it somewhere and sign it. :(
[14:35] <lamont> If I ruled the world, you would be able to have LP generate a key (which you could sign if you wanted) that was used for your PPA (and no other).  That keeps the secret key contained to the archive, and gets a unique signing-key for your PPA
[14:36] <kervala> ok thanks but it's not very important :)
[14:37] <Hobbsee> lamont: this requires that you trust that LP would not decide to use it for anything else.
[14:37] <kervala> PPA is really cool even with its bugs :p
[14:37] <lamont> Hobbsee: you're already trusting LP not to trojan the binaries... may as well complete the trust model...
[14:38] <lamont> Hobbsee: the other way would be to generate a key pair and upload both... then you and LP have the key, and you can do things with it too...
[14:38] <lamont> not sure which one scares me more..
[14:40] <kervala> when the binary missing bug will be fixed, does it exist a method to force rebuild of the package(s) without incrementing the version ?
[14:41] <Hobbsee> lamont: i'm thinking of a case where LP woudl decide to do other things with a key i signed.
[14:41] <Hobbsee> if, per se, it ever turned evil
[14:42] <Hobbsee> lamont: i think the latter would be more scary
[14:43] <Hobbsee> from the start, it would be a comprimised key - there would be no absolute certainty that you had signed it, rather than someone who had used launchpad
[14:43] <Hobbsee> lamont: and, if the sky fell in, and it got stuck in librarian, and then found.....
[14:44] <Hobbsee> then anyone could find it, sign as me, and wreak havoc, until the key got revoked, and the mirrors updated
[14:57] <MiserySalin> Hi there... I received a rejected-mail for my package. But I did the same like with every other package.
[14:58] <MiserySalin> Rejected:
[14:58] <MiserySalin> MD5 sum of uploaded file does not match existing file in archive
[14:58] <MiserySalin> Files specified in DSC are broken or missing, skipping package unpack verification.
[14:58] <MiserySalin> Can that be a new "problem" of bug #139619 ? ;-)
[14:58] <ubotu> Launchpad bug 139619 in soyuz "Allow orig.tar.gz from distribution repos" [High,In progress] https://launchpad.net/bugs/139619 - Assigned to Celso Providelo (cprov)
[15:06] <Hobbsee> MiserySalin: did you build iwth -sd or -sa?
[15:06] <MiserySalin> -sa
[15:07] <Hobbsee> the orig.tar.gz is also listed in the .dsc and source.changes, i assume?
[15:08] <Hobbsee> if so, yes, i'd say it's a side effect of the afore-mentioned bug.
[15:08] <MiserySalin> yes, it's in .dsc-file
[15:08] <MiserySalin> I tried a backport of the debian-version of http://packages.debian.org/sid/libfile-basedir-perl
[15:08] <Hobbsee> but not source.changes?
[15:08] <MiserySalin> it's in .sources, too
[15:09] <MiserySalin> Maybe soyuz don't understand that it isn't the same in ubuntu (with same filename)
[15:09] <Hobbsee> i'd say it's a side effect of that bug that cprov-lunch has not dealt with
[15:10] <MiserySalin> yes, thanks....
[15:10] <Hobbsee> but, i don't work on launchpad, so have not seen the internals
[15:25] <ubotu> New bug: #173928 in rosetta "Showing empty packaged translations" [High,In progress] https://launchpad.net/bugs/173928
[15:25] <ubotu> New bug: #173929 in launchpad "When recording a bug as affecting another upstream, do not try to set the upstream's bugtracker if the user chooses to use an existing upstream" [High,Confirmed] https://launchpad.net/bugs/173929
[15:42] <lamont> MiserySalin: if the .orig.tar.gz is already in the archive, with a different md5sum, then you probably can't upload it... only one copy of the file may exist
[15:48] <MiserySalin> Well... why it isn't replaced with the new uploaded file?
[15:48]  * lamont wonders if anyone filed a bug about queue-builder not knowing about ogre model..
[15:49] <lamont> MiserySalin: for the same reason debian doesn't replace it when you do the same thing: that file is already out there on mirrors, etc.
[15:49] <lamont> choices are: 1) use the one that's there. 2) change the version number.
[15:49] <MiserySalin> change version number of orig.tar.gz? is that a good idea?
[15:52] <lamont> ah.  bug 52698 is the ogre-bug
[15:52] <ubotu> Launchpad bug 52698 in soyuz "Auto-Dep retry algorithm doesn't check component" [Medium,Confirmed] https://launchpad.net/bugs/52698
[15:52] <lamont> MiserySalin: that's why there are occasionally things like foo_1.2.3.0.orig.tar.gz, while upstream has only released a 1.2.3
[15:53] <lamont> cprov: is 52698 headed for a release anytime soon?
[15:53] <MiserySalin> ahh... tricky ;-) ... thanks!
[15:54] <lamont> MiserySalin: there's always room for a more detailed version number.. :0)
[15:55] <cprov> lamont: I don't think we will have time for it in 1.1.12, so January is the best bet
[15:58] <lamont> cprov: thanks.  it offends me. :)
[15:58] <lamont> (the bug, not january)(
[15:59] <cprov> lamont: uhm, I will try to do something on this earlier, but no guarantees, we are already fully booked this milestone.
[16:01] <lamont> no worries
[16:02] <lamont> where it mostly shows up is when there are multiple packages, and say some architecture with a couple thousand packages to build in universe, and the front part of each 30 minute window between queue-builder runs is spent trying to build the 5 packages in main that are hit by this bug.  every queue-builder run
[16:02] <lamont> for today, I just tossed the 5 into the cellar (score==100) and now I don't have to worry about them so much
[16:03] <lamont> until they are missing for something important in main because the build-deps got promoted to main :-)
[19:00] <ubotu> New bug: #173976 in launchpad "resolved_upstream link says "open" instead of "resolved"" [Undecided,New] https://launchpad.net/bugs/173976
[19:45] <ubotu> New bug: #173981 in rosetta "NoneType exception while exporting KDE PO file" [Critical,In progress] https://launchpad.net/bugs/173981
[20:53] <ktenney> Howdy. is there a venue on Launchpad for general discussion of a project?
[20:54] <ktenney> wiki-like?
[20:54] <kiko> ktenney, not yet. we will RSN have mailing lists in beta, and wikis are a planned feature that aren't off the drawing board yet.
[20:54] <kiko> ktenney, in the near term we can make it easy for your own hosted wiki to authenticate against launchpad
[20:55] <ktenney> 'authenticate against' hmm
[20:55] <ktenney> don't know that
[20:55] <ktenney> but will look for it
[20:55] <ktenney> is there a Launchpad announce list?
[20:56] <kiko> ktenney, I mean in the OpenID sense.
[20:56] <ktenney> ah
[20:56] <kiko> ktenney, yeah, we announce to the -users list.
[20:57] <ktenney> I'll subscribe. Thanks
[21:02] <kiko> ktenney, what project are you using LP for?
[21:09] <ktenney> kiko-afk: http://launchpad.net/zcadoc
[21:09] <kiko-afk> ktenney, and lorenzo is helping out? what is awesome!
[21:09] <kiko-afk> very nice logo
[21:10] <ktenney> thx, yeah, it's been great fun
[21:14] <kiko-afk> ktenney, lorenzo spent 4 months working with us here in brazil. it was fun! and he helped my dogs give birth to their puppies.
[21:14] <kiko-afk> I really like him
[21:15] <ktenney> a puppy midwife! cool. my daughter is training to be a people midwife :-]
[21:15] <kiko-afk> ktenney, puppies are kinder creatures. but the pictures are gross!
[21:15] <kiko-afk> anyway I need to be afk for a few hours. you hold down the fort while I'm out.
[21:16] <ktenney> nice to meet you
[21:16] <kiko-afk> my pleasure, see you shortly
[21:17] <LaserJock> any Rosetta experts around?
[21:20] <ubotu> New bug: #174013 in launchpad "'+' character is not valid for ubuntu wiki" [Undecided,New] https://launchpad.net/bugs/174013
[21:20] <janimo> is there a plan for easily moveing packages in a PPA to a newer distro without uploading them? I have around gutsy 30 packages and I'd like them to be duplicated for hardy without creating new packages and changelogs just for that
[21:36] <Ubulette> janimo, i doubt it. all debs for a given package end up in the same dir so they can't have the exact same version. you have to add something to differentiate per dist, hence changing changelog and re-upping.
[21:39] <janimo> Ubulette: thanks. I know that's the case ATM, I was wondering if it's planned
[21:39] <LaserJock> some kind of mangler perhaps
[21:40] <javaJake> Hey
[21:40] <thumper> Hey
[21:41] <javaJake> Um, got a bug, was told to report it in syslog. Told me " PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report". Well, my sound works. :D
[21:42] <javaJake> But I don't know what to report. I don't really know what information to give.
[21:43] <thumper> javaJake: you can always start with a more general bug report and you should be told what to provide
[21:44] <thumper> javaJake: is this for ubuntu?
[21:44] <javaJake> Yes
[21:44] <javaJake> OK, sounds good.
[21:46] <javaJake> Um, what package would you suggest?
[21:47] <javaJake> Hmmm, it's a kernel message. So I'll report it against the kernel
 howdy
[22:05] <Rinchen> nifty. it works
[22:10] <Rinchen> so #launchpad is now mirrored on pibb
[22:10] <LaserJock> Rinchen: is that a good thing? ;-)
 It is for openid testing :-)
[22:11] <Spads> oh, pibb is another one of those "social networking" sites
[22:13] <LaserJock> yeah, apparently IRC isn't "social" enough
[22:31] <wiggy> any launchpad developers/admins present?
[22:31] <wiggy> we (plone in this case) are having a problem with the download service
[22:34] <Kmos> wiggy: try to mail feedback@launchpad.net
[22:35] <rick_h_> anyone have a link for the article on using LP/PPAs with bzr. I know I saw it, but my google is letting me down
[22:36] <rick_h_> hmm, maybe I'm thinking of the autoppa stuff
[22:40] <Rinchen> wiggy, what type of problem?
[22:41] <wiggy> Rinchen: https://bugs.launchpad.net/malone/+bug/173096
[22:41] <ubotu> Launchpad bug 173096 in malone "Misleading "Content-Encoding: gzip" header on downloads" [Undecided,New] 
[22:41] <wiggy> that is confusing users and we're getting bugreports about it
[22:41] <Rinchen> gah
[22:42] <Rinchen> We had something similar (but not quite the same) happen a while ago. 
[22:42] <wiggy> just removing that Content-Encoding header should be a simple and safe fix
[22:42] <wiggy> I'm not aware of anything using that header
[22:43] <Rinchen> wiggy, I'll ask around and see if someone can look into it tonight/tomorrow.
[22:43] <wiggy> that would be awesome
[22:43] <wiggy> we're very happy with it otherwise
[22:44] <Rinchen> wiggy, worst case I'll have it triaged in the morning UK time
[22:44] <wiggy> much appreciated
[22:46]  * wiggy can go to bed untroubled now
[23:41] <ubotu> New bug: #174037 in launchpad "Changes to bug status and adding comment not simultaneously possible" [Undecided,New] https://launchpad.net/bugs/174037
[23:45] <ubotu> New bug: #174038 in soyuz "bad md5sum in Packages file" [Undecided,New] https://launchpad.net/bugs/174038