[01:00] <SamB> how does one delete files using sftp?
[01:06] <wgrant> SamB: Which client? I use lftp, which works fine.
[01:06] <SamB> well, I'd really like a one-liner to do it from the shell ...
[01:07] <wgrant> You could probably do that with lftp, but there's also probably a better way.
[01:34] <SamB> hmm, pushing to 2a over smart-server involves an awful lot of Repository.get_parent_map calls ...
[01:35] <SamB> at least, it does when you have thousands of revs to push
[01:38]  * SamB tries again with trunk ...
[01:56] <SamB> wow, 2a repacks are amazingly stupid when done remotely ...
[01:58] <SamB> first, it evidently readv's each revision one-by-one
[02:06] <SamB> then (at the same time?) it does the repack locally ...
[03:11] <lifeless> SamB: smart server should repack remotely
[03:11] <lifeless> SamB: unless you ran 'bzr pack url' - don't do that.
[03:20] <SamB> lifeless: I don't!
[03:20] <SamB> lifeless: so, either launchpad's bzr is dumb, or bzr.dev is ...
[03:22] <lifeless> SamB: file a bug with what happened then
[03:22] <lifeless> include your .bzr.log contents for the event
[03:22] <SamB> lifeless: duh
[03:22] <SamB> that's the only place I can see the issue ;-)
[03:23]  * SamB makes sure nobody else has reported one like that ...
[03:29] <SamB> lifeless: are we still tagging these brisbane-core ?
[03:34] <lifeless> doesn't matter
[03:34] <lifeless> I'll look at it on monday :)
[03:34]  * lifeless is gone
[04:02] <SamB> https://bugs.edge.launchpad.net/bzr/+bug/410917 if anyone cares
[07:58] <bialix> garyvdm :-)
[07:59] <garyvdm> Hi bialix
[08:00] <bialix> hi Gary
[08:00]  * bialix reviews qexport
[08:27] <bialix> garyvdm: nice exception reporter for validate method
[08:34]  * bialix reviews qunbind
[08:46] <bialix> garyvdm: do you know what's jam want to achieve in his branch: https://code.launchpad.net/~jameinel/qbzr/progress ?
[08:48] <garyvdm> bialix: If we call methods that provide progress information, it displays it.
[08:49] <garyvdm> E.g. Annotate
[08:49] <bialix> ah, ok
[08:49] <bialix> it's not finished yet?
[08:50] <garyvdm> It works - but I think we need to try do some formatting on the messages that it prints.
[08:51] <garyvdm> may be "Loading: %s" % message
[08:51] <bialix> ok, so when jam will be ready (after bzr release) we can ping it
[08:51] <bialix> garyvdm: what you think about https://bugs.launchpad.net/qbzr/+bug/406794
[08:51] <bialix> it looks easy to fix
[08:52] <garyvdm> And I need to get qlog to show progress information like viz :-)
[08:52] <bialix> Gary, I don't know how viz works
[08:52] <bialix> never saw it in action
[08:54] <garyvdm> re: 406794 - I'll have to look at it.
[08:54] <bialix> what if we using fnmatch here instead of regexp?
[08:54] <bialix> so * will work
[08:54] <bialix> and something like 410??? will work too
[08:55] <bialix> or 410*
[08:55] <garyvdm> I don't know  - never used fnmatch.
[08:56] <bialix> it can translate glob wildcards into regexp
[08:57] <bialix> so you can write *.png to match filenames
[08:57] <bialix> do you get the idea?
[08:57] <bialix> shell patterns
[08:58] <bialix> try: python -c "import fnmatch; help(fnmatch)"
[08:58] <garyvdm> Ok - That sound cool
[08:58] <bialix> I'll fix it then
[09:05] <garyvdm> Errors from qbzr now point to https://bugs.launchpad.net/qbzr/+filebug and errors from bzr-explorer now point to https://bugs.launchpad.net/bzr-explorer/+filebug :-)
[09:06] <bialix> nice
[09:14] <bialix> garyvdm: look at http://paste.ubuntu.com/250209/
[09:14] <bialix> I wrote docstring. Is everything correct here?
[09:14] <garyvdm> Looks - good. You just missed how it searches for tags.
[09:15] <bialix> For message, author and tag it's used as regexp to search in corresponding metadata
[09:15] <bialix> it's not very clear?
[09:16] <garyvdm> Oh - sorry - my mistake
[09:16] <garyvdm> I think that we should also use glob wildcards for every thing.
[09:17] <bialix> I don't use it very often
[09:17] <bialix> I have no opinion here
[09:17] <bialix> but it's possible
[09:17] <bialix> you want this?
[09:17] <garyvdm> I've never used re's when searching. And I think that glob wildcards will make it more accessible.
[09:19] <bialix> what syntax bzr-search used?
[09:21] <garyvdm> bialix: No wild cards
[09:22] <bialix> so, I need to use fnmatch for everything except index, rigt?
[09:22] <garyvdm> right
[09:22] <garyvdm> I've allways wanted to add the ability to use wild cards when using bzr-search  in qlog
[09:23] <bialix> and if people start whine about regex we get them back
[09:23] <garyvdm> Yhea
[09:23] <lifeless> so
[09:23] <bialix> I'll update docstring accordingly
[09:23] <bialix> hai lifeless
[09:23] <lifeless> you can lookup all possible matches for the wildcard in the index metadata
[09:23] <lifeless> and then search for all of the resulting things
[09:24] <garyvdm> lifeless: Yes - thats what I planed to do.
[09:24] <lifeless> cool
[09:24] <garyvdm> lifeless - I can also make it not case sensitive that way.
[09:26] <bialix> garyvdm: new version of docstring: http://paste.ubuntu.com/250216/
[09:27] <garyvdm> bialix: great!
[09:27] <bialix> ok
[09:29] <bialix> it works
[09:30] <bialix> wow! we have a lot of bugs attached to revisions in qbzr
[09:30] <bialix> nice
[09:31] <bialix> we finally have equivalent to tags command
[09:31] <bialix> run qlog,select tag in search type, enter *
[09:31] <bialix> :-)
[09:31]  * bialix commiting
[11:42] <sender> anyone experience with the illustrious error: "pack-names is not an index of type <class 'bzrlib.index.GraphIndex'>." after bzr status, bzr log, etc..?
[15:05] <ronny> meh
[15:07] <ronny> jelmer: i just got started with playing with the subvertpy wc stuff, got pointers to different usages of it
[15:18] <ronny> hmm, guess i'll make a own example
[15:22] <ronny> jelmer: can you point me to the code thats usefull for doing checkouts? im a bit lost in the c code
[15:22] <LarstiQ> ronny: jelmer is at a festival today
[15:23] <ronny> oh, i see
[15:23] <ronny> hmm, i think i just found the code i was searching for
[15:23] <ronny> (it was in client, i digged around in wc
[15:24] <LarstiQ> right, wc I think would be operations on an existing wc
[15:24] <LarstiQ> whereas checkout would be a network operation
[17:10] <Noldorin> hello
[17:10] <Noldorin> could someone please help me figure out why i can't pull from this repo via HTTP? http://noldorin.com/repos/olivaw-bot/
[17:10] <Noldorin> pulling via FTP is no problem.
[17:11] <Noldorin> i get "bzr: ERROR: Not a branch"
[17:12] <LarstiQ> Noldorin: looking at the page in a browser mentions we don't have access
[17:12] <Noldorin> LarstiQ: that's just denying the directory listing though
[17:12] <Noldorin> isn't it?
[17:12] <Noldorin> does bzr actually need that?
[17:13] <LarstiQ> Noldorin: it also denies access to .bzr/
[17:13] <LarstiQ> Noldorin: (and .bzr/format so it is more than just denying directory listing)
[17:14] <Noldorin> hrmm
[17:14] <Noldorin> let me check
[17:20] <Noldorin> LarstiQ: i've checked permissions. they're frine
[17:20] <Noldorin> fine*
[17:27] <Noldorin> LarstiQ: any ideas?
[17:28] <LarstiQ> Noldorin: neither .bzr/branch/format or .bzr/repository/format seem to exist, what kind of object is it supposed to be?
[17:28] <LarstiQ> Noldorin: could your server be filtering out files starting with a .?
[17:28] <Noldorin> LarstiQ: it's possible
[17:29] <Noldorin> LarstiQ: what do you mean by object?
[17:30] <Noldorin> hrm
[17:30] <LarstiQ> Noldorin: is it a branch, a repository, a working tree?
[17:30] <Noldorin> LarstiQ: it's a repository i believe
[17:31] <Noldorin> since i just did bzr push
[17:32] <Noldorin> LarstiQ: server seems to havbe no problems recognising files starting with .
[17:32] <Noldorin> http://noldorin.com/repos/.bar.txt
[17:33] <LarstiQ> Noldorin: I get: File Not Found
[17:34] <Noldorin> LarstiQ: sorry, i just deleted it
[17:34] <Noldorin> http://noldorin.com/repos/olivaw-bot/.bzr/.bar.txt
[17:34] <Noldorin> there
[17:35] <LarstiQ> ah ok, good
[17:35] <LarstiQ> still not finding a format file though
[17:35] <Noldorin> yeah...
[17:36] <LarstiQ> Noldorin: could you temporarily disable the denying of directory listing? It is making debugging guessing in the dark
[17:36] <Noldorin> LarstiQ: seems like extensionless files don't get recognised :S
[17:37] <LarstiQ> Noldorin: oh &@#^
[17:41] <Noldorin> LarstiQ: hrmm...unregistered mime type?
[17:42] <Noldorin> registered the mime type, and no problem now :)
[17:43] <Noldorin> LarstiQ: should it be text/plain or something else?
[17:43] <LarstiQ> Noldorin: the mime-type of what exactly?
[17:43] <Noldorin> files with no extension
[17:44] <LarstiQ> Noldorin: they can be anything
[17:44] <LarstiQ> Noldorin: so I'd go with octet-stream
[17:45] <Noldorin> ok
[17:45] <Noldorin> will do
[17:45] <LarstiQ> wonder why your server doesn't do that by default
[17:45] <Noldorin> yeah
[17:45] <Noldorin> who knows
[17:46] <Noldorin> LarstiQ: what's the prefix?
[17:46] <Noldorin> ???/octet-stream
[17:46] <LarstiQ> Noldorin: application/octet-stream
[17:46] <Noldorin> thought so.
[17:47] <LarstiQ> Noldorin: basically "we don't know what this is, treat it as binary"
[17:47] <Noldorin> yeah, makes sense really
[17:47] <Noldorin> thanks for the help :)
[17:47] <LarstiQ> np
[17:47] <Noldorin> after all these FTP issues (no chmod) and now this, i should probably just change server
[17:47] <Noldorin> but oh well
[17:48] <LarstiQ> what's life without a bit of a challenge :)
[17:48] <Noldorin> heh, quite
[17:48] <Noldorin> as long as there's not *too* many :)
[17:48] <LarstiQ> right
[17:48] <LarstiQ> Noldorin: and be sure to quit if your blood pressure is rising too much
[17:50] <Noldorin> lol, yep.
[17:50] <Noldorin> i just want to figure why dir listing isn't working now
[17:50] <Noldorin> then it's all sorted i believe
[18:18] <mxpxpod> can I push a brand new branch to subversion using bzr-svn?
[18:26] <LarstiQ> lifeless: is http://bazaar-vcs.org/bzr/bzr.1.17/ the right submit location for 1.17.1 pqm?
[18:26] <LarstiQ> mxpxpod: I think so
[18:26] <mxpxpod> also, the first time I push a branch, I have to supply the place I want to push it.. is there a way to set that up so I never have to supply it?
[18:27] <LarstiQ> mxpxpod: you can have a push_location = foo and push_location:policy  = appendpath for example
[18:27] <mxpxpod> LarstiQ: what's that do?
[18:27] <mxpxpod> I just want the push location to be set to where I branched from by default
[18:28] <LarstiQ> mxpxpod: hmm, I don't think you can configure that
[18:28] <mxpxpod> darn
[18:28] <LarstiQ> mxpxpod: do have a look at `bzr help configuration` though
[18:29] <mxpxpod> LarstiQ: thanks
[18:29] <LarstiQ> mxpxpod: could you check if there is a bug filed on something like 'locations.conf should be able to work with push_location = :parent'?
[18:29] <mxpxpod> LarstiQ: yeah, I'll check
[18:31] <mxpxpod> oh, one last thing... let's say I make a branch of a subversion repo, then make a private branch from that branch
[18:32] <mxpxpod> to keep the private branch up to date with trunk, I'd just do a pull of the initial branch I made, right?
[18:33] <mxpxpod> and then do a bzr merge ../private within the initial branch to merge the changes from the private branch
[18:34] <mxpxpod> and then once I do a push in the initial branch, it will create a check-in in the svn repo for each commit I did in the private branch, correct?
[18:35] <LarstiQ> mxpxpod: that is the workflow I would use
[18:35] <mxpxpod> LarstiQ: right, I'm just making sure I got my commands right
[18:36] <mxpxpod> the commands would be different for a public branch, IIRC
[18:36] <LarstiQ> mxpxpod: you need an additional setting for the individual bzr commits to be svn commits I think, let me check
[18:37] <mxpxpod> since you'd have to merge from trunk instead of pulling from it
[18:37] <LarstiQ> mxpxpod: NEWS mentions push_merged_revisions = True
[18:37] <mxpxpod> like, if you had bzr branch trunk; bzr branch branches/someFeatureBranch
[18:39] <mxpxpod> instead of pulling from the branched trunk, you'd have to merge from the branched trunk, right?
[18:48] <LarstiQ> mxpxpod: unless you have no local commits, yes
[18:48] <mxpxpod> right, ok, thanks
[18:55] <mxpxpod> now, if I merge from a private branch, I'll probably want to rebase, right?
[18:56] <LarstiQ> mxpxpod: the situation isn't clear to me, merge from the private branch into trunk?
[18:56] <mxpxpod> yes
[18:57] <mxpxpod> LarstiQ: oh, I figured out how to make each change a changeset... use bzr merge --pull ../private; bzr push;
[18:57] <LarstiQ> mxpxpod: that only works if trunk has not diverged from ../private
[18:57] <LarstiQ> mxpxpod: (in which case you could also just `bzr pull ../private`)
[18:58] <mxpxpod> LarstiQ: right, but if you're constantly pulling from trunk and resolving, won't that keep it from diverging?
[18:59] <LarstiQ> mxpxpod: right, but you will change the mainline, which svn might not lie
[18:59] <LarstiQ> like
[18:59] <mxpxpod> LarstiQ: ah, ok
[19:00] <LarstiQ> mxpxpod: afaik you can't reorder the mainline on / for example
[19:00] <mxpxpod> ah, gotcha
[19:00] <LarstiQ> mxpxpod: but more recent svns have gotten better merge support
[19:00] <LarstiQ> so maybe it is possible now
[19:03] <mxpxpod> could be
[19:03] <mxpxpod> IIRC, anything 1.5 or greater handles merges well
[21:25] <Noldorin> lifeless: hey, you there?
[21:54] <lifeless> Noldorin: hi?
[22:13] <Noldorin> lifeless: hi there
[22:13] <Noldorin> lifeless: i've done a few more tests with my ftp server
[22:13] <Noldorin> it seems that the problem is indeed nothing to do with CHMOD
[22:16] <lifeless> Noldorin: go on
[22:18] <Noldorin> sorry, multitasking too much here :)
[22:18] <Noldorin> well
[22:18] <Noldorin> i'm getting the problem with locking again
[22:19] <Noldorin> it seemed it was a rare occasion when it actually didn't lock..
[22:19] <Noldorin> hrmm
[22:19] <Noldorin> can't think what we did differently last time anyway
[22:24] <Noldorin> lifeless: i'd be glad to set up a temporary FTP account for you, if it might help
[22:35] <Noldorin> lifeless: ping?
[22:53] <lifeless> Noldorin: hi
[22:53] <lifeless> Noldorin: did you file a bug about this?
[22:53] <lifeless> I think getting a failed run with -Dtransport is probably the most useful thing.
[22:59] <Noldorin> lifeless: not yetr
[22:59] <Noldorin> i will do though
[22:59] <Noldorin> lifeless: will do that right now
[23:26] <ronny> what does bzr expect for commit timestamps and timezones? same as git?
[23:29] <lifeless> huh?
[23:33] <lifeless> ronny: ?
[23:40] <ronny> lifeless: trying to figure what to pass to mutabletree.commit for timestamp and timezone
[23:40] <jelmer> 'moin ronny, lifeless
[23:42] <ronny> sup jelmer
[23:44] <lifeless> ronny: unless you need to control it, nothing
[23:44] <Noldorin> lifeless: this is my log with Dtransport turned on: http://pastebin.ca/1523363
[23:44] <ronny> lifeless: i need to controll it
[23:44] <lifeless> ronny: then its a float and an int
[23:44] <lifeless> seconds since epoch and tz in seconds
[23:45] <lifeless> Noldorin: and this was of a run that left it locked incorrectly?
[23:46] <Noldorin> lifeless: yep
[23:46] <ronny> hmm, meh, for now i'll set tz to 0 for all commits
[23:46] <lifeless> ronny: please don't do that; its easy to get the local tz
[23:48] <lifeless> Noldorin: your ftp server is broken
[23:48] <lifeless> broken broken broken :(
[23:48] <Noldorin> rubbish
[23:48] <Noldorin> lifeless: in what way, exactly?
[23:48] <lifeless> Noldorin: can you get a listing of the contents of .bzr/repository/lock ?
[23:48] <Noldorin> yeah one sec
[23:48] <lifeless> Noldorin: if you look at the log, search for repository/lock/held
[23:49] <ronny> lifeless: ok, time to play figuring stuff
[23:50] <lifeless> http://pastebin.ca/1523372
[23:50] <lifeless> thats just the held actions
[23:50] <lifeless> sorry, lock actions :)
[23:50] <lifeless> the make, put, rename sequence is how we take a lock out
[23:51] <Noldorin> lifeless: just /held/info
[23:51] <Noldorin> i see
[23:51] <lifeless> rename remove remove-directory is how we release a lock
[23:51] <lifeless> lock/held is the path of the directory that makes up a lock
[23:52] <ronny> lifeless: aware of good docs for datetime+timezones?
[23:52] <lifeless> lock/held/info is the metadata about the lock - when, who, and a nonce to allow identification of 'my lock'
[23:52] <lifeless> ronny: the python date and datetime module docs are quite good
[23:52] <lifeless> theres also things like bzrlib.osutils.local_time_offset()
[23:53] <lifeless> Noldorin: so looking in the abridged log I uploaded:
[23:53] <Noldorin> yeah...
[23:53] <lifeless> step 17,19,20 releases a lock
[23:54] <lifeless> held -> releasing.gzbwa6x1m3udf9nugpdm.tmp
[23:54] <lifeless> rm releasing.gzbwa6x1m3udf9nugpdm.tmp/info, rmd releasing.gzbwa6x1m3udf9nugpdm.tmp
[23:54] <lifeless> 23, 25, 27 make a new lock and put it into place
[23:54] <lifeless> except it fails
[23:55] <lifeless> can you cat /held/info ?
[23:55] <lifeless> .bzr/repository/lock/held/info, that is
[23:55] <ronny> lifeless: is it reasonable to expect timezone infos on a datetime object insted of a separate offset
[23:55] <Noldorin> lifeless: erm, i'm on windows, so i guess not
[23:56] <lifeless> Noldorin: well, show me the contents of the file :)
[23:56] <Noldorin> ok
[23:57] <Noldorin> sorry, not at all familiar with the unix tools like cat
[23:57] <lifeless> ronny: the datetime module does that; though its a nuisance to work with - you have to subclass stuff yourself, all the time
[23:57] <lifeless> Noldorin: no problem; I forgot myself is al
[23:57] <lifeless> all
[23:57] <Noldorin> heh
[23:57] <Noldorin> hostname: Alex-Laptop-PC
[23:57] <Noldorin> nonce: 40qh66wqvotaj97h8gxa
[23:57] <Noldorin> pid: 7328
[23:57] <Noldorin> start_time: 1249858210
[23:57] <Noldorin> user: alexreg@gmail.com
[23:59] <ronny> lifeless: yes, seems broken