[00:55] <mars> zobi1, best ask a question directly to the Translations team.  They can tell you more about the system:  https://answers.edge.launchpad.net/rosetta/+addquestion
[10:54] <Lord-Readman> Chris mate, its doing well http://impoll.net/cgi-bin/v.cgi?p=10231&r=9
[11:27] <magcius> Does Launchpad send an email to the project owners when a branch is linked?
[11:27] <wgrant> magcius: Linked to what?
[11:28] <magcius> If I "register a branch" with a project, will it/how would I send a message to the appropriate person?
[11:29] <wgrant> magcius: It won't notify them, unless they have subscribed to the RSS feed. If you want to request that they merge it, you could click 'Propose for merging'.
[11:30] <magcius> wgrant, ahhhh
[11:30] <wgrant> That will email the default reviewer for the target branch.
[11:30] <magcius> I'm still a bzr noobie, is a bzr merge like a git pull?
[11:30] <wgrant> Yes.
[11:30] <magcius> or does bzr pull have the same semantics too
[11:31] <wgrant> pull will bring the target's tip to the same as the source's, if the source has a superset of the target's revisions.
[11:32] <wgrant> But otherwise you need to merge.
[11:33] <magcius> when in normal practices will that not be the case?
[11:33] <magcius> i.e. can you do bzr pull --rebase like git?
[11:33] <magcius> Or is there something equivalent at all?
[11:33] <wgrant> It will not be the case when there have been commits on trunk since it was last merged into the branch.
[11:33] <wgrant> There is bzr-rebase, but it is not normally used.
[11:34] <wgrant> Rewriting history is frowned upon.
[11:34] <magcius> git pull --rebase isn't really rewriting history
[11:34] <wgrant> Doesn't it rebase the branch on top of trunk?
[11:35] <magcius> it's basically, 'find the common revision, undo and store everything from then as patches, pull, then apply the patches'
[11:35] <magcius> which is very useful if you have local commits for fixes or have applied patches that are not upstream]
[11:35] <wgrant> bzr rebase can do that easily.
[11:35] <wgrant> But it is not often done.
[11:36] <Meths> magcius: Until you merge patches from other people to send upstream, then rebasing reassigns credit for patches and is a bad thing (tm)
[11:36] <magcius> Meths, why would it do that?
[11:36] <siretart> magcius: the 'undo, store and redo' part is a typical case for "rewriting history"
[11:36] <magcius> Meths, doesn't bzr store both an author and committer?
[11:37] <magcius> (I swore it did, because I saw both in the log)
[11:37] <wgrant> It does.
[11:37] <magcius> So would a rebase re-assign both the author and committer?
[11:38] <Meths> magcius: Sorry, thought git did this.  Not bzr.
[11:38] <magcius> Meths, nope.
[11:39] <Meths> hmmm, okay.  Have to reread why Linus hates rebasing so much...
[11:39] <magcius> he does?
[11:39] <magcius> rebasing isn't something you usually do in upstream repos
[11:40] <magcius> but it's useful when merging in other changes since the histories have diverged
[11:40] <magcius> siretart, well my branch is a branch and I don't think it's quite that bad to rewrite history just so I can get latest changes. Is there a "better" way in the terms of bzr?
[11:41] <Meths> Ah, after rereading it's nothing to do with history rewriting, my bad.
[11:41] <magcius> Meths, link?
[11:41] <Meths> http://kerneltrap.org/Linux/Git_Management
[11:42] <siretart> magcius: you could try 'bzr merge' folowed by 'bzr revert --forget-merges'
[11:42] <magcius> siretart, bzr merge lp:upstream-branch ?
[11:43] <wgrant> That will forget the wrong merges.
[11:43] <wgrant> magcius: Why do you want to rewrite history?
[11:43] <siretart> wgrant: he wants 'git pull --rebase' semantics
[11:43] <magcius> wgrant, mainly to keep my commits on top so I can deal with them easily.
[11:43] <magcius> wgrant, and it's an easier fix if they go wrong to fix *my* commits instead of *their* code
[11:44] <siretart> magcius: I haven't followed bzr development closely lately, but AFAIUI looms and pipes are designed for this use cases
[11:44] <wgrant> looms are indeed for this sort of thing.
[11:44] <magcius> eek...
[11:44] <wgrant> pipes are handy too.
[11:44] <magcius> is that like git stash?
[11:44] <wgrant> No.
[11:44] <magcius> or git branches?
[11:44] <siretart> no
[11:45] <magcius> link to a simple introduction?
[11:45] <siretart> https://edge.launchpad.net/bzr-loom
[11:45] <magcius> and is it an external plugin, and will everybody need it installed?
[11:45] <wgrant> Also https://launchpad.net/bzr-pipeline
[11:45] <magcius> oops
[11:46] <magcius> on my system the "Download" button is cut off
[11:46] <magcius> the background, that is
[11:46] <siretart> since you 'pull --rebase', you don't want that branch published anyways, so only you need to have that plugin installed
[11:47] <magcius> Is there any reason the latest announcement is for the release of 1.3, but the download is 2.0?
[11:48] <magcius> http://imgur.com/hP9qO.png
[11:48] <magcius> I think your sliding door needs extra length.
[11:50] <magcius> eek, the "convert everything to a loom" does not really seem suitable for registering a branch
[11:50] <wgrant> Hm?
[11:50] <magcius> wgrant, a reply to which
[11:51] <magcius> They don't really explain the terminology.
[11:51] <magcius> A "loom" is a repo/branch?
[11:51] <magcius> A thread is a set of patches?
[11:51] <wgrant> A loom is a stack of threads.
[11:51] <wgrant> A thread is sort of a mini-branch
[11:51] <wgrant> So within a loomified branch, you have a stack of threads.
[11:52] <wgrant> As the bottom thread you might have trunk,
[11:52] <wgrant> Then above that you have a thread for each of your patches.
[11:52] <magcius> and each thread has a superset of the history of the one below it?
[11:52] <wgrant> So you can version your patches, while keeping them separately on top of trunk.
[11:52] <wgrant> Yes.
[11:52] <magcius> hmm
[11:52] <magcius> So I can add patches to any thread at one point?
[11:52] <wgrant> pipeline is similar, except that it uses a stack of actual branches.
[11:53] <wgrant> "at one point"?
[11:53] <magcius> any point in time
[11:53] <wgrant> Right.
[11:53] <wgrant> You can switch between threads and commit to each of them.
[11:53] <magcius> So if I add something to a thread below another, the thread above will share that history too?
[11:54] <magcius> i.e. get that commit too
[11:54] <wgrant> Right.
[11:54] <wgrant> As you move up the loom, the changes will be merged up.
[11:55] <magcius> What exactly is quilt then?
[11:55] <wgrant> quilt is unrelated to bzr.
[11:55] <magcius> I know
[11:55] <wgrant> But it's similar. It's a stack of patches.
[11:56] <magcius> What is it implemented on top of?
[11:56] <magcius> (I can't find anything with a simple search)
[11:56] <wgrant> Probably just patch.
[11:56] <magcius> I mean, what tool? Darcs? Monotone?
[11:56] <wgrant> None.
[11:56] <wgrant> It doesn't use a version control system.
[11:57] <magcius> Okay, so where can I find it?
[11:57] <wgrant> quilt maintains an unversioned series of patches.
[11:57] <wgrant> apt-get install quilt
[11:57] <magcius> eek, I'm not an ubuntu user
[11:57] <wgrant> (or your favourite operating system's package manager)
[11:57] <wgrant> http://savannah.nongnu.org/projects/quilt
[12:01] <magcius> alright, thanks
[12:01] <magcius> I'm also looking at Stacked Git
[12:02] <magcius> which seems to provide a similar thing. I thank you for informing me of this, I really, really like the idea.
[12:02] <wgrant> It's hopefully a bit less ugly than rebasing.
[12:04] <magcius> Although I'm quite disappointed it needs a conversion to a loom to work, is there a way to push the current thread as a regular branch?
[12:06] <lifeless> magcius: bzr init <target>; bzr push target
[12:06] <magcius> where target is?
[12:06] <lifeless> magcius: or bzr export-loom will push all threads to a bunch of adjacent branches
[12:07] <wgrant> The question was truly perfectly timed.
[12:08] <magcius> lifeless, oh, so when it converts to a loom it *converts to a loom*
[12:09] <lifeless> I don't have any context here
[12:09] <magcius> So much that bzr init works and somehow magically doesn't destroy history in the loom and magically destroys history in the bzr branch
[12:09] <lifeless> so you'll need to fill me in a bit
[12:11] <lifeless> certainly neither loomify or init will destroy history
[12:16] <lifeless> magcius: well, I'm off to bed; I don't know what issue you encountered, but please do file a bug or ask a question or something.
[12:20] <AlanBell> hi, I have a PPA question
[12:20] <AlanBell> I have packaged a python upstream project http://lpod-project.org in my PPA
[12:20] <AlanBell> following the python packaging guide (or trying to)
[12:20] <AlanBell> it built for Karmic which is great, how do I get it to build for Lucid/Jaunty?
[12:21] <AlanBell> ppa:alanbell/lpod lpod-python is the package
[12:23] <Laney> AlanBell: for lucid, try copying the package — https://help.launchpad.net/Packaging/PPA/Copying
[12:24] <magcius> Hmm... I just took a look at the new OpenSuSE Build System... is Canonical planning something similar?
[12:25] <magcius> https://build.opensuse.org/
[12:25] <wgrant> magcius: Similar to what aspects of it?
[12:25] <wgrant> Launchpad does very similar things already.
[12:25] <magcius> wgrant, the fact that you can create packages for a bunch of distributions.
[12:26] <wgrant> Launchpad does that for Ubuntu, but I do not know of plans to do it for any others.
[12:26] <magcius> RPM-based systems (RHEL, Fedora, OpenSuSE, Debian, Ubuntu)
[12:26] <magcius> er
[12:26] <magcius> I forgot I had said that
[12:26] <magcius> disregard the RPM-base
[12:26] <magcius> d
[12:37] <AlanBell> The following source cannot be copied:
[12:37] <AlanBell> * lpod-python 0.9-1ubuntu3 in karmic (same version already has published binaries in the destination archive)
[12:37] <wgrant> AlanBell: Copy the binaries too.
[12:37] <AlanBell> however it lets me do it if I copy the binaries
[12:37] <AlanBell> isn't that bad?
[12:38] <wgrant> Probably not. Remember that Lucid started off a complete binary+source copy of Karmic.
[12:38] <wgrant> And most of Lucid's binaries are still the same as Karmic's.
[12:38] <wgrant> You'll have to test if it works, but it probably will.
[12:38] <AlanBell> ok, well I will give it some testing
[15:58] <geser> what's the best/easiest way to check if I've an anonymous or non-anonymous login to the LP API?
[16:23] <DexterLB> can I use lp for projects that are not software? e.g. blender movies etc? And use bzr to upload the blend files?
[17:32] <patx2> can i delete my ppa on launchpad? if not can i delete the packages in it?
[17:38] <patx2> ah nvm i found it
[18:00] <davidstrauss> I apparently need this branch upgraded to update the import: https://code.launchpad.net/~davidstrauss/hiphop-php/trunk
[18:01] <davidstrauss> I can't seem to upgrade it from the shell like I normally can.
[18:02] <davidstrauss> mars: ^^
[20:43] <rye> Is there any protection from spammers posting the ads to bug reports at Launchpad?
[20:52] <kermiac> hi. is anyone around who can look into https://answers.edge.launchpad.net/launchpad/+question/101807
[20:53] <kermiac> we are currently discussing this spammer in #ubuntu-bugs
[21:15] <kermiac> sorry to be persistant but, is anyone around who can help with another spammer? I am currently cleaning up the mess they have made so far
[21:15] <kermiac> https://answers.edge.launchpad.net/launchpad/+question/101807
[21:17] <lifeless> have you tried to speak to them?
[21:20] <kermiac> lifeless: no, I haven't. Normally I would try to speak to them first but it REALLY seems like this is the same spammer we had just over a week ago with the nospammail.net email address. Also the LP account name say a lot "fail2ban"
[21:20] <lifeless> fail2ban is a package name
[21:21] <lifeless> we get lots of folk that fanboy packages they are interested in
[21:21] <lifeless> not saying you're wrong
[21:22] <lifeless> but please try to speak with them
[21:22] <lifeless> I wish that LP subscribed non-QA folk to bugs they touch
[21:22] <lifeless> so that you could reply to the bug and be sure they would see the reply
[21:23] <kermiac> ok. point taken, but I am currently cleaning up a lot of old bugs that they are changing - adding tags, changing status, removing upstream tasks, etc. Seems exactly like https://answers.edge.launchpad.net/launchpad-registry/+question/100682
[21:23] <lifeless> suspension is a big hammer
[21:23] <lifeless> they are definitely misguided
[21:23] <lifeless> but they aren't adding advertising
[21:24] <lifeless> nor are they swearing or being otherwise clearly hostile
[21:24] <kermiac> with them having a "nospammail.net" email address, I don't believe they would get the email even if I did contact them.
[21:24] <lifeless> your belief is wrong :)
[21:24] <lifeless> to get an address active on LP, it has to receive email
[21:24] <kermiac> ok, ty for the discussion lifeless. I will try to contact this user
[21:25] <lifeless> because the LP address activation process involves LP sending them an email and them clicking on a unique link contained in the mail
[21:26] <kermiac> That would normally be the first thing I do, but this seems to be the same person. But I understand your point about suspension being a big hammer. I will try to contact this user, although I don't believe it will have any effect
[21:27] <idnar> nospammail.net is a real mail hosting provider
[21:27] <idnar> (apparently)
[21:28] <lifeless> its working on the misguided theory that spammers have an economic motive to ignore 'probably bogus' addresses.
[21:28] <kermiac> I thought it was simply a redirect service. obviously I was wrong
[21:34] <kermiac> ok, I have contacted the user to see if that helps http://ubuntu.pastebin.com/f65721765
[21:34] <kermiac> ty for the discussion
[21:35] <lifeless> thanks
[21:51] <aboSamoor> where can I know the list of the bugs sorted by the number of the people affected ?
[21:52] <lifeless>  don't think the web ui permits that; you can sort by number of dups though, or bug heat (which is similar)
[22:56] <wgrant> aboSamoor, lifeless: You've been able to sort by 'number of users affected' for a few months now.
[23:01] <wgrant> lifeless: While poking around in launchpadlib overnight, I discovered how launchpad.projects manages to act like a dict.
[23:02] <wgrant> lifeless: It's a hack in launchpadlib to construct URLs manually, with hardcoded names and URL patterns for a few top level collections.
[23:03] <lifeless> wgrant: can you apply that to series ?
[23:04] <wgrant> lifeless: You probably could, but the infrastructure would need a bit of work, and it is a horrible hack that probably should be avoided so as to encourage a proper fix.
[23:04] <wgrant> lifeless: To be clear, these names and patterns are hardcoded inside launchpadlib's code itself, not the WADL.
[23:48] <lifeless> wgrant: that makes sense to me though
[23:48] <lifeless> wgrant: getFoo(arg) -> foo[arg]
[23:48] <lifeless> wgrant: as a compilable pattern
[23:48] <wgrant> lifeless: It really does.
[23:49] <wgrant> But that'll need WADL changes, which probably means leonardr.
[23:49] <lifeless> why?
[23:49] <lifeless> I mean, can't we just observe that there is a getFoo
[23:49] <wgrant> lifeless: How do I tell launchpadlib which method to call?
[23:49] <wgrant> And which arguments to pass to it?
[23:52] <lifeless> getFoo(name) => __getitem__(name)
[23:52] <lifeless> on a 'foo'
[23:53] <wgrant> lifeless: And export a method named '__getitem__'?
[23:53] <lifeless> eys
[23:54] <wgrant> Ew.
[23:54] <lifeless> why ew?
[23:54] <wgrant> Exposing names like that.
[23:54] <lifeless> wgrant: uhm, __getitem__ is []
[23:55] <wgrant> It seems better (and reasonably easy) to a method decorator that tells the WADL generator to mark it as the default getter.
[23:55] <wgrant> lifeless: Yeah, I know.
[23:55] <lifeless> wgrant: I'm not saying put __getitem__ in the wadl
[23:55] <lifeless> I'm saying in the client side, use 'getFoo' to instruct the creation of a foo with a __getitem__
[23:55] <lifeless> assume the definition is fine, fix the compiler
[23:56] <wgrant> lifeless: where do I get the string 'getFoo' from?