[00:00] <Verterok> ok, I'm on it, thanks!
[00:00] <poolie> lifeless, spiv, jam, igc, call in a minute if you want
[00:02] <spiv> Good morning.
[00:06] <lifeless> poolie: sure, call me
[00:08] <lifeless> jam: ping
[00:10] <jam> lifeless: pong
[00:10] <jam> poolie: Just made it back into the house, is the call still going?
[00:10] <lifeless> jam: it is
[00:11] <jam> lifeless: can someone on the call ring me? I can at least listen in
[00:11] <jam> (silent jam)
[00:12] <lifeless> jam: thanks for tweaking my patch; is the rest ok with you? time to land ...
[00:17] <Yasumoto> thanks for the help guys, turns out I hadn't unlocked my ssh key
[00:20]  * beuno wished Loggerhead had tests
[00:21] <jam> beuno: *write* them :)
[00:21] <beuno> jam, I'm trying wishing first
[00:22] <beuno> mwhudson, does it seem sensible that TemplatedBranchView finds the last revid if none is provided, instead of each controller?
[00:24] <mwhudson> beuno:  yes, i think
[00:29] <jam> markh: was there anything you specifically wanted for 1.7 that hasn't landed? I'd like to cut 1.7rc1 and i just want to make sure things aren't missing.
[00:29] <markh> jam: those setup changes would be nice
[00:29] <markh> I just mailed the list
[00:29] <jam> markh: I did the TBZR ones
[00:29] <jam> not sure what other ones
[00:29] <markh> alex's - remove survey etc
[00:29] <markh> and maybe the icon? ;)
[00:30] <jam> markh: I did the icon as well
[00:30] <markh> thx!
[00:30] <jam> markh: Well, BB says that Alexander's change is already merged
[00:30] <jam> so I'm tempted to say it is already there
[00:30] <jam> is it missing for you?
[00:30] <markh> I guess I was trusting bundle-buggy - lemme look...
[00:31] <markh> it wasn't a few days ago iirc
[00:31] <markh> jam: we still on bzr.dev right?
[00:31] <jam> markh: well, we do have a branch, but it is 99.99% bzr.dev
[00:32] <markh> oh - I missed word of that too.
[00:33] <jam> markh: As near as I can tell, it is in bzr.dev
[00:33] <jam> BB says 8/21 it landed
[00:34] <markh> jam: yes, it looks to me like it has too - thanks!
[00:34] <jam> markh: K, cutting tarballs
[00:35] <markh> yeah, BB says it is merged, but I don't see a mail from BB in that thread saying it was merged.  Oh well, at least it is - thanks!
[00:35] <fullermd> Well, good thing we did 1.6.1...
[00:37] <lifeless> jam: thanks for tweaking my patch; is the rest ok with you? time to land it?
[00:58] <beuno> mwhudson, http://bazaar.launchpad.net/~beuno/loggerhead/abstract_paths/revision/220
[00:59] <wasabi> Hey. Managed to cause bzr to crash. 1.3.1 on hardy.  I tried to --force remove a directory that had already been removed by hand.
[01:00] <wasabi> bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: tests/gupnp-test
[01:00] <wasabi> Now I cannot use bzr status at all
[01:00] <wasabi> Any way to patch the branch up?
[01:01] <james_w> hi wasabi
[01:01] <james_w> "tests/" was what you removed?
[01:01] <wasabi> no. tests/gupnp-test
[01:01] <wasabi> tests is still there
[01:01] <james_w> mkdir tests/gupnp-test; bzr add tests/gupnp-test; bzr st; bzr rm tests/gupnp-test;
[01:01] <james_w> that should fix it I believe
[01:02] <wasabi> that did it
[01:02] <james_w> the bug is fixed in later versions
[01:02] <james_w> 1.6 I believe
[01:02] <wasabi> K.
[01:02] <wasabi> Thanks. ;)
[01:02] <james_w> no problem
[01:02] <james_w> happy hacking
[01:05] <lifeless> spiv: any reason your faster branch isn't up for review?
[01:06]  * beuno_ -> home
[01:16] <mwhudson_> gar
[01:16] <mwhudson_> beuno: the stuff to do with all_same_author is cruft since the new_theme landing?
[01:16] <mwhudson_> oh right, it says so in the commit message
[01:17] <mwhudson_> beuno: you don't need to call fix_revid in annotate_ui
[01:19] <mwhudson_>         path = None
[01:19] <mwhudson_>  
[01:19] <mwhudson_>  
[01:19] <mwhudson_> 81
[01:19] <mwhudson_>         if len(args) > 1:
[01:19] <mwhudson_>  
[01:19] <mwhudson_>  
[01:19] <mwhudson_> 82
[01:19] <mwhudson_>             path = args[1]
[01:19] <mwhudson_> oops
[01:19] <mwhudson_> beuno: ^ that doesn't look right
[01:19] <mwhudson_> for e.g. annotate/100/file/in/subdir
[01:23]  * jml reads the startup time RFC
[01:23] <jml> it would be nice if that got summarised into a more static document.
[01:24] <lifeless> I didn't expect *quite* that enthusiastic a discussion
[01:27] <jml> lifeless: it's an interesting topic :)
[01:27] <jml> lifeless: speaking of enthusiastic discussions, when can we bury the adsorbSuite hatchet?
[01:33] <lifeless> lunchtime?
[01:34] <spiv> lifeless: because it was just idle hackery, and I haven't (yet) re-read what I've done to make sure it's not too hackish.
[01:37] <jml> lifeless: sounds good to me.
[01:39] <lifeless> jml: shall we say 12:30?
[01:40] <jml> cool core.
[01:40] <beuno> mwhudson_, you're right. I'll fix it
[01:41] <lifeless> spiv: be useful to write up notes :P
[01:41] <mwhudson_> beuno: i think that you can just path_info_pop the revid, then take the rest of the environ['PATH_INFO'] as the path
[01:41] <mwhudson_> beuno: also, there's some confusion about whether path should start with or end with a /
[01:42] <mwhudson_> beuno: i suggest normalizing it in TemplatedView and then getting rid of the silliness in the subclasses
[01:42] <beuno> mwhudson_, cool, will do. Cleanups are always fun
[01:42] <mwhudson_> right
[02:05] <lifeless> mwhudson: is there a good 'am I leaking references from my C module' tester?
[02:05] <mwhudson> lifeless: not really
[02:05] <lifeless> bugger
[02:06] <lifeless> do you know
[02:06] <mwhudson> lifeless: there's a trackrefs class somewhere
[02:06] <lifeless> does PyTuple_SetItem
[02:06] <lifeless> dereference the old value at that place?
[02:06] <lifeless> or refuse to set the item altogether?
[02:06] <mwhudson> i don't know
[02:07] <mwhudson> but overwriting a tuple item is kinda breaking the rules...
[02:07] <lifeless> do you know where the tuple code is defined
[02:08] <lifeless> mwhudson: I'm creating it in a long winded way
[02:08] <mwhudson> lifeless: Objects/tupleobject.c
[02:08] <lifeless> and writing to the C api, so kthxblah
[02:08] <mwhudson> (though it might even be a macro)
[02:08] <lifeless> ok cool
[02:08] <lifeless> it dereferences an old tuple item
[02:09] <lifeless> yay for sanity
[02:09] <mwhudson> lifeless: it decrefs the old value
[02:09] <mwhudson> the python/c api is *mostly* sane
[02:10] <lifeless> I *Love* open source
[02:10] <lifeless> being able to check that code myself, FTW>
[02:13] <lifeless> lol
[02:13] <lifeless> :!PYTHONPATH=. python -m timeit -s "from bzrlib.osutils import _walkdirs_utf8 as walkdirs" "print len(list(walkdirs('../test-repos/mozilla')))"
[02:13] <lifeless> Traceback (most recent call last):
[02:14] <lifeless> Command terminated
[02:18] <Verterok> lifeless: about startup-time, cleaning up a bit xmloutput plugin, 0.20s gain in 'bzr rocks'. WOW!
[02:20] <Verterok> maybe a major call to plugin developers, could help a bit on that area :)
[02:27] <lifeless> Verterok: so thats good; better would be 0.2s gained on 'bzr st'
[02:27] <lifeless> Verterok: which xmloutput also hooks into, yes ?
[02:27] <Verterok> lifeless: indeed
[02:27] <Verterok> lifeless: not any more
[02:27] <lifeless> mwhudson: how do I found out the refcount of an object?
[02:28] <Verterok> lifeless: xmloutput don't override any builtin :)
[02:28] <Verterok> now it provides it own hidden command xml*
[02:28] <lifeless> Verterok: oh cool, its the rpc service one right?
[02:28] <Verterok> yes
[02:28] <lifeless> excellent news, thank you :)
[02:29] <lifeless> can I pull the new one yet ?
[02:29] <lifeless> revno 99?
[02:30] <Verterok> lifeless: the point I tried to higlight was that those 0.2s came from not using lazy_import :)
[02:31] <lifeless> Verterok: ah right
[02:31] <Verterok> lifeless: what branch?
[02:31] <mwhudson> lifeless: sys.getrefcoutn
[02:31] <lifeless> http://bazaar.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc/
[02:32] <Verterok> lifeless: branch from lp:bzr-xmloutput, I moved xmlrpc branch to trunk
[02:33] <lifeless> Verterok: so the theory of lazy import is 'defer reading code that is not needed', which is good; but its granularity is limited
[02:33] <lifeless> Verterok: which is my somewhat more troubling point :)
[02:35] <Verterok> lifeless: while moving things to lazy_import I foudn some corner cases, like the need to import SimpleXMLRPCServer (the module) and then doing SimpleXMLRPCServer.SimpleXMLRPCServer :p
[02:35] <lifeless> poolie: down to 888ms
[02:36] <lifeless> Verterok: yah, moving those to separate modules that you only load when you actually need the subclass might help
[02:36] <markh> jam: where should I put the 1.7 binaries for windows?
[02:36] <lifeless> Verterok: but only if you only need the subclass sometimes
[02:36] <markh> (bzr's launchpad page has the most recent announcement as 1.6rc4 being released...)
[02:37] <Verterok> because if I lazy_imported SimpleXMLRPCServer (the class), I get: "TypeError: Error when calling the metaclass bases"
[02:38] <lifeless> Verterok: heh
[02:38] <lifeless> Verterok: thats a bug in something, I don't recall if its the class machinery or lazy import
[02:38] <Verterok> lifeless: yes, I did exactly that, moved all cmd_* to __init__.py, and most heavy imports into modules not used in cmd_* declaration
[02:39] <spiv> poolie: you're welcome to work from here tomorrow, btw.
[02:40] <Verterok> http://rafb.net/p/7lNeKY31.html
[02:40] <Verterok> lifeless: the traceback, in case it helps ^
[02:40] <lifeless> mwhudson: you'll probably shoot me when you see my code :P
[02:41] <lifeless> 848ms per loop now
[02:43] <poolie> lifeless, relative to what?
[02:43] <poolie> spiv, thanks very much
[02:44] <poolie> spiv, if i'm organized enough to go before rush hour i'll turn up just before the 9am call, otherwise later
[02:44] <poolie> (in which case i may miss it)
[02:46] <jml> you could turn up here if you'd like.
[02:47] <jml> being something close to a midpoint
[02:47] <lifeless> poolie: 1000ms in bzr.dev
[02:47] <lifeless> jml: where is here now?
[02:47] <lifeless> 812ms now
[02:48] <jml> lifeless: lindfield.
[02:48] <poolie> i assume he means pymble or lindfield
[02:48] <poolie> i'm taking my bike to the shop in hornsby, so it's logically closer
[02:49] <jml> poolie: oh, I see.
[02:49] <poolie> to get a new shlock absorber so i can cope with robert's puns
[02:49] <jml> heh
[02:51] <poolie> but it would be nice to come over some time
[02:54] <lifeless> poolie: schlock mercenary ftw
[02:59] <beuno_> damn
[02:59] <beuno_> I locked myself out of my server
[02:59] <lifeless> lol
[03:00] <beuno> damn
[03:01] <lifeless> real world result:
[03:01] <lifeless> :!python -m timeit -s 'import subprocess' 'subprocess.call(["./bzr", "st", "../test-repos/mozilla/"])'
[03:01] <lifeless> 10 loops, best of 3: 3.68 sec per loop
[03:01] <lifeless> :!python -m timeit -s 'import subprocess' 'subprocess.call(["./bzr", "st", "../test-repos/mozilla/"])'
[03:01] <lifeless> 10 loops, best of 3: 3.84 sec per loop
[03:02] <lifeless> I'm going to keep driving it down
[03:26] <lifeless> jml: now ok?
[03:35] <beuno> dinner!
[03:50] <jml> lifeless:  * resource dirty markers on non current resources - ignore? keep a history ?
[04:02] <mlh> I want to keep some db schemas in a nicely diffable format
[04:02] <mlh> does anyone know of something good that will do that?
[04:02] <mlh> (sorta OT I know)
[04:03] <poolie> mlh, do you mean as an alternative to sql data definition language (if that's the right name)
[04:06] <poolie> (replying to this naming thread)
[04:09] <lifeless> 745ms
[04:09] <lifeless> EFOOD
[04:17] <mlh> poolie: well ddl defines the db, I want to go the other way; db-> ddl
[04:18] <mlh> I know of a bunch of products that would do it ok, but I'm particularly looking for a complete, portable (ok, oracle) version
[04:18] <mlh> mature
[04:20] <poolie> i don't know
[04:21] <poolie> aiui launchpad commits to a bazaar branch a series of 'alter table' etc statements which are replayed in order to update the database
[04:21] <poolie> then from time to time they checkpoint the entire definition
[04:21] <mlh> yeah that's what we do currently (except the for checkpointing :-)
[04:22] <mlh> but rather than commit 'alter table' statements, I'd rather commit the state of the db everytime and derive 'alter table' statements from that
[04:24] <mlh> so I could generate sql ddl but it might not be so easy to derive the 'alter ...' statements
[04:24] <lifeless> right
[04:24] <lifeless> in particular explicit relations are not enough to define logical sanity
[04:24] <mlh> IDEALLY, you'd build the entire database every time, like you'd do a compile
[04:24] <poolie> mlh, the alter statements have information about how to update existing data that's not present in the creation from scratch
[04:24] <mlh> but it's just far too expensive for any decent size database
[04:24] <lifeless> deltas -> snapshot is possible, snapshots -> deltas isn't, unless all possible constraints are defined within the db
[04:24] <poolie> well, that's not enough if you need to update existing data
[04:25] <mlh> poolie: example?
[04:25] <poolie> uhm
[04:25] <poolie> my syntax will be wrong but
[04:26] <poolie> alter table customers rename column hair to hair_color;
[04:27] <mlh> well I won't disagree, but I'm thinking it's not a fundamental restriction
[04:27] <poolie> well, a diff between the overall ddl would presumably just drop and add that column
[04:27] <poolie> so, at some level the information about how they relate needs to be captured
[04:28] <mlh> oh ok.   I could infer a rename, git style :-)
[04:28] <lifeless> this is what I mean, that you can start with deltas, but not with snapshots
[04:28] <poolie> and we know how well that works :)
[04:28] <poolie> but that is kind of a trivial example, suppose you're renormalizing to split a table into two or more
[04:29] <mlh> well fair enough
[04:29] <mlh> at a first passt (and possibly ultimate) I was more interested in validating a schema rather than producing it
[04:29] <mlh> so I upgrade the db as usualy with 'alter ...' and whatever
[04:30] <mlh> at some point I'd save the ddl
[04:31] <mlh> I can then double check the upgrade operation by dumping the ddl and comparing to what's in bzr (dumped from the 'official' db)
[04:34] <mlh> fwiw, in my experience tables hardly ever get normalized .. it's just too hard
[04:34] <poolie> heh
[04:34] <lifeless> mlh: theres a bunch of stuff in the xp world on managing db evolution
[04:35] <lifeless> mlh: basically revolves around having a apply, revert methods on a class per evolution step
[04:35] <lifeless> you could generate a 'is this correct' by doing that to an empty db and dumping the resulting schema
[04:36] <lifeless> 3.51 seconds for st now
[04:36] <lifeless> down from 3.84
[05:25] <jam> markh: https://edge.launchpad.net/bzr/1.7/1.7rc1
[05:25] <jam> I just uploaded the official tarball
[05:28] <markh> I just saw the svn plugin die a strange death (but it wasn't obvious it was the null-pointer issue in that bug).  I might see if I can repro that again...
[05:29] <markh> the svn plugin seems very slow doing tests - I'm currently at "[590/982 in 65m26s,..." :(
[05:32] <jam> poolie: ping
[05:32] <poolie> jam, oh, hi
[05:32] <poolie> congrats on the release
[05:32] <jam> thanks
[05:32] <jam> I still need to get the email out.
[05:33] <lifeless> mwhudson: how do people profile extension modules.
[05:33] <lifeless> mwhudson: its driving me batty
[05:35] <poolie> jam, shall we talk?
[05:35] <poolie> i'm a bit distracted by these disk errors tbh
[05:35] <mwhudson> lifeless: i don't know
[05:35] <jam> lifeless: I inspect the raw C code to make sure it doesn't have stuff like "PyGetAttr" all over the place.
[05:35] <mwhudson> lifeless: callgrind?
[05:36] <jam> poolie: I'd like to talk sometime, but it's almost midnight here, so I'm fine doing it some other time
[05:37] <jam> poolie: do we have an idea on 1.8 RM?
[05:37] <lifeless> jam: I know thats what you do; its laughably primitive compared to what I'd do on a regular C program with symbols.
[05:38] <lifeless> jam: because its slow, manual, prone to errors
[05:38] <lifeless> jam:
[05:38] <poolie> jam, i'm happy to do it again, though it sounded like you might want to?
[05:38] <lifeless> :!PYTHONPATH=. python -m timeit -s "from bzrlib.osutils import _walkdirs_utf8 as walkdirs" "print len(list(walkdirs('../test-repos/mozilla')))"
[05:38] <poolie> i think we should work out if we want to keep the changes you did or not
[05:39] <lifeless> 10 loops, best of 3: 695 msec per loop
[05:39] <lifeless> down from 1000ms
[05:39] <poolie> like having a trunk freeze period
[05:39] <jam> lifeless: sounds good, just make sure you have a good test suite behind it :) I've certainly gotten caught up in benchmarking only to find out it was fast because it was wrong.
[05:40] <jam> poolie: I'm fine relaxing some of that freeze. I think I was mostly coming off of the 1.6 delay and wanting to not have 10 more regression releases.
[05:40] <jam> I *do* think we want it to be "1 week of minimal disruption"
[05:40] <jam> And was sort of thinking that way going towards 1.8
[05:41] <jam> But 1.6rc5 and 1.6.1rc2 was not particularly pleasant.
[05:41] <jam> (And that was after what, 1.6b3 ?)
[05:41] <poolie> i'm sure
[05:41] <poolie> it wasn't very nice for me either leading up to that
[05:41] <lifeless> jam: thats another reason I want to avoid putting complex C logic in pyrex; its kinda hard to test from python, given that the whole speed thing is about not exposing each logical step to python
[05:42] <poolie> i guess i'd rather branch earlier and leave trunk open
[05:42] <poolie> i can understand the temptation to try to make robert work on the release but it didn't seem to work :-)
[05:42] <markh> jam: uploading now
[05:43] <poolie> i can't believe Windows has no builtin ability to write an iso to disk
[05:43] <poolie> amazing
[05:43] <lifeless> poolie: 'antitrust'
[05:43] <jam> poolie: I think it started to
[05:43] <jam> In XP or so
[05:43] <jam> But no built-in DVD player, etc.
[05:43] <jam> Even if you *buy* a DVD drive, you always get some random 3rd party tool
[05:44] <jam> which you may forget about when re-installing.
[05:44] <poolie> not in vista afaics - you can write single files but not an iso
[05:44] <markh> imgburn is a reasonable freebie for burning
[05:44] <jam> poolie: ah, you're right. It supports a different method.
[05:44] <jam> markh: Is that upload from the official tarballs, or did you use bzr.dev?
[05:44] <lifeless> jam: I'm currently writing a pure C walk-and-stat-loop
[05:45] <markh> jam: from the branch
[05:45] <lifeless> jam: I want to have an accessible 'this is what we should expect'
[05:45] <jam> markh: I just want to make sure you had the latest tip. I had to fix NEWS as a last commit.
[05:45] <jam> I accidentally called it 1.7 instead of 1.7rc1
[05:45] <jam> lifeless: Depending on what you want, I'll wrap the inner functions in a python wrapper so I can test them directly
[05:46] <jam> but the C code ignores the python form
[05:46] <poolie> markh, thanks
[05:46] <jam> cdef versus def
[05:46] <jam> etc
[05:46] <poolie> i can get around it, i probably have a copy of nero somewhere, i just think it's bizarre
[05:46] <poolie> but it's probably antitrust as robert says
[05:47] <markh> jam: nope, I missed that last change.  I've cancelled the upload.
[05:48] <markh> should only take a few mins to rebuild
[05:48] <jam> poolie: Well, I'd rather they had a synaptic style package manager, too... :)
[05:48] <jam> Getting bootstrapped on win32 is always a pain.
[05:48] <markh> most nero oem versions know the drive model they were sold with!
[05:49] <markh> and refuse to work on others
[05:49] <markh> well - I've seen that more than once, so I'm calling it "most" :)
[05:49] <jam> poolie: what is our general policy about 3rd-party announcements?
[05:50] <jam> I just saw a "bzr-gedit" email on bazaar-announce
[05:50] <poolie> onto our announce list?
[05:50] <poolie> i think it's ok for plugins
[05:50] <lifeless> whats its there for really ;)
[05:50] <poolie> unless you think it's too noisy, in which case maybe ask them to throttle back
[05:50] <jam> I'm thinking to let it through.
[05:51] <jam> Just have to be careful, because I almost hit a spam entry.
[05:51] <jam> Well, *I'm* the noisy one in the bzr-1.6 release.
[05:51] <jam> With what, 7 announcements in a week?
[05:51] <jam> Though I throttled myself.
[05:52] <spiv> jam: that sounds uncomfortable ;)
[05:52] <jam> spiv: It can be, but you pass out before you cause real harm :)
[05:54] <poolie> jam, so you should go to bed
[05:54] <poolie> i'll be working from spiv's couch as i said but just ping me tomorrow
[05:54] <poolie> and we'll talk
[05:55] <jam> poolie: sure
[05:55] <jam> I'm just getting 1.8 opened in bzr.dev
[06:00] <lifeless> my vote is less stress on releases
[06:00] <lifeless> let the steady state drive things
[06:01] <lifeless> if that state is too low, stressful releases won't fix it
[06:03] <mwhudson> poolie, jam: is the fix for https://bugs.edge.launchpad.net/bzr/+bug/261315 going to be in 1.7 ?
[06:04] <jam> I approved it, but I don't think Martin submitted it.
[06:07]  * jml frowns.
[06:12] <jam> rc2 is just a release away if it is important :)
[06:12] <mwhudson> it's important
[06:26] <lifeless> ok
[06:26] <lifeless> now this is interesting
[06:26] <lifeless> :!time ./readdir
[06:26] <lifeless> Count: 5769
[06:26] <lifeless> real    0m0.662s
[06:26] <lifeless> user    0m0.232s
[06:26] <lifeless> sys     0m0.428s
[06:27] <lifeless> :!time find ../test-repos/mozilla/ -size 0 -size 1
[06:27] <lifeless> real    0m0.344s
[06:27] <lifeless> user    0m0.092s
[06:27] <lifeless> sys     0m0.236s
[06:27] <lifeless> ><
[06:27] <lifeless> still, this is encouraging, that a naive C program is slower in sys time than find :P
[06:28] <lifeless> (than find's total time)
[06:34] <lifeless> far out
[06:34] <lifeless> time to mail this out
[06:38] <mlh> find caches some stuff dunnit?
[06:42] <mwhudson> also avoids stat-ing things if it can
[06:49] <lifeless> mlh: fchdir() is the magic
[06:49] <lifeless> mwhudson: nothing to do with it
[06:52] <lifeless> mail to the list, enjoy, taking a breather
[06:52] <lifeless> 615ms now
[07:04] <vila> Good morning readdir
[07:04] <vila> errr bazaar
[07:09] <Verterok> morning vila
[07:10] <vila> hi Guillermo !
[07:25] <samurai> ERROR
[08:14] <lifeless> and st is down to 3.34 seconds from 3.84
[10:48] <strk> ERROR: No such file: '/srv/bzr/gnash/.bzr/repository/pack-names': [Errno 2] No such file
[10:48] <strk> now what ?
[10:48] <strk> I killed while committing....
[10:48] <strk> am I lost ?
[10:49] <strk> can I copy the file from another developer ? or regenerate it ?
[10:51] <strk> actually, I've no /srv/ dir, so could be on the server side
[10:52] <speakman> hi folks !
[10:53] <strk> ERROR: No such file: '/srv/bzr/gnash/.bzr/repository/pack-names': [Errno 2] No such file
[10:53] <strk> speakman: any idea about the above ? (I killed 'bzr' while committing)
[10:55] <james_w> strk: hmm, it seems you killed it at a very bad time
[10:55] <james_w> lifeless: ^
[10:55] <james_w> strk: and it does sound like it is server side then
[10:55] <speakman> I've got an issue which I'm not sure how to deal with; If I have one mainline called "trunk" and a branch of that called "new_feature", both laying in my homedir like "~/myproject/trunk" resp. "~/myproject/new_feature". Now, if there has been some greate improvments on the trunk - is it okay to first merge all new stuff from "trunk" into "new_feature", and when all conflicts are solved merge the "new_feature" branch into "trunk"?
[10:55] <james_w> strk: you can probably regenerate the file
[10:55] <strk> and it made *every* shared branch unusable :(
[10:56] <james_w> speakman: yes, that's perfectly fine
[10:57] <speakman> james_w: is it the prefered way to go?
[10:57] <speakman> (aka, or are there any other way to do it?)
[10:57] <james_w> speakman: either way works
[10:58] <james_w> you could just merge "new_feature" in to "trunk"
[10:59] <speakman> but i might still need to continue working on the "new_feature" branch, but I also need the improvments from "trunk" to make it work (conditions has changed, and fixes are in "trunk"). Thats my issue right now.
[11:00] <speakman> the former way seems to do the trick, but I wasn't sure about how messed up the "trunk" log will be when merging "new_feature" branch since "trunk"'s already in "new_feature".
[11:01] <speakman> I'm pretty new to VCS if it wasn't obvious :)
[11:04] <speakman> I just wanted to know if it will mess up anything to regulary merge trunk into feature-branches.
[11:12] <lifeless> james_w: I'm really not here
[11:12] <lifeless> james_w: please look at the rename code, it probably wrote to a temporary name, so its recoverable
[11:13] <james_w> speakman: not at all, and it won't mess up your "trunk" log
[11:13] <james_w> lifeless: thanks
[11:13] <strk> james_w: can you help with fixing the broken thing ?
[11:13] <lifeless> james_w: start with the method in pack-repo, which does the insertion, follow it into sftp transport
[11:13] <james_w> strk: yes, just looking
[11:13] <lifeless> strk: you're using sftp right ?
[11:13] <strk> lifeless: yes
[11:14] <strk> does james_w have access to the server ?
[11:14] <lifeless> strk: sftp prevent atomic renames (acts likes windows not posix) so there is an an unavoidable race
[11:14] <strk> I wonder why they switched to it then
[11:14] <lifeless> strk: he'll learn a little about the guts of this, then probably get you to use 'sftp' or 'hitchiker' or some such to do the recovery
[11:15] <lifeless> strk: no idea, they did not discuss with me, or any bzr dev I know of
[11:21] <james_w> strk: so, there should be a temporary file 'at /srv/bzr/gnash/.bzr/repository/%s.tmp.%.9f.%d.%d' % (abspath, time.time(), os.getpid(), random.randint(0,0x7FFFFFFF))
[11:21] <james_w> there may actually be two
[11:21] <james_w> strk: lifeless seems to suggest that you don't have ssh access to the server, is that correct?
[11:25]  * kinkie is away: lunch
[11:25] <strk> no idea, I might have it
[11:25] <strk> lemme try
[11:25] <strk> uhm, Permission denied (publickey).
[11:25] <strk> never logged before
[11:26] <strk> lemme ask on #savannah too
[11:27] <james_w> you clearly have sftp access, which should be enough, but I have never used it to give you exact instructions
[11:28] <strk> trying to ssh into bzr.savannah tells me I'm not allowed to execute commands
[11:28] <strk> tried no command and /bin/sh...
[11:29] <james_w> we'll have to use sftp then, do you have any experience with that?
[11:30] <strk> entry-level
[11:30] <james_w> better than me then
[11:30]  * strk trying to connect in sftp
[11:30] <james_w> you need to look in /srv/bzr/gnash/.bzr/repository/
[11:30] <strk> ok, I'm in
[11:31] <strk> I'm there
[11:31] <james_w> for files with the pattern "<path>.tmp.<pid>.<random>"
[11:31] <james_w> there may be more than one
[11:31] <strk> tmp.pack-names.1221039958.462796926.26759.lg3cf8o308
[11:31] <strk> pack-names.tmp.1221039957.749309063.26759.1014578531
[11:31] <strk> END
[11:32] <james_w> ok, let me get this right
[11:33] <strk> -rw-rw-r--    0 69570    6469          844 Sep 10 11:46 pack-names.tmp.1221039957.749309063.26759.1014578531
[11:33] <strk> -rw-rw-r--    0 69570    6469          794 Sep 10 11:39 tmp.pack-names.1221039958.462796926.26759.lg3cf8o308
[11:33] <james_w> I think we need "pack-names....". I think "pack-names...." will have one more line than "tmp..."
[11:33] <james_w> ok, so could you rename "pack-names...." to "pack-names" please?
[11:34] <strk> can I copy ?
[11:35] <james_w> that will work too
[11:35] <strk> uhm, sftp doesn't know how to copy, I'll get for backup and rename
[11:35] <strk> done
[11:36] <james_w> it got killed just before it renamed that file to "pack-names", just after it renamed "pack-names" to the other one to allow for rollback
[11:36] <james_w> great, you should now be able to start work again
[11:37] <strk> it seems to be working
[11:37] <strk> great. thanks a lot.
[11:37] <james_w> "bzr log sftp://bzr.savannah/srv/bzr/gnash/trunk" or whatever would be a good sanity check
[11:37] <james_w> check that the latest revision is the one that you committed when you got the problem
[11:38] <strk> bzr viz succeeded. wheter there's anything missing I dunno
[11:38] <lifeless> james_w: the rename code will tell you the difference
[11:38] <lifeless> james_w: please also file a bug - this 'theoretical' race is clearly a problem
[11:38] <lifeless> I've been suspicious of this magic method for a while
[11:38] <james_w> lifeless: the difference in what?
[11:39] <lifeless> james_w: which is the old and which is the new
[11:39] <james_w> do you want the bug about pack-names, or about sftp put?
[11:39] <james_w> lifeless: yeah, I was just double checking I was reading the code correctly.
[11:41] <lifeless> what ever method failed epically
[11:41] <lifeless> should not exist as-is
[11:41] <james_w> ok, I'll file it and you can fix it up appropriately
[11:41] <speakman> now I got stuck into a strange "resolve" behaviour: Conflict: can't delete languages because it is not empty.  Not deleting.
[11:42] <speakman> "languages" is a subdir which contained a few files. They were deleted on the "trunk" and now med "trunk" was merged into "new_feature" branch, it said it couldn't delete the subdir.
[11:43] <speakman> removing it manuallt didn't help
[11:43] <strk> you don't compile the list of changes for upgrades ?
[11:43] <speakman> not even recreating it empty will make "bzr resolve" fall trough
[11:43] <strk> the update manager always says "The list of changes is not available yet. Please try again later." for bzr
[11:43] <strk> fetching from the 'bleeding edge' repository
[11:44] <strk> (deb http://ppa.launchpad.net/bzr/ubuntu hardy main)
[11:44] <lifeless> strk: it looks for a special file,I don't think ppas create it, no
[11:55] <unangz> hello master2
[11:55] <unangz> i get stuck probelm
[11:56] <unangz> how to checkout from windows repository to ubuntu linux
[11:59] <lifeless> speakman: it probably can't be deleted cause your branch has more files, or local files
[11:59] <lifeless> speakman: jst bzr resovle  <path> it
[11:59] <lifeless> speakman: *then* bzr rm it
[12:02] <unangz> i was tried use ftp to checkout from windows, but when i commit, i get problem
[12:02] <unangz> the message error indicate bzr is locked
[12:17] <speakman> hm, that did work, thanks
[12:17] <speakman> why didn't "bzr resolve" work?
[12:17] <lifeless> speakman: with conflicts in the text of a file we can tell when you have deleted them
[12:18] <lifeless> (the <<<< is gone :)
[12:18] <speakman> unangz: paste your output to a pastebin
[12:18] <lifeless> with files on disk, we haven't written logic to tell when you've made it go away satisfactorily. It's probably doable
[12:18] <speakman> lifeless: oh, i see :)
[12:19] <lifeless> s/files/file-names/
[12:20] <speakman> one more question; what's your favorite "conflict resolver" tool? ;)
[12:20] <lifeless> for paths, 'mv' and 'bzr mv/bzr rm' :)
[12:21] <lifeless> for inside a file, I usually just read with vim
[12:21] <lifeless> <- not sophisitcated in that area
[12:22] <speakman> oh, okay :)
[12:23] <lifeless> I believe aaron uses vimdiff
[12:23] <speakman> I use kdiff3 alot, but I do all my development in emacs and I think emacs is almost as capable as kdiff3, just havn't had the time to learn how to.
[12:23] <lifeless> and there is an emacs mode
[12:29] <awilkins> speakman: I like Beyond Compare 3
[12:29] <awilkins> speakman: Payware, but cheap, and IMHO the best file/folder compare tool I've used.
[12:49] <lifeless> awilkins: nice rant :P
[12:53] <jelmer> lifeless, what happened to your index work?
[12:54] <jelmer> lifeless, I'm looking at how hard to expose the git working tree and index to the user atm
[12:54] <lifeless> btrees? its landed
[12:54] <lifeless> oh, marks.
[12:54] <lifeless> marks != i
[12:54] <lifeless> 'index'
[12:54] <lifeless> 'index' bad
[12:54] <jelmer> heh
[12:55] <lifeless> reread the 'marks' thread - 'review support' I think it was
[12:55] <bob2> btrees is in 'development'?
[12:55] <lifeless> BTreeGraphIndex is in bzr.dev
[12:55] <lifeless> night all
[13:24] <speakman> btw, any trac-bzr ppl here? :)
[13:29] <jelmer> speakman, hi
[13:31] <jelmer> james_w, ping
[13:31] <james_w> hey jelmer
[13:31] <jelmer> james_w: What's your preferred branch layout for debian packeges in bzr branches?
[13:32] <james_w> you mean full-source vs. debian only?
[13:32] <jelmer> james_w: yeah
[13:32] <jelmer> it seems we're using both for pkg-bazaar at the moment, it would be nice to standardise
[13:32] <jelmer> at least for new packages
[13:33] <james_w> I prefer full-source
[13:33] <james_w> I can't remember the discussion we had at the time to know what the arguments really were
[13:34] <jelmer> the main thing was disk usage and performance I think
[13:36]  * LarstiQ would probably lean towards just regular branches of upstream too, nowadays.
[13:37] <jelmer> LarstiQ, Cool
[13:37] <jelmer> siretart, Do you prefer either?
[13:43] <kenyon> We have a problem: this is what happens: http://paste.ubuntu.com/45311/ when I  say "bzr branch lp:~federico-pelloni/ejecter/main"
[13:44] <kenyon> so i need to activate launchpad's server certificate - but how?
[13:45] <kenyon> where can i get that cert and where do i put it?
[13:45] <james_w> kenyon: install ca-certificates if you are on Ubuntu or Debain
[13:45] <siretart> jelmer: I also prefer full source. I remember that lifeless preferred debian only, though.
[13:46] <awilkins> Any of you chaps know which/whether "time" is in GNUwin32 and which package?
[13:47] <siretart> james_w: I think the best argument of 'debian'-only is that it is trivial to mount it over a more recent bzr checkout and build upstream snapshots with it.
[13:47] <james_w> siretart: yes, I guess it is easier
[13:47] <kenyon> james_w: thank you - it seems it was already there - dpkg -l|grep cert said:  ii  ca-certificates 20061027-0ubuntu0.2
[13:48] <kenyon> i would maybe try and disable pycurl cert verification
[13:48] <siretart> james_w: however, with debian only we now have a very hard time to import the last NMU to the debian package :-(
[13:48] <james_w> siretart: doing the merge and failing if there are conflicts is more robust in the face of patches to the source
[13:49] <james_w> kenyon: sorry, I didn't actually look at your error. That's on I've not seen before
[13:49] <kenyon> cant i just download via ftp or http form lp ?
[13:49] <james_w> kenyon: do you have a proxy in the way?
[13:49] <james_w> kenyon: if you run "bzr launchpad-login <your lp id>" and try again it should work
[13:50]  * awilkins answers his own question ; "time" is a bash command, not a GNU util.
[13:50] <james_w> awilkins: I think it's both
[13:51] <awilkins> james_w: Maybe they haven't ported it to win32 then ; I know it's in Cygwin bash but I can't find an obvious package for it in gnuwin32
[13:51]  * awilkins considers writing a PoSH version
[13:51] <james_w> awilkins: % dpkg -S /usr/bin/time
[13:51] <james_w> time: /usr/bin/time
[13:51] <james_w> so it's in the "time" package on Ubuntu
[13:51] <kenyon> james_w  thank you  - seems my bzr is too old, it does not recognize the launchpad-login command
[13:52] <james_w> kenyon: what version are you using?
[13:52] <kenyon> Bazaar (bzr) 0.15.0 on feisty
[13:53] <james_w> oh, ok
[13:53] <kenyon> james_w i think i will give up on this and use a different newer machine
[14:37] <poolie> vila, hello?
[14:37] <vila> hey !
[14:38] <vila> I'm not used seeing you up so late :)
[14:38] <poolie> heh
[14:38] <poolie> i shouldn't be up so late
[14:38] <poolie> vila, meet pmatulis
[14:39] <vila> his client quited  it seems
[14:40] <pmatulis> ah
[14:41] <poolie> ding
[14:41] <vila> pmatulis: oh, you're here, hi :)
[15:22] <speakman> jelmer: ure still there?
[15:23] <jelmer> speakman, yep
[15:25] <speakman> jelmer: great, i found a bug with trac-bzr, but I just recalled I posted a bugreport on LP: https://bugs.launchpad.net/trac-bzr/+bug/267700
[15:28] <speakman> updated it...
[15:45] <HippySurfer> Hi, Newbie Alert. I am trying to work out how to use bzr to enable myself and a friend to collaborate. We are not able to host a shared repository anywhere. So I thought that I could give him a mirror branch and then send him merge directives created from my branch. But it does not work, when he attempts to merge my merge directive he gets an error message: zr: ERROR: Invalid url supplied to transport: "file:///Users/rjt/Tmp/bzr_test/m
[15:45] <HippySurfer> ain/": Win32 file urls start with file:///x:/, where x is a valid drive letter". This suggests that bzr is trying to access my main branch, which he does not have. I am a bit lost ...
[16:29] <abwesend_0> http://www.hanf-spiel.de/137695
[16:34] <abwesend_0> http://www.hanf-spiel.de/137695
[17:54] <jam> does anyone know what Ubuntu package to install to get man pages for stuff like "stat" ?
[17:55] <jam> I guess I'll try "manpages-dev"
[17:55] <LarstiQ> jam: manpages-posix-dev?
[17:55] <jam> I'm just used to them being installed by default
[17:55] <jam> from 'ages' ago
[17:56] <jam> LarstiQ: thanks for the pointer. Weird "manpages-dev" is a standard package, but "manpages
[17:56] <jam> "manpages-posix-dev" is not
[17:56] <jam> It's a "multiverse" package
[17:58] <jam> anyway 'manpages-dev' had what I needed. Now to figure out the exact size of "off_t" :)
[18:49] <jam> thanks statik, now I can take over the world with bzr nightlies :)
[18:49] <jam> btw, do you have any plans to abort the build if the revno hasn't changed?
[18:50] <statik> jam: np, just added the others to the team as well. right now what i think will happen is the PPA will reject the upload if the version hasn't changed
[18:51] <jam> statik: well I think 'dch' will also abort
[18:51] <jam> unless you supply the '-b' flag
[18:51] <jam> otherwise it doesn't let you supply a version string that sorts <= the current string
[18:51] <statik> in that case, moving from a plain script to a makefile would make this cleaner, so the first failed command stops things
[18:52] <james_w> set -e
[18:54] <statik> james_w: will that make my script stop at the first error?
[18:54] <jam> statik: yes
[18:54] <statik> awesome
[18:55] <james_w> statik, if you want to override it for a specific command add "|| true" at the end
[18:55] <statik> oh nice
[20:10] <willyyam> is there an easy setting to get bzr to add files with unicode filenames?
[20:12] <jelmer> willyyam, it should already be able to add files with unicode names
[20:13] <jelmer> willyyam, perhaps the file names are not valid characters within your current system encoding?
[20:14] <willyyam> very possibly - I've got windows users putting files into a samba share
[20:15] <willyyam> bzr is running on the linux side - I'll look into my LANG
[20:16] <james_w> willyyam: bug 187267 may interest you
[20:21] <willyyam> the bug mentioned by james_w and ubottu seems to be on the money - my LANG is en_CA.UTF-8, which should be allright, no?
[20:21] <willyyam> is there a way to check the encoding of an individual samba share?
[20:21] <james_w> I'm not sure
[20:22] <willyyam> basically, bzr is using the ascii codec to inpret the file list - is there a way to force utf8 interpretation?
[20:23] <willyyam> s/inpret/interpret
[20:23] <willyyam> trailing characters :-)
[20:24] <LarstiQ> willyyam: setting your locale
[20:25] <LarstiQ> willyyam: at commit time it needs to be correct that is
[20:28] <willyyam> my locale is correct - en_CA.UTF-8
[20:48] <jam> abentley: I'm getting 404 errors with wget and bzr when trying to merge a BB patch
[20:49] <jam> Ah, I might know why
[20:49] <jam> just a sec
[20:49] <jam> nope, quoting it wasn't the solution
[20:49] <jam> ah, single quoting was
[20:49] <jam> the problem is this one: http://bundlebuggy.aaronbentley.com/request/%3C021201c90ff8$df217e30$9d647a90$@com.au%3E
[20:50] <jam> It has "$" characters in it
[20:50] <jam> so you have to use '' around the URL. :(
[20:50] <jam> Would it be terrible to munge the URL a bit more?
[20:56] <abentley> jam: I've been meaning to make the URLs be based on numeric ids, rather than message-ids.  With the current mechanism as a fallback.
[20:57] <abentley> I suspect if I %encoded $, browsers would "helpfully" decode it.
[20:59] <gotgenes> I bound my bzr branch to my branch on Launchpad. It gave me some business about my format being deprecated, and to run bzr upgrade. I just ran a bzr upgrade, which failed. I moved the file backup.bzr to .bzr. Now Bazaar tells me "no repository present".
[21:00] <gotgenes> Suggestions?
[21:05] <lifeless> gotgenes: I am just leaving, but you'll probably need to give the url to people to have a look themselves
[21:05] <lifeless> gotgenes: also, I encourage you to file a Question on launchpad-code
[21:05] <gotgenes> lifeless: the problem is on my own machine, not LP
[21:06] <pickscrape> Could it be that a different .bzr needs moving? i.e. if you're using a shared repository? Just a guess.
[21:07] <gotgenes> Could be, but I followed the directions to the t:
[21:07] <gotgenes> http://rafb.net/p/VEHgWf58.html
[21:09] <gotgenes> Ugh, here's a better paste http://paste.pocoo.org/show/84956/
[21:10] <pickscrape> Does a .bzr directory exist at all?
[21:10] <gotgenes> pickscrape: yes
[21:10] <pickscrape> If so, what's in it?
[21:11] <pickscrape> I'm betting there's a .bzr in it
[21:11] <gotgenes> http://paste.pocoo.org/show/84957/
[21:11] <pickscrape> ok, I think I know what's happened
[21:12] <gotgenes> There's a "backup.bzr" in it
[21:12] <pickscrape> mv .bzr/backup.bzr .
[21:12] <pickscrape> mv .bzr old-bzr
[21:12] <pickscrape> mv backup-bzr .bzr
[21:13] <gotgenes> pickscrape: k, giving it a try
[21:14] <gotgenes> pickscrape: brilliant! http://paste.pocoo.org/show/84958/
[21:14] <pickscrape> So when you thought you were moving the .bzr back, you were actually moving it under the failed upgrade .bzr, which needed moving away first.
[21:14] <pickscrape> xcellent!
[21:14] <gotgenes> ah, well, I see now
[21:14] <gotgenes> that makes sense
[21:15] <gotgenes> many thanks, pickscrape!
[21:15] <gotgenes> BTW what guitars do you play?
[21:15] <pickscrape> No problem, glad it was so simple :)
[21:15] <pickscrape> :) I have a Les Paul Studio Lite M-III and a Charvel Model 3.
[21:16] <gotgenes> Nice!
[21:16] <gotgenes> I've never played a Charvel
[21:16] <pickscrape> The Charvel needs new pickups and bridge though. Lovely neck though.
[21:17] <pickscrape> Did that question stem from my nick?
[21:17] <gotgenes> Makes a huge difference if you love the neck
[21:17] <gotgenes> yes, it did
[21:17] <pickscrape> I think you're the first person to actually get it and not think it's just plain weird :)
[21:17] <gotgenes> haha
[21:18] <gotgenes> that's okay, I play some, too, so I saw your SN and said, "Ah, a guitar player!"
[21:18] <pickscrape> :) I don't play anywhere near as much as I used to (and should). Just don't have time these days
[21:19] <gotgenes> pickscrape: Same boat, but I still try and get in some playing every day, or at least every two.
[21:19] <pickscrape> I'm lucky if I play every two weeks :(
[21:21] <gotgenes> pickscrape: Anything's better than nothing. :-)
[21:21] <pickscrape> True that
[21:24] <jonnydee> lifeless: Hi :) I'm glad to see your fix for bug 255656 has been merged into 1.7 series. Shall I change status to "Fix committed" or "Fix released"?
[23:08] <rockstar> jam, we need to make sure not to miss TWiB tomorrow.