| * jelmer waves | 00:01 | |
| jelmer | maxb: I wonder if it would make sense to add these to a separate PPA | 00:01 |
|---|---|---|
| jelmer | surely we're not the only ones facing these backport issues? | 00:01 |
| jelmer | at least, I wouldn't mind using your backports in the subvertpy and dulwich PPA's | 00:02 |
| maxb | Conceivably. Though especially where debhelper is concerned, I'm aware I'm not caring about things like changes concerning udev rules and kernel modules, because I know the backport only needs to work for bzr stuff | 00:25 |
| poolie | hi spiv | 00:26 |
| spiv | Hi poolie. | 00:31 |
| spiv | The patch to make Twisted's error handling is inching closer to approval. | 00:32 |
| poolie | oh good | 00:32 |
| mgz | did maxb's issue with my pyrex change not updating his C files get resolved the other evening? | 00:33 |
| spiv | mgz: doesn't look like it: https://code.launchpad.net/~bzr/+recipe/bzr-daily | 00:40 |
| mgz | okay, I understand that page now, confusing. | 00:44 |
| mgz | 'successful' is a lie, cog-and-stop-sign is truth. | 00:44 |
| mgz | so, setup.py needs fixing somehow... | 00:47 |
| mgz | or that script is bypassing our setup.py somehow? the log makes no sense to me, the only pyrex mentions are from apt, but is something went wrong with recreating the C files there should be a note printed | 00:54 |
| mgz | what does `dh_auto_build --buildsystem=python_distutils` do? | 00:54 |
| poolie | i'm going to flush out some underway patches and then go back to colo/ui3 | 00:55 |
| poolie | mgz, good point about testtools matchers | 00:55 |
| poolie | that exists in the testtools we use on pqm so i'll rework my patch to do that | 00:56 |
| spiv | mgz: IIRC, it appears it is getting the .c files from the debian packaging branch, and not regenerating them | 01:05 |
| spiv | mgz: I don't know why it doesn't run pyrex though, it even build-depends: python-pyrex, and it would seem like a sensible thing to do | 01:05 |
| mgz | spiv: I'm trying to work out how that's happening, our setup.py should print a log message if it's not running pyrex | 01:07 |
| mgz | I may just file a bug and leave it for someone who knows debian better. | 01:07 |
| poolie | thanks for the review mgz | 01:46 |
| poolie | re bug 746859 | 01:46 |
| ubot5 | Launchpad bug 746859 in Bazaar "Daily builds not updating Pyrex generated C source" [Undecided,New] https://launchpad.net/bugs/746859 | 01:46 |
| poolie | this is very strange | 01:46 |
| poolie | i don't think we commit the c files | 01:46 |
| poolie | how can they be out of date? | 01:46 |
| mgz | poolie: re review, I think your code was actually a bit cleverer than the testtools way, I'll file a bug against them for the UDIFF thing. | 01:47 |
| mgz | as that also helps my complaint about unreadable output. | 01:48 |
| mgz | re bug, the thing is there's a pyrex file, and a c file, that need to be in sync after the commit. | 01:48 |
| spiv | poolie: the recipe merges in lp:~debian-bazaar/bzr/unstable-2.4, and that contains the C files | 01:48 |
| mgz | I think the daily builds start from a tarball. | 01:48 |
| mgz | or... what spiv said. | 01:49 |
| mgz | so, there's another bug about the start point being wrong perhaps, but I don't see why the build doesn't update the pyrex generated files | 01:49 |
| spiv | I'm pretty sure this is some sort of hangover from 'debs start with a source tarball and then add packaging goo', although I'm unclear on the precise route between that fact and this problem :) | 01:49 |
| spiv | It may be something like the timestamps of the .c files on disk in the checkout/build area aren't older than the .pyx files, so the build stuff thinks they are up to date. | 01:51 |
| poolie | i agree it seems to make sense to have udiff and ellipsis on by default | 01:51 |
| poolie | you can file for that | 01:51 |
| poolie | the matcher thing seems a bit too java-ish | 01:51 |
| poolie | something more concise is probably possible | 01:51 |
| * mgz agrees with the java-ish-ness | 01:54 | |
| mgz | oh, I take it back the not working, testtools does do the right thing, I just mistyped my example | 01:55 |
| poolie | REPORT_UDIFF gives you a diff when it fails | 01:56 |
| poolie | i think it's normally on in doctest | 01:56 |
| poolie | but not throug this api | 01:56 |
| mgz | provided you remembered to put newlines in the example, apparently. | 01:56 |
| mgz | it's certainly easier to read, it's probably a good default. | 01:58 |
| poolie | mgz i don't think testtools defaults to the right thing | 02:07 |
| poolie | or not in the version i have | 02:07 |
| mgz | no, it defaults to nothing, but I thought it ignored the report flag entirely (because I'd not supplied a multiline example) | 02:09 |
| mgz | in other words, ignore me! | 02:10 |
| poolie | spiv, what's the easiest or most python way to just make a random object that has an attribute | 04:21 |
| poolie | i see you can no longer assign to instances of object() | 04:21 |
| spiv | Easiest: random_obj = type('Random', () {}) | 04:23 |
| spiv | Most pythonic probably involves actually using the class statement :) | 04:23 |
| poolie | ! | 04:23 |
| spiv | Er, a missing comma, but you get the idea | 04:23 |
| poolie | is () {} a typo? | 04:23 |
| poolie | oh, i thought that was real magic :) | 04:24 |
| spiv | :) | 04:24 |
| spiv | For values of “easiest” equalling “can be done inside an expression”, anyway… | 04:25 |
| poolie | nice, thanks | 04:26 |
| bob2 | collections.namedtuple yo | 04:36 |
| poolie | mm true | 04:37 |
| poolie | but i think there you need to separately create the class and then the instance? | 04:37 |
| poolie | also it's probabyl not in 2.4 | 04:37 |
| poolie | hi | 04:37 |
| Peng | You can create a namedtuple class and instance in one statement, though. | 04:44 |
| Peng | err, expression | 04:45 |
| poolie | namedtuples(...)(...) | 04:46 |
| poolie | like that? | 04:46 |
| spiv | Right. Actually, that's sort-of true for my suggestion as well. | 04:46 |
| bob2 | ah, 2.4 support, forgot about that :) | 04:46 |
| poolie | yours is nice | 04:47 |
| spiv | Except that classes are also random objects that can have attributes. | 04:47 |
| poolie | type('FakeFoo', (), dict(thing=1)) | 04:47 |
| spiv | Whether you then instantiate the class is a separate question… | 04:47 |
| poolie | spiv you should do https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/54958 for jelmer sometime | 05:04 |
| poolie | not necessarily right now | 05:04 |
| poolie | i wonder if we could get a clean lint | 05:07 |
| poolie | it would catch some things | 05:07 |
| spiv | I regularly use pyflakes (the branch of it that understands lazy_import) on stuff I'm working on | 05:12 |
| vila | hi all ! | 07:48 |
| poolie | hi there vila | 07:49 |
| fullermd | ETOOENTHUSIASTIC | 07:49 |
| vila | :) | 07:49 |
| poolie | vila did we ever get a fix for the bad rendering of options like '--1.14' in ReST? | 07:49 |
| vila | poolie: not that I know of | 07:49 |
| poolie | hi jam? | 07:50 |
| vila | poolie: regarding config, I realize I haven't been clear about what I meant when saying 'implement all this design' | 07:50 |
| poolie | jam i just wondered why you answered https://answers.launchpad.net/bzr/+question/151218 | 07:50 |
| vila | poolie: the option registry is not needed yet (its main point is displaying help) and registring there is optional otherwise and anyway | 07:51 |
| vila | poolie: also, reaching the point where a Store guarantees minimal IOs is not needed yet either since we don't do that today and anyway I'd like some measurements in place before starting to implement it | 07:51 |
| poolie | i think the next steps are deciding on the api | 07:53 |
| vila | poolie: so what I meant was: I'd implement Section (read-only and write), Store and Stack and minimal implementations for the existing global, location and branch config files | 07:53 |
| poolie | and the closely related thing of working out where they'll be held to avoid repeatedly reading them | 07:53 |
| vila | even that can wait since it's an optimization vs what we have today | 07:53 |
| vila | so yeah, deciding on the api | 07:54 |
| vila | poolie: so, which part of the api poses problem ? | 07:55 |
| vila | poolie: hehe, just read bug #746993 :) | 07:58 |
| ubot5 | Launchpad bug 746993 in Bazaar ""bzr help configuration" looks awful" [Medium,Confirmed] https://launchpad.net/bugs/746993 | 07:58 |
| vila | poolie: also, you can do self.skip(reason) instead of raise TestSkipped(reason) | 08:06 |
| vila | poolie: ping ? | 08:14 |
| poolie | hi | 08:16 |
| vila | poolie: so, which part of the api poses problem ? | 08:17 |
| * poolie looks | 08:17 | |
| poolie | vila, i think getting it from a registry is a bit strange | 08:19 |
| poolie | ah | 08:19 |
| poolie | we need to know who will hold, and gc, the objects | 08:19 |
| vila | 'it' ? config ? option ? | 08:20 |
| poolie | i guess the branch or whatever is supposed to get one when it's first created | 08:20 |
| vila | yeah | 08:20 |
| poolie | shoudl we talk here or mail? | 08:20 |
| vila | as you see fit, here may be more effective though | 08:20 |
| vila | err, efficient ? | 08:20 |
| vila | both ? :D | 08:20 |
| poolie | i'll answer mail first | 08:22 |
| vila | ok | 08:22 |
| vila | ping me then ;) | 08:22 |
| poolie | why did you want "config.regsitry.get('bazaar', location)." ? | 08:23 |
| vila | I think I said "didn't" in the mail but there are two cases: | 08:25 |
| vila | if you have an already known bzrdir (branch, wt, etc), this should be used as it will already grab the relevant sections in bazaar | 08:25 |
| vila | but there could be cases where you don't have a bzrdir, so selection the relevant sections from bazaar should still be possible | 08:26 |
| vila | how stacks are built are still a bit unclear but some rules should already be pretty clear: command-line options, os.environ and bzrlib-defined default values should appear in the stack around the sections from the config file | 08:28 |
| maxb | jelmer: Hi. Do you think it is worth updating ~bzr/ppa with bzr-git snapshots that you put into sid, or should the PPA be left on the latest release? | 08:29 |
| vila | maxb: did you mean ~/bzr/beta ? | 08:29 |
| poolie | ok, so it seems like moving things that currently construct configs to instead get a .config_stack from their object would be good | 08:30 |
| maxb | vila: That would be the *other* thing we could do | 08:31 |
| vila | maxb: putting snapshots in ~bzr/ppa sounds... weird. I thought we agree about using only official releases in stable, now I realize that ppa *always* define a release but you get my point (I hope) | 08:33 |
| vila | poolie: right, that's part of the deployment in my mind | 08:35 |
| vila | poolie: but *that* could be done with a minimal implementation | 08:36 |
| poolie | vila, i think it could be done by just lifting out some common code today | 08:37 |
| poolie | imbw, it may be more complicated | 08:37 |
| poolie | in particular i guess we'd have to make sure it did not cause more io | 08:37 |
| poolie | maxb, vila, fwiw i think shipping snapshots there is fairly ok | 08:38 |
| poolie | ubuntu ships snapshots of some projects | 08:38 |
| vila | poolie: well more IO than one IO by read and by write will be hard :) | 08:38 |
| vila | poolie: in LTS ? And they get updated ? | 08:38 |
| maxb | In this specific case, I'm operating on the basis that "If Jelmer thinks the snapshot is good enough for unstable/testing, I'm happy with it being in the PPA" :-) | 08:41 |
| poolie | yes, in LTS | 08:41 |
| poolie | presumably they get updated by patches, rather than by updating to new snapshots | 08:41 |
| maxb | or not updated at all :-) | 08:42 |
| poolie | vila, specifically, i want to make sure that if there is a case where at the moment we don't read a remote branch.conf, this change should not cause us to start doing so (and thereby doing one more rt) | 08:42 |
| poolie | it's not a blocker just something to watch | 08:42 |
| vila | poolie: +2 | 08:42 |
| poolie | in other news i would love if you, or someone, would fix bug 344013 | 08:43 |
| ubot5 | Launchpad bug 344013 in Bazaar "bzr resolve should automatically resolve conflicted directory deletion" [High,Confirmed] https://launchpad.net/bugs/344013 | 08:43 |
| poolie | seems like it ought to be really easy! | 08:43 |
| vila | poolie: as a workaround: bzr.transform.orphan_policy=move | 08:44 |
| vila | poolie: I don't think it's easy :) | 08:44 |
| vila | or I wouldn't have proposed orphans ;) | 08:44 |
| poolie | nb this is (i think) the specific case where i've just rm -r'd the directory | 08:45 |
| poolie | is it really hard to notice that? | 08:45 |
| vila | no, what is hard is to extend the automatic resolution properly | 08:46 |
| vila | (from memory) | 08:46 |
| vila | and that may also be related to a single object being involved in several conflicts | 08:47 |
| vila | imbw | 08:47 |
| poolie | yes, i can imagine it might need some infrastructural work to the resolution machinery to make it possible to express this | 08:50 |
| vila | poolie: you should try bzr.transform.orphan_policy too, since it's off by default and it triggers rarely when on, I got almost no feedback there | 08:51 |
| vila | poolie: it's active here and on babune | 08:51 |
| poolie | what do i set it to? | 08:52 |
| vila | <vila> poolie: as a workaround: bzr.transform.orphan_policy=move | 08:52 |
| poolie | ok, set | 08:52 |
| vila | bzr help bzr.transform.orphan_policy | 08:52 |
| vila | NIY :D | 08:52 |
| poolie | i was just going to say that :) | 08:52 |
| vila | joke aside, I'm not sure about how this should work from the command line | 08:53 |
| vila | just DWIM ? | 08:53 |
| poolie | i'll file a thing for it | 08:53 |
| poolie | https://bugs.launchpad.net/bzr/+bug/747050 | 08:57 |
| ubot5 | Ubuntu bug 747050 in Bazaar "want per-configuration-variable help" [Medium,Confirmed] | 08:57 |
| vila | poolie: thanks ! | 08:59 |
| vila | poolie: http://paste.ubuntu.com/588152/ 'their configuration' ? | 09:08 |
| vila | poolie: is that: a Store needs to know where its lockdir is or some other config option specific to the lock dir ? | 09:09 |
| poolie | per-lockdir configuration | 09:09 |
| poolie | eg, whether to automatically steal apparently dead locks | 09:09 |
| vila | ha | 09:09 |
| poolie | people probably don't want to actually set this per lockdir, but they might well want it per location | 09:10 |
| vila | right, there is a chicken and egg issue there as config files needs a lock to access the file | 09:10 |
| vila | so, yeah, probably something global but per-location | 09:10 |
| vila | which can't be specified in the config file obviously | 09:11 |
| vila | unless we special case bazaar.conf | 09:12 |
| vila | >-/ | 09:12 |
| jam | poolie: I responded before I finished reading the rest of my email | 09:21 |
| poolie | ah i thought that was probably it - you were reading it in non-threaded mode or something | 09:22 |
| poolie | i wondered a bit if there was a mail delay as has happened in the past | 09:22 |
| poolie | jam, vila, is there a technical distinction between a checkout and a bound branch in bzr? | 09:35 |
| vila | hehe, I'd say: you can't unbind a lightweight checkout ? | 09:36 |
| vila | I never use checkouts, I only use branches, sometimes bound. | 09:37 |
| poolie | ok, so the difference is that a lightweight branch has a 'reference' type branch inside it, rather than a bound branch | 09:38 |
| vila | I'd love to replace looms/pipelines with colocated branches and integrate switch/up-thread/pump into core. | 09:38 |
| poolie | me too | 09:38 |
| vila | me too on branches or replacing ? | 09:39 |
| poolie | i also would love to do that | 09:39 |
| poolie | i mostly use colo branches, with some regular branches (in a repository), and occasionally checkouts | 09:40 |
| vila | and adding colocated support via branch.conf should also be doable without a format bump by duplicating last-revision (or even last-loom (hmm, tricky one ;)) from some 'current' definition in branch.conf | 09:41 |
| vila | that was a shameless plug ;) | 09:42 |
| poolie | hm | 09:42 |
| poolie | what is this to accomplish? | 09:42 |
| vila | what ? branch.conf ? Replacing .bzr/branches | 09:43 |
| poolie | oh, to put them all into that file rather than in the .bzr/branches sub directory? | 09:43 |
| * vila nods | 09:43 | |
| vila | This will probably requires versioning branch.conf | 09:43 |
| poolie | i don't know if that particular file is the right place | 09:44 |
| poolie | we can have others | 09:44 |
| vila | which raises the issue of conflicts there and how to resolve them | 09:44 |
| vila | which can be somehow addressed by having a Store that revert to the last valid committed version (up to the empty file) if a parse error is encountered | 09:45 |
| vila | that won't cover all cases but should ~work | 09:45 |
| vila | but enough blue-skying ;) | 09:45 |
| poolie | hm | 09:46 |
| poolie | i'm wondering how we reconcile having a repository directory (containing branches etc) vs bzr-colo putting the repository just into the single bzrdir | 09:47 |
| vila | forget about it and just use whatever repo is used by the branch ? | 09:48 |
| poolie | so, don't create a repository when the colo is set up? | 09:49 |
| poolie | that could work | 09:49 |
| vila | yup | 09:50 |
| vila | If we trust our fallback repos implementation to be robust, I'm also wondering whether we shouldn't start thinking about repos as a stack of read-only repos and one mutable one | 09:51 |
| vila | ooooh, come on vila, stop with the shameless plugs will you ? | 09:51 |
| poolie | hm, where? | 09:51 |
| poolie | ? | 09:51 |
| vila | well, in most cases we want one repo where we commit but we'd still like to find revisions wherever they are (think having lp as a repo fallback) | 09:52 |
| poolie | right, that could be useful | 09:53 |
| vila | or a local mirror or a ~/.bzr repo as a last resort before requiring a network connection | 09:53 |
| poolie | i think some searches will be slower if there are many of them | 09:53 |
| vila | yup | 09:53 |
| vila | we need a better graph support including optimized queries across the network | 09:54 |
| vila | but each repo should be able to maintain a cache of which revisions are known in each pack file, we can get rid of python bloating such caches by having a C implementation restricted to just a hash with revision-IDs as keys which should still be small enough | 09:56 |
| vila | so that shouldn't be an obstacle to start thinking about such repos at the conceptual level | 09:57 |
| vila | I'm not really introducing new concepts as far as the data model is concerned here, only new ways to use the existing ones | 09:59 |
| poolie | it could be good | 10:07 |
| poolie | i don't think it's very high up the stack | 10:07 |
| poolie | i mean, i don't think adding multiple fallbacks is very urgent compared to other things | 10:09 |
| vila | hmm, I think we already handle multiple fallbacks (but only for stacking), what we don't provide is a way to configure them | 10:21 |
| vila | but yeah, not a top priority so far | 10:21 |
| poolie | i'm wondering if we can deprecated bound branches | 10:26 |
| poolie | just have checkouts with branch references | 10:27 |
| poolie | there's a lot of old mail about this of cours-e | 10:27 |
| === hunger_ is now known as hunger | ||
| poolie | good night all | 10:43 |
| vila | poolie: g'night ! (but gimme my bound branches back ;) | 11:01 |
| === webm0nk3y is now known as jdobrien | ||
| spiv | jelmer: it's nice to see a patch that adds to test_import_tariffs :) | 13:52 |
| jelmer | spiv: Thanks :) | 14:10 |
| jml | hey | 14:10 |
| jml | I'd like to switch to using colo for launchpad hacking | 14:10 |
| jml | please help me | 14:11 |
| jelmer | jml: I don't have any experience using bzr-colo myself, but "bzr help colo-tutorial" should help | 14:14 |
| jml | jelmer: ok, thanks. | 14:19 |
| jam | vila: another "Welcome to Europe" for you. We did manage to get our furniture today. Everything made it in, except we couldn't get our Queen-size (150cm) box springs upstairs. (Neither through a window, nor through the stairway) | 14:20 |
| jam | So now we have to go out and buy split box springs | 14:20 |
| * vila bangs head on desk | 14:20 | |
| vila | jam: wecome back here :-} | 14:21 |
| vila | welcome ggrr | 14:21 |
| vila | jam: try futon ? | 14:23 |
| jelmer | maxb: wrt your question this morning; I don't think it necessarily makes sense to upload snapshots to the beta PPA, it seems that if we're ok with doing that we might as well use the nightly builds | 14:29 |
| jelmer | euhrm, daily builds | 14:29 |
| vila | jelmer: I've got a test_tariff failure locally, probably a plugin, how to you debug that ? | 14:35 |
| vila | found: builddeb | 14:36 |
| vila | jelmer: fixed in trunk, thanks ;) | 14:36 |
| vila | jelmer: don't bother answer my out-dated questions for bugs you already fixed :D | 14:37 |
| jelmer | :) | 14:38 |
| vila | jelmer: I still have failures with bzr-hg tip though ;) | 14:42 |
| jelmer | vila: you mean test import tariff fails if you load bzr-hg ? | 14:42 |
| vila | no no, different failures (re-running) | 14:43 |
| jelmer | ah | 14:43 |
| vila | AttributeError: 'HgRemoteRepository' object has no attribute 'lookup_foreign_revision_id' | 14:44 |
| vila | AttributeError: 'HgLocalBranch' object has no attribute 'generate_revision_history' | 14:44 |
| vila | etc | 14:44 |
| vila | jelmer: urgh, 103 failures 654 errors | 14:50 |
| vila | ./bzr tss -s bt.test_import with hg: ran 3 tests, 1 failure (bzrlib.foreign) | 14:50 |
| vila | meh, not hg 8-/ | 14:50 |
| jelmer | vila: Oh, there's bound to be plenty of those. The per_branch, per_repository and per_workringtree tests don't work against the foreign formats yet, that's still a WIP | 14:53 |
| vila | ok | 14:54 |
| vila | bah, typo in the env var name, *no* tariff test failure when hd is disabled | 14:56 |
| jelmer | vila: when *hg* is disabled ? :) | 14:59 |
| vila | jelmer: yes, the test fails for hg, pass when hg is disabled, well bzr-hg of course ;) | 15:00 |
| jelmer | vila: I suspect we may have to remove bzrlib.foreign from the blacklist, all foreign plugins import from it | 15:05 |
| vila | I thought you put it there to ensure proper lazy loading ? | 15:06 |
| jelmer | no, it was added when the test was initially written (presumably without any foreign plugins loaded) | 15:06 |
| vila | ha ok, then I won't object if you remove it | 15:07 |
| vila | well, if this can't be used to check for lazy loading that is ;) | 15:07 |
| jelmer | vila: bzrlib.foreign is imported to access the foreign vcs registry | 15:09 |
| vila | ... which reminds me that when I looked at the tests I was thinking: "Gee, we certainly need to explain why we blacklist these modules..." | 15:09 |
| vila | jelmer: hehe, back to putting all registries in their own separate file are we ? :D | 15:09 |
| jelmer | vila: None of these has ever changed either way afaik | 15:10 |
| vila | jelmer: .. which doesn't mean that more comments will hurt ;) | 15:10 |
| jelmer | vila: Shouldn't we rather explain why things are not blacklisted though? | 15:10 |
| vila | jelmer: that was a general remark, don't take for you ;) | 15:11 |
| vila | yeah, both will help people encountering failures for this tests | 15:11 |
| vila | test | 15:11 |
| vila | but may be just adding more tariff tests will render that useless | 15:11 |
| jelmer | yeah | 15:14 |
| jelmer | vila: MP proposed :) | 15:30 |
| vila | jelmer: approved | 15:33 |
| jelmer | vila: fwiw I have two more MPs up that add more entries to the blacklist :) | 15:34 |
| jelmer | vila: thanks for the review | 15:34 |
| vila | jelmer: I think *adding* doesn't need review, pqm will block and babune will double-check | 15:35 |
| vanguard | how can I "checkout" a previous commit without uncomming the previous history? | 15:35 |
| vila | .. if a problem arise | 15:36 |
| jelmer | vila: Well, add a lazy import and then add to the blacklist | 15:36 |
| jelmer | vanguard: "bzr branch -r<revno> thebranch newcopy-at-revno" | 15:36 |
| vanguard | jelmer: okay, that sounds expensive ... | 15:37 |
| jelmer | vanguard: You're asking about checking out a new copy - do you just want to reset the current tree? | 15:37 |
| vanguard | jelmer: I just want to take a look at the work I did back then, basically for bisecting and stuff | 15:37 |
| jelmer | vanguard: bzr revert -r<old-revno> | 15:38 |
| vanguard | jelmer: I do not want to base new work on it | 15:38 |
| vanguard | jelmer: but that will kill everything I did since that revision!? | 15:38 |
| jelmer | vanguard: it will only reset the working tree - you can go back by running "bzr revert" after that again | 15:38 |
| vanguard | jelmer: ah, okay, I see. Thanks! | 15:38 |
| vila | vanguard: if your working tree is clean (no uncommitted changes) revert is fine | 15:39 |
| jelmer | alternatively, you could export just that revision to a directory "bzr export -r<revno> /tmp/wt-at-revno" | 15:39 |
| vanguard | okay, that sounds good. | 15:39 |
| vila | vanguard: alternatively, if you can read diffs, bzr qlog/bzr qblame can also be used | 15:39 |
| vanguard | vila: that might work for some cases, but if I need to build a previous version again, that will not help me | 15:40 |
| vila | sure | 15:40 |
| jml | I think running 'bzr colo-ify ../devel' inside a Launchpad working tree might have been a bad idea. | 15:48 |
| jml | hah | 15:50 |
| jml | *after* a very lengthy process I am told: bzr: ERROR: '/home/jml/src/launchpad/stable/' is already a lightweight checkout. | 15:50 |
| james_w | jelmer, hey, was there a decision on https://code.launchpad.net/~jelmer/bzr-builddeb/fix-bz2-repack/+merge/54991 ? | 15:56 |
| james_w | does someone want to take a look at https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/libxklavier/natty-201103311620/+merge/55787 and https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/glib-networking/natty-201103311614/+merge/55785 see if they are legitimate, and if not avoid doing it for similar situations in future | 15:59 |
| james_w | plus https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/gst-plugins-bad0.10/natty-201103311110/+merge/55730 | 16:03 |
| jelmer | james_w: hey | 16:14 |
| jelmer | james_w: Not yet, I'm planning to have another look at it today. | 16:15 |
| james_w | jelmer, great, thanks | 16:15 |
| maxb | james_w: Hi, since you're around, did you see the thread on bazaar@ on whether bzr-builddeb should aim to be able to function and/or run tests on an old distroseries that predates source format 3.0 support in dpkg? | 16:22 |
| james_w | maxb, I did | 16:22 |
| james_w | maxb, and I agree with both of you :-) | 16:22 |
| james_w | hardy shouldn't have a lot of effort put in to it | 16:23 |
| james_w | but the majority of the code and tests should be fine to work without the new features | 16:23 |
| james_w | or is there something fundamental that requires the new version? | 16:23 |
| maxb | only that 'bzr selftest' currently won't pass on hardy | 16:23 |
| maxb | (for builddeb) | 16:23 |
| maxb | So, perhaps have the tests in question require dpkg >= whatever? | 16:24 |
| jelmer | maxb: that seems reasonable | 16:27 |
| james_w | maxb, add a dpkgv3 feature and require it in those tests? | 16:29 |
| james_w | I think that would be fine | 16:29 |
| james_w | but I agree that hardy isn't a particularly important platform for a developer tool | 16:29 |
| jelmer | "Ran 35295 tests in 21.551s" | 16:30 |
| jelmer | Is it me, or does 21 seconds seem longer than it actually is? | 16:31 |
| === deryck is now known as deryck[lunch] | ||
| vila | jelmer: can I have some of your hardware ? I'd *love* run 35.000 tests in 20 secs | 16:45 |
| === Ursinha is now known as Ursinha-lunch | ||
| jelmer | :) | 16:59 |
| jelmer | have a good weekend everyone :) | 17:02 |
| james_w | you too jelmer | 17:03 |
| vila | jelmer: enjoy your week-end ! | 17:09 |
| jam | vila: you to | 17:11 |
| jam | too | 17:11 |
| vila | jam: and you too ;) | 17:11 |
| vila | jam: hope you find a suitable bed ;) | 17:12 |
| jam | vila: well, we still have the matress (which fit), just not the box springs | 17:12 |
| jam | and we have our couches if necessary | 17:12 |
| === beuno is now known as beuno-lunch | ||
| === zyga is now known as zyga-brb | ||
| === zyga-brb is now known as zyga | ||
| === zyga is now known as zyga-dinner | ||
| === beuno-lunch is now known as beuno | ||
| eridu | I keep getting a "KeyError: No such TDB Entry" after trying to check out an SVN repo, even after deleting ~/.cache/bazaar/svn -- how could I figure out what's going on? ~/.bzr.log doesn't seem to be helpful. | 19:21 |
| === Ursinha-lunch is now known as Ursinha | ||
| === zyga-dinner is now known as zyga | ||
| === deryck[lunch] is now known as deryck | ||
| maxb | eridu: Hi, do you have a traceback from ~/.bzr.log? That would usually help debug the issue? | 20:20 |
| maxb | erm, lose that last ?-mark | 20:21 |
| eridu | maxb: yeah, it's on launchpad, lemme grab the link | 20:21 |
| eridu | maxb: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/747633 | 20:21 |
| ubot5 | Ubuntu bug 747633 in bzr (Ubuntu) "bzr crashed with KeyError in get_revision_paths()" [Undecided,New] | 20:21 |
| eridu | maxb: https://launchpadlibrarian.net/67919275/BzrLogTail.txt -- I can upload the rest of it if you want | 20:22 |
| maxb | hmm | 20:22 |
| maxb | Is the source repository public or private? | 20:22 |
| maxb | oh, I see in the bug | 20:23 |
| eridu | yeah | 20:23 |
| maxb | OK, well, this is kind of cheating, but you could try uninstalling the python-tdb package, and seeing if the SQLite-backed cache provides better diagnostics :-) | 20:23 |
| eridu | sure | 20:24 |
| maxb | The other thing that could be interesting would be to modify /home/tedks/.bazaar/plugins/svn/cache/tdbcache.py to catch the KeyError and report what the revnum it is looking for is | 20:24 |
| eridu | well, it seems to be working without python-tdb | 20:27 |
| eridu | oh, no, it gives me this error: bzr: ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for | 20:27 |
| eridu | that's odd, I thought that bug was fixed in bzr-svn 1.0.4 | 20:28 |
| maxb | for ..... ? | 20:28 |
| eridu | for the path to the repo root | 20:28 |
| maxb | hmm | 20:28 |
| maxb | You could consider trying bzr 2.3.1 and bzr-svn 1.0.4+bzr3475 from the ~bzr ppa if you think it may have been fixed after 1.0.4 | 20:29 |
| eridu | sure | 20:31 |
| eridu | upgrading now, though apt is holding back bzr and bzrtools --should I expect that? | 20:34 |
| eridu | with tdb, I get the same error, with bzr-svn 1.0.5dev (reported by bzr plugin) | 20:39 |
| eridu | ...and I get the same error with sqlite | 20:41 |
| maxb | hmm, ok | 20:43 |
| eridu | upgrading bzr to 2.3.1 doesn't help either | 20:43 |
| eridu | it looks like this bug: https://bugs.launchpad.net/bzr-svn/+bug/409668 | 20:44 |
| ubot5 | Ubuntu bug 409668 in Bazaar Subversion Plugin "accesses repository root" [Low,Fix released] | 20:44 |
| ianm_ | I have a local bzr repo (made with 'bzr init') that I'd like to move into a launchpad.net hosted project, can I bring it in with the commit history? | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!