[00:13] <poolie> hi spiv, how are you? and what fabulous adventures will you have today?
[00:16] <spiv> poolie: working towards bug 309682; I have a patch that works, but polishing all the little issues the patch glosses over is surprisingly involved.
[00:16] <poolie> how about a catch up call in a few minutes?
[00:16] <spiv> Sure
[07:26] <vila> hi all !
[07:43] <GaryvdM> Hi vila, Hi all
[07:43] <vila> GaryvdM: hey !
[07:50] <GaryvdM> vila: I hope you don't mind me asking about test writing a test. For bug 588698. The current tests that deal with merging merging new roots, crisscross merges, etc only check the shape of the graph after the merge. There are no asserts on the state of the files in the wt. This is done in other test that don't look at the shape of the graph. Would it be ok if my test for this bug did both?
[07:51] <vila> GaryvdM: if you feel the need then go for it
[07:51] <vila> there is no absolute rules about what a test *must* check
[07:52] <GaryvdM> Ok
[07:52] <vila> too little is as bad as too much but this can be rather subjective at times
[07:53] <GaryvdM> I would like to do both, because I'm not sure exactly it should work, and I would like to define it in a test.
[07:57] <vila> GaryvdM: may be two tests then ?
[07:58] <vila> GaryvdM: or more :)
[07:59] <vila> GaryvdM: ideally a test should check one thing to enhance the overall defect localization
[07:59] <GaryvdM> vila: But the actions that the 2 test would perform would overlap 95%
[08:00] <vila> GaryvdM: that is, a single defect is caught by at least one test which makes it obvious what the defect is or at least narrow down the code that needs to be investigated
[08:01] <vila> GaryvdM: it's hard for me to judge without concrete examples, but sometimes this indicates tests that are too high-level
[08:01] <vila> GaryvdM: in this case drilling down to get closer to the code you want to test avoid the duplication
[08:03] <vila> GaryvdM: in some cases though, due to some bad layering, you just can't avoid it so just go for the duplication but add comments or FIXME explaining the issue
[08:03] <GaryvdM> Ok
[08:04] <vila> GaryvdM: feel free to submit early versions for feedback, MPs can be used for that too (if properly explained)
[08:04] <spiv> GaryvdM: the first thing to optimise for in a test is clarity
[08:05] <spiv> GaryvdM: refactoring to reduce duplication is often helpful for that goal of course :)
[08:05] <poolie> hello vila
[08:05] <vila> poolie: hey !
[08:05] <spiv> GaryvdM: but it's important that the *intent* of a test is clear: if it's not, then when it fails, or when it needs to be updated for API or behaviour changes, then it's unclear what should be done.
[08:05] <vila> poolie: dear PP, I havean MP approved but its pre-requisite, could you help me ? https://code.edge.launchpad.net/~vila/bzr/671050-config-policy/+merge/40343
[08:06] <vila> s/but its/but not its/
[08:06] <spiv> GaryvdM: so if there are multiple aspects you want to verify it can be clearest to make multiple tests, so that each can have one explicit purpose.
[08:07] <GaryvdM> ok
[08:12] <spiv> GaryvdM: where I find it gets tricky is when I'm not sure yet what the behaviour should be, and I'm writing the test to help me discover that... :)
[08:12] <GaryvdM> spiv: And that is the case here...
[08:12] <spiv> But I guess it's like any other sort of authoring: you just keep revising till it makes good sense.
[08:12] <poolie> vila, done, thanks for asking
[08:14] <spiv> GaryvdM: so it's fine to start with an exploratory test (or tests) that probably do too much, so long as you are aware that once you've explored and hopefully understood the new territory it's probably worth reviewing the tests.
[08:14] <spiv> GaryvdM: (yes that sentence has lots of qualifiers, I'm not sure these are hard-and-fast rules...)
[08:15] <vila> poolie: great ! I'll tweak the comment, that's a point with quite deep implications that should be better addressed with the new config scheme but some parts are still unclear in my mind, so yes, a FIXME is appropriate
[08:16] <vila> spiv: should we talk about https://code.edge.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406 ?
[08:17] <spiv> vila: I chatted with poolie about it a bit
[08:18] <spiv> vila: on one hand, I'm pretty confident about the backwards compat stuff... but on the other the bug report has been pretty quiet, so the urgency for getting it in 2.2 is low.  So I'll just land it in 2.3 for now.
[08:18] <spiv> vila: (if later we decide it might be good to have in 2.2 after all... well, we know where to find the patch!)
[08:18] <spiv> vila: thanks for the review
[08:20] <vila> spiv: ha great, I feel relieved :)
[08:32] <poolie> yay :)
[08:33] <poolie> i had such a good day of mgmt today
[08:33] <poolie> (imho :-)
[08:44] <vila> poolie: way to go :)
[08:46] <vila> poolie: mgmt taks are the hardest to quantify which is a source of frustration when you try to summarize: "what the hell did I do today/this week/this month" :D
[08:47] <poolie> yep
[08:48] <vila> AAAARGH, I hate vbox when is starts to randomly generates mouse clicks all over the place !
[09:07] <poolie> !
[09:07] <poolie> that's what cats are for :)
[09:08] <poolie> ok i think that's enough fun for today
[09:09] <vila> hehe
[10:55] <awilkins> Hi, I'm running bzr 2.3b3 on CentOS 5 (python2.4), bzr-svn 0.7.5, subvertpy 1.0.4 and getting 'function' object has no attribute 'decode' when trying to pull svn branches ; stack trace http://pastebin.ubuntu.com/533419/
[11:06] <vila> awilkins: bzr-svn bug, try trunk ?
[11:06] <vila> awilkins: file a bug otherwise
[11:07] <spiv> awilkins: I agree with vila
[11:08] <awilkins> Looks like it's passing a generator to a function that expects a string
[11:09] <awilkins> Going to try it with 2.2.1
[11:12] <awilkins> Ah, well that produces a different error, so that's progress. I think the previous thing is a change to the API in 2.3 vs 2.2 ; the contructor in 2.2 expects a generator function, in 2.3 it expects a string
[11:14] <awilkins> Now it's a 2.5-ism I think ; 2.4 has no "any() " function, right?
[11:23] <vila> hmm, 2.2 was expecting a callable not a generator but yes, that's the offending change
[11:23] <vila> but where is any() involved ?
[11:23] <awilkins> vila, The calling code calls it a generator ... I'm not very pythonic I'm afraid
[11:23] <awilkins> any() is in bzr-svn
[11:23] <awilkins> logwalker.py
[11:23] <awilkins> Just patching it
[11:24] <awilkins> Grr. qbzr needs more context menus. Just want to be able to blame something and do a switch -b from the log menu
[12:00] <awilkins> jelmer, Looks like you already noticed that logwalker.py python2.4 bug :-)
[12:06] <GaryvdM> awilkins: Noted
[14:28] <vila> mgz: testtools-0.9.6 has been installed on pqm
[14:28] <vila> mgz: don't rejoice too fast though, we lost subunit in the process :-}
[14:29] <vila> mgz: this was an announce from the be-ready-but-not-too-fast dept
[15:02] <hangfire> I'm mainly an svn user, and I want to get a checkout from bzr://dxx-rebirth.bzr.sourceforge.net/bzrroot/dxx-rebirth . I've tried bzr co, bzr pull, bzr branch, and I get errors saying "not a branch". bzr init says that it's a "Shared repository". How can I get a copy?
[15:03] <jelmer> hey hangfire
[15:04] <hangfire> jelmer: hey
[15:04] <jelmer> hangfire: you'd want bzr branch or bzr co, but to check out an individual branch rather than the full repository
[15:04] <hangfire> jelmer: How can I get a list of branch nameS?
[15:04] <Odd_Bloke> hangfire: There should branches underneath that repository, and those are what you deal with/check out in bzr.
[15:04] <Odd_Bloke> jelmer's clearly on it. :)
[15:05] <jelmer> hangfire: Actually, looking at this again, is there any reason you're using bzr:// rather than http:// ?
[15:05] <jelmer> Odd_Bloke: hey! long time no see :-)
[15:05] <hangfire> jelmer: That's what's listed on sf.net :P
[15:05] <Odd_Bloke> jelmer: Indeed.
[15:05] <Odd_Bloke> jelmer: I've been hanging around a bit more because I heard there was a job going. ;)
[15:06] <hangfire> jelmer: ah! got it. Thanks
[15:06] <hangfire> Odd_Bloke: thanks too!
[15:07] <jelmer> Odd_Bloke: Ah, right, that one :-)
[15:07] <Odd_Bloke> jelmer: Congratulations on that, by the way. :)
[15:07] <Odd_Bloke> Since I was really spending time contributing to bzr (and other FS projects) I've gained both a job and a girlfriend, so my time is considerably more scarce than it was.
[15:08] <jelmer> Odd_Bloke: Thanks!
[15:08] <jelmer> Odd_Bloke: Ahh! I wondered what had happened to you.
[15:09] <Odd_Bloke> The job is with credativ, who work with free software, so it's not all bad.
[15:09] <Odd_Bloke> I'm just spending my time working on business logic stuff like OpenERP.
[15:09] <Odd_Bloke> And sysadmin stuff, and some website work in Django.
[15:09] <jelmer> Odd_Bloke: Ah, cool. Wasn't Chris or Johnny working there as well?
[15:10] <Odd_Bloke> jelmer: jonnylamb works as Collabora.
[15:10] <Odd_Bloke> Or at least did.
[15:10] <Odd_Bloke> Which may be where you're thinking of.
[15:10] <jelmer> I'm pretty sure I met another friend of yours who worked there, perhaps somebody other than Johnny or Chris.
[15:10] <fullermd> Well, that's hardly fair.  Messing with bzr hasn't gotten me a job or a girlfriend   :(
[15:11] <Odd_Bloke> jelmer: Tim Retout?
[15:11] <Odd_Bloke> Brad Smith, and Chris Halls are the other DDs who do/have worked here.
[15:11] <Odd_Bloke> And I assume you only know DDs. :p
[15:11] <jelmer> Odd_Bloke: I think so.
[15:12] <Odd_Bloke> fullermd: Waaah. :p
[15:13] <jelmer> Odd_Bloke: (-:
[15:14] <Odd_Bloke> OpenERP, which I spend most of my time working on, has a pretty lame upstream, I should probably get back into spending some spare time doing FS stuff.
[15:15] <jelmer> I vaguely recall seeing something about openerp and bzr recently
[15:15] <jelmer> somebody wanting to extend bzr-stats
[15:16] <Odd_Bloke> They do use Launchpad.
[15:16] <Odd_Bloke> At least for interfacing with contributors/users who are external to their partner programme.
[15:17] <jelmer> ah, cool
[16:29] <smoser> wonder if anyone can help. i think i'm not sure if i'm using import-upstream correctly or not.
[16:29] <smoser> $ bzr branch lp:ubuntu/natty/euca2ools natty.dist
[16:29] <smoser> $ cd natty.dist
[16:29] <smoser> $ bzr import-upstream 1.3.1 ../dl/euca2ools-1.3.1.tar.gz
[16:30] <smoser> results in http://paste.ubuntu.com/533507/
[16:30] <smoser> i'm on natty, but i think i'd seen this before
[16:46] <maxb> smoser: I believe you need to add --version before the 1.3.1
[16:46] <smoser> no. you do for merge-upstream, import-upstream wants it that way
[16:46] <maxb> Also, isn't it merge-upstream
[16:46] <smoser> (at least per its usage)
[16:46] <maxb> oh. ETOOMANYCOMMANDS
[16:47] <smoser> i actually want the import-upstream rather than merge-upstream. i just want the upstream pulled in, and then will merge it manually (basically dropping all ubuntu changes and patching in)
[16:47] <smoser> merge-upstream just leaves me with dozens of conflicts
[16:47] <smoser> james_w, ^ you have thoughts on above ?
[16:48] <maxb> smoser: is the debian/watch screwed up or is euca2ools-1.3.1-src-deps.tar.gz the right thing?
[16:48] <smoser> maxb, i'm not sure. i didnt' even look at the watch. silly me. probably should have looked there first.
[16:48] <james_w> smoser, please file a bug
[16:48] <maxb> I think the watchfile is erroneously too permissive
[16:49] <smoser> james_w, ok
[16:53] <maxb> smoser: fwiw, commenting out the line it breaks on appears to allow it to function correctly
[16:53] <maxb> it would appear to simply be a missing "if upstream is not None:"
[16:54] <james_w> smoser, lp:bzr-builddeb should have a quick fix for that problem
[16:54] <james_w> maxb, indeed
[16:54] <salgado> does anybody know why lazr.uri is not included in the OSX bundle (http://wiki.bazaar.canonical.com/MacOSXBundle/SnowLeopard)?  it's needed by lp-propose
[16:55] <james_w> salgado, does lp-propose depend on launchpadlib, or just lazr.uri?
[16:55] <salgado> james_w, probably launchpadlib
[16:56] <salgado> haven't checked, but it didn't work for martohls because lazr.uri was missing
[16:57] <james_w> salgado, right, I'm wondering if launchpadlib is bundled, or it's just reporting the first of a few missing dependencies
[16:57] <james_w> I don't know who builds the bundle though
[16:58] <salgado> launchpadlib is not included in the bundle listing on the wiki
[17:02] <maxb> james_w: Oh, btw, remember I said I was going to fix the missing tags issues blocking UDD imports?  Well, just so you know, I fixed one locally and then found the importer did all kinds of bizarre stuff with parallel importing into squeeze and sid, so I got blocked on having time to dig into that weirdness.
[17:02] <james_w> maxb, bizarre how?
[17:03] <maxb> Importing the same upstream version multiple times was the most obviously wrong thing that I recall
[17:04] <smoser> bugger. i had opened a bug. but it appears launchpad isn't wanting me to do that now
[17:04] <maxb> Also doing history-diverged distinct imports of the same debian version number on the squeeze and sid branches
[17:05] <vila> jam1: ping
[17:05] <james_w> maxb, the latter is intentional if the branches have previously diverged
[17:05] <jam> hi vila
[17:05] <vila> jam: how are things going ?
[17:08] <jam> pretty good today. how about you?
[17:08] <vila> jam: testtools-0.9.6 has been installed on pqm BUT subunit has been removed
[17:09] <vila> jam: mthaddon is adding subunit-0.0.6 from our stable ppa again, but the build is still ongoing
[17:09] <jam> sigh
[17:09] <vila> jam: since I will EOD soon, it would be nice if you could check how it goes
[17:10] <vila> jam: I'm not asking for landing my stuff, just make sure we *can* land something :-/
[17:11] <jam> sure
[17:11] <mgz> ha, upgrading testtools broke landing?
[17:11] <vila> jam: what are you working on these days ? hpss on lp ?
[17:12] <vila> mgz: AIUI testtools requires some version of subunit which wasn't the one installed
[17:12] <vila> mgz: my previous ping was to warn you that we *should* be able to finally land your branches so you may want to refresh them
[17:12] <mgz> ah. it... shouldn't work like that, subunit depends on testtools not visa versa, but I can imagine something broke.
[17:13] <mgz> vila: well, they'll need to head merged, they predate the NEWS split.
[17:13] <vila> mgz: yeah, so that may means shuffling the news entries anyway
[17:17] <jam> vila: so what's up with the 'temp-commit-file' being sent every hour or so? Is this just PQM fallout?
[17:17] <jam> and is there an RT for the breakage that I should be following?
[17:21] <jam> vila: I'm planning on sending a mail to the list about some possible "next things" for me. Commit to stacked branch, Branch.open() round trips over hpss, etc.
[17:21] <vila> jam: yup, pqm fallout
[17:22] <vila> jam: yes, 41340, it has been closed while testtools was installed but I think it's the one to re-open
[17:23] <vila> jam: commit to stacked branches would be nice, AIUI, some udd devs prefer checkouts
[17:23] <vila> jam: and on lp that means stacked right ?
[17:24] <jam> vila: well, it can mean stacked, yes
[17:24] <jam> I think really what they want is shallow
[17:24] <jam> which is something I poked at a while ago, which could really use a good hpss verb for it
[17:25] <awilkins> I'm now getting "Connection closed: Unexpected end of message" when trying to use bzr+ssh ... sftp works for the same branch
[17:26] <awilkins> The server logs the startup of the remote bzr instance...
[17:27] <jam> awilkins: can you try running with -Dhpss ?
[17:27] <awilkins> HPSS calls: 2 (1 vfs) SmartSSHClientMedium(bzr+ssh://None@cu013/)
[17:29] <smoser> james_w, bug 676606
[17:29] <exarkun> Why did this start happening?  http://buildbot.twistedmatrix.com/builders/hardy64-py2.5-select/builds/448/steps/bzr/logs/stdio
[17:29] <jam> awilkins: there will be some information in ~/.bzr.log indicating what requests were done, etc.
[17:30] <awilkins> And the full log : http://pastebin.ubuntu.com/533527/ ; nothing unordinary on the server I can see
[17:30] <james_w> smoser, thanks
[17:30] <james_w> smoser, did you try the fix?
[17:30] <smoser> just getting there.
[17:31] <jam> awilkins: so on the client side, it looks like we sent a request and got back no content in return
[17:31] <jam> "buf[:10]=''"
[17:31] <jam> means that there was no content in the reply
[17:31] <awilkins> jam, this is through an ssh tunnel ; I have a shell open on the same connection which works fine, as does SFTP.
[17:32] <awilkins> So there is a server though which tunnels are established to get access to the servers inside
[17:32] <jam> awilkins: sure, is it ssh inside the tunnel as well?
[17:32] <jam> or is it raw bzr:// ?
[17:32] <jam> etc
[17:32] <awilkins> jam, It's bzr+ssh:// through the same tunnel that the ssh shell connection is working through.
[17:32] <jam> These lines are a bit surprising, too:
[17:32] <jam> 0.152  ssh implementation is OpenSSH 0.974     result:   ('ReadError', 'home/awilkins/ace/.repo/workbench/trunk')
[17:33] <smoser> james_w, fix seems to work.
[17:33] <awilkins> jam, The version, or the lack of / on the front of the path?
[17:33] <jam> (it actually looks like we got an earlier failure, and are trying to continue working, when we shouldn't)
[17:33] <jam> awilkins: try this: "echo hello | ssh <that host over there> bzr serve --inet"
[17:33] <jam> the full string we are sending is "bzr serve --inet --directory=/ --allow-writes" in case that matters (it shouldn't)
[17:34] <jam> looks like "cu013" is <that host over there>
[17:34] <awilkins> jam, this is an instance of bzr in my home folder on the server and is being accessed via setting BZR_REMOTE_PATH, not via the normal PATH
[17:34] <jam> That *should" return "ok\x012\n"
[17:34] <jam> awilkins: well, then try that first
[17:34] <awilkins> jam, returns ok
[17:35] <jam> awilkins: you are setting BZR_REMOTE_PATH and not via config, right?
[17:36] <jam> another thing to check is that the remote bzr is executable, but you seem to have validated that with the "echo hello" check
[17:36] <jam> you could try:
[17:36] <awilkins> jam, setting it on the same command line - without, you get a command not found form the server
[17:36] <jam> echo hello | ssh cu013 $BZR_REMOTE_PATH serve --inet
[17:36] <jam> to make sure you have the remote path set correctly
[17:37] <jam> awilkins: I think you might have a username set wrong:
[17:37] <jam> [ 9024] 2010-11-17 17:27:21.522 INFO: HPSS calls: 2 (1 vfs) SmartSSHClientMedium(bzr+ssh://None@cu013/)
[17:37] <jam> None@ ?
[17:38] <jam> (we may just be displaying it when we shouldn't, because it is using the default)
[17:38] <vila> jam: I see that almost everytime
[17:38] <vila> jam: exactly
[17:38] <awilkins> jam, That's just the parameter in the stack trace ; I've been using this config for ages though
[17:38] <awilkins> jam, It works fine
[17:38] <awilkins> (for ssh)
[17:38] <awilkins> It previously worked fine for a similar server
[17:38] <james_w> smoser, excellent, thanks for testing
[17:39] <smoser> so, now for the general bzr education
[17:39] <awilkins> But had to start using a different one in the same cluster (it's CentOS 5 in a collabnet cluster)
[17:39] <smoser> i did the above, and imported upstream tarball
[17:39] <smoser> and i can bzr diff -r tag:upstream-1.3.1
[17:39] <smoser> but in bzr tags output i see:
[17:39] <smoser> upstream-1.3.1       ?
[17:40] <maxb> I believe that is expected, because whilst you have imported the revision, it is not (yet) in the ancestry of your current branch, so cannot be given a revno
[17:40] <smoser> why is that? and what is the repercussion of it.
[17:41] <smoser> hm.. so maybe import-upstream isnt what i want then?
[17:42] <maxb> Well, at this point you are free to 'bzr merge -r upstream-1.3.1 .'
[17:42] <awilkins> jam, I think I might just be being an idiot about how to set an env variable
[17:42] <james_w> smoser, import-upstream is only a building block for whatever you want to do
[17:42] <james_w> smoser, so maxb is right that a merge is one of the possible next steps
[17:43] <smoser> yeah. ok. i think i'm set now.
[17:43] <jam> awilkins: what shell are you using?
[17:43] <smoser> maxb, regarding the watch file, it does seem its incorrect. it gets a -src-deps download. i'll fix that.
[17:43] <jam> though if it is changing from "not found" to actually reporting something, that seems like progress
[17:44] <jam> (export BZR_REMOTE_PATH=...) seems like it should work for "bash"s, "set BZR_REMOTE_PATH=..." I think is tcsh.
[17:44] <awilkins> jam,  I'm using bash locally and on the sever
[17:45] <jam> awilkins: fwiw it seems to be failing at the first RPC, so I'm not sure yet that bzr is able to start the remote bzr correctly.
[17:45] <awilkins> was using  #  BZR_REMOTE_PATH="/home/awilkins/bin/bzr" bzr pull bzr+ssh://<url>
[17:45] <awilkins> Without the first part it complains about not finding bzr, but produces the same error
[17:45] <awilkins> With it, it doesn't
[17:45] <awilkins> (complain about not finding the command)
[17:46] <awilkins> I know it's running on the server because the logs are showing up the serve --inet --directory=/ commands
[17:49] <awilkins> jam, Hmm, the serve attempts that respond to the "hello" command have a return code 0, the others have no return code.
[17:49] <jam> awilkins: you pretty much have to have a return code...
[17:50] <jam> ah, you mean on the server it doesn't show as returning?
[17:50] <jam> that sounds like it might be segfaulting
[17:50] <jam> how did you install the code there?
[17:50] <jam> (did you compile extensions on a different platform, and then copy it?)
[17:50] <awilkins> jam, Yes, but they are not logging it - gets as far as "bzr-svn: using Subversion 1.4.2 ()" then stops
[17:50] <awilkins> jam, compiled in the same folder it's running in
[17:51] <jam> awilkins: using "make" ?
[17:51] <awilkins> jam, yes
[17:51] <awilkins> jam, bzr 2.2.1 using the tarball and building from the included c files
[17:53] <jam> awilkins: so one quick check, try going to the server, and using ~/bin/bzr log /home/awilkins/ace/.repo/workbench/trunk
[17:53] <jam> in case that segfaults for some unknown reason
[17:53] <jam> and how is ~/bin/bzr running in the same dir that it was compiled? (just a symlink?)
[17:53] <awilkins> jam, that runs just fine ; ~bin/bzr is a symlink, but I've tried the direct path as well with the same results
[17:55] <awilkins> jam, I'll get the server to run the selftests
[17:55] <jam> and just to be sure "ssh cu013 bzr log /home/awilkins/ace/.repo" also works, right?
[17:56] <jam> (well, add 'trunk' there)
[17:56] <awilkins> jam, .repo is actually a standard folder, the subfolders of it are repos
[17:57] <awilkins> jam, that works... it also works on the server (accidentally put the command there)
[17:58] <vila> awilkins: I would try 'bzr selftest -s bp.svn' first since you mentioned it
[17:59] <awilkins> vila, Gah, no testtools
[17:59] <awilkins> As an aside, I hate CentOS
[17:59]  * vila suggests >=0.9.6 :)
[18:00] <awilkins> yum is especially pants
[18:00] <vila> awilkins: no bzr packaged there ?
[18:00] <awilkins> vila, Nope
[18:01] <awilkins> vila, I dare not add too many repositories, because the last time I did it upgraded some component to be inbcompatible with the setup these servers have where they mount your home folder from a SAN somewhere
[18:01] <vila> weird... I was sure I saw someone mentioning updating bzr for Red Hat with a simple command... where... where did I read that (a bug report ?)
[18:01] <awilkins> Broken LDAP library or something
[18:01] <vila> oh
[18:01]  * awilkins tries yum install bzr
[18:02] <awilkins> I broke it once like that and they rewarded me by taking away my ability to trash the server image... which seemed odd, because I was going to fix it by trashing the server image...
[18:03] <awilkins> This is a CollabNet build farm, what do you expect, they are still in love with svn.
[18:04] <awilkins> I hope it really annoys them that I use my home folder to mirror all the SVN repos in the project as Bazaar branches, but frankly they probably haven;t noticed.
[18:04] <fullermd> Maybe if you checked that homedir into svn...
[18:05] <txdv> svn is the best subversioning system, all more advancved once support it, so you can easily use git/bzr/hg insteand of svn
[18:05] <awilkins> That's ironically "meta". Even more ironic given that the lead "programmer" on this project has actually written a versioned object database that actually stored it's repository (note- repository, not working copy) in an SVN working copy   >-o-<
[18:06] <awilkins> That's a pinched agony face, by the way, not a goatse-ascii (accidental)
[18:06] <fullermd> You get extra points if your svn->bzr conversion scripts automatically notice the new stuff in svn, and check out a bzr conversion of your homedir checkin in your homedir...
[18:18] <awilkins> jam, It is a segfault
[18:18] <jam> awilkins: well, at least I was right... now to figure out why
[18:18] <awilkins> jam, Started another port tunnel for plain bzr:// and  ran a server on the remote shell
[18:19] <awilkins> jam, It's something in bzr-svn
[18:19] <jam> awilkins: do you need to have bzr-svn available?
[18:19] <awilkins> jam, start it with --no-plugins and it works just fine
[18:19] <jam> I guess you were saying everything is running in svn upstream
[18:20] <awilkins> jam, I need it on the server shell but not when I'm pulling remotely
[18:20] <awilkins> It's just a staging area to reduce my download bandwidth really - some of these branches are fricking huge
[18:21] <brianjarita> hey guys... i did an apt-get update  with an apt-get upgrade on hardy and now I get "bzr: ERROR: exceptions.ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client')"
[18:21] <awilkins> So I can work around it by moving the plugin and putting a BZR_PLUGIN_PATH in the remote script for bzr
[18:21] <brianjarita> it was fine before I did the update ... I"m running ubuntu 8.04 server
[18:23] <brianjarita> any ideas on how to fix that?
[18:24] <awilkins> brianjarita, were any of the components installed manually rather than via apt?
[18:24] <brianjarita> nope
[18:25] <brianjarita> i have bzr 2.1.1-1, bzr-svn 1.0.2-2 and bzrtools 2.1.0-1 installed
[18:27] <vila> awilkins: or use BZR_DISABLE_PLUGINS, bzr help env-variables will tell you if it's available
[18:28] <awilkins> vila, would that work for the remote server? Does SSH pass those env variables (or just a limited subset like LC)
[18:30] <awilkins> brianjarita, (I keep wanting to type "brainjar"), those are not the most recent versions of those packages for Hardy in the bzr PPA (I know they're not from the default Hardy repo, because that's still at 1.13)
[18:31] <brianjarita> i see  2.2.1-0~bazaar1~hardy1
[18:31] <awilkins> brianjarita, Could you upgrade them to the newest versions in the PPA? (bzr-2.2.1-0~bazaar1~hardy1, bzr-svn-1.0.4-1~bazaar1~hardy1, bzrtools-2.2.0-2~bazaar1~hard1)
[18:32] <brianjarita> root@dev:~/Source# dpkg --list|grep bzr
[18:32] <brianjarita> ii  bzr                                   2.2.1-0~bazaar1~hardy1      easy to use distributed version control syst
[18:32] <brianjarita> ii  bzr-svn                               1.0.4-1~bazaar1~hardy1      Bazaar plugin providing Subversion integrati
[18:32] <brianjarita> ii  bzrtools                              2.2.0-2~bazaar1~hardy1      Collection of tools for bzr
[18:33] <awilkins> brianjarita, So why do you have 2.1.1-1 above?
[18:33] <brianjarita> sorry i was on the wrong terminal
[18:33] <brianjarita> i was on lucid at 10:24AM
[18:33] <brianjarita> that last post is hardy
[18:33] <brianjarita> Linux dev 2.6.24-26-server #1 SMP Tue Dec 1 18:26:43 UTC 2009 x86_64 GNU/Linux
[18:34] <awilkins> I presume you need bzr-svn :-)
[18:35] <brianjarita> bzr    2.2.1-0~bazaar1~hardy1, bzr-svn   1.0.4-1~bazaar1~hardy1 and bzrtools 2.2.0-2~bazaar1~hardy1 are all installed
[18:35] <knittl> 2a format has O(1) access time for text objects?
[18:36] <jelmer> brianjarita: it looks like you have a broken python-subvertpy
[18:36] <jam> awilkins: I imagine we only pass a limited subset of env vars, probably just the ones that ssh itself defaults to passing
[18:37] <jelmer> awilkins: Did you figure out why bzr-svn was breaking your setup?
[18:37] <jelmer> hey jam!
[18:37] <jam> knittl: they are stored delta compressed, so not exactly O(1), and the index files are btrees, so looking up the location of the text is more O(log(n))...
[18:37] <jam> hi jelmer
[18:37] <brianjarita> python-subvertpy is 0.7.5-1~bazaar1~hardy1
[18:37] <knittl> jam: is there a reference somewhere?
[18:38] <jam> knittl: is there a specific question I can help answer?
[18:38] <awilkins> jelmer, Alas, no, it's segfaulting with no stack trace, I've not got testtools installed yet 'coz I can't find a CentOS package name for it (grr)
[18:38] <knittl> jam: still writing on my thesis :P
[18:38] <knittl> and i have a line in it, that says »O(1) lookup time for any version of a file \todo{cite,verify}«
[18:39] <knittl> so i came to verify
[18:39] <jelmer> awilkins: what version of subvertpy?
[18:39] <jam> IMO O(1) is pretty poorly defined. And usually  means you have to actually find the terms and determine that this part is a minimal part of the overall time, etc.
[18:39] <awilkins> jelmer, 0.7.5, compiled from tarball. It pulls SVN branches just fine
[18:39] <knittl> O(1) is generally constant and not depending on number of commits, number of branches, number of files, etc.
[18:40] <awilkins> jelmer, I may have patched it slightly for that not-importing-pycompat thing
[18:40] <jam> knittl: I would guess that we aren't strictly O(1). If I would guess, I would at least give it O(log(N)) of "stuff"
[18:40] <jelmer> awilkins: what are you trying to do ?
[18:40] <knittl> i need evidence to back that up
[18:41] <knittl> there are no books on bzr, so bazaar internal documentation/format documentation is best i can get
[18:41] <jam> knittl: inventories (mapping Revision id => tree => actual file content) is stored as a tree structure, so that is generally a log(N) lookup.
[18:41] <knittl> what is N in O(log(N))?
[18:41] <awilkins> jelmer, I'm pulling SVN branches to my home folder on this server (because the SVN repo is in the same server rack and thus it's fast there), then pulling those bzr branches via bzr+ssh:// to my local machine
[18:41] <jam> knittl: Indices that map from a given text key (file_id, revision_id) to actual file content are btrees, which tends to be log100(N) lookup
[18:42] <jelmer> awilkins: and pulling the bzr branches over bzr+ssh:// fails?
[18:42] <knittl> what is N?
[18:42] <jam> knittl: the raw text content is stored in a group of zlib.compress(lots_of_delta_content)
[18:42] <jam> which is O(N_in_the_group) which is not strictly bounded, but significatly smaller than the N of all text content
[18:43] <awilkins> jelmer, Or if you manually configure another tunnel and use plain bzr:// from a server started on the shell ; it segfaults, but not if you use --no-plugins. The only plugin outside the default is bzr-svn
[18:43] <jam> inventory would be O(log(Num_files_in_the_tree))
[18:43] <awilkins> jelmer, Ill just be extra thorough and try just disabling bzr-svn
[18:43] <knittl> i'm still very disappointed by bzr's technical documentation :(
[18:43] <jam> file_key => pack file is O(log100(Num_all_texts_stored_in_the_repository))
[18:43] <jelmer> awilkins: I wonder why bzr-svn kicks in at all though
[18:44] <jam> knittl: it isn't a VCS for Comp Sci majors ...
[18:44] <jelmer> awilkins: the remote directory doesn't have .svn directories or anything like that?
[18:44] <knittl> let's say i can ignore compression
[18:44] <jam> jelmer: we're looking up a branch, that generally involves bzr-svn
[18:44] <jam> knittl: zlib.decompress is going to be O(size_of_file_content)
[18:44] <knittl> i said i _can_ ignore it ^^
[18:44] <jam> and given everything I've stated, is likely to be the dominating factor
[18:44] <jelmer> jam: but we check for .bzr before checking for .svn, and the .svn check happens using os.path.isdir().
[18:44] <knittl> why btree and not a hashmap?
[18:45] <awilkins> jelmer, The remote folder is a bare branch in a bare repository
[18:45] <awilkins> Sorry, slipping into git-ism - --no-trees
[18:45] <jam> awilkins: is it a shared repo?
[18:45] <awilkins> jam, It is
[18:45] <awilkins> jam, I will try one of the other repos
[18:45] <awilkins> I have many here
[18:45] <jam> awilkins: then is is "repo/.bzr repo/branch/.bzr/" which would mean we have to 'search"
[18:46] <jam> knittl: our keys aren't hashes to start with (vs git)
[18:46] <jam> and many operations look for "similar" data
[18:46] <jam> like log going over revisions tends to look at user-2001a, user-2001b, etc
[18:47] <jam> so you get locality by using a btree vs a hashmap
[18:47] <jam> same for text content
[18:47] <knittl> ok
[18:47] <jam> diff looks for 2 texts of file-id1, rev1, rev2
[18:47] <awilkins> repo layout is as at http://pastebin.ubuntu.com/533547/
[18:47] <knittl> jam: so where is documentation that can back up everything you said?
[18:47] <awilkins> I like this layout because you can do switch -b with ease
[18:48] <jam> knittl: ultimate documentation is in the code :)
[18:48] <knittl> i'm afraid IRC will not be allowed as citing source
[18:48] <jam> look in doc/developers/*
[18:48] <jam> and bzrlib/btree_index.py and bzrlib/groupcompress.py bzrlib/repofmt/groupcompress_repo.py
[18:48] <jam> there should be some slightly technical docstrings
[18:49] <jelmer> jam: but in awilkins situation we'd still not have to check for .svn as we'd find a .bzr controldir in every directory we browse, right?
[18:49] <jelmer> awilkins: Can you perhaps run your bzr serve process in gdb ?
[18:49] <knittl> jam: hm. ok
[18:49] <awilkins> jelmer, I'll see if it's installed
[18:49] <awilkins> Hooray, something that CentOS actually has
[18:49] <jam> jelmer: I don't know that we would *have* to, but I'm pretty sure I've always seen bzr-svn get invoked
[18:49] <jam> when it is present
[18:50] <maxb> bzr-svn gets involved far too much. Just look at .bzr.log and see it crazily attempt to open the internals of bzrdirs as svn repositories
[18:50] <knittl> btw, do i still need to sign contributors agreement for my branch? i still don't want to …
[18:51] <jelmer> maxb: how do you mean?
[18:51] <maxb> 0.480  Unable to open <bzrlib.transport.local.LocalTransport url=file:///home/maxb/wc/bzr/bzr/.bzr/repository/indices/2b60105ff8068389b09d6c735928fddd.six/> with Subversion: Unable to open an ra_local session to URL
[18:51] <maxb> for example
[18:52] <jelmer> maxb: that's when running 'bzr branches' ?
[18:52] <maxb> repeat for every index and pack in the repo
[18:52] <knittl> jam: i cannot find O(… in the three files you named
[18:52] <maxb> jelmer: hmm... multi-pull... which probably does exercise that code path
[18:52] <jelmer> maxb: yep
[18:52] <awilkins> how do you pass args to a program in gdb?
[18:52] <jelmer> awilkins: gdb --args /usr/bin/python /usr/bin/bzr serve
[18:52]  * awilkins is woefully spoiled by IDE attached debuggers
[18:53] <jelmer> maxb: The probe code (and the branch find code) are in bzr, not bzr-svn.
[18:53] <jelmer> maxb: we'd be trying to open those files with bzr, git and hg as well (provided you have those plugins installed), they're just a bit less verbose.
[18:54] <knittl> »When referring to revision numbers it is necessary to mention a branch URL as well« ← is that correct?
[18:54] <maxb> Hmm. I think some rethinking is in order there, but it probably can't be made quicker without also being made less extensible
[18:54] <awilkins> gdb stack trace at http://pastebin.ubuntu.com/533549/
[18:55] <jelmer> maxb: It should be possible to make it faster, the new Prober API should make that a bit easier.
[18:56] <awilkins> Why is it even throwing a SubversionException when serving a pure bzr branch ...
[18:56] <jelmer> awilkins: can you print the full backtrace ("bt")
[18:57] <fullermd> knittl: Well, maybe not a URL per se, but a branch one way or another, yes.
[18:57] <awilkins> jelmer, http://pastebin.ubuntu.com/533550/
[18:58] <jelmer> awilkins: is the branch tied to a http repository or something like that?
[18:59] <awilkins> jelmer, the parent branch is an SVN repo over https://
[19:00] <knittl> fullermd: URL can also be a path
[19:00] <jelmer> awilkins: can you to frame 3 and print ret->url ?
[19:00] <awilkins> jelmer, I have a thought - one thing is that these repos don't work with just "https://" you have to use "svn+https://" because they don't like being probed (return 401 errors and the like)
[19:03] <awilkins> jelmer, it says "no symbol ret in current context"
[19:04] <brianjarita> you guys were right ..... python-subvertpy is broken in hardy .... i compiled it from source and everything works now
[19:04] <brianjarita> thanks
[19:04] <jelmer> awilkins: argh, darn optimizations
[19:04] <jelmer> brianjarita: are you using the bzr ppa perhaps, or is this "plain" hardy?
[19:04] <brianjarita> plain hardy
[19:05] <brianjarita> hardy server 8.04 lts
[19:05] <brianjarita> right from the live cd from ubuntu
[19:05] <awilkins> jelmer, he must be using the ppa because he's not on bzr-1.13, he's on 2.2
[19:05] <brianjarita> yea i'm on 2.2
[19:06] <brianjarita> my repos are the regular ones
[19:07] <brianjarita> I didn't add anything to /etc/apt/sources.list
[19:07] <brianjarita> oh haha ... another IT guy did
[19:07] <brianjarita> i see     deb http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main
[19:07] <brianjarita> so yea I'm on ppa
[19:08] <awilkins> jelmer, How about printing the url from the kwargs, is that hard?
[19:09] <jelmer> awilkins: should be possible
[19:09] <jelmer> awilkins: "print PyString_AsString(PyObject_Repr(kwargs))" I think
[19:09] <jelmer> awilkins: I have to run in a few minutes though
[19:10] <awilkins> I was trying kwargs[0]-> nut not sure which member to try
[19:20] <jelmer> awilkins: any luck using "print PyString_AsString(PyObject_Repr(kwargs))" ?
[19:21] <awilkins> jelmer, nope
[19:22] <awilkins> $2 = 147905652
[19:23] <awilkins> jelmer, More coherent results from print kwargs[n], but you just get the refcount and object type
[19:23] <awilkins> As an integer
[19:44] <awilkins> jelmer, print (char*) PyString_AsString(PyObject_Repr(kwargs)) seems to work a bit better.. but it;s truncated with an ellipsis
[19:47] <awilkins> jelmer, the url is 'file://'
[20:40] <jam> losa ping: Last I heard, bzr's PQM was still broken because of needing the new subunit to be installed. I don't know if that has been addressed or not. vila and mthaddon were working on it, but both are past their EOD
[20:59] <joey> howdy,
[20:59] <joey> anyone know how to work around this?
[20:59] <joey> bzr: ERROR: No such file: u'/home/joey/canonical-docs/.bzr/repository/pack-names': [Errno 2] No such file or directory: u'/home/joey/canonical-docs/.bzr/repository/pack-names'
[20:59] <joey> I went do to a commit and got that error
[20:59] <beuno> ouch
[20:59] <poolie> hi joey, beuno, jam
[20:59] <poolie> joey: what happened?
[20:59] <beuno> heya poolie!
[21:00] <joey> hi poolie!
[21:00] <joey> bzr: ERROR: No such file: u'/home/joey/canonical-docs/.bzr/repository/pack-names': [Errno 2] No such file or directory: u'/home/joey/canonical-docs/.bzr/repository/pack-names'
[21:00] <poolie> that's unusual
[21:00] <joey> I hadn't used that branch in a while and went to do a commit ....
[21:00] <poolie> did your machine crash recently?
[21:00] <poolie> ah, or maybe not recently
[21:00] <joey> status, check, pull, update ...all get the same error
[21:00] <jam> morning poolie
[21:00] <poolie> yeah, i'm not surprised
[21:00] <joey> yeah it has crashed but not in the middle of an update
[21:00] <poolie> that's a pretty fundamental file to lose
[21:01]  * joey looks in lost.files
[21:01] <poolie> jam, thanks for your mail
[21:02] <joey> lost+found is empty
[21:02] <joey> I suppose I can just suck down the branch from LP and do a diff
[21:02] <poolie> so can you file a bug, and then
[21:03] <poolie> it should not be too hard to recreate the file, but i don't know if there's any command line way
[21:03] <poolie> bug titled 'pack-names file is missing'
[21:04] <joey> well I have no idea how it would have happened
[21:04] <poolie> it's ok
[21:04] <joey> no idea on how to reproduce it
[21:04] <poolie> we should still have a way to recover from it
[21:04] <poolie> 'rm pack-names' will reproduce it adequately :)
[21:04] <joey> oh hell
[21:04] <joey> you are NOT going to believe this
[21:04] <poolie> however, it's probably only about low priority, since if your machine is going to lose files, there's a limit what we can do
[21:04] <joey> pack-names.u1conflict
[21:05] <joey> I must have forgotten it was under RCS
[21:05] <beuno> u1conflict
[21:05] <beuno> ouch
[21:06] <joey> the reason I don't use U1 :-)
[21:06] <beuno> so that was ubuntu one's fault
[21:06] <beuno> hehe
[21:06] <joey> I've invited Matt G and few others to my house to help them fix it :-)
[21:06] <beuno> I have Matt G trapped in my place all week
[21:06] <jam> beuno, joey: AIUI u1 is not transaction safe wrt what bzr does
[21:06] <beuno> plus rockstar and others
[21:06] <jam> we write things in a certain order, but U1 doesn't know that
[21:06] <joey> ok so renaming that file worked!
[21:07] <joey> thanks O masters of all things bzr bizarre
[21:07] <beuno> jam, I thought they had fixed that, bzr was one of the testcases
[21:07] <jam> so you can get repo level corruption if u1 decides to merge things
[21:07] <jam> beuno: if I commit here, and you commit there, we end up with 2 different pack files added to pack-names
[21:07] <jam> which would then conflict (I assume)
[21:07] <jam> and you need to merge those lines together.
[21:07] <beuno> ah
[21:07] <beuno> right
[21:07] <joey> jam: wc but any idea on how to tell u1 to stop synchronizing?  When I issue it from the gui it just fails silently
[21:08] <jam> not to mention that you could sync pack-names before you upload the associated .pack files, etc.
[21:08] <jam> joey: beuno is the one to ask about that
[21:08] <beuno> joey, so, where is this located on your filesystem?
[21:08] <jam> beuno: In an eventually-consistent state with a single committer, u1 will probably work
[21:08] <jam> (for example, you can rsync a live repository, as long as you eventually get a complete snapshot)
[21:09] <beuno> joey, go to:  https://edge.one.ubuntu.com/files/
[21:09] <beuno> "stop syncing folder" under the more option
[21:11] <joey> beuno: that worked. Many thanks.
[21:11] <beuno> joey, np. I fixed that yesterday  :)
[21:11] <beuno> sprinting FTW
[21:14] <poolie> jam, thanks for your mail about lp-serve
[21:15] <poolie> also i spoke to spiv and he's very keen to work with you on hpss, and he's going to try to wake earlier to overlap more with you
[21:16] <jam> poolie: francis had a decent response to it
[21:37] <poolie> jam btw if you're still online, you might want to join #ubuntu-meeting
[21:39] <spiv> jam: good morning, btw!
[21:39] <jam> morning sp
[21:39] <jam> spiv
[21:40] <spiv> joey: also, perhaps check if there's a pack-names.old file or something in .bzr/repository somewhere.
[21:41] <spiv> joey: oh, I see you found a file to rename :)
[21:45] <poolie> spiv, can you join #ubuntu-meeting too?
[21:46] <jam> spiv: there was a question about https://bugs.launchpad.net/udd/+bug/653307
[22:10] <peitschie> mornin all :)
[22:13] <spiv> james_w: see my latest comment on 653307
[22:16] <james_w> spiv, replied, thanks