=== medberry is now known as med_away
=== statik_ is now known as statik
=== BasicPRO is now known as BasicOSX
[04:41] <poolie> hi spiv?
[04:45] <spiv> Hi poolie
[04:54] <poolie> how are you?
[04:57] <spiv> poolie: extra good now that I just hit "propose merge" on https://code.launchpad.net/~spiv/bzr/lockcontention-pushing-tag-733350-2.3/+merge/53947 :)
[04:57] <ubot5> Ubuntu bug 53947 in mplayer (Ubuntu) "incorrectly disables gnome-screensaver" [Medium,Fix released]
[04:57] <spiv> ubot5: uh, no
[04:58] <spiv> poolie: and thinking that my timing with the changelog_merge plugin is pretty serendipitous!
[05:00] <poolie> with linaro gcc?
[05:00] <poolie> yes, it is
[05:02] <spiv> I really only devoted more attention to it recently because it looked like relatively easy work for my cold-addled head last week.
[05:13] <spiv> poolie: I'm still really enjoying the kanban board btw
[05:14] <spiv> Even if some days I can't make things move as fast as I'd like
[05:22] <poolie> i'm glad
[05:22] <poolie> i'd like to make it read/write some time
[05:30] <poolie> done
[05:30]  * poolie goes to file a bug asking for 'tweak' state
[05:31] <poolie> https://bugs.launchpad.net/launchpad/+bug/373078
[05:31] <ubot5> Ubuntu bug 373078 in Launchpad itself "code review merge status and docs need clarity, particularly for 'tweak' cases" [High,Triaged]
[06:16] <poolie> spiv, is https://bugs.launchpad.net/udd/+bug/653312 anything like the other importer bugs you were working on?
[06:16] <ubot5> Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]
[06:18] <spiv> poolie: probably not, at a guess it'd be more like the "someone has done push --overwrite to a package branch that the importer doesn't know about" bugs
[06:27] <mgiuca> Hello
[06:27] <mgiuca> Can anyone tell me how to run the test suite?
[06:28] <mgiuca> I am just trying to run 'python bzrlib/tests/test_log.py' for example, but nothing happens (because there is no test runner in that file).
[06:29] <spiv> mgiuca: 'bzr selftest'
[06:30] <spiv> mgiuca: or for just that file, 'bzr selftest -s bt.test_log' is quickest
[06:30] <mgiuca> Oh, cool.
[06:30] <spiv> see 'bzr selftest --help' for more details
[06:30] <mgiuca> Thanks! I have done it before but I completely forgot.
[06:31] <spiv> (Don't forget to use ./bzr if you want to test the bzr you're hacking on rather than the system one)
[06:31] <mgiuca> Yup.
[06:34] <mgiuca> OK got it working now. Cheers.
[06:34] <mgiuca> (Had to download a custom version of testtools)
[08:02] <vila> hi all !
[08:02] <vila> poolie:, jam: I tried to better explain the fix for bug #735477, please re-review ;)
[08:03] <ubot5> Launchpad bug 735477 in Ubuntu Distributed Development "some imports survive a kill -SIGTERM leading to massive log output and no kill" [High,In progress] https://launchpad.net/bugs/735477
[08:09] <maxb> hmm, I should dust off my changes for better ordering of package imports when catching up
[08:11] <vila> maxb: yeah for 2.3.1 in bzr/ppa !
[08:12] <vila> maxb: so you ended up using dh_python for all series ?
[08:15] <maxb> I ended up just not merging the change to use dh_python2 for now
[08:16] <maxb> I think for the manually built PPAs it might be easiest to simply stick with whichever of python-support / python-central the package was previously using, for maverick and below
[08:17] <maxb> For the recipe builds for {karmic,lucid,maverick} & {natty} ... we really want a solution which builds all series out of a single branch
[08:17] <maxb> I have some evil machinations in mind
[08:18] <vila> ha, excelllent, I was wondering if that was the sore point (using different packaging for different series and the associated fallouts)
[08:18] <maxb> Mainly involving a PPA with packages for the older series which install a fake dh_python2 which actually runs dh_pysupport/central
[08:18] <vila> sounds pragmatic to me (but not understanding the details...)
[08:33] <poolie> maxb, yes, thanks
[08:33] <poolie> vila, are you able to give any ideas on https://bugs.launchpad.net/udd/+bug/653312?
[08:33] <ubot5> Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]
[08:34] <vila> poolie: isn't it a dupe of a bug fixed by spiv waiting for a more recent bzr version deployed on jubany ?
[08:35] <poolie> i asked spiv and he thought it was something different
[08:35] <vila> ha :-/
[08:36] <vila> then no idea, I'm not yet to the point where I can retry such failures locally but I'm working towards this goal
[08:37] <vila> poolie: err, just checking camlp5 and it's listed as failing due to bug #653320 instead
[08:37] <ubot5> Launchpad bug 653320 in Ubuntu Distributed Development "Import fails with "marked but not imported"" [High,Triaged] https://launchpad.net/bugs/653320
[08:38] <vila> couhdb is *not* listed as failing though
[08:38] <jam> morning all
[08:38] <vila> couchdb
[08:38] <poolie> i don't know where couchdb has gone
[08:38] <vila> (yeah, searched the right one in http://package-import.ubuntu.com/status/ ;)
[08:38] <vila> hey jam !
[08:38] <poolie> just an update for them might be good
[08:38] <vila> poolie: well, if it's not listed as a failure, it's supposed to succeed ;)
[08:40] <poolie> right, exactly
[08:41] <poolie> it's possible the package changed name
[08:41] <poolie> oh, would there be no page at all if it's passing?
[08:41] <poolie> that seems unlikely
[08:42] <vila> poolie: I think that's the way it works now: pages are created only for failures (and deleted once the import succeeds ?)
[08:42]  * poolie looks
[08:42] <poolie> sometimes the simplest answer is the best
[08:43] <vila> poolie: in categorize_failures.py get_info() calls remove_obsolete_pages()
[08:43] <poolie> perhaps we should leave them to avoid confusion?
[08:44] <poolie> well, write "succeeded at blah"
[08:44] <poolie> hooray
[08:44] <vila> poolie: I think there is a bug asking to list succeeding imports too (where jam said we should have a different page for all the succeeding ones)
[08:45] <jam> vila: yeah, I don't know if there is a bug, but certainly I've wanted it.
[08:45] <jam> It is good to see the failures, but strange to have the page just disappear when they succeed
[08:45] <vila> select * from revids where package='couchdb'; in meta-db hints that it succeeded at couchdb|1.0.1-0ubuntu9|natty|james.westby@ubuntu.com-20110129025244-i6nzlenngh54woq7|247954e4e2d02da1b1f49dfd059c0eb2aab39b75
[08:45] <vila> jam: I'm pretty sure you *wrote* it somewhere :)
[08:45] <poolie> the last commit was today which seems plausible
[08:45] <vila> err, I meant the comment, not the page ;)
[08:46] <vila> poolie: err, where do you see that ?
[08:47] <jam> vila: I write stuff all the time. :)
[08:47] <poolie> bzr log lp:ubuntu/couchdb
[08:47] <poolie> or https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/couchdb/natty
[08:51] <vila> oh, bah, of course ;)
[08:52] <poolie> i didn't think of it til i spoke to you
[08:52] <poolie> i thought the absence of a page meant failure
[08:54] <vila> Somthing escapes me there, the url above mentions 1.0.1-0ubuntu12 but not 1.0.1-0ubuntu9 and the opposite seem to be true on jubany (but maybe I don't know how to properly look on jubany)
[08:56] <vila> wow, 1.0.1-0ubuntu13 appeared as we speak...
[08:56] <vila> ha no, commit messages /tags misreading
[08:57] <vila> right, seems like the packagers are faster than the importer then
[08:57] <vila> 1.0.1-0ubuntu9 is revno 47 so this was created by the importer
[08:58] <poolie> that's a big cover letter :)
[08:58] <vila> oooh, so were ubuntu13 !
[08:59] <vila> poolie: hehe, ryeah, sorry about that but I thought there were far too many hidden assumptions in my fix that led to far too many misunderstandings
[09:00] <vila> did qlog always displayed the author instead of the committer or do I realize this only now because I don't often browse branches where they differ ?
[09:01] <vila> s/displayed/display/ no ? I suck in English there :-/
[09:04] <vila> I wonder if we should not use a private bzr version for the importer...
[09:05] <vila> ISTM that if we rely on the system one we will sooner or later encounter cases were we are not allowed to deploy a fix system-wide for an import failure
[09:06] <vila> related to that, turning the package importer into a bzr plugin may also make it easier to implement some features...
[09:09] <Merwin> Hi. I've got a question : I work on openerp, which is a big project, and doing a bzr branch on it take a long time over my slow connection. So each time I need to create a branch, I have to wait almost 1 hour...
[09:09] <Merwin> How could I avoid that?
[09:09] <vila> Merwin: use a shared repository
[09:09] <Tak> use a local shared...yeah
[09:09] <poolie> Merwin, well, you should make a local repository, branch into that
[09:09] <poolie> then just update your copy of trunk
[09:10] <Merwin> So I branch for the origin location, and then re-branch for any modifications from my local directory ?
[09:10] <Merwin> s/for/from
[09:11] <poolie> correct
[09:11] <Merwin> I there any options to pass for the 1st pull to specify that it's a shared repository?
[09:12] <poolie> Merwin, you'll want
[09:12] <poolie> 'bzr init-repo openerp'
[09:12] <poolie> cd openerp
[09:12] <poolie> bzr branch lp:openerp trunk
[09:12] <poolie> then
[09:12] <poolie> bzr branch trunk my-branch-1234
[09:12] <Merwin> Ok, thanks !
[09:12] <vila> Merwin: no, that's a local configuration which you can change after the fact with 'bzr reconfigure' but poolie typing faster than me explain what you should do when starting from scratch ;)
[09:20] <spiv> vila: the upgrade to 2.3.1 will fix the 44 failures like http://package-import.ubuntu.com/status/adduser.html#2011-03-15%2022:54:36.634617
[09:21] <vila> spiv: yeah, that was my understanding
[09:21] <spiv> vila: I don't know of any other fixes in that update relevant to the package-importer
[09:22] <vila> spiv: I thought the CHK ones weren't covered by one of your fix (landed in 2.3.[01] ?)
[09:22] <vila> s/fix/dixes/
[09:22] <vila> fixes even
[09:22] <mr-russ> hehe, that was a piece of comedy to begin reading the channel.
[09:23] <spiv> vila: the CHK ones already fixed
[09:23] <vila> mr-russ: my pleasure :)
[09:23] <spiv> vila: by deleting the damaged branches
[09:23] <vila> haaaaa
[09:23] <spiv> vila: and restarting those imports from scratch
[09:24] <vila> and shouldn't the ones related to bug #653312 be deleted as well ?
[09:24] <ubot5> Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/653312
[09:24] <spiv> vila: the revisions involved appear to all be quite old, so the best guess is it's some nasty bug we never even knew we had
[09:24] <spiv> vila: but that we fixed ages ago
[09:25] <poolie> i think i should stop
[09:25] <poolie> good night all
[09:25] <spiv> vila: it was pretty baffling, I don't 100% confident about the fix because the failure was pretty scary, I simply cannot see how we ever could have that sort of problem
[09:25] <spiv> poolie: yes, probably :)
[09:25] <spiv> poolie: good night
[09:25] <poolie> thanks
[09:25] <vila> spiv: I was under the impression that it was due to the too old bzr version used on jubany (before the 2.3b5 upgrade) and that we couldn't realize that without fixing 1) the branches on lp, 2) the bzr used on jubany 3) restart the imports from scratch
[09:25] <spiv> vila: I don't know about 653312
[09:26] <vila> poolie: enjoy your week-end
[09:26] <spiv> vila: no, too old bzr was a theory we tried, upgraded, no difference
[09:26] <spiv> vila: read the extensive bug comment history for the gory details :/
[09:26] <vila> spiv: but did you do 1, 2 and 3 above or only part of them ?
[09:27] <spiv> vila: I don't know what 1) means
[09:27] <vila> argh, 1) delete the branches on lp
[09:27] <spiv> vila: we did 2), upgrade to 2.3b5, but it turned out to be irrelevant
[09:27] <spiv> In the end we completely deleted the branches on lp, the import records, everything
[09:28] <spiv> There was a false start where we *thought* we'd deleted all the branches on lp, and some didn't get deleted.
[09:28] <spiv> (Again, not sure why!)
[09:28] <vila> yeah and doing that fixed the issue, hence me wondering about whether we should also delete the branches for the packages mentioned in bug #653312
[09:28] <ubot5> Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/653312
[09:28] <spiv> It was an immensely difficult and confusing bug, the bug comments are your best reference :)
[09:29] <spiv> Well, as I say I don't know about 653312
[09:29] <spiv> It sounds like a different sort of problem to me
[09:29] <jam> spiv: about the RetryWithNewPacks. I have the feeling there is something specific about what bzr-svn is doing differently from normal fetching
[09:29] <jam> in particular, I believe it fetches N revs at a time
[09:29] <spiv> The other one was about two different repos disagreeing about the contents of one revid
[09:30] <spiv> (as in significantly different file contents!)
[09:30] <spiv> 653312 is NoSuchRevision, which on the face of it sounds like a different category of problem
[09:30] <spiv> jam: it's possible
[09:31] <spiv> jam: but on my reading of the code I don't see how N revs vs. 1 rev or whatever could lead to the state that causes a traceback
[09:31] <jam> sure
[09:31] <jam> what I mean is that as it is fetching, it creates intermediate pack files
[09:31] <vila> spiv: ok
[09:32] <jam> so when it is done, it has many packs (some of which may have been autopacked, etc.)
[09:32] <vila> spiv: and 2.3.1 is good to deploy for the 44 failures right ?
[09:32] <spiv> jam: the main difference is that it always passes a hint
[09:32] <jam> I agree that I'm not sure how it would have an effect, but we haven't seen it with just bzr
[09:32] <spiv> jam: but the code path for dealing with hints looks robust
[09:33] <spiv> And the test we wrote passes a hint
[09:33] <jam> spiv: I believe it wasn't at one point, but should now
[09:33] <spiv> vila: yes
[09:33] <spiv> jam: I can't speak for the past, just for the code I've read recently :)
[09:40] <spiv> jam: anyway, hopefully when exarkun re-enables the offending configuration we'll be able to get more insight
[09:45] <jam> spiv: A note on the LockingContention issue
[09:45] <jam> I like caching the master branch,
[09:45] <jam> I don't like uploading a potentially large tag dict ,that we just downloaded from the master
[09:47] <jam> I believe I missed the other problem, which is that fetching a new tag was correctly trying to also upload it to the master, but the master was still locked from the fetch
[09:47] <jam> so that part I certainly like
[10:36] <spiv> jam: oh, I meant to mention that in the cover letter
[10:37] <spiv> jam: the master branch is write-locked throughout
[10:37] <spiv> jam: which means the tags dict we just wrote it cachec
[10:37] <spiv> *cached
[10:37] <spiv> and so merge_to won't actually trigger any more actual reads and writes to the master's tags
[10:39] <spiv> It'll do get_tags_dict, which will return the cached answer, and it'll be the same as the one we would write (usually anyway!  It would be possible but rare to have a situation where a master has more tags than an up-to-date bound branch), and so it would just return
[10:41] <spiv> It would be a bit more direct, and not depend on caching of tags, to tell _basic_push to ignore the master, but also more disruptive to the API.
[10:41] <spiv> (And caching the master is probably a good idea anyway)
[10:41] <jam> it seems to be relying on happy coincidence, vs explicit statements, but I'm happy enough with it for now, then
[10:43] <spiv> Either happy coincidence or robust performance design ;)
[10:44] <spiv> I think _basic_push smells a bit, especially how it is actually not treated as private by bzr-svn
[10:45] <spiv> So it'd be nice to perhaps try replace it with something better one day
[10:48] <jelmer> yeah, it's a bit odd how all that works
=== psynaptic|away is now known as psynaptic
[11:39] <jelmer> vila: The plan is to have 2.3.1 in natty, right?
[11:40] <vila> jelmer: sry was afk, but yes, it's our latest stable so it should go into natty. FFe AIUI but I don't know the process for that
[11:41] <jelmer> vila: we need to do one for bzr-builddeb as well
[11:42] <vila> jelmer: ok, does the fact that we have a MRE (Micro-Release Exception) for bzr has any influence on FFes (Feature Freeze exceptions right ?)
[11:42] <jelmer> vila: I'm not sure, I'm not all that familiar with MRE
[11:43]  * jelmer looks at the wiki
[11:43] <jelmer> vila: do you know if MRE is documented anywhere?
[11:43] <vila> jelmer: AIUI, MRE basically says: you're allowed to go into -updates so, IMHO, it should also takes precedence over FFe
[11:43] <vila> yes, just a sec
[11:45] <vila> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[11:53] <jelmer> vila: Thanks
[11:53] <jelmer> vila: It doesn't seem to mention FFe's, but I guess it would make sense if it did
[12:30] <jelmer> vila: https://bugs.launchpad.net/ubuntu/+source/configobj/+bug/737491
[12:30] <ubot5> Ubuntu bug 737491 in configobj (Ubuntu) "Sync configobj 4.7.2+ds-2 (main) from Debian unstable (main)" [Undecided,New]
[12:30] <jelmer> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/737499
[12:30] <ubot5> Ubuntu bug 737499 in bzr (Ubuntu) "Sync bzr 2.3.1-1 (main) from Debian unstable (main)" [Undecided,New]
[12:34] <vila> jelmer: thanks, very informative
[12:34] <vila> jelmer: what's the '+ds' ?
[12:35] <jelmer> vila: I have no idea :)
[12:35] <vila> lol
[12:36]  * vila stops his internal TLA guesser (no, that's not debian stable ;)
[12:36] <jelmer> heh
[12:37] <jelmer> Ah, the changelog says:  * +ds version, as release zip file contains root-level __MACOSX directory.
[12:40] <vila> ooh, hmm, so probably related to the fact that OSX loves to create .DS_Store files all over the place (hidden in the OSX finder so few people notice)
[12:40] <vila> I don't really know what is stored there but at least icons positions and some finder prefs... should be totally irrelevant :-/
[12:41] <vila> well, as far as packaging for non OSX oses is concerned at least
[12:42] <jelmer> That's probably why Stefano removed it
[13:25] <vila> jelmer: just noticed your discussion in #ubuntu-level with pitti :-/
[13:25] <vila> jelmer: so what should be done then ? "Just" an SRU ?
[13:26] <jelmer> vila: no, just the sync request I mentioned here earlier
[13:26] <vila> jelmer: ha, ok.
[13:26] <vila> I *will* understand one day, I will
[13:27] <jelmer> vila: 2.3.1 is for natty, so there's no need for a Stable Release Update, as natty is not out yet
[13:27]  * vila facepalms
[13:27] <jelmer> vila: However, natty is past the feature freeze date. So releases that add new features require an exception (FFe).
[13:46]  * maxb throws a build of 2.3.1 using dh_python2 in natty into bzr/proposed for sync semi-validation
[13:47] <vila> maxb: because you built 2.3.1 directly in bzr/ppa right ?
[13:48] <maxb> No?
[13:48]  * vila blinks
[13:49] <maxb> I previously built 2.3.1 using the old python-support / cdbs packaging in bzr/proposed
[13:49] <vila> maxb: ghaa, that's the step I missed
[13:49] <maxb> Now I'm building essentially the same package but with dh_python2 / dh7 packaging
[13:50] <vila> the thing I love with silly questions is that I really learned something when I'm wrong :-}
[13:51] <vila> nothing beats learning :)
[13:51] <maxb> Later I will have the fun of backporting the cdbs->dh7 to maverick, but avoiding the python-support->dh_python2
[13:56] <jelmer> maxb: why backporting of the cdbs->dh7 to maverick?
[13:56] <maxb> Just to minimize unnecessary delta between series
[14:23] <arand> I'm trying to "bzr checkout . . -r81" but I can't for the life of me figure out the syntax (I get error file exists ... ./.bzr)
[14:23] <beuno> arand, . .?
[14:23] <beuno> checkout into itseld?
[14:23] <beuno> *itself
[14:24] <maxb> "bzr checkout -r81" ?
[14:24] <arand> Well I want to change the working dir to the state of revision 81
[14:24] <arand> maxb: Same error: bzr: ERROR: File exists: u'/home/arand/utv/poppler/.bzr': [Errno 17] File exists: '/home/arand/utv/poppler/.bzr'
[14:25] <maxb> arand: huh... could you pastebin 'bzr info' output please?
[14:25] <arand> http://paste.debian.net/111121/
[14:25] <jelmer> "bzr co" creates a working tree, that doesn't work if you already have a checkout
[14:25] <jelmer> arand: try "bzr up -r81"
[14:27] <arand> That seems to work, so I basically only had the log in text and no data for the history?
=== hunger_ is now known as hunger
[15:14]  * jelmer can't believe he wasn't aware of BZR_TEST_PDB before
[15:27] <vila> jelmer: yeah, really handy when you need it ;)
[15:52] <jam> vila, jelmer: I'm off to pick up the family. Have a good weekend
[15:52] <vila> jam: same to you !
[15:52] <jelmer> jam: You too, fijn weekend !
=== deryck is now known as deryck[lunch]
[16:37] <psynaptic> I have a bound heavyweight branch checkout and have been committing locally using bzr commit --local
[16:37] <psynaptic> I need to push a set of the commits to the upstream branch
[16:38] <psynaptic> to avoid dumping thousands of line changes in one merge proposal
[16:39] <psynaptic> is there a common workflow for this?
[16:41] <jelmer> psynaptic: you should be able to unbind the branch and rebase
[16:42] <psynaptic> so unbinding is like removing the central server info from the branch?
[16:42] <jelmer> yeah - "bzr unbind"
[16:43] <psynaptic> ok, done that
[16:43] <psynaptic> there doesn't seem to be help for bzr rebase in our version
[16:44] <jelmer> psynaptic: it's part of the bzr-rewrite plugin
[16:44] <psynaptic> right, thanks.. will need to speak with infra about getting this added
[16:45] <maxb> So, you want to squash lots of commits into a single one?
[16:45] <maxb> psynaptic: ^ ?
[16:45] <jelmer> psynaptic: you should be also be able to install it locally in your home directory
[16:46] <psynaptic> maxb: nope, this is what I need:
[16:46] <psynaptic> I have say local 50 commits
[16:47] <psynaptic> I want to pick a point in time (a revno) and push all commits up to this point to the upstream branch
[16:47] <psynaptic> I'd like to keep the history intact
[16:47] <psynaptic> is this possible?
[16:47] <maxb> Oh, so you don't want bzr rebase at all then
[16:47] <psynaptic> oh ok
[16:47] <maxb> "bzr push -r whatever"
[16:48] <psynaptic> thanks, will try that
[16:50] <psynaptic> need to speak with the reviewer to see what he wants merging first, will try in 10
[17:06] <jelmer> psynaptic: has the mainline been merged since you did your first local commit?
[17:07] <psynaptic> yeah
[17:07] <psynaptic> I need to up
[17:07] <psynaptic> but last time I did that I got all the commits dumped into my working copy with pending merge tips for each commit
[17:08] <jelmer> psynaptic: In that case you indeed want bzr unbind + bzr rebase
[17:08] <jelmer> bzr push -r will complain about diverged branches
[17:08] <psynaptic> right
[17:09] <maxb> Is rebase strictly necessary here?
[17:09] <psynaptic> this is starting to get confusing!
[17:09] <psynaptic> but it's hard for people to review 5000+ line *changes*
[17:10] <jelmer> maxb: to avoid the merge commit, yes
[17:10] <maxb> I'd be inclined to unbind, branch the local commits aside to a new branch, reset the working branch to current mainline, and then merge *some* of the local commits back from the second local branch
=== deryck[lunch] is now known as deryck
[17:11] <jelmer> psynaptic: even with a merge the individual commits are still accessible for others to review
[17:11] <psynaptic> jelmer: sure, but we use launchpad and the reviewer just sees the whole review as a bundle to review, if that makes sense
[17:12] <psynaptic> also, my changes don't leave the working tree in a perfectly working state
[17:12] <psynaptic> which is a pain
[17:12] <jelmer> psynaptic: that doesn't really change if the revisions are all on the mainline though
[17:30] <zyga> Hi, I was using branch.get_rev_id(revno), is there a similar method that would work with tags?
[17:33] <jelmer> zyga: you can use branch.tags is the tag dictionary
[17:33] <zyga> thanks!
[17:35] <exarkun> On a Windows 7 machine (that I do not have direct access to), 'bzr checkout' is failing with this error message:
[17:35] <exarkun> bzr: ERROR: File exists: u'C:/cylon/buildslave/bs/windows7-64-py2.7/.bzr/repository/upload/hvb53sfw5m0wa72323g6.pack': [Error 183] Cannot create a file when that file already exists
[17:43] <jelmer> hi exarkun
[17:43] <jelmer> exarkun: what version of bzr is that? It looks like one of the bugs spiv fixed earlier.
[17:44] <exarkun> Hm.
[17:46] <exarkun> I don't know what version it is.  Probably the version that was packaged in a Windows installer as of about a week ago.
[17:49] <jelmer> actually, it's a different one
[17:49] <jelmer> bug 376895
[17:49] <ubot5> Launchpad bug 376895 in Bazaar "HPSS cannot rename-over packs on win32" [High,Confirmed] https://launchpad.net/bugs/376895
[17:49] <psynaptic> jelmer: my revisions are all local, does this affect it?
[17:49] <jelmer> psynaptic: does it affect what?
=== beuno is now known as beuno-lunch
[17:51] <psynaptic> jelmer: I may just be able to push all my changes afterall, will find out
[17:51] <exarkun> jelmer: Okay, thanks.
=== beuno-lunch is now known as beuno
[18:47] <cr3> maxb: thanks again for all the help yesterday, much appreciated!
[18:47] <maxb> Hello
=== psynaptic is now known as psynaptic|food
[19:23] <grettke> Question: I've got a checkout, and I want to "undelete" a directory that was removed in a previous commit... is the best way to do a pull of that directory at that previous revision?
[19:37] <maxb> grettke: I think the simplest way is "bzr revert -r past-revision-number-or-id-or-tag path/to/subdirectory/that/no/longer/exists"
[19:57] <knighthawk> is there a rpm for bzr-svn?
[19:57] <knighthawk> or is it a plugin?
[19:58] <maxb> The two are not mutually exclusive
[19:58] <maxb> Answers are "Almost certainly" and "Yes".
[19:59] <maxb> But I'm a Debian/Ubuntu person and shudder at the thought of RPMs
[19:59] <knighthawk> lol -
[19:59] <knighthawk> I'm almost 100% certain I've done a rpm install in the past but can't seem to find one today.
=== psynaptic|food is now known as psynaptic|afk
[21:02] <OnionRings> hi
[21:03] <OnionRings> ...
[23:06] <thomi> Hi - I'm trying to use bzrlib.log.logger to generate a log of just the mainline branch revisions. I'm specifying 'levels=1' in 'make_log_request_dict', but I still get all levels. Any ideas what I'm doing wrong? Here's the four lines of code involved: http://pastebin.com/Wh7sP7nd
[23:13] <thomi> hmm, it seems that I have to do something in my log formatter - I expected the settings in the request dict to determine what the formatter gets as input.