[00:15] <kiko> well
[00:15] <kiko> it's pretty rapid!
[00:15]  * Fujitsu watches a glacier outrun some feature development.
[00:16] <kiko> when we get started on something. the issue is mainly that a lot of the features aren't on the priority list.
[00:16] <Fujitsu> Noted.
[00:16] <Fujitsu> And assuming it doesn't get deferred release after release after release after release...
[00:17] <Fujitsu> Then another 5 releases...
[00:17] <Fujitsu> (that's actually a real-life example, though I an't remember exactly which bug)
[00:17] <Fujitsu> s/an't/can't/. Stupid lag.
[00:17] <mwhudson> we're certainly going to try to stop doing that
[00:18] <Fujitsu> That would be good.
[00:18] <Fujitsu> It was originally targetted for 1.1.6 or 1.1.7, was progressively deferred, then deferred again to 1.2.3 or so.
[00:29] <kiko> Fujitsu, it might be something that just isn't really important and the priority stack is high. the fact that the milestoning is visible may be somewhat unfortunate there..
[00:31] <ubotu> New bug: #172952 in malone "status sorting puts invalid bugs first" [Undecided,New] https://launchpad.net/bugs/172952
[00:31] <kiko> dupe
[00:31] <Fujitsu> kiko: Right, it probably isn't that important. But pushing it back and back visibly is a tad annoying.
[00:32] <kiko> Fujitsu, which is why I'm saying that the milestoning being visible can be a bit unfortunate. :)
[00:32] <kiko> if you didn't know it was scheduled, it wouldn't be such an issue
[00:32] <kiko> and engineers get sick, go on vacation, get stuck, etc
[00:32] <Fujitsu> Yep.
[00:33] <kiko> working with fixed deadlines, customers and priorities is a hard problem, no matter how much good will and late nights you put in.
[00:33] <Fujitsu> Noted.
[01:25] <somerville32> Can I close a bug via a bazaar push?
[01:26] <jelmer> sommerville32: one marked with `bzr commit --fixes` you mean ? afaik not yet
[01:35] <somerville32> if I put Closes lp: #XXX in my commit message and upload, will it close a bug?
[01:35] <jelmer> no, I'm pretty sure it doesn't do that yet
[01:36] <jelmer> that's the sort of thing --fixes is meant for
[03:54] <LaserJock> somerville32: it works for uploading, not commiting to bzr
[03:54] <somerville32> LaserJock, uploading bzr branches?
[03:54] <somerville32> or just packageS?
[03:54] <somerville32> Because if it doesn't work for bazaar uploads, it should
[03:55] <LaserJock> package
[03:55] <LaserJock> s
[03:55] <LaserJock> well, the bug isn't closed until it's in the archives
[03:56] <LaserJock> having a closes lp: #xxxx set the bug to Fix Commited might be helpful
[03:56] <LaserJock> although there might be problems with that
[03:58] <Fujitsu> How do you tell which is the proper branch? What if I push a branch containing a fix for some random project? My branch isn't at all officila.
[03:58] <Fujitsu> *official
[03:58] <LaserJock> exactly
[03:59] <somerville32> Launchpad isn't just for Ubuntu, folks :P
[04:00] <somerville32> I want this for _my_ project hosted on launchpad
[04:00] <somerville32> Maybe make it so that it can only close bugs under the project it is uploaded to?
[04:00] <Fujitsu> .... how is that relevant?
[04:00] <somerville32> Fujitsu, What exactly do you not understand about my request?
[04:00] <Fujitsu> Should I be able to say a bug is closed because I, somebody completely unrelated to the project, push a branch to LP:?
[04:00] <Fujitsu> s/://
[04:01] <somerville32> Fujitsu, You can do it now :/
[04:01] <somerville32> Fujitsu, You just visit the bug, and close it
[04:02] <somerville32> So... how is _your_ comment relevant?
[04:04] <Fujitsu> If I were pushing a bugfix branch, I would most probably reference a bug number in the changelog. That doesn't mean the bug should be closed.
[04:11] <somerville32> Fujitsu, There would be a syntax ofcourse 
[08:55] <ubotu> New bug: #173006 in soyuz "Build failure emails could link to the source package release" [Undecided,New] https://launchpad.net/bugs/173006
[08:57]  * Hobbsee waves
[08:57]  * somerville32 waves back.
[09:10] <kiko-zzz> somerville32, it's a planned improvements; I'd talk to thumper about it IIWY :)
[09:15] <somerville32> kiko-zzz, aweosme :)
[09:20] <ubotu> New bug: #173009 in soyuz "backport-source fails with a dpkg-genchanges error" [Undecided,New] https://launchpad.net/bugs/173009
[09:34] <bac> Hobbsee: ping
[09:35] <Hobbsee> bac: pong
[09:35]  * Hobbsee waves to sabdfl
[09:35] <sabdfl> moin moin, Hobbsee
[09:35] <Fujitsu> Hey sabdfl.
[09:35] <bac> sabdfl: morning
[09:36] <sabdfl> howdy, guys
[09:36] <Hobbsee> bac: what's up?
[09:36] <bac> Hobbsee: you know much about translations?  i've got a new project i want to set up to use translations but the ui is unclear.
[09:37] <Hobbsee> bac: close to nothing about translations, i'm afraid.  go talk to carlos :)
[09:37] <Hobbsee> bac: checking internal documentation, if it exists, may also help
[09:37] <Fujitsu> bac: What exactly are you unclear on?
[09:37] <bac> Hobbsee: none of that team is around atm
[09:37] <mrevell> hey bac, you're up early/late
[09:38] <bac> hey mrevell 
[09:38] <bac> mrevell: what happened to "Define usage" in the action portlet on the project overview page?
[09:38] <Fujitsu> It got consumed by +edit.
[09:39] <mrevell> bac: If you click "Change details" and scroll down, you'll find the options to define the project's usage.
[09:39] <bac> thanks guys, i was looking right past that
[09:39] <Fujitsu> A lot of people miss it, though it's normally the bug tracker bit.
[09:40] <bac> it was right in front of me but i was looking for the old way...  :(
[09:43] <mrevell> bac: Maybe we need to change the text on the translations.lp.net/project page that appears to the owners of projects who haven't enabled translations. I'm not sure if uploading a template automatically sets the "uses translations" flag.
[09:44] <mrevell> jtv: If a project owner uploads a translations template, does that automatically set the "uses Translations" flag for that project?
[09:45] <bac> mrevell: that's my next question...how do you upload the initial POT file? 
[09:45]  * bac wandering around in all new parts of LP
[09:45] <mrevell> bac: Are you the project owner?
[09:46] <bac> yep
[09:46] <Fujitsu> Translations... new? Wasn't Rosetta the first part to be publically available?
[09:46] <bac> Fujitsu: new to *me*
[09:46] <mrevell> Have you set up a release series for the project?
[09:46] <bac> mrevell: yes
[09:46] <Fujitsu> bac: Ah.
[09:47] <mrevell> Hmm, there should be an option to upload a template for each release series on your project's translations overview page - i.e. translations.launchpad.net/projectname
[09:47] <bac> mrevell: right.  go to the relase series, then to the translation tab
[09:47] <mrevell> And then "Upload translation" in the Actions menu
[09:49] <bac> mrevell: it's a bit confusing if you're on the project overview page and then go to the translation tab.  it just says "you need to upload" but no direction that it has to be done from a release series.  in retrospect it's "obvious"
[09:50] <mrevell> bac: Aren't your release series listed on that page? The release series names should be links to the upload page for that series
[09:51] <bac> mrevell: not on translations.lp.net/project
[09:51] <bac> no list of release on that page
[09:55] <mrevell> bac: In that case, I'm a little confused. I'll mail the translations guys to get a better understanding of how it fits together.
[09:56] <Hobbsee> oh neat.  stopping builds is still broken.
[09:56] <bac> mrevell: cool.  thanks.
[09:56] <mrevell> bac: On the translations overview page for the launchpad-documentation project, I get an link for each release series.
[09:57] <bac> mrevell: i wonder if that's b/c translations have been uploaded and approved for those releases?
[09:58] <mrevell> bac: Maybe but I don't think they have. The message I get says, "To set up Launchpad Documentation for translation in Launchpad, you need to upload a translation template for one of its release series."
[09:58] <mrevell> and then links to the upload pages for both series that the project has inherited from the launchpad-project group
[09:58] <mrevell> perhaps it's something to do with it being part of a project group
[09:59] <mrevell> Nope, I just tried another project and it also gave me a link to upload translations.
[09:59] <bac> mrevell: perhaps.  or maybe it's me trying to do something new at 4am
[09:59] <mrevell> :)
[09:59] <bac> mrevell: thanks for your help.  i'll look at it later.
[09:59] <mrevell> np, if you have a screenshot or pastebin of the text you get on the overview page, I'd be curious to see it.
[10:00] <mrevell> See you in your (later) morning :)
[10:04] <Hobbsee> oh, hum.  that's right, i need to file some more LP bugs.
[10:10]  * Hobbsee files a bug on the lack of cancelling builds functionality
[10:16] <ubotu> New bug: #173018 in soyuz "Soyuz refuses to let you cancel a build" [Undecided,New] https://launchpad.net/bugs/173018
[10:16] <Hobbsee> mrevell: which section of launchpad deals with teams, and team creation?
[10:16] <mrevell> Hobbsee: Are you filing a bug?
[10:16] <Hobbsee> mrevell: i'm filing many bugs.
[10:16] <Hobbsee> (yes)
[10:17] <mrevell> Hobbsee: :) Then launchpad is the project to file it under
[10:17] <Hobbsee> mrevell: ah right, i thought there might be a subset
[10:17]  * Hobbsee thinks https://bugs.edge.launchpad.net/launchpad/+bug/173019 is an excellent bug.
[10:17] <ubotu> Launchpad bug 173019 in launchpad "Information marked "optional" should not be mandatory to fill in." [Undecided,New] 
[10:17] <mrevell> Hobbsee: Nah. Anything that doesn't fit neatly into one of the others - e.g. malone - goes into launchpad.
[10:17] <Hobbsee> i wasn't sure if there were some teams i'd missed, that was all
[10:26] <ubotu> New bug: #173019 in launchpad "Information marked "optional" should not be mandatory to fill in." [Undecided,New] https://launchpad.net/bugs/173019
[10:28] <Hobbsee> launchpad_bugs++
[10:28] <Hobbsee> right.  3 reported...what else did i have to report?
[10:33] <kiko-zzz> this is why we have the best bugtracker
[10:35] <Fujitsu> kiko-zzz: Because Launchpad is buggy?
[10:35] <ubotu> New bug: #173021 in launchpad "OOPS when putting too big a number in the (optional) renewal period box when editing a team" [Undecided,New] https://launchpad.net/bugs/173021
[10:36] <Hobbsee> kiko-zzz: we have the best bugtracker, because so many bugs about said bugtracker are reported.  yup.
[10:36] <Fujitsu> Yep.
[10:37] <Hobbsee> kiko-zzz: i don't suppose you a) care, or b) have access to the buildds?
[11:10] <kiko-zzz> Hobbsee, I care, but cprov is the one to talk to
[11:10] <Hobbsee> kiko-zzz: i guess he's here now too :)
[11:11] <cprov> Hobbsee: hi, how can I help you ?
[11:12] <Hobbsee> cprov: any chance you can kill the build running on sejong?  it's marked as not OK - timed out, and has been going for 8+ hours.
[11:12] <Hobbsee> cprov: the LP version of that is not currently implemented.  (bug already filed)
[11:13] <cprov> Hobbsee: I don't have access to ubuntu buildd, only PPA ones
[11:13] <Hobbsee> cprov: darn.
[11:13] <Hobbsee> kiko-zzz: i take it you don't eihter, on that basis.
[11:14] <Hobbsee> Ng: might be able to do it, actually
[11:14] <Ng> Hobbsee: I think the current build is working - LP status tells me its only been building for 22 minutes and the machine is doing things (although it did get wedged overnight and I restarted it)
[11:14] <cprov> Hobbsee: https://edge.launchpad.net/+builds/sejong
[11:15] <Hobbsee> oh, ti has started working again.  pitti was right then, that it does eventually reset itself after marking as manual, then as auto again.
[11:15] <Hobbsee> Ng: cprov sorry for the noise
[11:15] <cprov> Hobbsee: np
[11:16] <Hobbsee> Ng: oh, you did fix it harder.  great :)
[11:17] <Ng> I'm by no means a buildd admin, but I will stab a wedged machine in the face and mark it as auto again :)
[11:17] <Hobbsee> Ng: hehe :)
[12:11] <cyberix> Packages from my PPA cannot be authenticated. Why is that?
[12:12] <cyberix> How does the authentication work anyway. I signed the package before dputting it.
[12:13] <Hobbsee> cyberix: you signed the source.  you didn't sign the binaries that launchpad built.
[12:13] <cyberix> How do I sign the binary?
[12:14] <cyberix> Someone else does?
[12:14] <Hobbsee> you don't.  that would require launchpad using your private gpg key to sign the packages as yours.
[12:14] <cyberix> Yes, that is what I asumed.
[12:14] <Hobbsee> which is oh so wrong, on so many levels.
[12:15] <cyberix> I can't know, if the binary is good anyway because I didn't compile it myself.
[12:15] <cyberix> Does Launchpad sign it with wathever key?
[12:15] <Hobbsee> this is true, you need to trust the build system.
[12:15] <cyberix> Just to make sure it has not been altered in transfer
[12:15] <Hobbsee> not yet.  it's on the todo list
[12:15] <cyberix> ok
[12:16] <cyberix> So I should not care by now
[12:16] <Hobbsee> you know that nothing is lost in transfer, anyway
[12:16] <Hobbsee> if there were losses between your machine, and launchpad, the md5sums would not match.
[12:16] <cyberix> ok
[12:16] <cyberix> thanks
[12:16] <Hobbsee> so no, you don't need to care currently
[12:18] <Hobbsee> cyberix: to sign the binaries on launchpad yourself would be the equivalent of putting your eftpos card, and pin somewhere very public, so anyone could take it and use it.
[12:19] <Hobbsee> cyberix: at best, it would be you giving your card, and pin to launchpad, and hope that they'd never do anything bad with it.
[12:19] <cyberix> Yep, doesn't make any sense.
[12:20] <Hobbsee> oh, and you can know if the binary is good
[12:20] <Hobbsee> they build using a chroot system, so you'll get the same output binary as launchpad does, if you build it with a !pbuilder
[12:20] <cyberix> I'm talking about a case where Launchpad would suddenly turn evil.
[12:21] <Hobbsee> as in, inserting other random stuff, on top of your source?
[12:21] <cyberix> for example
[12:23] <Hobbsee> you could build your binary, check where it installs things to, and diff each individual file with your cleanly-built version
[12:23] <Hobbsee> cyberix: do you run ubuntu?
[12:24] <Hobbsee> cyberix: if you did, the first thing you'd do would be to switch distro.  after that, you'd probably stop uploading to ppa.
[12:24] <Hobbsee> if you suspected LP had turned evil.
[12:25] <cyberix> Of course.
[12:25] <cyberix> But I would still not want to have shipped evil stuff that has been signed by me to be good.
[12:25] <Hobbsee> which would not happen, as you're not signing the binaries, only the source.
[12:26] <cyberix> Yes
[12:26] <Hobbsee> i see what you're saying now
[12:26] <Hobbsee> the question about "well, if i didn't build the source to get a binary, why should i sign it?"
[12:27] <cyberix> yep
[12:27] <Hobbsee> a logical question.  a good one :)
[12:27] <Hobbsee> and an equally good answer.  "this is one of the reasons that you don't".
[12:28] <Hobbsee> should get that added to the FAQ.
[12:30] <cyberix> I could of course revoke my key with message "Launchpad has now gone evil and they managed to steal my identity."
[12:30] <cyberix> Or something like that.
[12:30] <cyberix> Saying "It wasn't me", even if it actulla was me.
[12:30] <Hobbsee> cyberix: only if you were silly enough to give them the private key
[12:31] <cyberix> Ot if I signed their evil binary package.
[12:31] <cyberix> Or
[12:31] <Hobbsee> cyberix: assuming you keep your private key private...they can't actually do anything with your public key of interest
[12:31] <Hobbsee> you'd have awful trouble doing that - you don't have a login to their servers.
[12:31] <Hobbsee> debsign -r doesn't work over https :)
[12:32] <Hobbsee> in fact, debsign won't even let you sign a binary
[12:32] <cyberix> How ever, key revocation doesn't usually work very well anyway.
[12:32] <cyberix> oh
[12:32] <Hobbsee> what makes you say that?
[12:32] <Hobbsee> oh, yes, i see, it does depend on other people actually refreshing the keys every once in a while
[12:33] <cyberix> Yes
[12:33] <Hobbsee> not sure if you can ever get aroudn that
[13:10] <daub> hi, i want to dput my package to the build service. but the package was rejected with following message:
[13:10] <daub> Signer has no upload rights at all to this distribution.
[13:10] <daub> Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
[13:11] <daub> in the changelog file i use gutsy as distribution.
[13:12] <rick_h_> daub: when you run dput, you have to specify the heading from your dput conf
[13:12] <frenchy> daub: Where are you uploading to.
[13:12] <rick_h_> I think the docs have you create a my-ppa section
[13:12] <rick_h_> so your dput command has to be dput my-ppa .....
[13:12] <rick_h_> I did the exact same thing my first time using the ppa setup
[13:14] <daub> ok, now i changed it to my-ppa
[13:15] <daub> i thought it was something like a placeholder
[13:15] <rick_h_> daub:there's a global dput config that defaults to the universe repository I think.
[13:15] <rick_h_> so it was just saying you can't upload a package to universe right now
[13:17] <Hobbsee> rick_h_: s/universe/ubuntu/
[13:18] <rick_h_> Hobbsee: ah, sorry
[13:18] <Hobbsee> as in, the official ubuntu archives
[13:18] <rick_h_> daub: check out /etc/dput.cf for the rest of the config 
[13:18] <rick_h_> you can go in and make your ppa the default one in the future
[13:18] <daub> rick_h_: i followed th instructions on launchpad
[13:19] <daub> have i to do any changes?
[13:20] <rick_h_> daub: no, just specify my-ppa when you run dput
[13:21] <daub> ok, i'm waiting for the accepted/rejected message
[13:21] <rick_h_> daub: good luck!
[13:22] <daub> accepted, yes :)
[13:22] <rick_h_> good stuff, now the build wait begins
[13:22] <Peng> Donning my RTFM-proof asbestos suit, what about Mercurial support and open-sourcing Launchpad?
[13:23]  * Peng gets in a car and drives away at high speeds.
[13:23] <rick_h_> Peng: I'm with you on the Hg front. <3, but I'm not holding my breath
[13:23] <Hobbsee> they plan to open source eventually, no timeframe has been given.
[13:28] <frenchy> I'd like to package w_scan if it hasn't already been done.  Is that possible?
[13:28] <daub> rick_h_: i see now the source package in my ppa. will it build now a .deb?
[13:28] <frenchy> Probably a bit late at this stage for Hardy.
[13:29] <rick_h_> daub: yep, it just takes a little while to get time on a build server and such
[13:29] <Hobbsee> frenchy: not a question for here, but sure, why not?
[13:30] <frenchy> Hobbsee: Ooops ... hhahah ... sorry guys.
[13:30] <Hobbsee> frenchy: why wouldn't you be able to?
[13:30] <daub> rick_h_: ok, i'll check this later. thanks.
[13:30] <Hobbsee> frenchy: it appears they've never heard of makefiles, etc, though.  or something.
[13:31] <ddaa> no plans to support hg in the short term, but you could have a look at the bzr-hg plugin.
[13:32] <Peng> ddaa: Any Canonical-runs-bzr sort of politics involved?
[13:33] <rick_h_> daub: if you select the "view build records" you can see packages waiting to be built, in build, and completed. Play around with it.
[13:33] <ddaa> Peng: I am not sure what you mean.
[13:34] <ddaa> Certainly, Launchpad runs bzr. Bzr was largely started in an effort to provide a good DVCS for Launchpad and Ubuntu.
[13:35] <ddaa> And one of the points of Launchpad is to unify disparate data sources. So we got to pick one DVCS.
[13:35] <Peng> ddaa: I meant "runs" as in "owns".
[13:36] <ddaa> That sounds a bit fallacious to me. It does not own bzr any more that it owns Ubuntu.
[13:36] <Peng> Sponsors, then. Whatever term you want.
[13:37] <Peng> (Canonical *does* own the copyright to the bzr code, though.)
[13:37] <ddaa> Peng: for the same reasons that the FSF own the copyright of GNU tools.
[13:37] <Peng> I know.
[13:37] <Peng> I'm not complaining about that.
[13:41] <ddaa> Peng: to try to answer your initial question: Launchpad got to pick one DVCS, and we think that bzr is superior technically and in user experience.
[13:42] <ddaa> Supporting interoperation with hg and git is something we want to do eventually, but there will only ever be one first class DVCS in Launchpad (as far as I understand the current strategy).
[13:42] <Peng> ddaa: Would it be technically difficult? Or just having to maintain multiple things, or nobody's gotten around to it or what?
[13:42] <ddaa> I cannot give a simple answer to that.
[13:43] <ddaa> Partly, it's lack of resources. Partly is that doing it as well as we would want to is technically difficult.
[13:44] <ddaa> There also the fact that hg/git are not nearly as prevalent as CVS and Subversion.
[13:44] <Peng> Neither is bzr. :P
[13:45] <ddaa> We aim at fixing that :)
[13:45] <Peng> Heh.
[13:46] <Peng> One could claim that supporting hg and git in Launchpad would help make them and Launchpad more prevalent too.
[13:48] <ddaa> My personal position (not speaking for my employer here) is that users can help themselves using (and improving) bzr-git and bzr-hg if they want to work with git or hg data on Launchpad.
[13:49] <ddaa> They are transparent interoperation plugins and do not require a centralized service to provide an authoritative conversion.
[13:50] <ddaa> Of course, it does not help if you want to publish hg or git data.
[13:50] <Peng> And it's also less clean and riskier than using hg or git directly.
[13:51] <ddaa> I understand they are compelling reasons (mostly, network effects) for people to use hg or git.
[13:53] <ddaa> If one of them becomes massively more prevalent than the other, and bzr becomes bound to irrelevance, we'll go with the community.
[13:53] <ddaa> The bzr folks are doing a great job to ensure that does not happen though :)
[13:54] <Peng> It'd be nice if there were fewer choices, but I'd hate for any of the DVCSes to go away. They all have their benefits and new ideas.
[13:54] <doko> ddaa: https://code.edge.launchpad.net/~ubuntu-java/uj/icedtea7 , do you know how to get this published, or who to ask?
[13:55] <ddaa> In any case, Launchpad needs to pick one DVCS. We plan to provide tight integration between projects and between launchpad services. Supporting multiple first-class DVCS would be a lot of extra effort and would defeat the point.
[13:55] <kiko> ddaa, could you edit that into a faq?
[13:56] <ddaa> kiko: I just said a lot of things. If you could pick the bits you want in a FAQ, I'm willing to edit them.
[13:57] <ddaa> doko: that should be published any minute.
[13:57] <ddaa> automatically
[13:57] <doko> ddaa: but it doesn't :-(
[13:58]  * ddaa checks
[13:58] <kiko> ddaa, just an answer to "what RCSs does launchpad support (and why)?"
[13:58] <ddaa> I'll write a ML message for review.
[14:02] <ddaa> doko: looks like there's nothing to be published
[14:03] <ddaa> maybe you should file a but to the effect that "hosted branches registered via the web ui but never pushed to always appear as 'not published yet'".
[14:03] <doko> ddaa: so how do I start? Tried to create a local archive as well, then binding it to the lp URL
[14:04] <ddaa> you need to "bzr push"
[14:05] <ddaa> "bzr push bzr+ssh://doko@bazaar.launchpad.net/~ubuntu-java/uj/icedtea7" or something close to that
[14:05] <ddaa> there should be an example command displayed on the page for you
[14:07] <doko> ddaa: well, ok, it was not clear to me that this is not just an example command, but required to start working with the repo
[14:08] <ddaa> doko: I am not sure we are in sync
[14:08] <ddaa> it's not required for your to start working
[14:08] <ddaa> but you do need to somehow upload data to Launchpad for Launchpad to publish it
[14:10] <ubotu> New bug: #173045 in launchpad-bazaar "Branches are not published" [Undecided,New] https://launchpad.net/bugs/173045
[15:30] <ubotu> New bug: #173062 in launchpad "implement PM system " [Undecided,New] https://launchpad.net/bugs/173062
[15:31] <Hobbsee> ....
[15:31] <Peng> Ouch, next mirror of a new branch in 5 hours.
[15:31] <Hobbsee> repeat after me, launchpad is not a forum.
[15:32] <Hobbsee> launchpad is not a place for socializing.
[15:32] <Hobbsee> why oh why would you therefore want a pm system, when people would only get notified by email anyway?
[15:33] <Peng> You integrate lots of things into Launchpad. Integrating e-mail is a valid suggestion.
[15:34] <ember> Hobbsee it was me, and it wasn't intent to 'socialize" was just to quickening and simply things
[15:34] <Hobbsee> but...when youd' have to send the notifications by email anyway?
[15:34] <Hobbsee> how does that help speed things up?
[15:35] <Hobbsee> youd' have to visit LP, see what the PM was about, respond via LP, and wait for them to do the same?
[15:35] <Hobbsee> Peng: yeah, but i would have classed PM's in with forums and such
[15:36] <ember> you are talking normal pm forums systems
[15:36] <ember> doesn't have to be that way
[15:36] <ember> that's why it was just an idea..
[15:37] <Hobbsee> i seem to be missing what else you're proposing
[15:38] <Hobbsee> ah well
[15:39] <Hobbsee> i'm a lowly user - other people decides what gets done and doesn't.  i doubt that'll go very high on the list, but that's their decision, not mine.
[15:39] <ember> well a start is that you just can check your pm in your email without going on lp
[15:39] <ember> well i'm not either 
[15:40] <Hobbsee> but that's the same as email, or close to...
[15:40] <Peng> Well, having messages organized by project or even branch isn't so bad.
[15:40] <Peng> The thing is, in many cases there better places to discuss things, in public like in bugs or mailing lists.
[15:41] <ember> Hobbsee i understand you, i was waiting for feedback thou
[15:43] <Peng> I'd say the clunkiness and effort of a PM system isn't worth the organization benefits over email.
[15:45] <ember> or perhaps a link in the email of the user to open the email client
[15:47] <Hobbsee> whcih is another page load, and annoying.
[15:49] <ember> yeah, youre right for those who don't use email clients it may be annoying
[15:51] <Hobbsee> ...we have official incomplete-expiry now?
[15:53] <ember> why?
[15:53] <Hobbsee> there's a tooltip telling me that the bug will expire in 59 days
[15:53] <Hobbsee> i thought it was reverted till further notice.
[15:54] <ember> lol
[15:57] <somerville32> Hobbsee, You must have missed the further notice?
[15:57] <somerville32> :P
[15:57] <Hobbsee> somerville32: i expected them to actually tlel lp-users, ubuntu-devel@, etc, seeing as it affects them an awful lot
[15:58]  * somerville32 nods.
[15:58] <Hobbsee> somerville32: i don't think that effective notification is getting a whole stack of auto-expired bugmail.  again.
[15:59] <somerville32> Hobbsee, btw, everything is good again :]
[15:59] <Hobbsee> somerville32: w.r.t?
[16:00] <somerville32> security
[16:00] <Hobbsee> oh, good.
[16:17] <SteveM> My project appears to have a corrupted download. Re-uploading does not fix the problem (a re-download on another machine gives the bad file). I assume this is caching at work. Does anyone know how long download binaries are cached?
[16:32] <kiko-fud> SteveM, not caching. something else. bac can you help him?
[16:34] <bac> kiko-fud: sure
[16:34] <SteveM> Maybe mirroring and redirection?
[16:34] <bac> hi SteveM
[16:34] <SteveM> Hi!
[16:34] <SteveM> Repeat: My project appears to have a corrupted download. Re-uploading does not fix the problem (a re-download on another machine gives the bad file). I assume this is caching at work. Does anyone know how long download binaries are cached?
[16:45] <ubotu> New bug: #173081 in launchpad "Rename the 'Launchpad Janitor'" [Undecided,New] https://launchpad.net/bugs/173081
[16:55] <kiko-fud> bac?
[16:55] <bac> kiko-fud: ?
[16:55] <kiko-fud> bac, see SteveM's re-post :-P
[16:55] <bac> kiko-fud: handled
[16:55] <SteveM> Figured out.
[16:55] <bac> kiko-fud: everyone is happy.  :)
[16:55] <SteveM> .tar.gz files were being unpacked by the browser.
[16:56] <SteveM> We're testing .tgz instead.
[16:56] <kiko-fud> ah, cool
[16:56] <kiko-fud> I didn't see the resolution, just the re-post
[16:56] <SteveM> We'd jumped to private chat.
[17:00] <Peng> (100% not a bash.) I think it's interesting that Launchpad is very public about releases and development and bugs, while it's closed-source. Sounds a little tricky to do.
[17:32] <SteveM> I'm trying to figure out how to get launchpad downloads of .tar.gz files to behave as expected by most users. Right now, Launchpad downloads send a "Content-Encoding: gzip" header with these files. While nominally correct, this is causing browsers to unpack the files on download.
[17:32] <SteveM> That's causing confusion, since the files are keeping the .tar.gz filename extension.
[17:32] <SteveM> Same problem, by the way, with .tgz files.
[17:34] <intellectronica> SteveM: interesting problem. consider this, though - the only way to get around that on the server is to serve the files using the wrong mime type, which is a bit nasty). on the client, otoh, you can decided how to handle different file types.
[17:34] <intellectronica> SteveM: surely you've experienced this problem with other sites too?
[17:34] <SteveM> intellectronica: The problem, though, isn't the MIME type.
[17:34] <SteveM> It's the Content-Encoding heaer.
[17:34] <SteveM> s/heaer/header/
[17:35] <intellectronica> SteveM: really? what value do you get?
[17:35] <SteveM> "Content-Encoding: gzip"
[17:35] <SteveM> There's actually no MIME type in the response.
[17:35] <intellectronica> SteveM: looks like a bug to me.
[17:36] <SteveM> Many servers will send a MIME type with this type of content that indicates the gzip. Most browsers (except safari) ignore the gzip part of that.
[17:37] <SteveM> But, with a "Content-Encoding" header, all browsers will unpack it.
[17:37] <intellectronica> SteveM: Content-Encoding: gzip tells the browser to unpack the file, which you only want in cases where you actually serve stuff you want the browser to display
[17:37] <intellectronica> SteveM: maybe you can raise a bug?
[17:37] <SteveM> IMHO, right.
[17:37] <SteveM> Will do.
[17:37] <intellectronica> SteveM: excellent, thanks!
[17:50] <ubotu> New bug: #173096 in malone "Misleading "Content-Encoding: gzip" header on downloads" [Undecided,New] https://launchpad.net/bugs/173096
[18:05] <Peng> Oh, good. Even if it said 5 hours to mirror a branch, it was much less.
[18:05] <Peng> 2 or 3, maybe.
[18:05] <Peng> Or less.
[19:33] <nxvl_work> hi
[19:33] <nxvl_work> is there any way to find people on LP by county?
[19:36] <nxvl_work> is there any way to find people on LP by country?
[19:42] <kiko> well
[19:42] <kiko> there are loco teams
[19:42] <kiko> nxvl_work, what do you want to know specifically?
[20:06] <ubotu> New bug: #173121 in malone "branch search fails with full description" [Undecided,New] https://launchpad.net/bugs/173121
[22:35] <ubotu> New bug: #173139 in launchpad "HWDB needs to make system_fingerprint URL-safe in result sets" [Undecided,New] https://launchpad.net/bugs/173139
[22:40] <ubotu> New bug: #173141 in malone "urls should follow some common naming scheme" [Undecided,New] https://launchpad.net/bugs/173141
[23:21] <Peng> With branch statuses, what's the difference between "Fix Available" and "Best Fix Available"? Once your code is perfect, change it to Best?
[23:23] <kiko-afk> I think best fix might be a bit of an overkill
[23:26] <Peng> Well I know that there could be no better fix ever. It's completely impossible. My patch is perfect.
[23:32] <kiko-afk> Peng, now now, let's not get carried away, it's just a branch status. 
[23:32] <kiko-afk> Best Fix Available; Best Fix EVAH
[23:32] <Peng> It would spam everybody if I changed it, wouldn't it?
[23:35] <kiko-afk> I'm not 100% sure as I haven't used this feature myself