[00:01] hi, I have deleted a package 8 hours ago (webstrict_1.4-0ubuntu1), but I still can see it here: http://ppa.launchpad.net/sabily.team/ppa/ubuntu/pool/main/w/webstrict/, is it normal? [00:03] jmehdi: it takes about a day to disappear iirc [00:03] Though it's a bit odd, why does it matter? [00:04] mwhudson: ok [00:10] emm i tried to upload (for the first time) a package, and i got this message: .orig.tar.gz already exists in Primary Archive for Ubuntu Linux, but uploaded version has different contents. [00:10] Why it is checking in "Primary Archive for Ubuntu Linux" ? [00:10] I've uploaded it in my PPA. [00:11] aboudreault: An orig.tar.gz for that version already exists in Ubuntu. PPAs also look in Ubuntu for their orig.tar.gz. [00:11] But does it really say Ubuntu Linux? [00:11] jmehdi: I've had a look at your PPA through the API, and there's something a bit strange going on. Try deleting the package again. [00:11] if i remember well, yes. [00:12] aboudreault: It should just say Ubuntu, but anyway. [00:12] wgrant: so, i have to change the version or what ? [00:12] You should reuse the orig.tar.gz from Ubuntu if possible, but otherwise rename the orig.tar.gz. [00:12] aboudreault: Why not just use the Ubuntu one? [00:12] could try.. it said that the content was different. [00:13] will try that. thanks [00:13] jmehdi: It looks like you might have deleted it before the binary was published, so the binary was still published and is keeping the source around. [00:13] jmehdi: When it's properly deleted, you should see "Removal requested on " in the publishing history. [00:13] wgrant: could be possible, cause I saw I forgot the ~ppa and deleted it immediately [00:14] jmehdi: You deleted it a couple of minutes after the build finished, but the binary might not have actually entered the system at that point. [00:14] jmehdi: So just try to delete it again. [00:14] wgrant: ok, deleted again [00:14] * wgrant checks. [00:14] It worked. [00:15] At least, the binary is gone. [00:15] So hopefully something will notice that the source can die too, as no binaries reference it. [00:15] wgrant: ok, I'll try to push again the ~ppa version since its build failed [00:15] wgrant: could I push it now? [00:15] jmehdi: No. [00:16] But in 7 or so minutes it might work. [00:16] jmehdi: But you just need to retry the build; don't reupload. [00:16] wgrant: ok, I'll retry the build tomorrow [00:16] wgrant: got to sleep now, thanks! :) [00:17] jmehdi: np [00:17] * wgrant files a bug or two about it. [00:22] jmehdi: "# Removal requested 42 seconds ago. " - the source will go away very shortly. [00:25] About vcs-imports Are any of the sourceforge imports working? === xnox````` is now known as xnox [00:39] xnox: some of them are, yes [00:39] xnox: are you the eina import dude? [00:41] mwhudson, maxb: Assuming an absence of bugs like bug #376256, packages seem to be removed after a publisher run or two. Not a day, any more. [00:41] Launchpad bug 376256 in soyuz "Deleting a source before binaries are accepted leaves things published" [Undecided,New] https://launchpad.net/bugs/376256 [00:41] mwhudson: nope gnomesword dude [00:41] xnox: ah [00:41] * mwhudson has a look [00:41] * xnox it never managed to import [00:42] wgrant: i assume that i have to download the file *.orig.tar.gz that is on launchpad to generate my `debuild -S -sd` ? [00:42] s/assume/suppoe [00:42] suppose. [00:42] aboudreault: You should, yes. [00:42] xnox: wow, 44 hours and still failing :( [00:43] How can I find it ? [00:43] * xnox thinks it's a waste of launchpad unless you want to experiment with such stubborn testcases [00:43] ha got it i think. [00:43] it was on karmic [00:44] mwhudson: I'm friendly with upstream is there something they can do from their side? [00:44] xnox: yes, i am changing it to not try again after five failures [00:44] xnox: no, not really [00:44] xnox: i can grab the repo via rsync and import from a file:/// url [00:45] xnox: but it's a fiddle :/ [00:46] mwhudson: ok. I'm pulling into development-subtrees format from scratch and it seems to work locally right now.... [00:46] xnox: ah, using bzr-svn? [00:46] xnox: currently launchpad uses cscvs (something else i want to change soon) [00:47] mwhudson: yeap. I might just push it to launchpad, *cough* unless it's too much [00:47] no, should be fine [00:47] xnox: how big is it? [00:50] mwhudson: old one ~100MB I'll wait till I see new one [00:50] not as big as I thought.... [00:50] that's totally fine then :) [00:51] cool dude =D [00:53] * xnox wonders when the first kernel git-repo import to launchpad will happen [00:53] there's a little bug/missing feature in bzr-git currently [00:53] xnox: what are you using development-subtrees for? [01:00] lifeless: trying to experiment with the new autobuild plugin for nightly builds of software I package =D In addition I'm about to embark on a project were I'll have 4 major parts, though interconnected but yet separate on their own. (one non-free) [01:02] subtrees is faster for bzr-svn =D didn't expect [01:02] visually not a real benchmark [01:02] xnox: it shouldn't be; subtrees are not supported yet. [01:03] lifeless: maybe because priously I was on 1.9-rich-root..... [01:04] * xnox can't remember exactly but it was always telling "or some other name" [01:04] xnox: 1.9-rich-root is the current supported format you should use for bzr-svn [01:05] lifeless: ok, not killing it since it copied about 1/5 of revisions already... I'll be geany pig [01:05] xnox: if you want to beta test stuff, get bzr 1.15 dev and use --development-rich-root [01:05] *that* is a lot faster and has the same caveats and warnings [01:06] lifeless: ok I am on 1.14.1 i'll upgrade [01:06] xnox: did you perhaps mean '--development-rich-root' not '--development-subtrees' [01:07] they are different things [01:08] lifeless: nope subtrees, defo [01:08] 1.14 doesn't have --development-subtrees [01:09] xnox: bzr --version tells 1.14.1 and help other-formats has development-subtree [01:10] is "s" at the end make the difference [01:10] bah, its docs [01:10] xnox: anyhow, dont use development-subtree [01:10] xnox: --development-rich-root is what we're working on [01:11] ok [01:11] and it will get subtrees soon [01:11] --development-subtree is actually something different again [01:13] real coders don't write documentation, eh =D [01:17] https://launchpad.net/api gives a strange error.. [01:21] james_w: ~bzr-nightly-ppa bzr-svn-0.6 hardy, intrepid..... jaunty is missing =( [01:22] xnox: yeah, there's a problem with the jaunty packaging branch [01:22] I haven't had time to fix it or use the debian packaging branch instead I'm afraid [01:23] which one is it? I'm ok at packaging and have some spare time [01:24] james_w: lp:~bzr/bzr-svn/jaunty-ppa ? [01:24] yeah, I think so [01:25] code.launchpad.net/~dailydebs-team to check for sure [01:25] it's a problem with the branch itself rather than the packaging though [01:52] james_w: jaunty-ppa is stacked onto lp:bzr-svn/0.5 instead of the 0.6 that is lp:bzr-svn apart from that this is the only difference between jaunty vs hardy/intrepid [01:52] do you have dailydebs logs to look at? [01:52] [hardy|intrepid] ppa are not stacked onto any bzr-svn [01:53] how does it manages to merge? [01:56] about bzr-svn 0.6 hmmm it asks for username and password? [02:25] jelmer: thanks for filing the bug :) === savvas_ is now known as savvas [03:53] Grah. Who changed build pages so we can no longer hack URLs to get binaries early? [04:45] wgrant: LOL =D you made me laugh [04:45] xnox: How? [04:46] it's functionality that was quite useful at times [04:46] It was :( [04:46] 20 minutes is quite a while. [04:57] sinzui: I think people are going to have to sometimes live with API breakage, or you're quite constrained in what changes you can make internally. [04:58] wgrant: yes. I just have difficulties with the semantics of alpha and beta [04:58] sinzui: they are fluid terms, defined very differently by different people. [04:59] sinzui: So does Ubuntu One. [04:59] sinzui: in terms of API compatibility, if we say "We're breaking API compatibility until we say otherwise", then it doesn't matter to me whether we call it alpha, beta or susan. [04:59] Other products and projects have no problems breaking compatibility at beta. [05:00] suddenly alpha would be less funny than suddently susan [05:00] wgrant: Python breaks compatibility with every major release [05:01] jml: Yes... in very subtle and unexpected ways, as we've found with 2.5->2.6... [05:01] wgrant: jml: we namespaced the URL to support different versions so that users have reliability. I cannot foresee a day when the API wont be beta. [05:01] sinzui: That's an awful lot of compat shims. [05:01] I can't see that happening. [05:02] * sinzui already as a 1400 line diff in review to remove a compatability shim [05:02] wgrant: Twisted has had issues with every release from 2.4 on. [05:02] sinzui: hasn't it been reviewed yet? [05:02] jml: no [05:02] jml: We didn't exist for 2.4->2.5, fortunately. [05:03] * jml fixinates. [05:03] sinzui: All that for just removing canonical.launchpad.webapp.testing? [05:03] Impressive. [05:03] I guess that means you have lots of tests. [05:04] wgrant: 3 deft find and replaces, 4 reversions, and 8 hand fixes in 30 minutes. no more canonical.launchpad.testing [05:04] sinzui: Pretty easy review, then. [05:05] very boring. I may have to provide coffee to who ever does it [05:05] sinzui: I confess here and now, I'm not doing a detailed line-by-line review. [05:06] * wgrant blames jml for any future breakage. [05:06] jml: the import UnitTest as LaunchpadUnitTest is a speed bump in the diff [05:07] I'm sure all eyes are on me at the moment. [05:09] Does anyone notice the big fat problem on edge? [05:09] [05:09] Someones made those tiny little icons repeat-x [05:10] my that is fun. A chorus line of me [05:10] ugh... [05:10] The icing probably hasn't updated yet. [05:10] if you force refresh, there is like... no styling at all [05:11] The icing updates in a minute or so, from experience. [05:11] Hmmm, still not fixed. [05:11] There we go. [05:11] * wgrant checks what's new. [05:11] wee [05:12] fixed [05:12] that was fun =D [05:12] I did manage to catch it =D [05:13] (that was the daily edge update, I presume) [05:16] are there any "eastern eggs" on launchpad? [05:16] apart from famous LP:1 [05:16] * xnox wants to fix bug 1 [05:16] https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout) [05:16] xnox: all the easter eggs are in the test [05:17] tests [05:35] wgrant: you presume correctly. to help avoid bigger issues, we accept a small window of server A is new and amazing, with server B being old and boring versions of edge. Which means you can get funnies. [05:38] spm: But is it intentional that the new icing takes a while to get there? [05:39] no. that's not cause and effect. you're getting part of new server, and part of old - end result is weirdness [05:39] do we include the revno in the icing url [05:39] Oh, I thought the icing would be served by the load balancer. [05:39] lifeless: You do. [05:40] So both could be present at once. [05:41] spm: so what we need to fix this, is for squid to only ask new servers for requests after a single server is upgraded [05:41] spm: or for old servers to have the new icing url [05:41] lifeless: of get the devs to improve the stop/start/working now time? :-P [05:41] s/of/or/ [05:41] spm: nah, the race is orthogonal to that; think of 0-downtime planning [05:42] I dunno. yah try for a troll, and he takes the question seriously.... /me sighs [05:42] Speaking of 0-downtime... is read-only-launchpad fixed yet? [05:43] wgrant: thats not really 0-downtime [05:44] lifeless: seriously tho - if we can make squid do that? that'd be great! just need to hook it into logic around edge1 potentially not restarting and remaining dead till human^Wlosa intervention. [05:44] lifeless: I know, but it's related enough that it reminded me of it. [05:45] spm: should be doable, number of ways [05:49] spm: safesty would be to down , upgrade, bring up disabled from squid, then tell squid repeat on the others, enable all. [05:49] spm: easiest way is simply to change the peer definitions [05:50] yeah makes sense. the logistics of making it so ... hmmmm. not so much not-doable, but.... [05:53] its three squid --reconfigure calls [06:54] wgrant: https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA#Deleting%20packages says it's a half-hourly cronjob [06:57] maxb: Aha, that would explain it. [06:57] maxb: But things seem to not be marked for removal immediately after deletion; I wonder if the publisher does that. [06:58] I assume the publisher has to republish the Packages/Sources files before the files become candidates for deletion [06:58] Ah, true. === herb__ is now known as herb [09:19] Hello I have an issue with an inactive translation team in launchpad, what can be done to ensure that it is possiblle to revive the team? [09:20] ianto: Have you tried to contact the team? [09:20] They were last active in 2007 so I'm guessing their email doesn't work anymore [09:21] s/2007/2006 [09:22] https://edge.launchpad.net/~ubuntu-l10n-cy/+members#active , people are trying to join but obviously no-one can accept them [09:23] It also means that I can't upload .po files because I am not on the team [09:24] ianto: I, too, have email addresses much older than 2006 so there is no reason to assume the admin cannot be contacted. [09:24] ianto: please try that first. [09:25] ianto: other than that you can talk to dpm about it. [09:25] OK... I've had at least 20 email addresses since ;06 and only check 2 now but I will email Daffydd too [09:26] ianto: really? why do you change them that often? I've had mine since 1996, I think. [09:27] henninge: Well more like 15 than 20, 20 was an over-estimate and because I like cool domain names :) [09:27] ;-) [09:52] mrevell: Thanks! [09:53] wgrant: You got it? Cool :) [09:53] mrevell: Yep. [09:54] good morning fellas [10:14] cprov: Under what conditions are binary uploads rejected because of a newer upload? Only if newer binaries exist, or also if the source is superseded/deleted? [10:15] wgrant: let me check, one sec [10:16] (I also notice that lots of binary uploads for the rebuild are failing, because they seem look for ancestry in the primary archive too) [10:16] wgrant: binaries conflict only with published files in the repo (no blacklisted versions) [10:17] wgrant: failed-to-upload in the rebuilds ? [10:17] cprov: Yes, lots of them. [10:17] Because there are newer binaries in primary. [10:17] (well, not *lots* yet) [10:17] http://people.ubuntuwire.com/~wgrant/rebuild-ftbfs-test/ [10:17] wgrant: the lookups should not leak to the primary archive. [10:18] cprov: Shall I file a bug, then? [10:19] wgrant: probably, wait a second [10:21] Copy archives also don't follow ogre-model, which makes them a bit misleading. [10:22] wgrant: that's a configuration bug, isn't it ? [10:23] cprov: I didn't think there was a configuration option for that, but I could well be wrong. [10:23] wgrant: +edit-dependencies should allow owners to say 'Follow primary archive components' [10:24] cprov: Oh, true. I forgot about that. [10:26] cjwatson: ^^ You might want to fix that, if you can. [10:29] wgrant: crap, binary uploads to copy archives do no reach the publishing tables ... we have to process them. [10:30] wgrant: I'm not sure I understand. What should I fix? [10:30] cprov: I did ask about that last night, but somebody seemed to think they'd be processed. [10:30] wgrant: was it me ? [10:30] it's a karmic rebuild test, surely it's correct for it to build against karmic [10:30] cjwatson: ogre-model isn't being respected in the rebuild; you need to tell it to use the right components. [10:31] cprov: No. [10:31] oh, gotcha [10:31] fixed [10:31] cjwatson: Thanks. [10:32] are there any build failures due to that? [10:32] by the way, the ubuntuwire ftbfs pages would be a lot more useful if they had links to the build page in LP for each architecture [10:33] (well, each arch that fails) [10:33] at the moment they link to the source, the sourcepackagerelease, and the build log [10:33] makes it awkward to do retries [10:34] cjwatson: They initially did show that, but it was decided to change them to point to the log instead. You can easily enough get to the build page with two clicks (one to get to the DSPR, and one in the builds portlet to the build) [10:34] But I can probably add an extra link in each cell, somewhere. [10:35] I believe that was my request, because I usually wanted to look at logs, and when it was just rebuild buttons, usually wanted to do it for several architectures (for which the sourcepackagerelease was a good landing location) [10:35] I might split the two parts of the text in each cell. [10:35] The arch to the build, the letter to the log? That sort of makes sense, although it's a bit odd... [10:36] Does anybody have any good ideas? [10:36] I'm not that worried about my usage, because I've not been giving FTBFS as much time as I'd prefer, so don't block just to support my previous request. [10:37] There were requests to link directly to the logs from others too. [10:37] And requests to link the build page. [10:37] wgrant: right, need a bug for binary upload ancestry lookup, it's looking up Primary archive. [10:38] cprov: Alright, will file. [10:38] wgrant: i.e, every source that is new in karmic will fail-to-upload. [10:38] Yep. [10:38] splitting build/log by arch/letter could work, but probably needs documentation on the page. [10:38] persia: Certainly. [10:39] cprov: Why weren't the binary uploads being processed? Are PPA/primary/partner processed by separate jobs? [10:39] wgrant: https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090513/+build/1002174 is a good example. [10:39] cprov: Yep, I've seen several of those. [10:39] wgrant: PPA & PRIMARY/PARTNER are separated [10:39] cprov: OK, interesting. [10:40] wgrant: that is less urgent than the lookup issue, but annoying for debug. [10:41] cprov: But they're all on cesium (or its successor?), as each set of buildds can be used for either? [10:42] wgrant: yes, the binary uploads are waiting in the copy-archive ACCEPTED queue, no worries, it will catch up when we CP. [10:42] wgrant: we only have 8 failed-to-upload builds (up to sources starting with 'c') [10:42] https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090513/+builds?build_text=&build_state=uploadfail [10:43] cprov: I know (I prefer http://people.ubuntuwire.com/~wgrant/rebuild-ftbfs-test/, although it has update latency), but they will get more frequent as the rebuild progresses. [10:44] cprov: Erm, al-maisan fixed the ancestry bug in 2.2.4. [10:44] Bug #369209 [10:44] Launchpad bug 369209 in soyuz "Rebuild archive: versions are erroneously checked against primary archive for binary uploads" [High,Fix released] https://launchpad.net/bugs/369209 [10:45] wgrant: apparently missed some bits ... [10:45] cprov: Reopen, or file again? [10:45] wgrant: re-open, I'd say [10:45] wgrant: it's exactly the same issue reported, right ? [10:46] cprov: There's no error message, and I don't know if there's something else it could have meant, but it certainly seems to be the same issue... [10:46] You'd best reopen it, I guess. [10:47] Bugs people: Why on earth are there three links to edit tags now? [10:47] wgrant: it's clear in the apport upload-processing log: apport_1.1.1-0ubuntu1_all.deb: Version older than that in the archive. 1.1.1-0ubuntu1 <= 1.1.1-0ubuntu2 [10:47] wgrant: that version only exist in karmic PRIMARY [10:48] wgrant: moreover, there are no binary publications in the COPY archive itself [10:48] wgrant: no ancestries should be found ... [10:49] wgrant: it's erroneously falling back to PRIMARY, although it's not clear why it's doing it by looking at the code. [10:49] cprov: One would think. But the fix for the bug might have been to have it check the COPY archive, which then decides to cascade to PRIMARY because it has none. I can't see the diff :P [10:50] wgrant: ehe, you are so funny, Jef! :) [10:52] wgrant: links directly to the logs are useful too. I don't have any bright UI ideas but I'm sure it would fit somewhere :-) [10:53] wgrant: on the bright side these failed-to-upload builds do not affect the rebuild results, after all a new source was uploaded to karmic and built. [10:53] cprov: jef does seem to have taken over from my previous role rather well! [10:54] But yes, the upload failures don't matter, as long as the bug gets fixed. [10:55] wgrant: no kidding, he comments every single blog post I read ... [10:55] Hmm. It occurs to me that IIUC, with the way scoring works, anyone who wants to retry a failed PPA build is out of luck until the rebuild finishes [10:56] yes, we need to fix that [10:56] maxb: I pointed something similar out last night, and cprov then pointed that particular case out. [10:56] Although nobody filed a bug. [10:56] Or was it bigjools. [10:56] I forget. [10:56] * maxb will file a bug in a bit if no one already has [10:56] (language packs also get ignored, as they are scored to 0) [10:57] maxb: thanks, meanwhile, bug me for rescoring your retries. [10:57] maxb: I don't think there is one, thanks [10:58] I don't have any at the moment, it was just a random thought passing through my head :-) [11:04] Can anyone think of any reason why retries shouldn't keep their original score? [11:05] maxb: I can't; I can almost as easily upload a new source if I want to DoS the buildds. [11:05] Actually, a new upload would go on the end of the queue - a retry at original score would go to the front of the queue (within packages of the same score) [11:06] maxb: yes, that source already had its build slot. It shouldn't be as easy as a 'click' to get in front of the build queue again. [11:06] hmm [11:06] I imagined it would be scored as normally, ie. without the time bonus initially. [11:07] Would going to the front of the queue actually be an issue? [11:07] If we have abusive people, yes. But there are better ways of dealing with them than punishing everybody. [11:07] I mean, you'd need a very stupid person indeed to sit there mashing retry repeatedly [11:07] maxb: for the other people, kinda yes. [11:07] I think we shou;ld probably be more trusting [11:07] Trust generally works well in Launchpad. [11:07] yes [11:07] People who abuse that trust just get booted out. [11:08] it makes more sense to keep the original score in PPA domain [11:08] exactly [11:08] Why not in the primary archive too? [11:09] maxb: otherwise main retries would dominate universe, for instance. [11:09] and that doesn't seem fair [11:09] I don't see a problem with that, really. [11:09] how many retries are done, typically? [11:10] Hmm, actually. [11:10] Shouldn't main retries be more important than universe anyway? [11:10] We do sometimes have mass-givebacks. [11:10] Which block the port buildds for several days. [11:10] Point [11:10] In PPAs it's fine, because there are dozens of buildds. [11:10] But most port archs only have two rather slow buildds. [11:10] So cprov is right. [11:11] Maybe it should be mass-giveback => 0, individual-giveback => original score? [11:11] That would be ideal. [11:11] And easy enough, I suspect - given that the mass-giveback script already has to retry them, it must be easy for it to rescore too. [11:12] * maxb needs to go now, but will summarize this conversation into a bug later [11:13] well, it's actually more complex than this, mass-retry are strictly done by buildd-admins and keep their original score, currently [11:13] because we do *trust* buildd-admins :) [11:14] cprov: But buildd admins can rescore even through the web UI. [11:14] the individual UI build retry (mostly done by uploaders) resets the score [11:14] wgrant: right [11:14] So the retry UI needs to set the score to the original value, and the script/SQL just has not reset the score, or set it to 0 [11:14] s/has not/has to not/ [11:15] wgrant: don't know if buildd-admins would agree with that change in the mass-retry [11:15] cprov: It wouldn't change the behaviour from the current one, would it? [11:15] Only the individual retry behaviour would be altered. [11:15] wgrant: the question here is to whether or not trust uploaders and keep the original score values for UI retries [11:16] UI == UI & API soon [11:16] cprov: You trust us to upload. You must trust us to retry with a normal score. [11:16] I don't have strong arguments for the current behavior, we can change it if it make everyone happier. [11:17] But none of this is actually necessary; you could just give retries a static score of more than 4. [11:18] ERRRR, missing cherrypick for the binary upload ancestry lookup issue [11:18] FFS! [11:18] cprov: Ahaha. [11:18] cprov: But... wasn't it on 2.2.4 db-devel, so wouldn't require a CP? [11:19] wgrant: we should have required the re-rollout on the builddmaster machine :-/ [11:19] cprov: I recall a similar problem occurred a couple of months ago... [11:19] You went looking for an issue, and found the builddmaster was out of date... [11:20] wgrant: last release, the email query ... we are getting good at it :( [11:20] cprov: Ah, yes. [11:21] * wgrant must remember to look at the dates of commits in future, as each Launchpad milestone is in fact multiple milestones! [11:23] wgrant: we do a re-roll after the main release to fix release issues [11:24] bigjools: I know, but forgot that stuff was still targetted to the previous release, not the next. [11:24] (really there should be a 2.2.4.1 milestone, but I guess that makes things overcomplicated) [11:24] no kidding :) [11:24] maybe a close-out date [11:26] Or just a point on the re-roll checklist to update the builddmaster, of course. [11:26] that'd be handy [11:58] Hi [11:58] How can i check which of my GPG keys my PPA is linked to, please ? [11:59] Also, if i want to change my GPG key for a PPA, do I have to sign the CoC again with the new key ? How to do so, if it's needed ? [12:00] SiDi: Check on the page for your user - any keys there have access to the PPA. [12:00] And no, your upload key doesn't have to have signed the CoC - any one key on your account will do. [12:03] Ah good to hear [12:03] so any active key will work for my PPA ? [12:03] Yes. [12:03] Ok, cheers [12:04] np === salgado-afk is now known as salgado === fta_ is now known as fta === salgado is now known as salgado-brb [13:01] when will bug 371640 land? [13:01] Launchpad bug 371640 in soyuz "Upload processing order is unstable" [Medium,Fix committed] https://launchpad.net/bugs/371640 [13:02] cprov, ^^ any idea? [13:02] fta: 2.2.5 [13:03] fta: 27th this month [13:03] fta: is it causing you extra trouble with the mozilla-daily PPA ? [13:05] i had to add a workaround, a 10 minutes delay between the upload of the orig and the rest, so it's slowing down my work [13:05] i guess 27th is fine === salgado-brb is now known as salgado [13:36] How do you compare different branches with bzr? [13:36] compare them how? [13:36] diff? [13:36] I get this: bzr: ERROR: Files are in different branches [13:36] ah [13:36] "bzr diff --old branch1 --new branch2 path" might be the trick [13:36] james_w: well, what I _really_ want is to compare a local branch to one at LP [13:38] james_w, the --new and --old addition works for my local branches! [13:38] ace [13:38] ... and the same is true if I substitute "lp:blahblah", so thanks! [13:38] should work for remote branches too [13:38] bingo! :-) [13:40] I think there's a proposal to make that case a bit easier to type as well [13:40] I just typed it without the --new and --old [13:40] ... and that doesn't work [13:40] i usually do `bzr diff -r branch:$BRANCH_URI ./` [13:43] james_w: on LP, can I retract a merge request? (It's and older one that turned out to be bogus) [13:43] james_w: it was already rejected but it remains on the list [13:43] mok0: I'm not sure sorry, I would have thought rejecting it would work [13:44] james_w: that would be the logical thing [13:44] the LP folks make much more use of merge proposals than me though, so maybe someone else has experience [13:44] You could delete them last time I tried. [13:44] or maybe they never have to reject a proposal :-) [13:44]