[00:02] <poolie> hi spiv
[00:02] <poolie> i'm going out for a bit at 11
[00:16] <bignose> I'm getting very confused over this ‘bzr-svn’ behaviour
[00:16] <bignose> Subversion repositories that worked fine last weekmonth, with the exact same versions of all packages, are breaking now
[00:17] <bignose> even after I delete the local repository of the bound branch, and re-create
[00:17] <bignose> is there some other cache of Subversion data that I need to delete in order to clear out “inconsistent details in skipped record: …” errors?
[00:22] <AuroraBorealis> can anyone help me with bzr explorer keeps freezing cause of a lock issue or something?
[00:26] <AuroraBorealis> but no one is ever here :<
[00:32] <poolie> AuroraBorealis, hi, what's up
[00:32] <AuroraBorealis> bzr keeps locking up and keeps saying it can't acquire lock: "unable to obtain lock file: c:\users\<username>\AppData\Roaming\bazaar\2.0\lock
[00:32] <AuroraBorealis> i keep deleting that folder but it keeps freezing bazaar and saying it :<
[00:33] <poolie> maybe you have two processes trying to change the configuration at once?
[00:33] <poolie> is there a traceback in .bzr.log?
[00:33] <AuroraBorealis> where would that log be
[00:33] <poolie> 'bzr version' will tell you
[00:34] <poolie> bignose, https://bugs.launchpad.net/bzr/+bug/418257
[00:34] <ubot5> Ubuntu bug 418257 in Bazaar "inconsistent details in skipped record" [Medium,Confirmed]
[00:34] <poolie> according to that bug it's just a spurious warning
[00:34] <poolie> is the command actually aborting?
[00:35] <bignose> the command doesn't fail
[00:35] <AuroraBorealis> http://pastebin.com/TdHRE2Lt
[00:35] <bignose> but its appearance is simultaneous with the merge failures I've been getting
[00:35] <bignose> s/merge failures/failures to commit merges/
[00:36] <lifeless> poolie: AuroraBorealis's path looks like a lock on the config directory
[00:36] <AuroraBorealis> yeah, but it keeps coming back even if i delete the lock/ folder
[00:37] <AuroraBorealis> and it isn't a branch so bzr break-lock doesn't work there either
[00:37] <lifeless> AuroraBorealis: this is -totally- a guess, but I suspect something (perhaps bzr-explorer) is trying to update your config too often, and deadlocking itself / your deletion
[00:37] <lifeless> gettting a backtrace like poolie suggests will help
[00:37] <AuroraBorealis> annnnd how do i fix this? its not doing this on any other computer
[00:37] <AuroraBorealis> how do i get a back trace?
[00:38] <lifeless> it will be in the log file
[00:38] <lifeless> bzr --version
[00:38] <lifeless> will show you the path of your log file
[00:38] <AuroraBorealis> that pastebin is from the log file, i dont see any stack traces
[00:40] <AuroraBorealis> http://pastebin.com/m05hWcdT that is all i get once i open bzr explorer from scratch and make it freeze again
[00:41] <poolie> bignose, well what is that failure?
[00:42] <lifeless> AuroraBorealis: ok; uhm I have to go for a bit; opefully someone here can help you further. It looks to me like a bzr bug; not sure why the lock is being lost, but I suspect its being taken out too often
[00:43] <AuroraBorealis> i'll keep an eye on it
[00:43] <AuroraBorealis> and keep deleting it for now :>
[00:48] <spiv> Hi poolie
[00:48] <mgz> OOPS-2014K7
[00:48] <mgz> second try loaded mp fine...
[00:49] <spiv> bignose: there's ~/.bazaar/svn-cache too
[00:49] <spiv> bignose: and of course the SVN repo itself is presumably changing, it's possible that it's something about the state of it now vs. 1 month ago that is triggering the problem
[00:51] <poolie> AuroraBorealis, it would be useful to find out if the process mentioned (like 6820 in this case) is still alive and if so what it's doing
[00:52] <AuroraBorealis> there is no process 6820 atm
[00:52] <AuroraBorealis> but i'll check it once it does it again
[00:55] <bignose> poolie: <URL:https://bugs.launchpad.net/bzr-svn/+bug/805343>
[00:55] <ubot5> Ubuntu bug 805343 in Bazaar Subversion Plugin "Crash w/ StopIteration" [Undecided,New]
[00:56] <bignose> spiv: I have no ‘~/.bazaar/svn-cache/’ directory
[00:59] <bignose> poolie: the sequence now is: create new Bazaar repo; ‘bzr branch --bind svn+ssh//benf@foo/bar/trunk/ trunk/’ → (several) “inconsistent details in skipped record: …”;
[01:01] <bignose> poolie: then merge also complains about inconsistencies; then attempting to commit in the Subversion bound branch complains it's not up-to-date.
[01:01] <bignose> even though ‘bzr update’ reports it *is* up-to-date.
[01:02] <bignose> since all of this came together (the “inconsistent details” message along with the subsequent failure to commit a merge) it seems likely they're related.
[01:04] <bignose> also with “KeyError: 'ben@benfinney.id.au-20110701055442-gb327dd7rxdgl61l'” trying to track differences in files
[01:04] <bignose> it's all difficult for me to untangle what problems
[01:04] <bignose> everyone says “no that's a separate problem” for each thing I report :-/
[01:04] <bignose> yet they all occur at once
[01:34] <spiv> mgz: apparently that OOPS was LP getting a 503 from the Librarian service (where the diffs are stored).  I guess it's a transient problem.
[01:36] <mgz> thanks spiv, I only got the one oops indeed.
[01:52] <thumper> is bzr-search documented anywhere nicely?
[01:55] <lifeless> I think there is a bit in one of the guides
[01:55] <thumper> ta
[01:55] <lifeless> or bzr help plugins/search
[02:06] <bignose> okay, Bazaar refuses to commit even locally-made changes in this Subversion bound branch.
[02:06] <bignose> so nothing to do with merge.
[02:06] <bignose> details in an email message to the list.
[03:07] <poolie> thumper, it has help
[03:15] <poolie> oh, this is the "i won't file a bug" bug
=== medberry is now known as med_out
[06:23] <bradm> hi, I'm having a weird error message from bzr
[06:23] <bradm> bzr: ERROR: Received bad protocol version marker: 'HTTP Error 404: NOT FOUND\n'
[06:23] <bradm> but I only get that from a dual stack ipv6 host, on ipv4 only host it's fine
[06:27] <spiv> Huh.
[06:27] <spiv> That's a funny string.
[06:28] <bradm> oddly I still get that if I do a ip addr flush on ipv6 addresses
[06:28] <spiv> I'd suspect there's something weird happening on the host, but I cannot guess what
[06:29] <spiv> That's not a valid HTTP response, and there's not really any reason why HTTP should be involved, so it's pretty mysterious
[06:29] <bradm> let me try on my desktop instead of laptop and see
[06:30] <bradm> my laptop's a pretty up to date natty install
[06:32] <spiv> Which protocol are you trying?  bzr:// ?
[06:33] <bradm> bzr branch lp:~harvest-dev/harvest/production
[06:33] <spiv> Oh, hmm, if you're trying http://foo/bar, then it's probably a that the remote httpd isn't giving proper 404 responses to bzr's attempt to POST to /bar/.bzr/smart
[06:34] <bradm> woah, desktop's response is even weird
[06:34] <bradm> er
[06:34] <bradm> bzr: ERROR: http://bazaar.launchpad.net/%2Bbranch-id/77880/.bzr/repository/indices/87baa8aa154c5e4a84187e7161d073f0.six is redirected to https://launchpad.net
[06:34] <spiv> What does 'bzr lp-login --no-check' report?
[06:34] <bradm> that works, gives my lp username
[06:35] <spiv> Ok, that latter response is probably unrelated, it's a transient issue so probably retrying will work ok
[06:35] <spiv> Huh, so you're logged into lp it'll be using bzr+ssh.  Then that response is even weirder!
[06:36] <spiv> What happens if you try "bzr+ssh://bazaar.launchpad.net/+branch/" instead of "lp:" ?
[06:37] <bradm> same thing
[06:37] <spiv> Hmm
[06:37] <spiv> So bazaar.launchpad.net doesn't have an ipv6 address
[06:37] <bradm> but oddly my desktop (which isn't logged into LP) is pulling down data ok it seems
[06:37] <bradm> no, we haven't done ipv6 anywhere yet
[06:38] <spiv> Ok, ipv6 is probably a red herring
[06:38] <spiv> More likely to be a screwy SOCKS proxy or something
[06:38] <spiv> Or something weird in your ~/.ssh/config?
[06:38] <spiv> (assuming you are using OpenSSH as your SSH client)
[06:38] <bradm> oh here we go
[06:39] <bradm> I might have to blame Ng for this
[06:39] <spiv> What happens if you try 'ssh -l YOUR_LAUNCHPAD_USERNAME bazaar.launchpad.net' ?
[06:41] <bradm> that connects fine, says no shells on this server
[06:41] <bradm> might have something here in my ssh config
[06:42] <bradm> yup, that fixed it, we were testing some stuff with LocalCommands to pull some data about hosts
[06:43] <bradm> and funnily enough, that string is what the local command returned when the host wasn't in the db
[06:44] <spiv> Hah.
[06:45] <bradm> thanks for the help in finding that
[06:46] <bradm> I should have thought what else had changed in the past day or so
[06:46] <poolie> bradm i saw a redirect error like that before
[06:46] <poolie> i wonder if it's weird handling of pack files not found
[06:47] <bradm> poolie: maybe - retrying it worked fine on my desktop now
[06:47] <bradm> and fixing the LocalCommand to redirect stderr to /dev/null fixes my laptop too
[06:48] <poolie> istr someone filed a bug about it recently
[06:49] <spiv> poolie: oh right, it might be that.  I was assuming it was a transient outage in the external-to-internal URL mapper
[06:55] <poolie> i can't find the bug i was thinking of
[06:55] <poolie> but it was also a pack file redirecting to some unlilkely location
[07:46] <Riddell> good morning
[07:57] <vila> Riddell: morning
[08:08] <alf_> Hi! Is there a way to tell bzr which gpg identity to use for signing commits?
[08:10] <Riddell> alf_: bzr sign-my-commits . "Amy Pond <amy@example.com>"
[08:11] <Riddell> although it seems not for the create_signatures config option or the re-sign command for individual commits
[08:11] <Riddell> that should be fixed, please file bugs :)
[08:13] <alf_> Riddell: Sorry, I wasn't exact enough... In my case I have two gpg identities/users "alf1@foo.bar" and "alf2@foo.bar". My commits are made using alf2@foo.bar email but when trying to sign, I am prompted for the password of alf1.
[08:14] <quotemstr> Can I cherry-pick hunks from a single file?
[08:17] <alf_> quotemstr: cherry-pick and apply them to another branch?
[08:26] <Riddell> alf_: that's not currently possible, if you file a bug then I'll implement it
[08:27] <alf_> Riddell: so, bzr always signs using the default/first GPG identity?
[08:27] <Riddell> alf_: yes
[08:27] <alf_> Riddell: I will file a bug, thanks!
[08:32] <alf_> Riddell: There seems to be an existing bug about this: lp #68501
[08:32] <ubot5> Launchpad bug 68501 in Bazaar "bzr should have an option for defining which gpg key to use for signing" [Wishlist,Confirmed] https://launchpad.net/bugs/68501
[08:32] <alf_> Riddell: I will add a comment there
=== hunger_ is now known as hunger
[08:48] <bialix> Riddell: hello
[08:48] <Riddell> hi bialix
[08:49] <bialix> can we talk about https://bugs.launchpad.net/bzr-explorer/+bug/805813 ?
[08:49] <ubot5> Ubuntu bug 805813 in Bazaar Explorer "explorer 1.2 (trunk) does not work with bzr 2.3.3" [Critical,Confirmed]
[08:49] <bialix> Riddell: ^
[08:50] <Riddell> hmm, breakage from qverify-signatures?
[08:51] <Riddell> no, that's qbzr
[08:51] <bialix> no, explorer: 516: Jonathan Riddell 2011-06-16 [merge] refresh automatically branch views on changes
[08:52] <bialix> I have no idea why it failed with 2.3, but if we can fix it to work with 2.3, it will be great
[08:52] <bialix> otherwise we have to force bzr version check in explorer
[08:53] <bialix> and update docs
[08:53] <Riddell> hmm, I can't recreate the problem using 2.3.1
[08:54] <bialix> it failed for me everytime with 2.3.3 on Windows
[08:55] <bialix> that's could be PyQt-specific
[08:56] <bialix> hmm, I have PyQt 4.5.2, Qt 4.5.2 packaged into windows installer
[08:56] <Riddell> ok I'll reboot into windows and try
[09:00] <bialix> jam1: HI
[09:00] <jam1> hi
[09:01] <bialix> jam1: do you by any chance know is there any plans to update PyQt libraries on windows installer build machine?
[09:03] <bialix> I'm not sure but I thought at some point there was discussion about upgrading it. Currently installer has Qt 4.5.2
[09:04] <bialix> Riddelll: I suspect it's related to PyQt version
[09:04] <vila> jam1: hey !
[09:05] <bialix> hello vila
=== jam1 is now known as jam
[09:05] <vila> bialix: _o/
[09:06] <jam> I don't have any plans, but if we need to we can
[09:07] <bialix> Riddelll: ping
[09:11] <bialix> Riddelll: we either should fix this bug or beg jam to update PyQt on build machine. Fixing a bug is better, although updating PyQt is also good.
[09:13] <bialix> jam: I think it will be nice to update PyQt for next 2.4 beta
[09:15] <bialix> I think Gary has used more fresher PyQt version on his build machine. I'm not sure though
[09:16] <Riddelll> bialix: how do I do the equivalent of export BZR_PLUGINS_AT= on windows?
[09:16] <bialix> set BZR_PLUGINS_AT=xxx from command line, or use system properties
[09:16] <bialix> set works for current shell
[09:21] <Riddelll> bialix: how do I find out what version of pyqt I have installed?
[09:22] <bialix> start explorer -> help -> about
[09:23] <Riddelll> bialix: PyQt 4.8.2 from standalone bzr windows installer, I can't recreate the problem
[09:24] <Riddelll> what PyQt do you have?
[09:24] <bialix> I see 4.5.2... wait
[09:24] <bialix> problem with paths?
[09:25] <Riddelll> bialix: what do you mean with paths?
[09:25] <bialix> I have PyQt for Python in my PATH
[09:25] <bialix> wait a sec, I will edit my PATH
[09:27] <bialix> hmm, still 4.5.2
[09:28] <Riddelll> bialix: did you install pyqt yourself or from the bzr standalone installer?
[09:28] <bialix> standalone installer
[09:28] <bialix> I don't have 4.5.2 installed on my computer
[09:28] <bialix> so that should be from installer
[09:28] <bialix> how can we have different pyqt versions from the same installer?
[09:29] <Riddelll> spooky
[09:29] <bialix> Riddelll: can you check your PATH?
[09:29] <Riddelll> bialix: how?
[09:30] <Riddelll> (I'm afraid I know very little about Windows)
[09:30] <bialix> type "path" in command prompt
[09:31] <Riddelll> http://paste.kde.org/92659/
[09:31] <bialix> ok
[09:33] <Riddelll> this is the PyQt files I think it's using http://paste.kde.org/92671/
[09:36] <bialix> Riddelll: I still can't find where my system can load 4.5.2
[09:36] <bialix> I'm trying on another machine now
[09:38] <bialix> Riddelll: what's your bzr version on windows?
[09:39] <Riddelll> 2.3.1
[09:39] <bialix> I have 2.3.1 installed on another machine, it has PyQt 4.8 as your
[09:39] <bialix> I suspect that was build by garyvdm
[09:40] <bialix> 2.3.3 and 2.4 was build on different machine, that can explain why they have another pyqt
[09:40] <bialix> Riddelll: could you install latest 2.4b4, please?
[09:40] <Riddelll> ok
[09:44] <Riddelll> bialix: that gives me PyQt 4.5.2
[09:44] <Riddelll> but I still can't recreate the problem when using bzr explorer from trunk
[09:45] <sagaci> hi, just wondering if there's a similar option to wget -c when branching
[09:45] <bialix> Riddelll: have you tried to open some branch?
[09:45] <Riddelll> bialix: boom
[09:46] <bialix> Riddelll: the problem occurs only on opening the actual branch, Welcome screen has no problem
[09:46] <Riddelll> "TypeError: WorkingTreeView cannot be converted to PyQt4.QtCore.QObject in this context"
[09:46] <bialix> yep
[09:46] <Riddelll> very strange, WorkingTreeView should be a widget which should be QObject happy
[09:46] <Riddelll> bialix: what's a decent editor to use on windows?
[09:47] <bialix> well.... notepad++?
[09:48] <bialix> I'm using FAR + FTE, but this is kinda vintage
[09:49] <bialix> Riddelll: something Qt-based, maube, like Qt Creator?
[09:51] <Riddelll> actually I remember I have KDE installed here so I can use Kate
[09:51] <Riddelll> but I think I would need to work out how to do windows development first, there's no source files with this standalone install
[09:51] <bialix> bzr branch lp:bzr-explorer explorer?
[10:01] <jam> bialix: I have 4.5.2 from the bzr installer
[10:02] <jam> That said, we had problems the last time we upgraded PyQT. I think that was the 4.7 series.
[10:02] <jam> If you're happy with the 4.8 stuff, I'm happy to upgrade.
[10:05] <Riddelll> jam: the current version on the installer on bazaar.canonical,.com is 4.8 so going back to an older PyQt for newer bzr versions seems strange and error prone
[10:07] <bialix> Riddelll: I think bazaar.canonical.com wasn't updated, it's a wiki
[10:08] <Riddelll> right enough, but if bzr 2.3.1 ships with pyqt 4.8 then shipping bzr 2.3.3 with pyqt 4.5 is strange
[10:09] <bialix> jam: Riddelll that's because 2 different build machines are involved here
[10:09] <Riddelll> right
[10:10] <bialix> jam: I think upgrading to 4.8 on ec2(?) will be good
[10:10] <bialix> I think Riddelll is agree
[10:11] <bialix> wiki page is out of date :-/
[10:12]  * bialix edits it now
[10:17] <Riddelll> I see my problem, I did a Qt signal connect() into WorkingTreeView which is an "object" not a "QObject" and that's not allowed in older PyQts
[10:17] <bialix> oh
[10:21] <Riddelll> bialix: this will fix it http://paste.kde.org/92719/
[10:23] <bialix> yes, please land the fix
[10:23] <Riddelll> groovy, I'll switch back to a real operating system to do that :)
[10:23] <bialix> :-)
=== mrevell is now known as mrevell-lunch
[12:47] <CaMason> can I somehow search the log for when a particular line of code was introduced?
[12:49] <deni> hi guys
[12:49] <sagaci> hi
[12:49] <deni> can anyone tell how to checkout a repo from the server but only the repo...not the working tree
[12:49] <deni> so that i can then make a branch out of that local repo and work in that
[12:50] <vila> jam: thanks for the heads-up for the news entry, two wrongs can sometime makes a right ;)
[12:51] <james_w> deni, bzr init-repo --no-trees foo; cd foo; bzr branch <wherever> target; cd ..; bzr branch foo/target target
[12:51] <james_w> that will give a copy of only the branch in foo, and a branch and working tree in "target"
[12:52] <james_w> CaMason, bzr annotate is a good starting point. If you have bzr-gtk then gannotate has a back button that is very useful. There's also "bzr log -p" that can help
[12:52] <vila> CaMason: annotate will give a more precise answer (most of the time)
[12:52] <CaMason> thanks I'll give that a go
[12:52] <vila> CaMason: qannotate from the qbzr plugin is an alternative too
[12:53] <CaMason> aha, ideal
[12:53] <CaMason> if only it had a search function ¬_¬
[12:54] <vila> qannotate *has* a search function
[12:54] <CaMason> where?
[12:54] <vila> gannotate used to have one too but I didn't use it for a long time
[12:54] <vila> ctrl-F
[12:54] <CaMason> oh qannotate
[12:54] <vila> unless you use an old version
[12:55] <CaMason> yeah trying ctrl+f, no dice
[12:55] <vila> where ?
[12:55] <CaMason> in qannotate.. click on code area, ctrl+f - nada
[12:55] <vila> ha, old version then
[12:55] <CaMason> :)
[12:55] <vila> but gblame has ! :D
[12:56] <CaMason> its ok, I grepped with normal annotate and found the issue - thanks
[12:56] <deni> james_w: tnx....i knew it had something to do with no-trees but i just didn't user it right obviously
[12:57] <sagaci> just did a bzr branch lp:ubuntu/oneiric/ubuntu-docs, it's up to 220MiB, any idea how big this thing will be?
[12:58] <vila> sagaci: hmm, wasn't lp:ubuntu-docs 2M only ?
[13:02] <sagaci> vila, but this is bzr branch lp:ubuntu/oneiric/ubuntu-docs
[13:03] <vila> yup, I noticed, I'm wondering why there is such a huge difference though
[13:04] <sagaci> yeah, up to 280MiB now :S
[13:04] <vila> hmm, you've got a fat pipe :)
[13:05] <sagaci> any reasoning?
[13:05] <vila> without seeing the content of the branch, no idea (could be some binaries wrongly committed in the history or something)
[13:06] <sagaci> :/
[13:06] <jam> vila, sagaci: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntu-docs/oneiric/.bzr/repository/packs/
[13:06] <jam> Has a 320MB pack file in there
[13:07] <vila> including tarballs or pictures or whatever
[13:07] <jam> I don't know *why*, everything else is a lot smaller.
[13:07] <jam> But that one is from Aug-4-2009
[13:07] <jam> so it isn't particularly new.
[13:07] <sagaci> oh, so nearly finished
[13:07] <sagaci> so when I push a small change, do I have to push the whole 320 or just the small diff?
[13:08] <vila> sagaci: finished here at 512.572  Transferred: 423293kB (826.0kB/s r:423286kB w:7kB)
[13:08] <sagaci> sorry, wouldn't have a clue how bzr works
[13:08] <vila> vila:~/src/ubuntu-docs :) $ du -sk .
[13:08] <vila> 176984	.
[13:08] <vila> vila:~/src/ubuntu-docs :) $ du -sk .bzr
[13:08] <vila> 135056	.bzr
[13:08] <vila> vila:~/src/ubuntu-docs :) $
[13:09] <sagaci> yep
[13:10] <vila> sagaci: may be worth filing a bug (but I'm pretty sure there is some related existing one), adding your case as a comment will help
[13:10] <vila> bah, bad parentheses: sagaci: make sure your case is documented in a related bug or a new one
[13:12] <jam> sagaci: we repack during fetch, I'm not sure why the LP version is so bloated.
[13:13] <jam> are you using http vs bzr+ssh?
[13:13] <jam> (The files on disk on Launchpad are about 400MB, so that is very comparable to what it transferred to you.)
[13:13] <jam> if you have access, you could "bzr pack lp:..." though that will be slow and download another 400MB and upload 200MB :)
[13:48] <vila> AAARGH, I'm cursed :(
[13:52] <sagaci> :s
[13:52] <vila> no matter how many times I run the tests locally it appears that I always have some pqm failures when freezing a release :(
[14:04] <SafPlusPlus> Hi guy, do you mind a noob question?
[14:05] <SafPlusPlus> I want to pull the changes from a remote repository, but not apply them yet, but I can't figure out if that's possible. Any insights?
[14:07] <vila> SafPlusPlus: pull them in a different branch
[14:08] <SafPlusPlus> vila: That sounds like an interesting aproach, I'll tinker with that, thanks!
=== isxek is now known as acl_
[14:54] <vila> puzzling, blackbox.test_branch.TestBranch.test_branch_broken_pack can (and did) fail ramdonly with even a  failed to open trace file: [Errno 13] Permission denied: '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file' ....
[15:06] <RainCT> Hi
[15:07] <RainCT> Quick question, how can I delete a tag that's already been pushed to the server? (When using "bzr tag --delete foo; bzr push;" after the next "bzr pull" it's there again)
[15:07] <vila> bzr tad --delete server:foo
[15:07] <vila> gha
[15:07] <vila> bzr tag --delete server:foo
[15:07] <vila> that is: delete the tag on the server, tag deletions don't propagate, known bug
[15:08] <vila> bug #138802, you can subscribe to it and mention that you're affected
[15:08] <ubot5> Launchpad bug 138802 in Bazaar "tag deletion does not propagate" [Medium,Confirmed] https://launchpad.net/bugs/138802
[15:09] <vila> RainCT: ^
[15:12] <RainCT> vila: Thanks. "bzr tag --delete server:foo" doesn't work though ("No such tag: foo").
[15:13] <vila> well, by server:foo I meant whatever url you want to push too
[15:13] <vila> bzr config (or bzr info for older versions) will tell you which url it is
[15:14] <maxb> Shouldn't it be 'bzr tag --delete -d :parent tagname' ?
[15:14] <vila> RainCT: but be aware that other users or the server branch will also have to delete this tag
[15:14] <vila> ha right, maxb is probably right RainCT ^
[15:18] <RainCT> Yup, with -d it worked. Thanks
[15:20] <vila> jam: ping
[15:21] <vila> I need a teddy bear about creating a 2.4 pqm branch and when we want to do that (to avoid blocking trunk from landing API changes)
[15:22] <vila> ha, past EOD for jam I suspect, will mail the list
[15:36] <Riddell> alf_: how's this? https://code.launchpad.net/~jr/bzr/68501-gpg-signing-key/+merge/67210
[15:41] <alf_> Riddell: Looks great, thanks! Another thing that coulb be useful perhaps, is also considering the id passed to bzr sign-my-commits for the key to use. eg bzr sign-my-commits . bla@bla.org, should try to use a bla@bla.org key.
[15:42] <alf_> Riddell: but in any case with your changes there is a way to handle this (changing signing_key temporarily), so thanks! :)
[15:43] <Riddell> I did consider adding a command line option to sign-my-commits and re-sign but I'm not sure how often you want to change your signing key, normally I expect people will only ever use one, or occationally use a different one for a different branch which can be set in config
[15:46] <alf_> Riddell: yes, that makes sense
[15:47] <alf_> Riddell: can signing_key be set in locations.conf?
[15:47] <Riddell> alf_: yes
[15:47] <alf_> Riddell: great :)
[16:40] <vila> Riddell: no time for a real review but:
[16:40] <vila> 1) use get_user_option so you don't have to define special methods ( we are getting away from them)
[16:40] <vila> 2) use gpg.signing_key instead of just signing_key
[16:41] <vila> 3) at some point we'll gain a command-line switch to override config options, don't bother for now
=== deryck is now known as deryck[lunch]
=== beuno is now known as beuno-lunch
=== deryck[lunch] is now known as deryck
=== beuno-lunch is now known as beuno
=== yofel_ is now known as yofel
=== med_out is now known as medberry
[20:29] <tsdh> Hi
[20:29] <tsdh> How can I bring back a file I've accidentally deleted?
[20:32] <lifeless> was it previously committed?
[20:32] <tsdh> Yes.
[20:32] <lifeless> bzr revert filename
[20:38] <tsdh> Thanks.
[22:08] <jimis> is bzr-2.4.0 already broken on python2.4?
[22:08] <jimis> or it's the plan to break compatibility?
[22:09] <jimis> Because I need to install it on RHEL5
[22:17] <mgz> it's already broken.
[22:19] <jimis> I just found out :-o
[22:20] <jimis> I wish they broke it after 2.4, RHEL5 is just way too common
[22:21] <jimis> anyway I'll try 2.3, but I remember seeing some fixes lowering CPU/network usage that I needed them, hopefully they are on 2.3
[22:21] <mgz> a subset of them got backported.
[22:22] <jimis> ok, thanks mgz
[22:23] <jimis> hopefully it will be good enough for huge packages, I'll try branching lp:gcc :-)
[22:25] <poolie> hi mgz, all
[22:27] <mgz> hey poolie!
[22:41] <jimis> how can I list all branches of lp:project from the command line?
[22:43] <maxb> You'd need a small launchpadlib script, or screenscraping
[22:44] <jimis> hmm didn't think it was that hard, I was just curious how to get the same info I get from the website
[22:45] <maxb> for b in lp.projects['bzr'].getBranches(status=("Development", "Experimental", "Mature", "Merged", "Abandoned")): print b.unique_name
[22:46] <maxb> Hmm, there are a lot of those, perhaps I should have picked a smaller project :-)
[22:46] <jimis> thanks :-)
[22:46] <jimis> maybe it should be a command
[22:46] <jimis> for example "bzr info lp:bzr"
[22:47] <jimis> or list
[22:47] <jimis> or anything :-p
[23:13] <jimis> 1025MB VSZ, 850MB RES and counting... :-)
[23:46] <jimis> when branching over http, is it expected to download a lot times more data than lp:project?
[23:48] <dOxxx> it's possible that it's having to repack revision data, which over HTTP is a very expensive operation.
[23:49] <dOxxx> using lp: the server is able to do the repacking
[23:49] <lifeless> dOxxx: I think you are thinking of push :)
[23:49] <lifeless> jimis: yes, its expected
[23:50] <lifeless> jimis: over http it has to read the raw files and discard unneeded data, over lp: it streams just the needed data.
[23:51] <jimis> but behind firewall I guess it's the only choice
[23:52] <jimis> anyway I hope it reads all data only once :-)
[23:53] <spiv> Usually yes, although sometimes we've had bugs (I think 'bzr branch --stacked' may currently have a bug along those lines)
[23:55] <jimis> nice, it seems it entered the "Done" phase :-)
[23:56] <jimis> spiv: I was aware of the bugs, that's why I needed 2.4. But they seem fixed on 2.3.3 as well
[23:56] <jimis> otherwise it would fetch GBs of data