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