AuroraBorealisso , i have the small changes that i made to make bazaar explorer not freak out when signing commits01:41
AuroraBorealishow do i go about making a patch file to submit with the bug report?01:41
spivAuroraBorealis: commit the change, and push the branch with the change to launchpad.  If you commit with --bug=lp:1234 it'll get automatically linked to the right bug.  (If you don't, you can use the "link branch" link on the bug page to do the same thing.)01:44
AuroraBorealisah ok, will try that in a second!01:44
spivAuroraBorealis: you probably also want to add a merge proposal for the branch you push to launchpad, but just doing the above will at least make branch appear on that bug page01:45
AuroraBorealisdo i have to do anything on launchpad to push to it?01:46
AuroraBorealisi have not done that before01:46
AuroraBorealis(for a project that isn't mine)01:48
AuroraBorealisor do i click "register a branch"01:51
spivAuroraBorealis: "bzr push lp:<your_lp_id>/<project_name>/<branch_name>"01:56
spivAuroraBorealis: you'll need to add an SSH public key to your LP account (if you haven't already) and run "bzr launchpad-login" (if you haven't already)01:57
AuroraBorealisyeah i have that01:57
spivEr, I typoed slightly, it's lp:~<your_lp_name>01:57
spive.g. lp:~spiv/bzr/foo01:57
AuroraBorealishow do i link it to a bug in the command line?02:01
AuroraBorealisironically i can't use bazaar explorer because of the bug i'm trying to fix xD02:02
AuroraBorealisoh --bug02:03
maxbDoes that work? The documented option is --fixes02:05
AuroraBorealisyeah its --fixes02:06
AuroraBorealiswhich i found after googling02:06
AuroraBorealisok, so i pushed it, its here: https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix02:08
AuroraBorealiswill it do something to the bug report after its done 'scanning' the branch?02:08
spivAuroraBorealis: look now02:12
AuroraBorealisnow what02:13
AuroraBorealisdo i just wait for someone to do something with it?02:18
pooliehi all02:49
Noldorin_hi jelmer03:21
AfCI'm using bzr builddeb. I'm backporting something. I did a build. Took 4 hours, no problem. At the very end, I discover that all though I fixed Build-Depends, I missed correcting the same entry in Depends.04:33
AfCIs there a way to get the .deb rebuilt based on new debian/control04:34
pooliewas the 4h in buildding the source deb or building the binary?04:34
AfCwithout doing another 4 hour build? ie, it's just the very outside wrapper that is changing04:34
AfCpoolie: binary04:34
poolieoh, without actually recompiling it?04:34
AfCI mean, sure I could do surgery with tar :) but I'm trying to find a more proper way to do it.04:35
pooliedpkg-buildpackage with '-nc' "don't clean" somewhere should do it04:35
AfCThe dependency was making "libgmp-dev" (oneiric, unstable) be "libgmp3-dev" (natty)04:35
AfCpoolie: ok. I've got a feeling that with builddeb's defaults, the build-dir/ is already gone04:36
AfC[I know it is]04:36
pooliehm, maybe the things you wanted to preserve are already deleted then?04:37
pooliei guess you could force installation without the dependency to test the package, then do a full clean rebuild when you're happy04:37
AfCBe faster to make an empty package called "libgmp-dev" :/04:39
AfCpoolie: (and, yes, --force-depends has it on board now for testing)04:39
pooliei think there is some way to configure that into dpkg short of making an empty package04:40
AfCI'm guessing that `bzr buildpkg --dont-purge` more or less leads to `-nc`04:40
pooliewell, it would make it at least possible to use -nc later04:49
vilahello guys !06:31
pooliehello vila06:51
jammorning all06:54
vilapoolie, jam : _o/06:54
pooliehi guys07:05
pooliedid you do testing of the new pqm that showed a tmpfs didn't help?07:05
vilapoolie: replied to your mail,07:06
vilabut in a nutshell, I'm very surprised it doesn't give better results but I don't know which test to propose to ensure it's really active in the chroot07:06
jamI'm also surprised about tmpfs, poolie. Didn't you try it locally and found it was quite useful?07:19
jampoolie: though I'll also say, timing results are showing the new machine running the test suite in <30 min. Which is a pretty good starting point. As long as it is <1hr, I don't see it impacting our workflow much.07:33
poolieyeah, that is nice07:34
pooliei was just surprised07:34
vilapoolie: any idea about further tests ?07:35
pooliei don't see your mail yet07:35
lifelessvila: you did use the tmpfs *in the chroot* right ?07:39
lifelessvila: as opposed to *outside the chroot*07:39
lifelessvila: to test, schroot ...; mount :)07:39
vilalifeless: I don't have access to run such commands ... but I indeed ask to check inside the chroot07:41
lifelessok. weird.07:41
viladunno what kind of check was done though...07:41
vilagrr, I hate it when postfix stop working and I don't notice until someone tells me: 'where is your mail ?'08:07
poolieguys, i might stop soon08:39
poolievila, lifeless, i reckon perhaps it was broken by the schroot fstab causing the external /tmp to be bound over the internal tmpfs08:40
vilapoolie: I had the same kind of feeling but... I trusted our admin08:42
vilaattn packagers and installer builders: 2.4.1 has been frozen ;)08:44
pooliegood for you08:49
=== poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer
=== gthorslund_ is now known as gthorslund
=== zyga is now known as zyga-afk
jelmervila: hmm, is it not possible to change a remote branches' configuration?10:48
jelmermaxb: hi10:58
jelmermaxb: bzr-builder fails to build on lucid and maverick with an error from the python helper10:59
jelmerdo you perhaps know what's going on there?10:59
jelmerhey Riddell10:59
maxbDo you have a buildlog handy?10:59
Riddellgood morning10:59
jelmermaxb: FATAL: python-backport-helper needs updating to know which of python-support or python-central 'bzr-builder' should be build with11:01
maxboh, right11:01
maxbWell, the error's pretty clear :-)11:01
=== zyga-afk is now known as zyga
jelmerbzr-builder wasn't in the daily ppa until recently, perhaps it's not in the hardcoded list?11:01
maxbI was being a bit paranoid at the time, perhaps it should just default to python-support11:01
jelmermaxb: it has to be central for all bzr-related packages11:02
jelmermaxb: since they install under bzrlib.plugins11:02
jelmeralthough defaulting to python-support seems reasonable, given that's also the default e.g. debhelper uses11:02
daubersHello, I've come in this morning to bzr complaining that it hasn't got enough values to unpack  with all my branches. Pastebin of the error: http://pastebin.ubuntu.com/687544/ how can I fix this?11:07
jelmerdaubers: what are the contents of your .bzr/branch/last-revision file?11:14
daubersjelmer: It's empty11:18
jelmerdaubers: did you perhaps have a recent machine crash after changing that branch?11:19
daubersjelmer: Not as far as I'm aware11:19
vilajelmer: it should be possible to change a remote config, if it's not, it's a bug11:28
vilajelmer: unless you don't have write access of course11:28
jelmervila: I'm finding that calling set_append_revisions_only(True) doesn't work11:28
vilajelmer: oh, I thought you were referring to either the new design or 'bzr config'11:29
vilajelmer: that's even more surprising given that the package importer did that for a bunch of lp branches11:29
daubersHmmm.... whatever caused it has caused it on every branch on this box11:30
jelmerdaubers: bug 623152 seems to be what you're hitting11:31
ubot5Launchpad bug 623152 in bzr (Ubuntu) "ValueError: need more than 1 value to unpack in _last_revision_info" [Medium,Triaged] https://launchpad.net/bugs/62315211:31
daubersjelmer: Yeah, looks it. I'll restore them from the backup, probably easiest I think11:32
jelmerdaubers: It's surprising if you're hitting this without an unclean unmount though11:33
daubersjelmer: This is on the remote server, all pushed through sftp11:34
daubersChecked the RAID it's on, and that's fine11:34
jelmerI was going to mention that newer versions of bzr can fsync after updating last-revision, but that doesn't really help if you're using sftp.11:35
jamvila: ugh. package importer is *really* unhappy11:35
jelmervila: ah, this is where it gets interesting11:36
jam1092 failures, all the recent ones are: with key lazr.restfulclient.errors.HTTPError:<module>:main:get_versions:get_debian_versions:__getitem__:get:_request11:36
jelmer(Pdb) print branch.get_config().get_user_option('append_revisions_only')11:36
jelmer(Pdb) print branch.get_append_revisions_only()11:36
vilajam: lp outage11:37
vilajam: requeued11:37
vilajelmer: urgh11:37
vilajelmer: what kind of branch ?11:38
jelmervila: remote. it looks like we have a default get_append_revisions_only() implementation that returns False11:38
jamvila: should those be marked as transient-should-always-be-retried?11:38
jam(you may have already done so)11:39
vilajam: in theory, yes, in practice there are potentially may root causes11:39
vilajam: there is a bug about the importer making tea while lp is down11:39
jamvila: well, lazr.restfulclient.errors.HTTPError sure looks transient to me.11:39
vilajam: in this case yes, but it's not a hard rule11:40
vilajam: not all lp errors are transient11:40
jamvila: sure, though again, I was saying this specific traceback could be marked as auto-retry.11:43
jamAnd the other discussion, all failures should be considered soft-transient, so try X times, and then mark it hard-failure.11:43
jambut that is something else11:44
jamvila: is there a bug # for the .xz thing?11:44
jamI just saw some of the failing imports with it11:44
vilajam: right, but the bug explains that you can't *start* auto-retrying until lp is up again or you end up re-trying too much too soon and it becomes a permanent failure11:44
jamand it would be good to either link it to the bug, or requeue it if it has been fixed11:44
jamvila: sure. Though if you round-robin 500 packages that gives you some time :)11:45
jamEspecially since LP isn't supposed to go down for more than 5min now.11:45
jamthen again, maybe it makes this more important11:45
jamsince they'll be going down 2-3 times / week no11:45
vilajam: feel free to play around with it, I'm just explaining the status quo11:45
jamvila, jelmer: anyway, .tar.xz thing?11:46
vilajam: yes; there is an udd bug for the .xz issue, linked to the upstream bug IIRC11:46
jelmerbzr-builddeb should be able to handle xz now, I haven't seen the bug for the udd issue11:46
jamvila: sure, I mean linked to: http://package-import.ubuntu.com/status/bedtools.html#2011-09-11%2009:29:19.28765211:46
jamthe actual package-importer tracebacks, etc.11:47
vilaha, that, no, not done, patches welcome11:47
jamjelmer: bedtools and qtwebkit-source are at least failing with "unknown extension ...tar.xz"11:47
jamjelmer: did you work out the bz2 issues for the kde packages?11:47
jelmerjam: we need to update to a newer bzr-builddeb on jubany, that should fix it11:48
jelmer(the .tar.xz issue)11:48
jelmerjam: Riddell did, it turns out OpenSUSE's bz2 generates slightly different output because of a patch they ship11:48
jelmerjam: he's filed a bug against pristine-tar: debian bug 64101911:49
ubot5Debian bug 641019 in pristine-tar "pristine-tar does not work with tar files made by openSUSE" [Normal,Open] http://bugs.debian.org/64101911:49
vilajelmer: oh, right, I was about to pull the newer builddeb on jubany and was interrupted by the week-end, thanks for the reminder, I'll do that now11:49
vilajelmer: oh, also, you mentioned detecting dpkgmergechanlog to avoid installing a broken hook ?11:50
jamvila: what's the current procedure for updating the failed-imports => bug #. Is it still just ssh to jubany and manually update the file?11:50
jelmervila: yeah, it would be nice to look into that, but I haven't actually landed any branches which help address that.11:50
vilajam: the explanations file is part of the branch11:51
vilajelmer: ok, np, just checking11:51
vilabuilddeb upgraded on jubany, brace yourselves :)11:51
vilarequieing bedtools (last to fail with .xz)11:52
vilaha crap, forgot --priority11:53
vilaI'll let it purge its queue first11:54
jam447 to go. Not bad, though maybe 1/minute or so?12:05
jamjelmer: on RemoteBranch.get_append_only... I *think* it was meant that you could try to push things, because the real branch on the remote side would refuse it12:07
jamrather than doing a round-trip just to check the bit.12:08
vilajam: try analyze_log with a tail -F from jubany :-p12:08
jelmerjam: ah, that makes sense12:08
jelmerjam: so in that case this is a bug I introduced because I made _get_append_revisions_only public.12:09
jamjelmer: could be. I won't claim 100% accuracy on my understanding.12:11
jamvila: I try not to ssh into jubany unless I must :)12:11
jelmerjam: wrt 2.5-better-gpm-estimate, didn't that branch already land on 2.4?12:12
* jelmer vaguely recalls reviewing something similar earlier12:13
jelmerhmm, maybe I just looked at it earlier and then didn't have time to actually review..12:14
jamjelmer: the estimation changes haven't landed anywhere IIRC12:17
jamthere were 2 or 3 other tweaks to get_parent_map that I've proposed that have landed12:17
jamlet me double check that12:17
jamvila: "tail .../progress_log" | scripts/analyze_log.py -12:18
jamJust gives me "- does not exist"12:18
jamI'm guessing it is an out-of-date udd branch?12:18
jamIs it supposed to be somewhere else?12:18
jam(just running it normally shows average speed of 41s, which is close to my guessed time.)12:20
jamso it will take ~5-7 hrs to finish the backlog.12:20
vilajam: refresh your memory: https://code.launchpad.net/~vila/udd/analyze_log/+merge/7405612:21
jamvila: says merged here, doesn't work on jubany12:23
vilayou don't need it on jubany, you pipe from jubany and execute locally12:23
jam /msg vila seems a bit convoluted12:24
* vila checks with a mirror, a bit tired, yeah, may be, but convoluted...12:30
jamjelmer: any idea why installing python-lzma on natty requires installing python-2.6 ?12:39
jamdoes lzma *only* work on 2.6?12:39
jamor would it be a packaging bug?12:39
jelmerjam: my guess is that it's just a packaging bug12:41
jam ./import_package.py seems to spend an awful lot of time waiting for stuff. It is at 400+s running, and only 20s CPU time.12:52
vilawhich one ?12:54
jamI'm at least poking at the unicode decode errors12:55
jambut so far, I haven't found a version that has anything but ascii12:55
vilathe one I looked at has a NFKD file12:56
vilajam: bah, I mixed bzip2 and .xz issues, no bug for .xz AFAIR, I just mentioned it to jelmer who proposed a fixed that I reviewed13:32
vilathe bzip2 issue has a bug linked to prisitine-tar upstream13:32
jelmervila: debian bug 49948913:34
ubot5Debian bug 499489 in pristine-tar "please add LZMA/XZ/Lzip support" [Wishlist,Open] http://bugs.debian.org/49948913:34
vilajelmer: thanks13:38
vilajelmer: this makes me feel a bit more how prisitine-tar can blow up for the package-importer... as soon as someone starts using a new compressor or a new option... boom13:39
vilajelmer: I wonder if we can be more robust by getting the *tar* and compressing the tar delta instead of trying to get a delta from the compressed form13:40
jamvila: fundamentally the .dsc files contain the sha1 hash of the tar.bz213:41
jelmervila: that won't help - pristine-tar has trouble reproducing the compression13:41
jamwhich is what we are trying to reproduce13:41
vilajelmer: anyway, with your xz patch, all previsous failing imports have now passed13:41
jelmervila: it has no problems with the tar file that is compressed13:41
vilajelmer: aiui, it needs to recognize the compressed form13:42
vilaoh, argh, doomed13:42
=== med_out is now known as medberry
jelmervila: it needs to reproduce the compressed file 100% from the pristine tar delta, which means tracking all the compression parameters13:45
vilayeah, yeah, hence: doomed13:46
jelmerapparently that is fairly tricky for .xz13:46
vilaadding these parameters do the .dsc is not option ? :-}13:47
jelmervila: they are not known by the debian developer either..13:49
vilajelmer: really ? the upstream devs already provide the compressed tarballs ?13:52
jelmervila: in a lot of cases, yes13:52
vilajelmer: how about mentioning the *tarballs* sha sums instead ?13:52
jelmerin some situations the tarball gets repacked, e.g. if it's zipped or if there are non-DFSG-compatible files in it13:52
jelmervila: if we do that, we still can't reproduce the tarball13:53
jelmervila: and we need to reproduce it bit for bit13:53
vilajelmer: I mean: work with the uncompressed  tarballs and generate the deltas for the tarballs, compress the tarballs and the deltas13:54
vilajelmer: this way we still can reproduce the tarballs bit for bit no ?13:54
jelmervila: we have to reproduce the final files, not the tarballs13:55
vilaand we only have to track the tar format and not the compressors formats (which doesn't mention the parameters anyway, at least for bzip2)13:55
jelmervila: we have to reproduce the *compression* as well13:55
vilajelmer: why ?13:56
vilato build the package you extract the tarball anyway, isn't it what matters ?13:56
vilaI understand the practices and toolchains requires the compressed form today, I'm just trying to find an escape from the 'sorry, no idea what parameters were used here, will never be able to reproduce the compressed form' trap13:57
vilawhich is currently blocking the bzip2 produced on Suse with a non-standard bzip213:58
vilaand even there the fix may be doable13:58
Noldorin_hi jelmer14:44
jelmerhi Noldorin_14:45
Noldorin_jelmer, been testing this bzr-git issue over the past few days, but can't seem to get anywhere with it i'm afraid...14:46
jelmerNoldorin_: what have you been testing exactly?14:46
jelmerthat issue you ran into earlier?14:46
Noldorin_jelmer, yes with the unknown git databaser entry... you remember?14:47
Noldorin_i'm trying to merge in parts of the revision that make it fial14:47
Noldorin_but it gives loads of conflicts14:48
Noldorin_not sure how to go about it :-S14:48
Noldorin_have tried a few thigns over the past few days...14:48
jelmerNoldorin_: merging it won't help in this regard, the revision itself would still be processed in its current form14:49
Noldorin_how should i go about testing this problematic r47 then?14:50
jelmerNoldorin_: try creating a new revision on top of r46 which has some of the changes from r47 and see what the minimal set of changes is that triggers the issue14:50
Noldorin_jelmer, but how do i do that specifically?14:51
Noldorin_exactly what i'm trying14:51
Noldorin_it just messes up the whole branch hmm14:51
jelmerNoldorin_: bzr branch -r46 /path/to/original/branch test; then create a new commit with some of the changes from r47, commit, then dpush into git14:51
Noldorin_jelmer, yep yep, but how exactly do i get "some of the changes"?14:52
Noldorin_doing by hand is not practical14:52
Noldorin_there are many many changes14:52
jelmerNoldorin_: you might be able to do "bzr merge ../path/to/individual/file -r47"14:54
jelmerNoldorin_: and do that for every file14:54
jelmerbut you'd have to make sure it doesn't record any pending merges ("bzr st" should display this)14:55
Noldorin_jelmer, wouldn't always record pending merge?14:55
Noldorin_i don't know what the alternative is..14:55
jelmerNoldorin_: you can also revert pending merges with "bzr revert --forget-merges"14:56
Noldorin_ah ok14:57
Riddelljelmer: did you say you were going to upload bzr-explorer 1.2.1 to debian?  it doesn't seem to have arrived14:59
jelmerRiddell: I did say that, and then I got distracted by something else last week. Sorry about that.14:59
jelmerRiddell: I'll have a look at uploading qbzr and bzr-explorer now.14:59
timrcUsing bzrlib, Let's say I create a local branch of a remote tree and make/commit a change in my local working tree.  Do I use "clone_on_transport" to push that change back to the remote tree?15:07
jelmertimrc: hi15:10
jelmertimrc: do you perhaps mean remote branch rather than remote tree?15:10
jelmertimrc: If so, you should be able to use wt.branch.push(Branch.open(remote_url))15:11
timrcthat is pretty much what I have, so far15:11
timrcremote branch, yeah15:11
jelmertimrc: it looks like you indeed want to push to a remote branch (we don't support operations against remote working trees)15:11
timrcjelmer, okay15:12
jelmertimrc: it seems like you indeed want local_branch.push(remote_branch)15:12
jelmertimrc: clone_on_transport creates a clone of the local branch, so would error out saying that a branch already exists (I think)15:12
timrcit has an option, 'use_existing_dir' which threw me off15:13
timrcI was using create_clone_on_transport to create a new remote branch and then using the launchpad mergeProposal API call, but I want to eliminate the mergeProposal step15:13
abentleyjam: around?15:34
vilaRiddell: babune's all red: http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastFailedBuild/testReport/junit/bzrlib.tests.test_transport/TestTransport/test_transport_fallback/15:34
vilaRiddell: how did you manage to pass on pqm ?15:35
vilaRiddell: Ouch, I see, ignore_i18n is called only once and doesn't cleanup at the end of the tests, protecting the others15:38
vilaRiddell: when running with --parallel=fork (as babune does) this works only for test_trans_dependency and break for the other tests15:39
timrcjelmer, that did the trick, thanks15:48
Riddellvila: uh oh15:58
Riddellvila: so test_transport_fallback  is the only one that's failing15:59
Riddellor are there others?15:59
vilaRiddell: I replied to your email about this problematic test but it got delayed locally :-/ Dunno if you got it ?15:59
RiddellI got a reply late on Friday15:59
vilaRiddell: a single one is failing on babune, but given the way we split with --parallel, there is no guarantee that it's the only one15:59
vilaRiddell: i.e. every test that potentially try to mutter() or whatever (exceptions ? str(e)) risk triggering the same issue16:00
Riddellwhy does --parallel affect it?16:00
vilaRiddell: with --parallel, several *process* are involved16:01
vilaRiddell: each one running a slice of the whole test suite16:01
vilaRiddell: the slicing is always the same for a given test suite but can vary as soon as you add or remove a test or change the parametrization or the list goes on16:02
vilaRiddell: monkey-patching like you did is against all isolation rules :)16:02
vilaRiddell: at the very least you should use overrideAttr16:02
vilaRiddell: so the patching is cleaned up at the end of the test16:03
Riddellok, I'll try that16:03
vilaRiddell: moreover, as mentioned in my mail, if the test needs disk resources (and it does as soon as it requires a config file which itself is required by i18n) it should use TestCaseInTempDir or TestCaseWithTransport16:04
vilaRiddell: OR16:04
Riddellwell I'm trying to get it to not use i18n so that's not an issue now surely16:04
vilaRiddell: the failing test has no idea you monkey patched i18n.install, it's running in a different process !16:05
vilaRiddell: an alternative is to force the install of a Null translation for *all* tests (overriden for tests that want to test specific aspects)16:06
Riddellyes that might be an idea16:07
vilaRiddell: I thought there was some code doing that when you started working on i18n but it probably wasn't commented well enough to explain the current issue16:08
Riddellwhere would that be?16:08
vilai18n, let me refresh my memory (may be that was in a mp that never landed)16:08
vilaRiddell: _translations back in revno 599416:09
vilaRiddell: may be incomplete16:10
vilaRiddell: the idea is that it's None until one is installed in the nominal case (i.e. for users)16:11
vilaRiddell: but tests can install whatever they need: either a null one or a test specific one16:12
vilaRiddell: now, poolie may ask you to put that in library_state instead, but I still don't fully understand the library_state story16:12
vilaRiddell: the implementation in bzrlib/i18n.py revno 5994 may be broken, you certainly know better, but the bit that should be applied here is that you don't want a test to trigger an access to a file on disk at any cost16:15
vilaRiddell: revno 5875.3.25 pretty much contains what I'm trying to explain (except for making sure all tests start with a null translation which should be an overrideAttr call in TestCase.setUp() roughly))16:22
Riddellvila: how about this? https://code.launchpad.net/~jr/bzr/i18n-fix-tests/+merge/7503716:33
=== yofel_ is now known as yofel
vilaRiddell: approved, babune will tell you if it's still unhappy ;)16:39
jamabentley: I'm around now if you're still interested in chatting18:22
abentleyjam: cool. Mumble?18:23
jamsure, just a sec18:24
=== beuno is now known as beuno-lunch
=== beuno-lunch is now known as beuno
lamalexguys i really like bzr-colo. thank you!20:15
lamalexit would be really amazing if bzr-colo had some sort of secondary/temporary versioning system that would get rid of unknown files when you did a bzr switch20:17
lamalexi think i could implement that.20:17
fullermdOh right, I forgot I can't bzr check this repo because of symlinks.  Bah.20:29
nigelbfullermd: git stash like? :)20:56
nigelblamalex: ^20:56
lamalexnigelb, yes sort of but implicitily when you changed branches20:57
Noldorin_hey jelmer -- are you aware that bzr-git borks on dpush when there are uncommitted changes?21:07
jelmerNoldorin_: complains or actually tracebacks?21:09
Noldorin_jelmer, just complains i think. i can pastebin if you like?21:09
jelmerNoldorin_: please do; it might be expected behaviour though21:09
Noldorin_jelmer, http://pastebin.com/zs6bL0Yg21:10
jelmerNoldorin_: I think this is just brokenness from the bug you were working on earlier21:11
Noldorin_ah ok21:11
Noldorin_i think so too21:11
Noldorin_it disappears after bzr revert21:11
Noldorin_of course21:11
Noldorin_jelmer, ah wait, i'm just encountering this error again with "workign tree is out of date"21:12
Noldorin_i just did a bzr revert and then bzr st21:12
Noldorin_after that21:12
jelmerNoldorin_: that restores from the repository though, and that might have inconsistent data because of the failed dpush21:18
Noldorin_jelmer, ohh...why shoudl the dpush corrupt the repository data though?21:19
jelmerNoldorin_: because of the bug you hit21:19
Noldorin_oh ok21:19
jelmerwhich is about misrepresenting bzr data in git21:19
Noldorin_jelmer, so these myriad problems are all to do with the bug eh?!21:19
Noldorin_jelmer, i guess i have to reclone the branch and do uncommit/revert for each new test?21:20
jelmerNoldorin_: yep (and not in a shared repository)21:20
Noldorin_ah ok21:20
Noldorin_jelmer, what is a shared repository?21:20
jelmerNoldorin_: in two words, "bzr init-repo"21:20
Noldorin_okay got it21:21
Noldorin_i don't use that, so no problem21:21
Noldorin_jelmer, hmm how can i get a list of changes introduced in r47?21:47
jelmerNoldorin_: bzr log -v -r4721:47
Noldorin_-v was what i needed ;-)21:47
jelmerfrom what I could tell earlier the problem is related to one of the tree shape operations21:48
jelmerrather than the contents changing21:48
Noldorin_well as i mention in the commit message, i restructure the the directory hierarchy in this changeset21:49
Noldorin_jelmer, hence i guess it's the moves/remaming of files/dirs that's messing it up?21:51
jelmerNoldorin_: presumably21:52
Noldorin_*continues checking*21:52
jelmerNoldorin_: really useful would be some sort of recipe that reproduces this issue in a clean branch21:53
jelmerthat way we can add a regression test, then improve the code until it works21:54
Noldorin_i will do some more investigation on my branch first though21:54
=== supton__ is now known as supton
nigelbHrm, what time does poolie start his day?23:24
jelmernigelb: usually around now23:28
jelmernigelb: I'm doubting your statements about your regular sleeping times btw :)23:28
nigelbjelmer: okay :)23:28
nigelbI was working23:28
nigelbJust finished :)23:28
nigelbLike, $DAYJOB work.23:28
poolienigelb, hello23:56

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