[00:00] <lifeless> well, the normal thing is just to commit at this point
[00:00] <lifeless> this happens if someone else committed to the remote location and you needed to update to be able to commit
[00:01] <workthrick> lifeless: yes, I know, but only I use that branch
[00:01] <lifeless> anyhow, if you grab the revid of the pending merge
[00:01] <lifeless> and do
[00:02] <lifeless> bzr revert; bzr pull . -r revid:<,...>
[00:02] <lifeless> that will reset onto that revid
[00:03] <workthrick> lifeless: aha, and how do I grab the revid of it?
[00:03] <lifeless> bzr st --show-ids
[00:05] <workthrick> hmm, not seeing it
[00:05] <workthrick> pending merge tips: (use -v to see all merge revisions)
[00:05] <workthrick>   Maciej Katafiasz 2011-06-13 Add initial lipid DB files from Christer
[00:05] <workthrick> it shows me the file IDs, but not revids
[00:05] <lifeless> garh
[00:05] <lifeless> uhm
[00:05] <lifeless> bzr heads --dead
[00:05] <lifeless> should show it; thats in bzrtools I think
[00:10] <workthrick> yup
[00:10] <workthrick> lifeless: that worked fine, thanks
[00:11] <lifeless> cool
[00:12]  * workthrick packs up and migrates home
[03:42] <george_e> Quick question... I have installed Bazaar 2.3.1 on a Windows server and I have created a branch with one file in it...
[03:42] <george_e> How can I push / pull to that branch?
[05:59] <gour> i see that LP cannot grok (aka import) bitbucket hg branches...what is your experience with hg <--> bzr ?
[06:04] <spiv> gour: talk to jelmer
[06:12] <lifeless> gour: we should handle bitbucket branches fine
[08:25] <vila> jelmer_: Did I mention loom test failing with: TypeError: push() got an unexpected keyword argument 'lossy' ? Or did you already fix that and Alzheimer is striking again ?
[08:50] <Riddell> good morning
[08:53] <vila> _o/
[08:54] <fullermd> Morning?  Pah.  What'd morning ever do for me?
[09:02] <vila> fullermd: bring coffee ? Good thing that
[09:19] <fullermd> Morning doesn't bring coffee.  I have to keep it at hand myself, as a weapon for when the morning ambushes me.
[09:25] <gour> spiv: when is jelmer around?
[09:26] <gour> lifeless: all the branches i wanted to import from bitbucket were suspended (or not mirror any longer) due to 5 failures
[09:27] <gour> although i can hg pull without any problem
[09:27] <Peng> fullermd: Morning brings a beautiful, fresh feeling to the world.
[09:27] <Peng> fullermd: Also a bunch of noise from your neighbors.
[09:32] <Riddell> asking again, what's going wrong with me using requeue_package? http://paste.kde.org/81493/
[09:35] <lifeless> gour: IIRC bitbucket expose broken urls, or is that gitorious
[09:36] <vila> Riddell: You need to prepend PYTHON_PATH=python_debian/ and of course be in the 'scripts' dire
[09:36] <vila> ctory
[09:37] <Riddell> ah, but of course
[09:37] <vila> Riddell: <cough> did I forget to explain that ?
[09:38] <vila> Riddell: <cough> it helps to look at the bash hostory
[09:38] <vila> history
[09:38] <fullermd> Peng: Obviously, it brings you far better drugs than me   :p
[09:39] <Riddell> documentation though bash history, the best way
[09:39] <vila> Objection your honor !
[09:40] <vila> It's archeology ! Nothing to do with documentation ! I requires removing such remarks from the log !
[09:40] <vila> This is an obvious trick to influence the jury !
[09:50] <gour> lifeless: hmmm...but initial import was done...problem was with incremental imports
[09:53] <lifeless> stub: ok
[09:53] <lifeless> bah
[09:53] <lifeless> gour: ok; well have a look at the bzr-hg bug reports
[09:53] <lifeless> or the wiki page tracking conversion support
[09:56] <gour> where could i find them?
[10:01] <gour> here is the branch: https://code.launchpad.net/~gour/myclientbase/trunk
[11:45] <Riddell> there doesn't see to be any documentation on gpg signing, would it be an idea if I updated http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ and added it to the user guide?
[11:45] <jelmer_> Riddell: the problem is that we also don't really have a good way to verify GPG signatures yet at this point
[11:46] <Riddell> jelmer_: yes, is there a reason for that?  nobody bothered to learn gpgme?
[11:47] <jelmer_> Riddell: I'm not sure of the background - I think part of it is just that nobody got around to it, and we need to watch out for performance issues if we start automatically verifying everything.
[11:47] <vila> jelmer_: Did I mention loom test failing with: TypeError: push() got an unexpected keyword argument 'lossy' ? Or did you already fix that and Alzheimer is striking again ?
[11:48] <jelmer_> vila: hi; I think you did, though I can't reproduce it here
[11:48] <jelmer_> vila: which test ?
[11:48] <vila> letmecheck
[11:49] <jelmer_> Riddell: I think jam knows more of the details
[11:50] <vila> jelmer_: per_branch.test_push.TestLossyPush.test_lossy_push_raises_same_vcs(BzrBranchLoomFormat1)
[11:50] <Riddell> yes, I see he did a basic verification plugin back in the day which seems to have disappeared
[11:52] <vila> ./bzr selftest -s bt.per_branch.test_push.TestLossyPush -> ran 13 tests/ 4 errors
[11:55] <jelmer_> vila, thanks
[11:55] <jelmer_> vila, I was just running the plugin tests and not finding anything :)
[11:55] <jelmer_> vila: hmm, we really need an InterLoomBranch..
[11:56] <vila> ha right, getting all the relevant tests for a given plugin may be tricky
[11:56] <vila> jelmer_: may be, but you can also push/pull between looms and regular branches
[12:46] <Riddell> the config options for gpg signatures are strange, create_signatures always is used but I don't think when-required or never is (and can branches require signatures?)
[12:46] <Riddell> I don't think check_signatures is used at all except that weirdly require turned on create_signatures always
[12:54] <Riddell> is http://wiki.bazaar.canonical.com/ConfiguringBzr the current documentation for config options?
[12:55] <Kamping_Kaiser> hi all, i just tried to  commit the deltion of some files (-x 'd two modified files), and bzr told me an empty commit was pointless http://paste.debian.net/119678/ . does this look like a bug or a feature you you? (wondering if i should go looking for a bug report)
[12:59] <jelmer_> Riddell, that sounds about right
[12:59] <jelmer_> Riddell, I use "create_signatures = always" myself for that special day in the future when we start being able to actually verify them
[13:00] <jelmer_> Kamping_Kaiser, what happens if you run "bzr rm" first?
[13:03] <maxb> I have a mega bug of udd tag moves for someone to process this week :-) https://bugs.launchpad.net/udd/+bug/795703
[13:05] <Kamping_Kaiser> jelmer_: if i run bzr rm on the tree as is  it gives the same error. shall i try restoring the files then bzr rming them?
[13:08] <jelmer_> Kamping_Kaiser: It should at least give a slightly different error (removed vs missing)
[13:10] <Kamping_Kaiser> jelmer_: http://paste.debian.net/119679/ this is what i get folling on from the last paste. have  i missunderstood your suggestion?
[13:11] <jelmer_> Kamping_Kaiser, that's odd indeed, please file a bug
[13:12] <Kamping_Kaiser> jelmer_: should i include the contents of those pastes?
[13:12] <Kamping_Kaiser> and is there anything else that would be handy? (repo state, etc)
[13:13] <jelmer_> Kamping_Kaiser: I'm not sure; given I've never seen this and I never use -x I would be inclined to blame -x
[13:14] <Kamping_Kaiser> ok. i'll tar it up and hang onto it for a few weeks incase its requested
[13:14] <jelmer> Kamping_Kaiser, thanks :)
[13:14] <Kamping_Kaiser> np :)
[13:18] <Kamping_Kaiser> jelmer: submitted as https://bugs.launchpad.net/bzr/+bug/796582, hopefully its lucid enough to be understood
[13:19] <Kamping_Kaiser> and i just realised i didn't specify my version or os, *fail*
[13:25] <Kamping_Kaiser> 'night all
[13:26] <jelmer> g'night Kamping_Kaiser
[13:30] <jelmer> Riddell: Sorry, was distracted there for a bit
[13:31] <jelmer> Riddell: I guess any more support for verifying signatures, even just some API functionality that might not be hooked up in the UI yet, would be a step forward.
[13:31] <jelmer> bzr-gtk does verification at the moment, but has implemented it manually. That sort of code really should be in the core.
[13:41] <Riddell> jelmer: should I update http://wiki.bazaar.canonical.com/ConfiguringBzr to match current reality?
[13:47] <jelmer> Riddell, please do
[13:47] <jelmer> Riddell, although I also wonder how well maintained that page still is at the moment compared to the docs in the tree
[13:48] <Riddell> ah, it's user-reference/configuration-help.txt
[13:49] <Riddell> maybe I should make that match reality and make the wiki page point to that
[13:56] <jelmer> Riddell: wfm
[13:57] <jelmer> Perhaps we should set up a wikkid instance backed onto a copy of lp:bzr so users can still easily contribute fixes
[14:39] <Riddell> jelmer: is that possible?
[14:39] <Riddell> much of what was once on the bazaar wiki seems to have been moved to the docs
[14:41] <jelmer> Riddell: I think it should be, though we might have to wait for wikkid to get openid support. ad it will require some setup of course
[14:41] <jelmer> like the Ubuntu wiki much of what's on our wiki is outdated, the docs are much nicer and have been better reviewed.. but the wiki is the only thing users can easily contribute to
[14:42] <gour> jelmer: jello, attempt to mirror some bitbucket branches gives "The import has been suspended because it failed 5 or more times in succession. " where could i find some log or are there some known issues with bitbucket import?
[14:43] <jelmer> gour, the log should be linked from the import page
[14:44] <jelmer> you might have to delete the import and create it again if the import existed before the last launchpad deployment a couple of days ago
[14:44] <gour> jelmer: i do not find it...here is the branch https://code.launchpad.net/~gour/myclientbase/trunk
[14:45] <abentley> vila: I've restored the original test_merge_from_branch tests and just forced the root-id.
[14:45] <abentley> vila: The one outstanding issue I know is you and jam disagreeing about how to handle tests that prove an exception isn't raised.
[14:45] <jelmer> gour, the "see the log" link
[14:47] <gour> ahh...i thought those were some other logs
[14:48] <gour> jelmer: is it something bzr-hg related?
[14:48] <jelmer> gour, how do you mean?
[14:48] <jelmer> gour, the imports are done using bzr-hg
[14:48] <gour> jelmer: i mean, some already known issue?
[14:49] <jelmer> gour: see my comment above, you might want to throw out the existing import and create a new import
[14:51] <gour> ahh..got it
[14:58] <abentley> vila: I looked at your branch.  Why did you change test_shelf?
[15:04] <vila> abentley: just checking I understood how it worked, revert the change if that's an issue
[15:05] <abentley> vila: it was just surprising because I didn't change that file, and AIACT, you just changed it to use context managers.  The change itself looks fine.
[15:06] <jelmer> gour, I've been looking at fixing the hg imports recently so if you find issues (after the branch has been recreated, please let me know and/or file bugs)
[15:06] <vila> yeah, and get rid of the seek, it was indeed to see if I got the context managers right, I shouldn't have committed that
[15:06] <gour> jelmer: ok
[15:08] <vila> abentley: I think I said I prefer checking like you did, that's the intent of the test isn't it ? Not checking anything... will be surprising if the test ever fails
[15:10] <abentley> vila: Okay, I've pushed a revision that merges your changes.  Am I cleared for landing?
[15:26] <vila> abentley: yup
[15:29] <abentley> vila: Thanks.  It's been fun hacking on the merge code once again.
[15:29] <vila> abentley: hehe, glad you enjoyed it ;)
[15:32] <abentley> vila: aw, darn.  Your testtools is too old for ExpectedException.
[15:32]  * vila bangs head
[15:33] <vila> that sucks
[15:33] <vila> you mean the pqm one right ?
[15:36] <abentley> vila: Yes.
[15:36] <abentley> vila: It's okay, I'm rewriting it as assertRaises.
[15:37] <vila> ok, ExpectedException has been introduced in 0.9.9, 0.9.11 has been released yesterday-ish but pqm still uses 0.9.8
[15:37] <vila> abentley: cool, can you leave the EE form in comment saying it requires 0.9.9 ?
[15:38] <vila> abentley: I'm afraid nobody will remember to use it otherwise when testtools is upgraded
[15:38] <vila> abentley: the lp pqm has a more recent testtools ?
[15:39] <abentley> vila: Launchpad explicitly manages that dependency, so our buildbot uses it.  (Our PQM doesn't run tests.)
[15:40] <vila> hmpf
[15:40] <vila> ok, thanks
[15:57] <abentley> jelmer: I readdressed that email to exclude the merge proposal because I thought it was meta-conversation that didn't belong  on the proposal itself.
[15:59] <jelmer> abentley: ah, sorry
[15:59] <jelmer> abentley: I thought thunderbird was being smart again and had excluded it
[15:59] <abentley> jelmer: nope.  We use reply-to headers, which require effort to avoid.
[16:16] <SpamapS> the bzr in daily breaks with a nasty crash for me...
[16:16] <SpamapS> oh wait, its the bzr git plugin I think
[16:20] <jelmer> SpamapS, hi
[16:20] <jelmer> SpamapS, can you elaborate?
[16:32] <SpamapS> sorry
[16:32] <SpamapS> yes
[16:32]  * SpamapS gets a backtrace ready
[16:34] <SpamapS> jelmer: http://paste.ubuntu.com/625946/
[16:36] <jelmer> SpamapS: that looks like a mismatched bzr and bzr-git, it should be fixed in newer versions of bzr-git
[16:36] <jelmer> SpamapS, you're running bzr 2.4-ish I suspect?
[16:39] <SpamapS> jelmer: daily build
[16:51] <jelmer> SpamapS: hah, looks like the version number of the daily builds needs to be updated
[16:52] <ccxCZ> Is there way to make subdirectories separate branches, while the main project would remember the revisions of the subprojects? I asked here some time ago and I was told some implementation of this was underway
[16:53] <jelmer> ccxCZ: You might be looking for "bzr split"
[16:53] <jelmer> ccxCZ: bzr split can split off a directory as a new branch, while both the original branch and the new branch keep the original history
[16:55] <jelmer> SpamapS, that should be fixed now - what version of bzr-git does dpkg report you have?
[16:56] <ccxCZ> jelmer: I know about that. but that won't keep project state anywhere - which revision of which sub-branch works with the master one
[16:56] <SpamapS> jelmer: 0.6.0-1~bazaar1~natty1
[16:57] <jelmer> SpamapS: that's not the daily builds PPA - where does it come from?
[16:57] <SpamapS> I think from the proposed PPA.. which I also enabled on my way to daily.. ;)
[16:57] <jelmer> ccxCZ: Ah, ok. In that case you're after nested trees: bug 267770
[16:58] <jelmer> ccxCZ: until that's implemented in core there are a couple of plugins you can use instead (bzr-externals most notably)
[16:58] <jelmer> SpamapS: ah, ok
[16:58] <jelmer> SpamapS: in that case the problem should go away when a new bzr-git is published in the PPA
[16:59] <jelmer> http://code.launchpad.net/~bzr/+recipe/bzr-git-daily
[16:59] <SpamapS> jelmer: thanks for checking.
[17:03] <ccxCZ> kthnx, will check that out
[18:20] <ssbr> Hi. What's the most recent version of bzr that supports Python 2.5?
[18:24] <fullermd> 2.3.x
[18:26] <ssbr> fullermd: excellent, thank you
[18:52] <SpamapS> jelmer: similar problems with bzr-builddeb
[18:52] <jelmer> garr, I really should get that new bzr-builder deployed so we no longer have this problem
[18:52] <SpamapS> http://paste.ubuntu.com/626023/
[18:53] <jelmer> SpamapS: actually, bzr-builddeb seems ok
[18:54] <jelmer> SpamapS, which bzr-builddeb are you running?
[18:54] <SpamapS> 2.7.4+bzr565~natty1
[18:55] <SpamapS> well.. I was.. have to get some work done for a bit.. but I can move back to it to help diagnose any issues
[18:55] <jelmer> SpamapS: Can you pastebin the output before the backtrace?
[18:57] <jelmer> IIRC this happens if bzr-builddeb is unable to find back the upstream tarball *after* it's fetched it
[18:57] <SpamapS> http://paste.ubuntu.com/626028/
[18:57] <SpamapS> yes
[18:58] <SpamapS> hmm
[18:58] <SpamapS> actually this one may be wrongly building as a native package
[18:59] <jelmer> SpamapS: it's not building as a native package (otherwise it wouldn't be retrieving the upstream tarball)
[18:59] <SpamapS> yeah.. never mind
[18:59] <SpamapS> this branch is a bit whacked
[19:02] <jelmer> SpamapS: did it fetch a .tar.gz file?
[19:03] <SpamapS> jelmer: no
[19:03] <jelmer> the output seems to suggest it did, despite the warning about the invalid host name
[19:03] <SpamapS> the branch was not setup to bzr bd properly
[19:03] <maxb> Anyone around who can provide me with a second opinion on whether I've found a bug in TreeTransform.trans_id_tree_path?  namely, does it actually make any sense for it to be resolving symlinks in its path argument?
[19:03] <SpamapS> its used purely as a source of data for bzr builder recipes..
[19:04] <jelmer> SpamapS: is the branch available somewhere publicly?
[19:05] <jelmer> SpamapS: I'm particularly curious because somebody else reported similar behaviour and I never managed to figure out how we could get a success from apt but no file.
[19:05] <SpamapS> jelmer: lp:ensemble ;)
[19:15] <jelmer> SpamapS: thanks
[19:15] <jelmer> SpamapS, the problem appears to be that the version suggests a non-native package but the package is built as a native package
[19:15] <SpamapS> jelmer: it may have to do with being a 1.0 format debian dir but not native.. so the extraction causes issues
[19:16] <SpamapS> jelmer: like I said, the debian dir is just not setup right. :-/
[19:16] <jelmer> so bzr-builddeb thinks that if the ensemble ppa contains a 0.5-0ensemble252~oneiric1 package, that it has the upstream source for ensemble 0.5
[19:16] <SpamapS> jelmer: it will most likely be removed or fixed soon enough. Maybe a better error message would be in order though. :)
[19:16] <jelmer> SpamapS, It's not this specific debian directory, more the way in which the recipes are built at the moment (recipes can only be native for now)
[20:56] <poolie> hi all
[20:57] <jelmer> 'morning poolie
[20:57] <jelmer> you're up early :)
[21:11] <poolie> i'm in california
[21:11] <poolie> i don't know what time it is :)
[21:12] <jelmer> ahh :)
[21:12] <fullermd> Pretty impressive, actually.  Usually it takes people few weeks there before that happens   :p
[21:14] <poolie> :)
[22:52] <poolie> a