=== medberry is now known as med_away
=== statik_ is now known as statik
=== BasicPRO is now known as BasicOSX
pooliehi spiv?04:41
spivHi poolie04:45
pooliehow are you?04:54
spivpoolie: 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
ubot5Ubuntu bug 53947 in mplayer (Ubuntu) "incorrectly disables gnome-screensaver" [Medium,Fix released]04:57
spivubot5: uh, no04:57
spivpoolie: and thinking that my timing with the changelog_merge plugin is pretty serendipitous!04:58
pooliewith linaro gcc?05:00
poolieyes, it is05:00
spivI really only devoted more attention to it recently because it looked like relatively easy work for my cold-addled head last week.05:02
spivpoolie: I'm still really enjoying the kanban board btw05:13
spivEven if some days I can't make things move as fast as I'd like05:14
pooliei'm glad05:22
pooliei'd like to make it read/write some time05:22
* poolie goes to file a bug asking for 'tweak' state05:30
ubot5Ubuntu bug 373078 in Launchpad itself "code review merge status and docs need clarity, particularly for 'tweak' cases" [High,Triaged]05:31
pooliespiv, is https://bugs.launchpad.net/udd/+bug/653312 anything like the other importer bugs you were working on?06:16
ubot5Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]06:16
spivpoolie: 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" bugs06:18
mgiucaCan anyone tell me how to run the test suite?06:27
mgiucaI 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:28
spivmgiuca: 'bzr selftest'06:29
spivmgiuca: or for just that file, 'bzr selftest -s bt.test_log' is quickest06:30
mgiucaOh, cool.06:30
spivsee 'bzr selftest --help' for more details06:30
mgiucaThanks! I have done it before but I completely forgot.06:30
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
mgiucaOK got it working now. Cheers.06:34
mgiuca(Had to download a custom version of testtools)06:34
vilahi all !08:02
vilapoolie:, jam: I tried to better explain the fix for bug #735477, please re-review ;)08:02
ubot5Launchpad 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/73547708:03
maxbhmm, I should dust off my changes for better ordering of package imports when catching up08:09
vilamaxb: yeah for 2.3.1 in bzr/ppa !08:11
vilamaxb: so you ended up using dh_python for all series ?08:12
maxbI ended up just not merging the change to use dh_python2 for now08:15
maxbI 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 below08:16
maxbFor the recipe builds for {karmic,lucid,maverick} & {natty} ... we really want a solution which builds all series out of a single branch08:17
maxbI have some evil machinations in mind08:17
vilaha, excelllent, I was wondering if that was the sore point (using different packaging for different series and the associated fallouts)08:18
maxbMainly involving a PPA with packages for the older series which install a fake dh_python2 which actually runs dh_pysupport/central08:18
vilasounds pragmatic to me (but not understanding the details...)08:18
pooliemaxb, yes, thanks08:33
poolievila, are you able to give any ideas on https://bugs.launchpad.net/udd/+bug/653312?08:33
ubot5Ubuntu bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged]08:33
vilapoolie: isn't it a dupe of a bug fixed by spiv waiting for a more recent bzr version deployed on jubany ?08:34
pooliei asked spiv and he thought it was something different08:35
vilaha :-/08:35
vilathen no idea, I'm not yet to the point where I can retry such failures locally but I'm working towards this goal08:36
vilapoolie: err, just checking camlp5 and it's listed as failing due to bug #653320 instead08:37
ubot5Launchpad bug 653320 in Ubuntu Distributed Development "Import fails with "marked but not imported"" [High,Triaged] https://launchpad.net/bugs/65332008:37
vilacouhdb is *not* listed as failing though08:38
jammorning all08:38
pooliei don't know where couchdb has gone08:38
vila(yeah, searched the right one in http://package-import.ubuntu.com/status/ ;)08:38
vilahey jam !08:38
pooliejust an update for them might be good08:38
vilapoolie: well, if it's not listed as a failure, it's supposed to succeed ;)08:38
poolieright, exactly08:40
poolieit's possible the package changed name08:41
poolieoh, would there be no page at all if it's passing?08:41
pooliethat seems unlikely08:41
vilapoolie: I think that's the way it works now: pages are created only for failures (and deleted once the import succeeds ?)08:42
* poolie looks08:42
pooliesometimes the simplest answer is the best08:42
vilapoolie: in categorize_failures.py get_info() calls remove_obsolete_pages()08:43
poolieperhaps we should leave them to avoid confusion?08:43
pooliewell, write "succeeded at blah"08:44
vilapoolie: 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:44
jamvila: yeah, I don't know if there is a bug, but certainly I've wanted it.08:45
jamIt is good to see the failures, but strange to have the page just disappear when they succeed08:45
vilaselect * 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|247954e4e2d02da1b1f49dfd059c0eb2aab39b7508:45
vilajam: I'm pretty sure you *wrote* it somewhere :)08:45
pooliethe last commit was today which seems plausible08:45
vilaerr, I meant the comment, not the page ;)08:45
vilapoolie: err, where do you see that ?08:46
jamvila: I write stuff all the time. :)08:47
pooliebzr log lp:ubuntu/couchdb08:47
poolieor https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/couchdb/natty08:47
vilaoh, bah, of course ;)08:51
pooliei didn't think of it til i spoke to you08:52
pooliei thought the absence of a page meant failure08:52
vilaSomthing 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:54
vilawow, 1.0.1-0ubuntu13 appeared as we speak...08:56
vilaha no, commit messages /tags misreading08:56
vilaright, seems like the packagers are faster than the importer then08:57
vila1.0.1-0ubuntu9 is revno 47 so this was created by the importer08:57
pooliethat's a big cover letter :)08:58
vilaoooh, so were ubuntu13 !08:58
vilapoolie: hehe, ryeah, sorry about that but I thought there were far too many hidden assumptions in my fix that led to far too many misunderstandings08:59
viladid 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:00
vilas/displayed/display/ no ? I suck in English there :-/09:01
vilaI wonder if we should not use a private bzr version for the importer...09:04
vilaISTM 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 failure09:05
vilarelated to that, turning the package importer into a bzr plugin may also make it easier to implement some features...09:06
MerwinHi. 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
MerwinHow could I avoid that?09:09
vilaMerwin: use a shared repository09:09
Takuse a local shared...yeah09:09
poolieMerwin, well, you should make a local repository, branch into that09:09
pooliethen just update your copy of trunk09:09
MerwinSo I branch for the origin location, and then re-branch for any modifications from my local directory ?09:10
MerwinI there any options to pass for the 1st pull to specify that it's a shared repository?09:11
poolieMerwin, you'll want09:12
poolie'bzr init-repo openerp'09:12
pooliecd openerp09:12
pooliebzr branch lp:openerp trunk09:12
pooliebzr branch trunk my-branch-123409:12
MerwinOk, thanks !09:12
vilaMerwin: 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:12
spivvila: 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.63461709:20
vilaspiv: yeah, that was my understanding09:21
spivvila: I don't know of any other fixes in that update relevant to the package-importer09:21
vilaspiv: I thought the CHK ones weren't covered by one of your fix (landed in 2.3.[01] ?)09:22
vilafixes even09:22
mr-russhehe, that was a piece of comedy to begin reading the channel.09:22
spivvila: the CHK ones already fixed09:23
vilamr-russ: my pleasure :)09:23
spivvila: by deleting the damaged branches09:23
spivvila: and restarting those imports from scratch09:23
vilaand shouldn't the ones related to bug #653312 be deleted as well ?09:24
ubot5Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/65331209:24
spivvila: the revisions involved appear to all be quite old, so the best guess is it's some nasty bug we never even knew we had09:24
spivvila: but that we fixed ages ago09:24
pooliei think i should stop09:25
pooliegood night all09:25
spivvila: 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 problem09:25
spivpoolie: yes, probably :)09:25
spivpoolie: good night09:25
vilaspiv: 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 scratch09:25
spivvila: I don't know about 65331209:25
vilapoolie: enjoy your week-end09:26
spivvila: no, too old bzr was a theory we tried, upgraded, no difference09:26
spivvila: read the extensive bug comment history for the gory details :/09:26
vilaspiv: but did you do 1, 2 and 3 above or only part of them ?09:26
spivvila: I don't know what 1) means09:27
vilaargh, 1) delete the branches on lp09:27
spivvila: we did 2), upgrade to 2.3b5, but it turned out to be irrelevant09:27
spivIn the end we completely deleted the branches on lp, the import records, everything09:27
spivThere 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
vilayeah and doing that fixed the issue, hence me wondering about whether we should also delete the branches for the packages mentioned in bug #65331209:28
ubot5Launchpad bug 653312 in Ubuntu Distributed Development "Import fails with NoSuchRevision" [High,Triaged] https://launchpad.net/bugs/65331209:28
spivIt was an immensely difficult and confusing bug, the bug comments are your best reference :)09:28
spivWell, as I say I don't know about 65331209:29
spivIt sounds like a different sort of problem to me09:29
jamspiv: about the RetryWithNewPacks. I have the feeling there is something specific about what bzr-svn is doing differently from normal fetching09:29
jamin particular, I believe it fetches N revs at a time09:29
spivThe other one was about two different repos disagreeing about the contents of one revid09:29
spiv(as in significantly different file contents!)09:30
spiv653312 is NoSuchRevision, which on the face of it sounds like a different category of problem09:30
spivjam: it's possible09:30
spivjam: 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 traceback09:31
jamwhat I mean is that as it is fetching, it creates intermediate pack files09:31
vilaspiv: ok09:31
jamso when it is done, it has many packs (some of which may have been autopacked, etc.)09:32
vilaspiv: and 2.3.1 is good to deploy for the 44 failures right ?09:32
spivjam: the main difference is that it always passes a hint09:32
jamI agree that I'm not sure how it would have an effect, but we haven't seen it with just bzr09:32
spivjam: but the code path for dealing with hints looks robust09:32
spivAnd the test we wrote passes a hint09:33
jamspiv: I believe it wasn't at one point, but should now09:33
spivvila: yes09:33
spivjam: I can't speak for the past, just for the code I've read recently :)09:33
spivjam: anyway, hopefully when exarkun re-enables the offending configuration we'll be able to get more insight09:40
jamspiv: A note on the LockingContention issue09:45
jamI like caching the master branch,09:45
jamI don't like uploading a potentially large tag dict ,that we just downloaded from the master09:45
jamI 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 fetch09:47
jamso that part I certainly like09:47
spivjam: oh, I meant to mention that in the cover letter10:36
spivjam: the master branch is write-locked throughout10:37
spivjam: which means the tags dict we just wrote it cachec10:37
spivand so merge_to won't actually trigger any more actual reads and writes to the master's tags10:37
spivIt'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 return10:39
spivIt 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
jamit seems to be relying on happy coincidence, vs explicit statements, but I'm happy enough with it for now, then10:41
spivEither happy coincidence or robust performance design ;)10:43
spivI think _basic_push smells a bit, especially how it is actually not treated as private by bzr-svn10:44
spivSo it'd be nice to perhaps try replace it with something better one day10:45
jelmeryeah, it's a bit odd how all that works10:48
=== psynaptic|away is now known as psynaptic
jelmervila: The plan is to have 2.3.1 in natty, right?11:39
vilajelmer: 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 that11:40
jelmervila: we need to do one for bzr-builddeb as well11:41
vilajelmer: 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
jelmervila: I'm not sure, I'm not all that familiar with MRE11:42
* jelmer looks at the wiki11:43
jelmervila: do you know if MRE is documented anywhere?11:43
vilajelmer: AIUI, MRE basically says: you're allowed to go into -updates so, IMHO, it should also takes precedence over FFe11:43
vilayes, just a sec11:43
jelmervila: Thanks11:53
jelmervila: It doesn't seem to mention FFe's, but I guess it would make sense if it did11:53
jelmervila: https://bugs.launchpad.net/ubuntu/+source/configobj/+bug/73749112:30
ubot5Ubuntu bug 737491 in configobj (Ubuntu) "Sync configobj 4.7.2+ds-2 (main) from Debian unstable (main)" [Undecided,New]12:30
ubot5Ubuntu bug 737499 in bzr (Ubuntu) "Sync bzr 2.3.1-1 (main) from Debian unstable (main)" [Undecided,New]12:30
vilajelmer: thanks, very informative12:34
vilajelmer: what's the '+ds' ?12:34
jelmervila: I have no idea :)12:35
* vila stops his internal TLA guesser (no, that's not debian stable ;)12:36
jelmerAh, the changelog says:  * +ds version, as release zip file contains root-level __MACOSX directory.12:37
vilaooh, 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
vilaI don't really know what is stored there but at least icons positions and some finder prefs... should be totally irrelevant :-/12:40
vilawell, as far as packaging for non OSX oses is concerned at least12:41
jelmerThat's probably why Stefano removed it12:42
vilajelmer: just noticed your discussion in #ubuntu-level with pitti :-/13:25
vilajelmer: so what should be done then ? "Just" an SRU ?13:25
jelmervila: no, just the sync request I mentioned here earlier13:26
vilajelmer: ha, ok.13:26
vilaI *will* understand one day, I will13:26
jelmervila: 2.3.1 is for natty, so there's no need for a Stable Release Update, as natty is not out yet13:27
* vila facepalms13:27
jelmervila: However, natty is past the feature freeze date. So releases that add new features require an exception (FFe).13:27
* maxb throws a build of 2.3.1 using dh_python2 in natty into bzr/proposed for sync semi-validation13:46
vilamaxb: because you built 2.3.1 directly in bzr/ppa right ?13:47
* vila blinks13:48
maxbI previously built 2.3.1 using the old python-support / cdbs packaging in bzr/proposed13:49
vilamaxb: ghaa, that's the step I missed13:49
maxbNow I'm building essentially the same package but with dh_python2 / dh7 packaging13:49
vilathe thing I love with silly questions is that I really learned something when I'm wrong :-}13:50
vilanothing beats learning :)13:51
maxbLater I will have the fun of backporting the cdbs->dh7 to maverick, but avoiding the python-support->dh_python213:51
jelmermaxb: why backporting of the cdbs->dh7 to maverick?13:56
maxbJust to minimize unnecessary delta between series13:56
arandI'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
beunoarand, . .?14:23
beunocheckout into itseld?14:23
maxb"bzr checkout -r81" ?14:24
arandWell I want to change the working dir to the state of revision 8114:24
arandmaxb: Same error: bzr: ERROR: File exists: u'/home/arand/utv/poppler/.bzr': [Errno 17] File exists: '/home/arand/utv/poppler/.bzr'14:24
maxbarand: huh... could you pastebin 'bzr info' output please?14:25
jelmer"bzr co" creates a working tree, that doesn't work if you already have a checkout14:25
jelmerarand: try "bzr up -r81"14:25
arandThat seems to work, so I basically only had the log in text and no data for the history?14:27
=== hunger_ is now known as hunger
* jelmer can't believe he wasn't aware of BZR_TEST_PDB before15:14
vilajelmer: yeah, really handy when you need it ;)15:27
jamvila, jelmer: I'm off to pick up the family. Have a good weekend15:52
vilajam: same to you !15:52
jelmerjam: You too, fijn weekend !15:52
=== deryck is now known as deryck[lunch]
psynapticI have a bound heavyweight branch checkout and have been committing locally using bzr commit --local16:37
psynapticI need to push a set of the commits to the upstream branch16:37
psynapticto avoid dumping thousands of line changes in one merge proposal16:38
psynapticis there a common workflow for this?16:39
jelmerpsynaptic: you should be able to unbind the branch and rebase16:41
psynapticso unbinding is like removing the central server info from the branch?16:42
jelmeryeah - "bzr unbind"16:42
psynapticok, done that16:43
psynapticthere doesn't seem to be help for bzr rebase in our version16:43
jelmerpsynaptic: it's part of the bzr-rewrite plugin16:44
psynapticright, thanks.. will need to speak with infra about getting this added16:44
maxbSo, you want to squash lots of commits into a single one?16:45
maxbpsynaptic: ^ ?16:45
jelmerpsynaptic: you should be also be able to install it locally in your home directory16:45
psynapticmaxb: nope, this is what I need:16:46
psynapticI have say local 50 commits16:46
psynapticI want to pick a point in time (a revno) and push all commits up to this point to the upstream branch16:47
psynapticI'd like to keep the history intact16:47
psynapticis this possible?16:47
maxbOh, so you don't want bzr rebase at all then16:47
psynapticoh ok16:47
maxb"bzr push -r whatever"16:47
psynapticthanks, will try that16:48
psynapticneed to speak with the reviewer to see what he wants merging first, will try in 1016:50
jelmerpsynaptic: has the mainline been merged since you did your first local commit?17:06
psynapticI need to up17:07
psynapticbut last time I did that I got all the commits dumped into my working copy with pending merge tips for each commit17:07
jelmerpsynaptic: In that case you indeed want bzr unbind + bzr rebase17:08
jelmerbzr push -r will complain about diverged branches17:08
maxbIs rebase strictly necessary here?17:09
psynapticthis is starting to get confusing!17:09
psynapticbut it's hard for people to review 5000+ line *changes*17:09
jelmermaxb: to avoid the merge commit, yes17:10
maxbI'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 branch17:10
=== deryck[lunch] is now known as deryck
jelmerpsynaptic: even with a merge the individual commits are still accessible for others to review17:11
psynapticjelmer: sure, but we use launchpad and the reviewer just sees the whole review as a bundle to review, if that makes sense17:11
psynapticalso, my changes don't leave the working tree in a perfectly working state17:12
psynapticwhich is a pain17:12
jelmerpsynaptic: that doesn't really change if the revisions are all on the mainline though17:12
zygaHi, I was using branch.get_rev_id(revno), is there a similar method that would work with tags?17:30
jelmerzyga: you can use branch.tags is the tag dictionary17:33
exarkunOn a Windows 7 machine (that I do not have direct access to), 'bzr checkout' is failing with this error message:17:35
exarkunbzr: 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 exists17:35
jelmerhi exarkun17:43
jelmerexarkun: what version of bzr is that? It looks like one of the bugs spiv fixed earlier.17:43
exarkunI don't know what version it is.  Probably the version that was packaged in a Windows installer as of about a week ago.17:46
jelmeractually, it's a different one17:49
jelmerbug 37689517:49
ubot5Launchpad bug 376895 in Bazaar "HPSS cannot rename-over packs on win32" [High,Confirmed] https://launchpad.net/bugs/37689517:49
psynapticjelmer: my revisions are all local, does this affect it?17:49
jelmerpsynaptic: does it affect what?17:49
=== beuno is now known as beuno-lunch
psynapticjelmer: I may just be able to push all my changes afterall, will find out17:51
exarkunjelmer: Okay, thanks.17:51
=== beuno-lunch is now known as beuno
cr3maxb: thanks again for all the help yesterday, much appreciated!18:47
=== psynaptic is now known as psynaptic|food
grettkeQuestion: 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:23
maxbgrettke: I think the simplest way is "bzr revert -r past-revision-number-or-id-or-tag path/to/subdirectory/that/no/longer/exists"19:37
knighthawkis there a rpm for bzr-svn?19:57
knighthawkor is it a plugin?19:57
maxbThe two are not mutually exclusive19:58
maxbAnswers are "Almost certainly" and "Yes".19:58
maxbBut I'm a Debian/Ubuntu person and shudder at the thought of RPMs19:59
knighthawklol -19:59
knighthawkI'm almost 100% certain I've done a rpm install in the past but can't seem to find one today.19:59
=== psynaptic|food is now known as psynaptic|afk
thomiHi - 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/Wh7sP7nd23:06
thomihmm, 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.23:13

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!