| AuroraBorealis | so , i have the small changes that i made to make bazaar explorer not freak out when signing commits | 01:41 |
|---|---|---|
| AuroraBorealis | how do i go about making a patch file to submit with the bug report? | 01:41 |
| spiv | AuroraBorealis: 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 |
| AuroraBorealis | ah ok, will try that in a second! | 01:44 |
| spiv | AuroraBorealis: 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 page | 01:45 |
| AuroraBorealis | do i have to do anything on launchpad to push to it? | 01:46 |
| AuroraBorealis | i have not done that before | 01:46 |
| AuroraBorealis | (for a project that isn't mine) | 01:48 |
| AuroraBorealis | or do i click "register a branch" | 01:51 |
| spiv | AuroraBorealis: "bzr push lp:<your_lp_id>/<project_name>/<branch_name>" | 01:56 |
| spiv | AuroraBorealis: 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 |
| AuroraBorealis | yeah i have that | 01:57 |
| spiv | Er, I typoed slightly, it's lp:~<your_lp_name> | 01:57 |
| spiv | e.g. lp:~spiv/bzr/foo | 01:57 |
| AuroraBorealis | how do i link it to a bug in the command line? | 02:01 |
| AuroraBorealis | ironically i can't use bazaar explorer because of the bug i'm trying to fix xD | 02:02 |
| AuroraBorealis | oh --bug | 02:03 |
| maxb | Does that work? The documented option is --fixes | 02:05 |
| AuroraBorealis | yeah its --fixes | 02:06 |
| AuroraBorealis | which i found after googling | 02:06 |
| AuroraBorealis | ok, so i pushed it, its here: https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix | 02:08 |
| AuroraBorealis | will it do something to the bug report after its done 'scanning' the branch? | 02:08 |
| spiv | Yep. | 02:09 |
| spiv | AuroraBorealis: look now | 02:12 |
| AuroraBorealis | hooray! | 02:12 |
| AuroraBorealis | now what | 02:13 |
| AuroraBorealis | do i just wait for someone to do something with it? | 02:18 |
| poolie | hi all | 02:49 |
| AuroraBorealis | hi. | 02:50 |
| Noldorin_ | hi jelmer | 03:21 |
| AfC | I'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 |
| poolie | ouch | 04:34 |
| AfC | Is there a way to get the .deb rebuilt based on new debian/control | 04:34 |
| poolie | was the 4h in buildding the source deb or building the binary? | 04:34 |
| AfC | without doing another 4 hour build? ie, it's just the very outside wrapper that is changing | 04:34 |
| AfC | poolie: binary | 04:34 |
| poolie | oh, without actually recompiling it? | 04:34 |
| poolie | probably | 04:34 |
| AfC | I mean, sure I could do surgery with tar :) but I'm trying to find a more proper way to do it. | 04:35 |
| poolie | dpkg-buildpackage with '-nc' "don't clean" somewhere should do it | 04:35 |
| AfC | The dependency was making "libgmp-dev" (oneiric, unstable) be "libgmp3-dev" (natty) | 04:35 |
| AfC | poolie: ok. I've got a feeling that with builddeb's defaults, the build-dir/ is already gone | 04:36 |
| AfC | [I know it is] | 04:36 |
| poolie | hm, maybe the things you wanted to preserve are already deleted then? | 04:37 |
| poolie | i guess you could force installation without the dependency to test the package, then do a full clean rebuild when you're happy | 04:37 |
| AfC | yeah | 04:37 |
| AfC | Be faster to make an empty package called "libgmp-dev" :/ | 04:39 |
| AfC | poolie: (and, yes, --force-depends has it on board now for testing) | 04:39 |
| poolie | i think there is some way to configure that into dpkg short of making an empty package | 04:40 |
| AfC | I'm guessing that `bzr buildpkg --dont-purge` more or less leads to `-nc` | 04:40 |
| poolie | well, it would make it at least possible to use -nc later | 04:49 |
| vila | hello guys ! | 06:31 |
| poolie | hello vila | 06:51 |
| jam | morning all | 06:54 |
| vila | poolie, jam : _o/ | 06:54 |
| poolie | hi guys | 07:05 |
| poolie | did you do testing of the new pqm that showed a tmpfs didn't help? | 07:05 |
| vila | poolie: replied to your mail, | 07:06 |
| vila | but 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 chroot | 07:06 |
| jam | I'm also surprised about tmpfs, poolie. Didn't you try it locally and found it was quite useful? | 07:19 |
| poolie | yes | 07:19 |
| jam | poolie: 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 |
| poolie | yeah, that is nice | 07:34 |
| poolie | i was just surprised | 07:34 |
| vila | poolie: any idea about further tests ? | 07:35 |
| poolie | i don't see your mail yet | 07:35 |
| lifeless | vila: you did use the tmpfs *in the chroot* right ? | 07:39 |
| lifeless | vila: as opposed to *outside the chroot* | 07:39 |
| lifeless | vila: to test, schroot ...; mount :) | 07:39 |
| vila | lifeless: I don't have access to run such commands ... but I indeed ask to check inside the chroot | 07:41 |
| lifeless | ok. weird. | 07:41 |
| vila | dunno what kind of check was done though... | 07:41 |
| vila | 1f | 07:54 |
| vila | pff | 07:54 |
| vila | grr, I hate it when postfix stop working and I don't notice until someone tells me: 'where is your mail ?' | 08:07 |
| poolie | guys, i might stop soon | 08:39 |
| poolie | vila, lifeless, i reckon perhaps it was broken by the schroot fstab causing the external /tmp to be bound over the internal tmpfs | 08:40 |
| vila | poolie: I had the same kind of feeling but... I trusted our admin | 08:42 |
| vila | attn packagers and installer builders: 2.4.1 has been frozen ;) | 08:44 |
| poolie | good for you | 08: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 | ||
| jelmer | vila: hmm, is it not possible to change a remote branches' configuration? | 10:48 |
| jelmer | maxb: hi | 10:58 |
| jelmer | maxb: bzr-builder fails to build on lucid and maverick with an error from the python helper | 10:59 |
| jelmer | do you perhaps know what's going on there? | 10:59 |
| jelmer | hey Riddell | 10:59 |
| maxb | Do you have a buildlog handy? | 10:59 |
| Riddell | good morning | 10:59 |
| jelmer | maxb: FATAL: python-backport-helper needs updating to know which of python-support or python-central 'bzr-builder' should be build with | 11:01 |
| jelmer | https://launchpadlibrarian.net/79653003/buildlog_ubuntu-lucid-i386.bzr-builder_0.7.1%2Bbzr144~daily10~lucid1_FAILEDTOBUILD.txt.gz | 11:01 |
| maxb | oh, right | 11:01 |
| maxb | Well, the error's pretty clear :-) | 11:01 |
| === zyga-afk is now known as zyga | ||
| jelmer | bzr-builder wasn't in the daily ppa until recently, perhaps it's not in the hardcoded list? | 11:01 |
| maxb | I was being a bit paranoid at the time, perhaps it should just default to python-support | 11:01 |
| jelmer | maxb: it has to be central for all bzr-related packages | 11:02 |
| jelmer | maxb: since they install under bzrlib.plugins | 11:02 |
| jelmer | although defaulting to python-support seems reasonable, given that's also the default e.g. debhelper uses | 11:02 |
| daubers | Hello, 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 |
| jelmer | daubers: what are the contents of your .bzr/branch/last-revision file? | 11:14 |
| daubers | jelmer: It's empty | 11:18 |
| jelmer | daubers: did you perhaps have a recent machine crash after changing that branch? | 11:19 |
| daubers | jelmer: Not as far as I'm aware | 11:19 |
| vila | jelmer: it should be possible to change a remote config, if it's not, it's a bug | 11:28 |
| vila | jelmer: unless you don't have write access of course | 11:28 |
| jelmer | vila: I'm finding that calling set_append_revisions_only(True) doesn't work | 11:28 |
| vila | jelmer: oh, I thought you were referring to either the new design or 'bzr config' | 11:29 |
| vila | jelmer: that's even more surprising given that the package importer did that for a bunch of lp branches | 11:29 |
| daubers | Hmmm.... whatever caused it has caused it on every branch on this box | 11:30 |
| jelmer | daubers: bug 623152 seems to be what you're hitting | 11:31 |
| ubot5 | Launchpad bug 623152 in bzr (Ubuntu) "ValueError: need more than 1 value to unpack in _last_revision_info" [Medium,Triaged] https://launchpad.net/bugs/623152 | 11:31 |
| daubers | jelmer: Yeah, looks it. I'll restore them from the backup, probably easiest I think | 11:32 |
| jelmer | daubers: It's surprising if you're hitting this without an unclean unmount though | 11:33 |
| daubers | jelmer: This is on the remote server, all pushed through sftp | 11:34 |
| daubers | Checked the RAID it's on, and that's fine | 11:34 |
| jelmer | I 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 |
| jam | vila: ugh. package importer is *really* unhappy | 11:35 |
| jelmer | vila: ah, this is where it gets interesting | 11:36 |
| jam | 1092 failures, all the recent ones are: with key lazr.restfulclient.errors.HTTPError:<module>:main:get_versions:get_debian_versions:__getitem__:get:_request | 11:36 |
| jelmer | (Pdb) print branch.get_config().get_user_option('append_revisions_only') | 11:36 |
| jelmer | True | 11:36 |
| jelmer | (Pdb) print branch.get_append_revisions_only() | 11:36 |
| jelmer | False | 11:36 |
| vila | jam: lp outage | 11:37 |
| vila | jam: requeued | 11:37 |
| vila | jelmer: urgh | 11:37 |
| vila | jelmer: what kind of branch ? | 11:38 |
| jelmer | vila: remote. it looks like we have a default get_append_revisions_only() implementation that returns False | 11:38 |
| jam | vila: should those be marked as transient-should-always-be-retried? | 11:38 |
| jam | (you may have already done so) | 11:39 |
| vila | jam: in theory, yes, in practice there are potentially may root causes | 11:39 |
| vila | jam: there is a bug about the importer making tea while lp is down | 11:39 |
| jam | vila: well, lazr.restfulclient.errors.HTTPError sure looks transient to me. | 11:39 |
| vila | jam: in this case yes, but it's not a hard rule | 11:40 |
| vila | jam: not all lp errors are transient | 11:40 |
| jam | vila: sure, though again, I was saying this specific traceback could be marked as auto-retry. | 11:43 |
| jam | And the other discussion, all failures should be considered soft-transient, so try X times, and then mark it hard-failure. | 11:43 |
| jam | but that is something else | 11:44 |
| jam | vila: is there a bug # for the .xz thing? | 11:44 |
| jam | I just saw some of the failing imports with it | 11:44 |
| vila | jam: 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 failure | 11:44 |
| jam | and it would be good to either link it to the bug, or requeue it if it has been fixed | 11:44 |
| jam | vila: sure. Though if you round-robin 500 packages that gives you some time :) | 11:45 |
| jam | Especially since LP isn't supposed to go down for more than 5min now. | 11:45 |
| jam | then again, maybe it makes this more important | 11:45 |
| jam | since they'll be going down 2-3 times / week no | 11:45 |
| jam | now | 11:45 |
| vila | jam: feel free to play around with it, I'm just explaining the status quo | 11:45 |
| jam | vila, jelmer: anyway, .tar.xz thing? | 11:46 |
| vila | jam: yes; there is an udd bug for the .xz issue, linked to the upstream bug IIRC | 11:46 |
| jelmer | bzr-builddeb should be able to handle xz now, I haven't seen the bug for the udd issue | 11:46 |
| jam | vila: sure, I mean linked to: http://package-import.ubuntu.com/status/bedtools.html#2011-09-11%2009:29:19.287652 | 11:46 |
| jam | the actual package-importer tracebacks, etc. | 11:47 |
| vila | ha, that, no, not done, patches welcome | 11:47 |
| jam | jelmer: bedtools and qtwebkit-source are at least failing with "unknown extension ...tar.xz" | 11:47 |
| jam | jelmer: did you work out the bz2 issues for the kde packages? | 11:47 |
| jelmer | jam: we need to update to a newer bzr-builddeb on jubany, that should fix it | 11:48 |
| jelmer | (the .tar.xz issue) | 11:48 |
| jelmer | jam: Riddell did, it turns out OpenSUSE's bz2 generates slightly different output because of a patch they ship | 11:48 |
| jam | ouch | 11:48 |
| jelmer | jam: he's filed a bug against pristine-tar: debian bug 641019 | 11:49 |
| ubot5 | Debian bug 641019 in pristine-tar "pristine-tar does not work with tar files made by openSUSE" [Normal,Open] http://bugs.debian.org/641019 | 11:49 |
| vila | jelmer: 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 now | 11:49 |
| vila | jelmer: oh, also, you mentioned detecting dpkgmergechanlog to avoid installing a broken hook ? | 11:50 |
| jam | vila: 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 |
| jelmer | vila: yeah, it would be nice to look into that, but I haven't actually landed any branches which help address that. | 11:50 |
| vila | jam: the explanations file is part of the branch | 11:51 |
| vila | jelmer: ok, np, just checking | 11:51 |
| vila | builddeb upgraded on jubany, brace yourselves :) | 11:51 |
| vila | requieing bedtools (last to fail with .xz) | 11:52 |
| vila | ha crap, forgot --priority | 11:53 |
| vila | I'll let it purge its queue first | 11:54 |
| jam | 447 to go. Not bad, though maybe 1/minute or so? | 12:05 |
| jam | jelmer: 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 it | 12:07 |
| jam | rather than doing a round-trip just to check the bit. | 12:08 |
| vila | jam: try analyze_log with a tail -F from jubany :-p | 12:08 |
| jelmer | jam: ah, that makes sense | 12:08 |
| jelmer | jam: so in that case this is a bug I introduced because I made _get_append_revisions_only public. | 12:09 |
| jam | jelmer: could be. I won't claim 100% accuracy on my understanding. | 12:11 |
| jam | vila: I try not to ssh into jubany unless I must :) | 12:11 |
| jelmer | jam: wrt 2.5-better-gpm-estimate, didn't that branch already land on 2.4? | 12:12 |
| * jelmer vaguely recalls reviewing something similar earlier | 12:13 | |
| jelmer | hmm, maybe I just looked at it earlier and then didn't have time to actually review.. | 12:14 |
| jam | jelmer: the estimation changes haven't landed anywhere IIRC | 12:17 |
| jam | there were 2 or 3 other tweaks to get_parent_map that I've proposed that have landed | 12:17 |
| jam | let me double check that | 12:17 |
| jam | vila: "tail .../progress_log" | scripts/analyze_log.py - | 12:18 |
| jam | Just gives me "- does not exist" | 12:18 |
| jam | I'm guessing it is an out-of-date udd branch? | 12:18 |
| jam | Is 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 |
| jam | so it will take ~5-7 hrs to finish the backlog. | 12:20 |
| vila | jam: refresh your memory: https://code.launchpad.net/~vila/udd/analyze_log/+merge/74056 | 12:21 |
| jam | vila: says merged here, doesn't work on jubany | 12:23 |
| vila | you don't need it on jubany, you pipe from jubany and execute locally | 12:23 |
| jam | /msg vila seems a bit convoluted | 12:24 |
| * vila checks with a mirror, a bit tired, yeah, may be, but convoluted... | 12:30 | |
| jam | jelmer: any idea why installing python-lzma on natty requires installing python-2.6 ? | 12:39 |
| jam | does lzma *only* work on 2.6? | 12:39 |
| jam | or would it be a packaging bug? | 12:39 |
| jelmer | jam: my guess is that it's just a packaging bug | 12: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 |
| vila | which one ? | 12:54 |
| jam | anon-proxy | 12:55 |
| jam | I'm at least poking at the unicode decode errors | 12:55 |
| jam | but so far, I haven't found a version that has anything but ascii | 12:55 |
| vila | the one I looked at has a NFKD file | 12:56 |
| vila | http://package-import.ubuntu.com/status/acidbase.html#2011-09-01%2007:39:12.274606 | 12:58 |
| vila | jam: bah, I mixed bzip2 and .xz issues, no bug for .xz AFAIR, I just mentioned it to jelmer who proposed a fixed that I reviewed | 13:32 |
| vila | the bzip2 issue has a bug linked to prisitine-tar upstream | 13:32 |
| jelmer | vila: debian bug 499489 | 13:34 |
| ubot5 | Debian bug 499489 in pristine-tar "please add LZMA/XZ/Lzip support" [Wishlist,Open] http://bugs.debian.org/499489 | 13:34 |
| vila | jelmer: thanks | 13:38 |
| vila | jelmer: 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... boom | 13:39 |
| vila | jelmer: 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 form | 13:40 |
| jam | vila: fundamentally the .dsc files contain the sha1 hash of the tar.bz2 | 13:41 |
| jelmer | vila: that won't help - pristine-tar has trouble reproducing the compression | 13:41 |
| jam | which is what we are trying to reproduce | 13:41 |
| vila | jelmer: anyway, with your xz patch, all previsous failing imports have now passed | 13:41 |
| jelmer | vila: it has no problems with the tar file that is compressed | 13:41 |
| vila | jelmer: aiui, it needs to recognize the compressed form | 13:42 |
| vila | oh, argh, doomed | 13:42 |
| === med_out is now known as medberry | ||
| jelmer | vila: it needs to reproduce the compressed file 100% from the pristine tar delta, which means tracking all the compression parameters | 13:45 |
| vila | yeah, yeah, hence: doomed | 13:46 |
| jelmer | apparently that is fairly tricky for .xz | 13:46 |
| vila | adding these parameters do the .dsc is not option ? :-} | 13:47 |
| vila | half-kidding | 13:47 |
| jelmer | vila: they are not known by the debian developer either.. | 13:49 |
| vila | jelmer: really ? the upstream devs already provide the compressed tarballs ? | 13:52 |
| jelmer | vila: in a lot of cases, yes | 13:52 |
| vila | jelmer: how about mentioning the *tarballs* sha sums instead ? | 13:52 |
| jelmer | in some situations the tarball gets repacked, e.g. if it's zipped or if there are non-DFSG-compatible files in it | 13:52 |
| jelmer | vila: if we do that, we still can't reproduce the tarball | 13:53 |
| jelmer | vila: and we need to reproduce it bit for bit | 13:53 |
| vila | jelmer: I mean: work with the uncompressed tarballs and generate the deltas for the tarballs, compress the tarballs and the deltas | 13:54 |
| vila | jelmer: this way we still can reproduce the tarballs bit for bit no ? | 13:54 |
| jelmer | vila: we have to reproduce the final files, not the tarballs | 13:55 |
| vila | and 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 |
| jelmer | vila: we have to reproduce the *compression* as well | 13:55 |
| vila | jelmer: why ? | 13:56 |
| vila | to build the package you extract the tarball anyway, isn't it what matters ? | 13:56 |
| vila | I 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' trap | 13:57 |
| vila | which is currently blocking the bzip2 produced on Suse with a non-standard bzip2 | 13:58 |
| vila | and even there the fix may be doable | 13:58 |
| Noldorin_ | hi jelmer | 14:44 |
| jelmer | hi 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 |
| jelmer | Noldorin_: what have you been testing exactly? | 14:46 |
| jelmer | that 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 fial | 14:47 |
| Noldorin_ | but it gives loads of conflicts | 14:48 |
| Noldorin_ | not sure how to go about it :-S | 14:48 |
| Noldorin_ | have tried a few thigns over the past few days... | 14:48 |
| jelmer | Noldorin_: merging it won't help in this regard, the revision itself would still be processed in its current form | 14:49 |
| Noldorin_ | how should i go about testing this problematic r47 then? | 14:50 |
| jelmer | Noldorin_: 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 issue | 14:50 |
| Noldorin_ | jelmer, but how do i do that specifically? | 14:51 |
| Noldorin_ | exactly what i'm trying | 14:51 |
| Noldorin_ | it just messes up the whole branch hmm | 14:51 |
| jelmer | Noldorin_: bzr branch -r46 /path/to/original/branch test; then create a new commit with some of the changes from r47, commit, then dpush into git | 14:51 |
| Noldorin_ | jelmer, yep yep, but how exactly do i get "some of the changes"? | 14:52 |
| Noldorin_ | doing by hand is not practical | 14:52 |
| Noldorin_ | there are many many changes | 14:52 |
| jelmer | Noldorin_: you might be able to do "bzr merge ../path/to/individual/file -r47" | 14:54 |
| jelmer | Noldorin_: and do that for every file | 14:54 |
| jelmer | but 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 |
| jelmer | Noldorin_: you can also revert pending merges with "bzr revert --forget-merges" | 14:56 |
| Noldorin_ | ah ok | 14:57 |
| Riddell | jelmer: did you say you were going to upload bzr-explorer 1.2.1 to debian? it doesn't seem to have arrived | 14:59 |
| jelmer | Riddell: I did say that, and then I got distracted by something else last week. Sorry about that. | 14:59 |
| jelmer | Riddell: I'll have a look at uploading qbzr and bzr-explorer now. | 14:59 |
| timrc | Using 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 |
| jelmer | timrc: hi | 15:10 |
| jelmer | timrc: do you perhaps mean remote branch rather than remote tree? | 15:10 |
| jelmer | timrc: If so, you should be able to use wt.branch.push(Branch.open(remote_url)) | 15:11 |
| timrc | http://paste.ubuntu.com/687688/ | 15:11 |
| timrc | that is pretty much what I have, so far | 15:11 |
| timrc | remote branch, yeah | 15:11 |
| jelmer | timrc: it looks like you indeed want to push to a remote branch (we don't support operations against remote working trees) | 15:11 |
| timrc | jelmer, okay | 15:12 |
| jelmer | timrc: it seems like you indeed want local_branch.push(remote_branch) | 15:12 |
| jelmer | timrc: clone_on_transport creates a clone of the local branch, so would error out saying that a branch already exists (I think) | 15:12 |
| timrc | it has an option, 'use_existing_dir' which threw me off | 15:13 |
| timrc | I 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 step | 15:13 |
| abentley | jam: around? | 15:34 |
| vila | Riddell: 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 |
| vila | Riddell: how did you manage to pass on pqm ? | 15:35 |
| vila | Riddell: Ouch, I see, ignore_i18n is called only once and doesn't cleanup at the end of the tests, protecting the others | 15:38 |
| vila | Riddell: when running with --parallel=fork (as babune does) this works only for test_trans_dependency and break for the other tests | 15:39 |
| vila | test_transport_dependency | 15:39 |
| timrc | jelmer, that did the trick, thanks | 15:48 |
| Riddell | vila: uh oh | 15:58 |
| Riddell | vila: so test_transport_fallback is the only one that's failing | 15:59 |
| Riddell | or are there others? | 15:59 |
| vila | Riddell: I replied to your email about this problematic test but it got delayed locally :-/ Dunno if you got it ? | 15:59 |
| Riddell | I got a reply late on Friday | 15:59 |
| vila | Riddell: a single one is failing on babune, but given the way we split with --parallel, there is no guarantee that it's the only one | 15:59 |
| vila | Riddell: i.e. every test that potentially try to mutter() or whatever (exceptions ? str(e)) risk triggering the same issue | 16:00 |
| Riddell | why does --parallel affect it? | 16:00 |
| vila | Riddell: with --parallel, several *process* are involved | 16:01 |
| vila | Riddell: each one running a slice of the whole test suite | 16:01 |
| vila | Riddell: 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 on | 16:02 |
| vila | Riddell: monkey-patching like you did is against all isolation rules :) | 16:02 |
| vila | Riddell: at the very least you should use overrideAttr | 16:02 |
| Riddell | fg | 16:03 |
| Riddell | tsk | 16:03 |
| vila | Riddell: so the patching is cleaned up at the end of the test | 16:03 |
| Riddell | ok, I'll try that | 16:03 |
| vila | Riddell: 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 TestCaseWithTransport | 16:04 |
| vila | Riddell: OR | 16:04 |
| Riddell | well I'm trying to get it to not use i18n so that's not an issue now surely | 16:04 |
| vila | Riddell: the failing test has no idea you monkey patched i18n.install, it's running in a different process ! | 16:05 |
| vila | Riddell: 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 |
| Riddell | yes that might be an idea | 16:07 |
| vila | Riddell: 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 issue | 16:08 |
| Riddell | where would that be? | 16:08 |
| vila | i18n, let me refresh my memory (may be that was in a mp that never landed) | 16:08 |
| vila | Riddell: _translations back in revno 5994 | 16:09 |
| vila | Riddell: may be incomplete | 16:10 |
| vila | Riddell: the idea is that it's None until one is installed in the nominal case (i.e. for users) | 16:11 |
| vila | Riddell: but tests can install whatever they need: either a null one or a test specific one | 16:12 |
| vila | Riddell: now, poolie may ask you to put that in library_state instead, but I still don't fully understand the library_state story | 16:12 |
| vila | Riddell: 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 cost | 16:15 |
| vila | Riddell: 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 |
| Riddell | vila: how about this? https://code.launchpad.net/~jr/bzr/i18n-fix-tests/+merge/75037 | 16:33 |
| === yofel_ is now known as yofel | ||
| vila | Riddell: approved, babune will tell you if it's still unhappy ;) | 16:39 |
| Riddell | merci | 16:39 |
| jam | abentley: I'm around now if you're still interested in chatting | 18:22 |
| abentley | jam: cool. Mumble? | 18:23 |
| jam | sure, just a sec | 18:24 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| lamalex | guys i really like bzr-colo. thank you! | 20:15 |
| lamalex | it 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 switch | 20:17 |
| lamalex | i think i could implement that. | 20:17 |
| fullermd | Oh right, I forgot I can't bzr check this repo because of symlinks. Bah. | 20:29 |
| nigelb | fullermd: git stash like? :) | 20:56 |
| nigelb | gah | 20:56 |
| nigelb | lamalex: ^ | 20:56 |
| lamalex | nigelb, yes sort of but implicitily when you changed branches | 20:57 |
| Noldorin_ | hey jelmer -- are you aware that bzr-git borks on dpush when there are uncommitted changes? | 21:07 |
| jelmer | Noldorin_: complains or actually tracebacks? | 21:09 |
| Noldorin_ | jelmer, just complains i think. i can pastebin if you like? | 21:09 |
| jelmer | Noldorin_: please do; it might be expected behaviour though | 21:09 |
| Noldorin_ | okay | 21:10 |
| Noldorin_ | jelmer, http://pastebin.com/zs6bL0Yg | 21:10 |
| jelmer | Noldorin_: I think this is just brokenness from the bug you were working on earlier | 21:11 |
| Noldorin_ | ah ok | 21:11 |
| Noldorin_ | i think so too | 21:11 |
| Noldorin_ | it disappears after bzr revert | 21:11 |
| Noldorin_ | of course | 21:11 |
| Noldorin_ | jelmer, ah wait, i'm just encountering this error again with "workign tree is out of date" | 21:12 |
| Noldorin_ | :-S | 21:12 |
| Noldorin_ | weird | 21:12 |
| Noldorin_ | i just did a bzr revert and then bzr st | 21:12 |
| Noldorin_ | after that | 21:12 |
| jelmer | Noldorin_: that restores from the repository though, and that might have inconsistent data because of the failed dpush | 21:18 |
| Noldorin_ | jelmer, ohh...why shoudl the dpush corrupt the repository data though? | 21:19 |
| jelmer | Noldorin_: because of the bug you hit | 21:19 |
| Noldorin_ | oh ok | 21:19 |
| jelmer | which is about misrepresenting bzr data in git | 21:19 |
| Noldorin_ | jelmer, so these myriad problems are all to do with the bug eh?! | 21:19 |
| jelmer | basically | 21:20 |
| Noldorin_ | jelmer, i guess i have to reclone the branch and do uncommit/revert for each new test? | 21:20 |
| jelmer | Noldorin_: yep (and not in a shared repository) | 21:20 |
| Noldorin_ | ah ok | 21:20 |
| Noldorin_ | jelmer, what is a shared repository? | 21:20 |
| jelmer | Noldorin_: in two words, "bzr init-repo" | 21:20 |
| Noldorin_ | okay got it | 21:21 |
| Noldorin_ | i don't use that, so no problem | 21:21 |
| Noldorin_ | jelmer, hmm how can i get a list of changes introduced in r47? | 21:47 |
| jelmer | Noldorin_: bzr log -v -r47 | 21:47 |
| Noldorin_ | thanks | 21:47 |
| Noldorin_ | -v was what i needed ;-) | 21:47 |
| jelmer | from what I could tell earlier the problem is related to one of the tree shape operations | 21:48 |
| jelmer | rather than the contents changing | 21:48 |
| Noldorin_ | yes | 21:49 |
| Noldorin_ | well as i mention in the commit message, i restructure the the directory hierarchy in this changeset | 21:49 |
| Noldorin_ | hmm | 21:49 |
| Noldorin_ | jelmer, hence i guess it's the moves/remaming of files/dirs that's messing it up? | 21:51 |
| jelmer | Noldorin_: presumably | 21:52 |
| Noldorin_ | okay | 21:52 |
| Noldorin_ | *continues checking* | 21:52 |
| jelmer | Noldorin_: really useful would be some sort of recipe that reproduces this issue in a clean branch | 21:53 |
| jelmer | s/clean/empty/ | 21:53 |
| jelmer | that way we can add a regression test, then improve the code until it works | 21:54 |
| Noldorin_ | yep | 21:54 |
| Noldorin_ | i will do some more investigation on my branch first though | 21:54 |
| === supton__ is now known as supton | ||
| nigelb | Hrm, what time does poolie start his day? | 23:24 |
| jelmer | nigelb: usually around now | 23:28 |
| jelmer | nigelb: I'm doubting your statements about your regular sleeping times btw :) | 23:28 |
| nigelb | jelmer: okay :) | 23:28 |
| nigelb | haha | 23:28 |
| nigelb | I was working | 23:28 |
| nigelb | Just finished :) | 23:28 |
| nigelb | Like, $DAYJOB work. | 23:28 |
| poolie | nigelb, hello | 23:56 |
| nigelb | Morning! | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!