[00:01]  * 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:02] <jelmer> at least, I wouldn't mind using your backports in the subvertpy and dulwich PPA's
[00:25] <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:26] <poolie> hi spiv
[00:31] <spiv> Hi poolie.
[00:32] <spiv> The patch to make Twisted's error handling is inching closer to approval.
[00:32] <poolie> oh good
[00:33] <mgz> did maxb's issue with my pyrex change not updating his C files get resolved the other evening?
[00:40] <spiv> mgz: doesn't look like it: https://code.launchpad.net/~bzr/+recipe/bzr-daily
[00:44] <mgz> okay, I understand that page now, confusing.
[00:44] <mgz> 'successful' is a lie, cog-and-stop-sign is truth.
[00:47] <mgz> so, setup.py needs fixing somehow...
[00:54] <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:55] <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:56] <poolie> that exists in the testtools we use on pqm so i'll rework my patch to do that
[01:05] <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:07] <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:46] <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:47] <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:48] <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:49] <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:51] <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:54]  * mgz agrees with the java-ish-ness
[01:55] <mgz> oh, I take it back the not working, testtools does do the right thing, I just mistyped my example
[01:56] <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:58] <mgz> it's certainly easier to read, it's probably a good default.
[02:07] <poolie> mgz i don't think testtools defaults to the right thing
[02:07] <poolie> or not in the version i have
[02:09] <mgz> no, it defaults to nothing, but I thought it ignored the report flag entirely (because I'd not supplied a multiline example)
[02:10] <mgz> in other words, ignore me!
[04:21] <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:23] <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:24] <poolie> oh, i thought that was real magic :)
[04:24] <spiv> :)
[04:25] <spiv> For values of “easiest” equalling “can be done inside an expression”, anyway…
[04:26] <poolie> nice, thanks
[04:36] <bob2> collections.namedtuple yo
[04:37] <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:44] <Peng> You can create a namedtuple class and instance in one statement, though.
[04:45] <Peng> err, expression
[04:46] <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:47] <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…
[05:04] <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:07] <poolie> i wonder if we could get a clean lint
[05:07] <poolie> it would catch some things
[05:12] <spiv> I regularly use pyflakes (the branch of it that understands lazy_import) on stuff I'm working on
[07:48] <vila> hi all !
[07:49] <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:50] <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:51] <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:53] <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:54] <vila> so yeah, deciding on the api
[07:55] <vila> poolie: so, which part of the api poses problem ?
[07:58] <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
[08:06] <vila> poolie: also, you can do self.skip(reason) instead of raise TestSkipped(reason)
[08:14] <vila> poolie: ping ?
[08:16] <poolie> hi
[08:17] <vila> poolie: so, which part of the api poses problem ?
[08:17]  * poolie looks
[08:19] <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:20] <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:22] <poolie> i'll answer mail first
[08:22] <vila> ok
[08:22] <vila> ping me then ;)
[08:23] <poolie> why did you want "config.regsitry.get('bazaar', location)." ?
[08:25] <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:26] <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:28] <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:29] <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:30] <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:31] <maxb> vila: That would be the *other* thing we could do
[08:33] <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:35] <vila> poolie: right, that's part of the deployment in my mind
[08:36] <vila> poolie: but *that* could be done with a minimal implementation
[08:37] <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:38] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <vila> no, what is hard is to extend the automatic resolution properly
[08:46] <vila> (from memory)
[08:47] <vila> and that may also be related to a single object being involved in several conflicts
[08:47] <vila> imbw
[08:50] <poolie> yes, i can imagine it might need some infrastructural work to the resolution machinery to make it possible to express this
[08:51] <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:52] <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:53] <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:57] <poolie> https://bugs.launchpad.net/bzr/+bug/747050
[08:57] <ubot5> Ubuntu bug 747050 in Bazaar "want per-configuration-variable help" [Medium,Confirmed]
[08:59] <vila> poolie: thanks !
[09:08] <vila> poolie: http://paste.ubuntu.com/588152/ 'their configuration' ?
[09:09] <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:10] <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:11] <vila> which can't be specified in the config file obviously
[09:12] <vila> unless we special case bazaar.conf
[09:12] <vila> >-/
[09:21] <jam>  poolie: I responded before I finished reading the rest of my email
[09:22] <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:35] <poolie> jam, vila, is there a technical distinction between a checkout and a bound branch in bzr?
[09:36] <vila> hehe, I'd say: you can't unbind a lightweight checkout ?
[09:37] <vila> I never use checkouts, I only use branches, sometimes bound.
[09:38] <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:39] <vila> me too on branches or replacing ?
[09:39] <poolie> i also would love to do that
[09:40] <poolie> i mostly use colo branches, with some regular branches (in a repository), and occasionally checkouts
[09:41] <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:42] <vila> that was a shameless plug ;)
[09:42] <poolie> hm
[09:42] <poolie> what is this to accomplish?
[09:43] <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:44] <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:45] <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:46] <poolie> hm
[09:47] <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:48] <vila> forget about it and just use whatever repo is used by the branch ?
[09:49] <poolie> so, don't create a repository when the colo is set up?
[09:49] <poolie> that could work
[09:50] <vila> yup
[09:51] <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:52] <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:53] <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:54] <vila> we need a better graph support including optimized queries across the network
[09:56] <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:57] <vila> so that shouldn't be an obstacle to start thinking about such repos at the conceptual level
[09:59] <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
[10:07] <poolie> it could be good
[10:07] <poolie> i don't think it's very high up the stack
[10:09] <poolie> i mean, i don't think adding multiple fallbacks is very urgent compared to other things
[10:21] <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:26] <poolie> i'm wondering if we can deprecated bound branches
[10:27] <poolie> just have checkouts with branch references
[10:27] <poolie> there's a lot of old mail about this of cours-e
=== hunger_ is now known as hunger
[10:43] <poolie> good night all
[11:01] <vila> poolie: g'night ! (but gimme my bound branches back ;)
=== webm0nk3y is now known as jdobrien
[13:52] <spiv> jelmer: it's nice to see a patch that adds to test_import_tariffs :)
[14:10] <jelmer> spiv: Thanks :)
[14:10] <jml> hey
[14:10] <jml> I'd like to switch to using colo for launchpad hacking
[14:11] <jml> please help me
[14:14] <jelmer> jml: I don't have any experience using bzr-colo myself, but "bzr help colo-tutorial" should help
[14:19] <jml> jelmer: ok, thanks.
[14:20] <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:21] <vila> jam: wecome back here :-}
[14:21] <vila> welcome ggrr
[14:23] <vila> jam: try futon ?
[14:29] <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:35] <vila> jelmer: I've got a test_tariff failure locally, probably a plugin, how to you debug that ?
[14:36] <vila> found: builddeb
[14:36] <vila> jelmer: fixed in trunk, thanks ;)
[14:37] <vila> jelmer: don't bother answer my out-dated questions for bugs you already fixed :D
[14:38] <jelmer> :)
[14:42] <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:43] <vila> no no, different failures (re-running)
[14:43] <jelmer> ah
[14:44] <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:50] <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:53] <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:54] <vila> ok
[14:56] <vila> bah, typo in the env var name, *no* tariff test failure when hd is disabled
[14:59] <jelmer> vila: when *hg* is disabled ? :)
[15:00] <vila> jelmer: yes, the test fails for hg, pass when hg is disabled, well bzr-hg of course ;)
[15:05] <jelmer> vila: I suspect we may have to remove bzrlib.foreign from the blacklist, all foreign plugins import from it
[15:06] <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:07] <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:09] <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:10] <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:11] <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:14] <jelmer> yeah
[15:30] <jelmer> vila: MP proposed :)
[15:33] <vila> jelmer: approved
[15:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:48] <jml> I think running 'bzr colo-ify ../devel' inside a Launchpad working tree might have been a bad idea.
[15:50] <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:56] <james_w> jelmer, hey, was there a decision on https://code.launchpad.net/~jelmer/bzr-builddeb/fix-bz2-repack/+merge/54991 ?
[15:59] <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
[16:03] <james_w> plus https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/gst-plugins-bad0.10/natty-201103311110/+merge/55730
[16:14] <jelmer> james_w: hey
[16:15] <jelmer> james_w: Not yet, I'm planning to have another look at it today.
[16:15] <james_w> jelmer, great, thanks
[16:22] <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:23] <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:24] <maxb> So, perhaps have the tests in question require dpkg >= whatever?
[16:27] <jelmer> maxb: that seems reasonable
[16:29] <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:30] <jelmer> "Ran 35295 tests in 21.551s"
[16:31] <jelmer> Is it me, or does 21 seconds seem longer than it actually is?
=== deryck is now known as deryck[lunch]
[16:45] <vila> jelmer: can I have some of your hardware ? I'd *love* run 35.000 tests in 20 secs
=== Ursinha is now known as Ursinha-lunch
[16:59] <jelmer> :)
[17:02] <jelmer> have a good weekend everyone :)
[17:03] <james_w> you too jelmer
[17:09] <vila> jelmer: enjoy your week-end !
[17:11] <jam> vila: you to
[17:11] <jam> too
[17:11] <vila> jam: and you too ;)
[17:12] <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
=== 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
[19:21] <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.
=== Ursinha-lunch is now known as Ursinha
=== zyga-dinner is now known as zyga
=== deryck[lunch] is now known as deryck
[20:20] <maxb> eridu: Hi, do you have a traceback from ~/.bzr.log? That would usually help debug the issue?
[20:21] <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:22] <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:23] <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:24] <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:27] <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:28] <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:29] <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:31] <eridu> sure
[20:34] <eridu> upgrading now, though apt is holding back bzr and bzrtools --should I expect that?
[20:39] <eridu> with tdb, I get the same error, with bzr-svn 1.0.5dev (reported by bzr plugin)
[20:41] <eridu> ...and I get the same error with sqlite
[20:43] <maxb> hmm, ok
[20:43] <eridu> upgrading bzr to 2.3.1 doesn't help either
[20:44] <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]
[23:41] <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?