[00:00] <beuno> krisives, no, bzr only stores it on the top level
[00:00] <beuno> andresj, I don't know what you want to do  :)
[00:00] <beuno> my instinct is that you could use bzr-upload
[00:00] <krisives> Or a symlink?
[00:00] <beuno> to deploy your cahnges without a .bzr dir
[00:01] <andresj> bzr-upload? that sounds like it would do its job tremendously well
[00:01] <andresj> i have a production server, which has the constraints i talked about
[00:01] <beuno> andresj, yes, bzr-upload pushed the changes that have been made since the last revision
[00:01] <krisives> To ignore a directory do I do `bzr ignore dir/` or `bzr ignore dir/*` ?
[00:01] <andresj> then i have a development server, which is hosted in my own machine, so it doesn't have sch constraints
[00:01] <beuno> uses sftp or ssh
[00:01] <andresj> does bzr-upload need a .bzr dir?
[00:01] <andresj> (on the "to" side)
[00:02] <beuno> not remotely
[00:02] <beuno> it just stores the last revid uploaded in a hidden file on the remote end
[00:02] <andresj> ##awesome! :D sounds like a good candidate
[00:02] <andresj> hum... does that file need to be in the "root" of the remote end's repo?
[00:02] <krisives> Will `bzr ignore` remove it from version control, or do I also have to `bzr remove --keep dir/` ?
[00:02] <beuno> andresj, https://edge.launchpad.net/bzr-upload
[00:02] <andresj> ok, i'll check it out :D
[00:03] <beuno> andresj, it places it on the root of wherever you tell it to upload
[00:03] <andresj> hum...
[00:03] <beuno> but that's much easier to change
[00:03] <andresj> oooh
[00:03] <beuno> I can tweak that for you, I'm one of the authors  ;)
[00:03] <andresj> soudns like a good candidate for a one-word deploy command!! :D
[00:03] <beuno> andresj, that's exactly what motivated it  :)
[00:04] <andresj> beuno: lol it would be amazing if you could do that :D
[00:04] <beuno> andresj, do what?  specify where you want to store that file?
[00:04] <andresj> beuno: yes.
[00:04] <beuno> it's just a text file with the revid, has no information
[00:05] <beuno> but I can easily add a switch that changes it's location  (I think)
[00:05] <beuno> let me play with it for a bit
[00:05] <andresj> well i can play around with it; wouldnt want to spend too much of your time :D
[00:05] <beuno> andresj, if it's a one-off you can just edit the plugin
[00:06] <beuno> you can even make it upload automatically every time you commit if you want to
[00:06] <beuno> line 106 of __init__.py specifies where it stores the revid
[00:06] <andresj> that would actually be awesome.
[00:07] <andresj> decision: trunk or ubuntu .dev
[00:07] <andresj> * .deb
[00:07] <beuno> I'd go with trunk
[00:07] <andresj> same thoughts here :P
[00:07] <beuno> http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README
[00:08] <beuno> that should give you a nice overview
[00:09] <andresj> wow, thank you so much! :-) launchpad should have manual "add karma points" option ;P
[00:10] <beuno> I have IRC karma I add on to manually  ;)
[00:10] <andresj> lol well that i completely missed—am i not informed enough about these concepts? :P
[00:16] <AfC> I bought beer for a hacker once. That should also get me Lauchpad karma points.
[00:22] <krisives> lol
[00:28] <poolie> i think it should have a 'thanks' button
[00:28] <poolie> it's nice there is one in answers, but it should be everywhere
[00:28] <wgrant> That was shot down.
[00:28] <poolie> maybe it could have a beer bottle icon, but that may give offence to some people
[00:28] <wgrant> Just recently.
[00:28] <poolie> wgrant: really? :/
[00:28] <wgrant> Yes.
[00:28]  * wgrant finds the bug.
[00:29] <wgrant> Bug 394076
[00:46] <poolie> i think we should reopen it
[00:46] <poolie> i don't know if it will get done soon though
[01:04] <andresj> self.upload_full_tree(): NotImplementedError
[01:05] <andresj> aaaah
[01:05] <andresj> no support for symlinks, right?
[01:07] <bob2> is that the bzr-upload plugin?
[01:08] <andresj> yes
[01:09] <andresj> I replaced raise NotImplementedError with continue; maybe i'll implement symlink support later :P
[02:01] <mobodo> are there bzr binaries available anywhere?
[02:01] <mobodo> (for linux)
[02:02] <sidnei> mobodo, you mean ubuntu *wink*
[02:02] <mobodo> actually, let me check, I'm not sure
[02:02] <wgrant> The Pyrex bits are just for speed, aren't they?
[02:03] <sidnei> mobodo, i assume you have looked at this page: http://bazaar-vcs.org/Download
[02:03] <sidnei> wgrant, mostly confident that's correct.
[02:03] <lifeless> wgrant: today, the C extensions are all optional, but *strongly recommended*
[02:03] <mobodo> ah, right, I can extract from a ppa
[02:04] <lifeless> wgrant: behaviour isn't identical without them, in particular data compression is reduced without the extensions
[02:04] <wgrant> lifeless: Oh.
[02:04] <wgrant> I see.
[02:05] <lifeless> wgrant: for the record, not all the extensions are pyrex either
[02:05] <mobodo> I feel dumb, I can't even find the linux flavour of my web server :P
[02:05] <mobodo> uname -a should do it, right?
[02:08] <mobodo> CentOS... oh my...
[02:09] <lifeless> fedora RPM's may be the go for you
[02:10] <mobodo> I'll try that... I need to install locally, so rpm will be easier
[02:14] <SamB> hmm ... what's a repository format that isn't going to be deprecated for a long time?
[02:15] <SamB> but isn't bzr-svn's default format either now or soon?
[02:15] <lifeless> 2a
[02:15] <SamB> you see, I'm trying to write a blackbox test like jelmer asks for here: https://code.launchpad.net/~naesten/bzr-svn/408560-format-flags/+merge/9606
[02:16] <lifeless> SamB: we deprecate rarely. whats bzr-svn's current default?
[02:16] <SamB> I'm adding support for specifying the format for an "svn-import"
[02:16] <SamB> hmm ...
[02:17] <SamB> rich-root-pack
[02:17] <SamB> it seems
[02:18] <fullermd> I think it actually uses default-rich-root, so whatever that points to at a given point in time...
[02:18] <igc> morning all
[02:19] <SamB> fullermd: ah
[02:19] <SamB> well, I want a format that will be around for a while but definately isn't that in the future ;-)
[02:21] <lifeless> SamB: 1.9-rich-root then
[02:22] <lifeless> hi igc
[02:22] <SamB> thanks
[02:22] <igc> hi lifeless
[02:22] <SamB> igc: better?
[02:22] <igc> hi samb
[02:22] <SamB> you were sick, I believe?
[02:23] <igc> SamB: still recovering but orders of magnitude better
[02:24] <igc> SamB: I had some surgery last Monday (stoma reversal) that was meant to be a few nights in hospital but ...
[02:24] <igc> SamB: things didn't go so well
[02:24] <SamB> ah
[02:25] <igc> SamB: nothing a few days in intensive care, several bags of blood and a second operation couldn't fix though
[02:26] <igc> SamB: so I'm tired & ticked off with the world but I'll get over it
[02:51] <lifeless> igc: hi, so faster commit is this || close
[02:51] <igc> lifeless: that's exciting - well done
[02:51] <lifeless> igc: if you grab bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/iter-changes-partial-parents and merge bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/commit-specific-files
[02:51] <igc> lifeless: I'll take a look when I get a moment
[02:52] <lifeless> the two combined make specific and full commits the same speed for launchpad [hot cache]
[02:59] <SamB> lifeless: that's too bad
[02:59] <SamB> because there is no || in python
[03:02] <lifeless> hold up your thumb and index finger close together
[03:02]  * SamB ;-P
[03:02] <SamB> anyway ...
[03:03] <SamB> it seems that 1.9 and 1.14 aren't distinguishable by "bzr info"?
[03:04] <lifeless> 1.14 is only a new working tree format
[03:04] <SamB> ah.
[03:05] <SamB> so no-working-tree => indistinguishable :-)
[03:35]  * igc food
[03:52] <kfogel> 'bzr branch lp:mup' gets the "Absent factory" error (bzr bug #408251) for me.  Wonder if it's my lp plugin?
[03:54]  * spiv -> lunch
[03:57] <spiv> kfogel: I see that error too, it's not a bug in your client
[03:58] <kfogel> spiv: dang
[03:58] <spiv> kfogel: at a glance it looks like the remote branch is faulty.
[03:58] <kfogel> spiv: I really want to get lp:mup, too.  Thing is, my branch is not the same as the original one in the bug.  CAn that many branches on lp be buggy?
[03:59] <spiv> kfogel: probably with the "classic" bug, not a new problem
[04:00] <spiv> kfogel: yes, please read the description of https://bugs.edge.launchpad.net/bzr/+bug/354036
[04:00] <spiv> kfogel: certainly the workaround (bzr branch nosmart+lp:mup) will work for you.
[04:00] <kfogel> spiv: thx
[04:00] <SamB> spiv: huh ... why does that look so much like the "bzr send is broken with chk" bug?
[04:00] <kfogel> spiv: do we think those two are dups?
[04:01] <kfogel> bug #40825 and bug #354036
[04:01] <spiv> kfogel: maybe, I don't know.
[04:01] <kfogel> heh
[04:01] <kfogel> I meant bug #408251
[04:01] <kfogel> spiv: ok
[04:01] <spiv> The difficulty is that that error is not a very precise symptom.
[04:01] <spiv> And the cause tends to be somewhat distant.
[04:02] <SamB> how does that relate to bug 393349 ?
[04:02] <spiv> i.e. a client with a bug does a push that appears to work, some time later someone else does a pull or branch and gets that error.
[04:02] <spiv> Basically that error just means "a record that bzr expected to be there wasn't there"
[04:03] <spiv> And that might be because bzr is looking for the wrong thing, or because it should be there but wasn't pushed, etc.
[04:03] <SamB> maybe somebody should change AbsentContentFactory to give better AttributeErrors?
[04:03] <spiv> SamB: it's a related class of problem
[04:04] <spiv> SamB: (not sending enough data)
[04:04] <SamB> I'm saying that it should say something about *what* content was absent
[04:04] <spiv> Hmm, that's better phrased as "it's related because it's the same class of problem"
[04:04] <SamB> not just look like someone forgot to implement a method ;-)
[04:04] <spiv> Well, it does, mostly, it gives the key.
[04:04] <spiv> (in current bzr)
[04:04] <spiv> See kfogel's bug comment, for instance.
[04:05] <SamB> spiv: ah, that's basically what I meant ;-)
[04:05] <SamB> but maybe it should also give a clearer indication that AbsentContentFactories aren't expected to have ... whatever attribute?
[04:06] <spiv> kfogel: so, the fixer script from 354036 does find some missing inventories on lp:mup
[04:07] <spiv> kfogel: so your problem is almost certainly that bug.  Unfortunately due to the way codehosting works it's not enough to have an owner of the branch run the fix script :(
[04:08] <kfogel> spiv: (sorry, in another conversation, will check backscroll and catch up soon)
[04:10] <spiv> kfogel: summary: it's a dupe, and I've marked the bug as such.
[04:11]  * spiv -> really lunch.
[04:12] <kfogel> spiv: ah great, thanks
[04:49]  * kfogel is away: sleep
[05:15] <poolie1> igc, not urgent, but would be curious about your comments on https://code.edge.launchpad.net/~mbp/bzr/408193-hardlink/+merge/9567
[05:16] <igc> poolie1: sure. I certainly won't get it today though sorry
[05:36]  * poolie1 reading https://code.edge.launchpad.net/~jameinel/bzr/1.18-bundle-and-stack-393349/+merge/9334
[07:13] <vila> hi all
[07:14]  * fullermd waves at vila.
[07:46] <igc> hi vila
[07:47] <vila> hey igc, glad to see you here :)
[07:47] <igc> vila: yeah - it's good to be back in the land of the living :-)
[07:47] <vila> igc: I'm grumpy too this morning if that's of any help :-D
[07:47] <igc> vila: :-)
[08:12] <fullermd> Grumpiness is healthy.  It shows that your mind is working well enough that you're not saddled with optimism or other such disorders.
[08:22] <ronny> fullermd: a set of well-placed optimism helps tho
[08:28] <fullermd> Pshaw.  Optimists are the people who put water in a glass so they can DROWN you in it.
[08:32] <ronny> fullermd: if i didnt have some optimism i wouldn't brother with the opensource work i do
[08:32] <ronny> fullermd: also i figured how to drown you with a drop of water
[08:33] <mdke> lifeless: around?
[08:34] <fullermd> Oh, that doesn't require optimism.  Just the conviction that everybody else is incompetent, and if you want something done right, you'll have to do it yourself   8-}
[08:34] <ronny> fullermd: oh, lol
[08:35] <ronny> fullermd: i get that surprisingly often
[08:35] <fullermd> Arrogance is an excellent substitute for optimism, altruism, and various other alternate sources of gumption.
[08:35] <mdke> perhaps someone else may also be able to help. I need to merge a bzr branch which has been imported from git with a bzr branch that was imported from svn. lifeless recommended I use "bzr fast-export" and "bzr fast-import" but I haven't got those commands
[08:35] <mdke> I'm running bzr 1.17 - is there a newer version I need?
[08:35] <fullermd> mdke: They're part of the fast-import plugin.
[08:36] <mdke> doh
[08:36] <mdke> fullermd: thanks!
[08:36] <ronny> fullermd: i dont like arrogance tho, it enables higher falure rate
[08:37] <fullermd> Only if you're incompetely, like Everybody Else, see.  It totally doesn't apply to Me.
[08:37]  * bialix tired to unpack zipped branches to do some work with them
[08:37] <mdke> hmm, I still don't have the command, having installed bzr-fastimport (0.0.1~bzr112-0ubuntu1)
[08:37] <bialix> how hard would be to implement zip transport or zip+ decorator
[08:37] <bialix> ?
[08:37] <ronny> fullermd: humans tend to fail, and tend to liet to themself about it
[08:37] <bialix> any hints?
[08:38] <mdke> aha, it's bzr-fast-export
[08:38] <fullermd> Lying to yourself is ineffective.  There are always other people around to remind you that you're doing it.
[08:38] <fullermd> That's where mass murder comes into the picture...
[08:39] <mdke> next questions. lifeless said to use the -r parameter for the export, but bzr-fast-export doesn't seem to have such an option
[08:39] <bialix> spiv: around?
[08:40] <ronny> fullermd: when you are better than most people around your current location, they kind of aint in that position
[08:40] <fullermd> mdke: I've got it in mine.  The release/package may be Really Old.
[08:40] <mdke> hmm
[08:40] <fullermd> mdke: Mine says "0.8dev", just pulled as a branch.
[08:40] <ronny> meh, so far i need the internet to get equivalent and/or better peers
[08:40] <spiv> bialix: yeah
[08:41] <spiv> bialix: what can I break^Wdo for you today? :)
[08:41] <mdke> fullermd: ok, I'll look for a newer version, mine seems to be coming from Ubuntu rather than the bzr ppa
[08:41] <bialix> spiv: I feel the need to write plugin to work with zipped branches, any hints?
[08:41] <spiv> bialix: as in a .bzr directory in a zip file?
[08:41] <bialix> spiv: what is better: zip transport (subclass of Local) or zip+ decorator?
[08:42] <bialix> entire branch inside zip, yes
[08:42] <spiv> Hmm, I think a new transport.
[08:42] <mdke> fullermd: there is a newer version in Ubuntu Karmic, I'll try it there. Thanks again for your help
[08:43] <spiv> Otherwise what would get_transport('zip+file://....').clone('foo') mean?
[08:43] <spiv> Does that mean a new zip file, or would it mean a new file inside a zip?
[08:43] <bialix> spiv: I guess I want read-only transport
[08:44] <spiv> I think you need more like "zip://<escaped url of zip file>/path/inside/zip"
[08:44]  * bialix upgrade to ff 3.5.2, sorry if I'll disappear for a bit
[08:44] <spiv> Or possibly create a ZipServer along the lines of ChrootServer
[08:45] <spiv> (So URLs like zip-111111://... that are just in-process names for an already-open zip file)
[08:45]  * bialix back
[08:46] <bialix> spiv: escaped url?
[08:46] <spiv> 17:44 < spiv> Or possibly create a ZipServer along the lines of ChrootServer
[08:46] <spiv> 17:45 < spiv> (So URLs like zip-111111://... that are just in-process names for an already-open zip file)
[08:46] <spiv> I think that would be a better option.
[08:47] <bialix> I don't understand
[08:47] <bialix> in my imagination I'd like to work from command line as: bzr pull zip://path/to/archive.zip/branch/inside/zip
[08:47] <spiv> Well, it depends a bit on exactly how you want it to work... you want to be able to do "bzr branch http://.../somefile.zip foo"
[08:48] <spiv> Hmm.
[08:48] <bialix> I think valid URL for branch inside zip could be zip://path/to/archive.zip/branch/inside/zip
[08:48] <bialix> so path/to/archive.zip is actually zip file
[08:48] <spiv> Ok, that works, but only for local paths obviously.
[08:49] <spiv> If you're fine with that restriction then go for it.
[08:49] <bialix> yep, that's why I've asked about zip+ decorator
[08:49] <spiv> (zipfile://... might be clearer?)
[08:49] <spiv> Or rather, it works with some hackery.
[08:49] <bialix> zipfile? maybe it is, but longer to type
[08:50] <spiv> You can't just look at the URL you propose and know what the path to the zip file is.
[08:50] <bialix> yes, I guess I need to introduce some restrictions
[08:50] <spiv> Which is why I proposed a scheme more like http
[08:50] <spiv> Where you have a netloc (host) and a path.
[08:50] <bialix> or use different URL scheme, as discussed with colocated branches
[08:50] <bialix> what is netloc?
[08:51] <spiv> jargon for the "host" part of "http://host/foo", roughly.
[08:51] <bialix> ok, I understand
[08:51] <bialix> but no, it will complicate of usage
[08:51] <spiv> So, zip://path%2Fto%2Farchive.zip/branch/inside/zip, for an ugly example.
[08:52] <bialix> it's really ugly
[08:52] <spiv> Yep.
[08:52] <bialix> and I can't use tab-completion then
[08:52] <bialix> I can try to find zip file recursively, trying to open path/to/archive.zip/branch/inside/zip, then path/to/archive.zip/branch/inside etc
[08:53] <spiv> I think there's a better way.
[08:53] <bialix> once I found zip file I'll use remainder as relpath inside zip
[08:53] <bialix> what about read-only?
[08:54] <bialix> is it declared somehow or I just need not to implement write methods?
[08:54] <spiv> bialix: I think implementing a ZippedBzrDir would actually work better.
[08:54] <bialix> why?
[08:55] <spiv> bialix: then plan paths and URLs would Just Work, no new URL syntax in the UI necessary
[08:55] <bialix> ah, and I can reuse std probing?
[08:55] <bialix> hi Gary!
[08:56] <garyvdm> Hi
[08:56] <spiv> And you won't have this friction with probing in a transport, which in your proposal you'd either be redoing *lots* or doing a hack to share state between Transports, which are mostly stateless.
[08:56] <bialix> spiv: ZippedBzrDir will be enough? or I need ZippedBzrBranch as well?
[08:56] <spiv> Right.
[08:57] <spiv> Well, if I were to implement this, I'd make a ZippedBzrDir and then a ZipTransport/ZipServer
[08:57] <bialix> perhaps I need to look at bzr-svn/bzr-git to see how they implement foreign formats
[08:57] <bialix> I don't undertsand
[08:57] <bialix> what is ZipTransport/ZipServer?
[08:57] <spiv> The ZippedBzrDir would probe the transport it is given, and if it finds a zip file,
[08:58] <bialix> garyvdm: can you look at failing test?
[08:58] <spiv> then it would create a ZipServer object (which gives you a single place to open/close the zip file, and possibly do some caching),
[08:59] <bialix> spiv: is there example of doing so?
[08:59] <spiv> (the ZipServer would be backed on to the real transport)
[08:59] <bialix> spiv: it sounds a lot like black bzr magic
[08:59] <garyvdm> bialix: The qbzr treemodel test - yes - it will be easy to fix. I'll do it tonight.
[08:59] <garyvdm> bialix: Sorry - I have been very busy with other things.
[09:00] <spiv> And then construct a ZipTransport from the ZipServer, and then pass *that* back into regular BzrDir.open_from_transport
[09:00] <bialix> garyvdm: we need to release qbzr in sync with bzr
[09:00] <bialix> spiv: oh
[09:00] <spiv> bialix: take a look at ChrootServer (and bzrlib.smart.server's serve_bzr function)
[09:01] <spiv> But the ZipTransport here wouldn't be something that could be directly constructed from a URL from a user (just like you can't just pass a chroot:/... URL on the command line).
[09:02] <spiv> bialix: if you look at ChrootServer it's a very simple class, and I imagine your ZipfileServer would be pretty simple too; basically just an object to hold an opened zipfile.
[09:03]  * bialix looks at ChrootServer and serve_bzr
[09:03] <spiv> (like how ChrootServer is basically just an object to remember what the backing transport is, regardless of any t.clone('..') etc done on the individual transport objects)
[09:03] <bialix>     chroot_server = ChrootServer(transport)
[09:03] <bialix>     chroot_server.setUp()
[09:04] <bialix>     transport = get_transport(chroot_server.get_url())
[09:05] <spiv> Right.
[09:05] <bialix> I'm not quite understand how it prevents of clone('..')
[09:06] <spiv> transport there will be an instance of ChrootTransport
[09:06] <lifeless> mdke: hai
[09:06]  * igc dinner
[09:06] <bialix> so, should I subclass Chroot(Server|Transport) for Zipped*?
[09:07] <spiv> Which implements every method of Transport by first checking the path is safe (see ChrootTransport._safe_relpath), and then calling self.server.backing_transport.<method>
[09:10] <spiv> I wouldn't subclass Chroot* for you.
[09:10] <bialix> just reimplement the logic?
[09:10] <spiv> Yeah.
[09:10] <bialix> last question: how can I force read-only?
[09:10] <spiv> I suppose if you subclassed just ChrootTransport you'd be able to reuse all the shim methods... but it's not a very good fit.
[09:10] <spiv> For that I'd just use the readonly+ decorator, I think :)
[09:10] <bialix> oh, I found
[09:10] <bialix> is_readonly method of transport should do
[09:11] <bialix> so, I have two ways for my plugin: do only zip:// transport, or going hard path and implement ZipBzrDir, Server, Transport
[09:11] <spiv> For the implementation of write methods like mkdir just raise TransportNotPossible("readonly transport"), just like ReadonlyTransportDecorator does.
[09:12] <spiv> Personally, I think the latter is actually the easy path :)
[09:12] <spiv> Because otherwise you're going to be fighting the design of bzrlib.transport rather than working with it.
[09:12] <bialix> TransportNotPossible: ok
[09:13] <spiv> (and return False from is_readonly, of course, as you've noticed)
[09:14] <bialix> maybe you're right about easy path, I need to experiment with Server a bit
[09:15] <bialix> spiv: thanks for the hints, I'll try to play with it
[09:15] <spiv> Another example of the Server/Transport pattern is MemoryServer/MemoryTransport.
[09:17] <bialix> ok
[09:52] <garyvdm> Hi - Any advice on how I should respond to this: http://paste.ubuntu.com/247031/ ?
[09:55] <luks> is it worth responding to?
[09:56] <luks> convincing somebody that version control is useful can be tough
[09:56] <garyvdm> luks - yes - I have to collaborate with this guy on a website...
[09:57] <fullermd> In cases like this, I like to use swearing...
[09:57] <jpds> garyvdm: How does he plan to keep track of change?
[09:57] <garyvdm> At the moment, I'm commit his changes on his behalf.
[09:57] <garyvdm> jpds: He doesn't
[09:58] <bialix> garyvdm: I'm windows box person
[09:59] <bialix> does my words as former windows maintainer will help?
[09:59] <luks> I think the problem here is VCS in generally, not bzr specificially
[09:59] <luks> *general
[09:59] <garyvdm> bialix: The windows issue is easy to deal with.
[10:00] <garyvdm> It the "why vcs?" issue that is hard.
[10:00] <bialix> I don't understand what is windows issue here
[10:00] <garyvdm> *It's
[10:00] <garyvdm> bialix: FUD
[10:00] <bialix> call vcs as automatic backup
[10:00] <bialix> that's all
[10:01] <maxb> Ask him how *he* plans to deal with merging changes when you are both doing work simultaneously, and then point out how VCS would make that so much easier?
[10:01] <garyvdm> maxb: Yes
[10:01] <luks> make him screw up something, so he needs an older version :P
[10:02] <garyvdm> Or just keep on overwriting his changes...
[10:02] <fullermd> I've used that technique with some success.
[10:02] <fullermd> Though usually, the response ends up being an endless stream of commits with no log messages, and/or the log message "This week's work" every Friday at 16:55.
[10:02] <maxb> And ask him how he would deal with discovering that a mysterious subtle bug was introduced some time ago, and explain about bisecting :-)
[10:03] <luks> fullermd: better than nothing
[10:03] <luks> one step at a time :)
[10:03] <garyvdm> maxb: That will just go straight over his head...
[10:03] <maxb> oh dear
[10:03] <fullermd> Yeah, the response to that will be "Who cares where it came from?  It's there now, so fix it."
[10:04] <bialix> fullermd: you talk about backup or overwriting changes?
[10:04] <fullermd> bialix: Overwriting.
[10:04] <fullermd> Or, you can keep checking it in for him.  And billing him for the time you spend doing so.
[10:18] <garyvdm> This is what I'm sending him: http://paste.ubuntu.com/247060/
[10:23] <bialix> there is always enough lights to one who want to see, and enough darkness to one who don't
[11:06] <luks> heh
[11:06] <luks> http://crossonline.blogspot.com/2009/08/howto-version-control-using-bzr.html - comparing bzr to rcs
[11:12] <vxnick> anyone have any experience with bzr-keywords? Not sure how to get it working
[11:14] <fullermd> Installing the plugin and enabling the filter got it working for me.
[11:14] <fullermd> Shortcomings in filtering make it less than useful, though.
[11:14] <bialix> I guess you need to use 2a format to enable filtering?
[11:15] <fullermd> 1.14
[11:15] <fullermd> (2a includes the new WT format too of course)
[11:15] <vxnick> hmm
[11:16] <vxnick> I setup some rules in ~/.bazaar/rules, but that didn't seem to do anything
[11:16] <vxnick> and put a keyword in a test file
[11:17] <fullermd> How are you checking that it does anything?
[11:17] <vxnick> committing various changes to see if it updates the placeholder in the file with the revision info
[11:17] <fullermd> That's one of the filter problems rearing its head.  Commit will never update them (expand if they're collapsed, or update if they're already expanded)
[11:18] <fullermd> If you make a new 'branch' of it, they'll be expanded there.
[11:18] <vxnick> ah I see
[11:18] <fullermd> With a branch igc has on LP, they'll be updated on 'pull' too.
[11:18] <fullermd> Still not commit (or, I think, merge either)
[11:18] <vxnick> yep you're right, branching expands the keyword fine
[11:18] <fullermd> revert also won't touch 'em.
[11:18] <vxnick> that's annoying
[11:19] <fullermd> Well, that's why I say "yes it works" and "less than useful" in the same breath  :)
[11:19] <vxnick> I can see why :)
[11:19] <fullermd> (and of course you can't test whether 'checkout' actually expands them either, since the default format doesn't include rules, and checkout still doesn't have a --format so you can tell it which WT format to use)
[11:20] <vxnick> bah
[11:20] <vxnick> is this a known issue or worth raising a ticket for on LP?
[11:21] <fullermd> Well, there's bug 385879
[11:21] <vxnick> ah thanks
[11:22] <fullermd> The title on that is slightly misleading, since it's really a filter bug, not an EOL (or keywords, for that matter) bug.
[11:22] <vxnick> I'm guessinf the filter stuff is what's causing the expansion/collapsing problem though
[11:49] <bialix> is it correct that `bzr rm` without arguments does not throw error?
[11:52] <fullermd> I'm pretty sure that goes through the tree and explicitly sets removed status for missing files.
[11:53] <bialix> ok
[12:27] <poolie1> hello vila
[12:42] <mobodo> has anybody ever done a local/user install of bzr?
[12:45] <mobodo> oh, nevermind, it's on the faq :)
[12:45] <mobodo> hmmmpfr, except that I need gcc to compile and I don't have access to it..
[12:48] <Kinnison> You don't *need* the gcc IIRC
[12:49] <Kinnison> it just makes things go faster if you can compile stuff
[13:01] <poolie1> that's true
[13:01] <poolie1> it is much better with it though
[13:02] <vila> poolie1: just back from my lunch break !
[13:04] <poolie1> pqm seems to be jammed, i just asked on #is
[13:16] <ronny> hmm, appearantly renaming things is a quite pleasant operation on a memorytree, not so far for all the other things
[13:18] <ronny> jelmer: you got any example for stuff like recording rename+content_change in subvertpy, the svn api is still like a black box to me
[13:18] <jelmer> ronny: Rename is a copy + delete, there is no separate operation for that
[13:19] <jelmer> I'll see if I can update the example to do a simple content change
[13:21] <ronny> hmm, and i guess i'll have to invent something that records changes on one of my trees so i can do my own magic on each of the vcs's
[13:26] <jelmer> ronny, updated example pushed
[13:38] <igc> vxnick, fullermd: I really hope to take a look at the content filtering bugs this week or next
[13:38] <vxnick> igc: excellent :)
[13:38] <vxnick> that'd be much appreciated
[13:44] <igc> xvnick, fullermd: I had planned to a week or so back but had some distractions (doc site upgrade) for a few days and then was off last week for medical reasons
[13:51] <NEBAP|work> how can I add a user to a project on launchpad?
[13:51] <vxnick> igc: understandable :) Will bzr-keywords then expand placeholders upon commit, etc, so we can see them in our local copy?
[13:52] <igc> vxnick: ask me again when I'm awake :-)
[13:52] <vxnick> np ;)
[13:53] <igc> vxnick: seriously, if you put a bug report in explaining exactly what you expect, that's the best way for me to asynchronously respond
[13:53] <igc> ... in a considered way
[13:53] <vxnick> igc: fair enough, I'll stick a report, thanks
[14:03] <mobodo> is it possible to list the content of a remote branch?
[14:05] <vxnick> mobodo: bzr ls ?
[14:29] <CaMason> I've branched from a main branch and made some changes. I've committed to my branch. How can I now merge back to the other one, whilst retaining my whoami info?
[14:40] <bialix> merge does not change your whoami info
[14:50] <CaMason> bialix, ah, it was because I did a selective merge for a particular revision
[14:50] <bialix> it's called cherrypick
[14:51] <CaMason> that's the one
[14:51] <CaMason> so I cherrypicked to a different branch, then merged from that
[14:51] <bialix> bzr has no good support for this
[14:51] <bialix> I'm using replay command from bzr-rewrite plugins (former bzr-rebase)
[14:52] <bialix> instead of cherrypick you can rebase/replay your revisions
[14:52] <CaMason> this is ok for me - I've got one main working branch, but many of those changes aren't fit for the main trunk
[14:52] <CaMason> I'll look that up
[14:52] <bialix> CaMason: do you aware of DAG concept?
[14:52] <CaMason> nope
[14:53] <bialix> I'd recommend to read DaggyFixes document from monotone
[14:53] <CaMason> great - will do
[14:53] <bialix> after I've started to practice this method my cherrypicks went much better
[14:54] <CaMason> this is what I've just done, right?
[14:54] <bialix> I'm not sure what you done
[14:54] <CaMason> ah it kinda is
[14:55] <bialix> no, cherrypick to other branch and then merge -- it's like replay works
[14:55] <CaMason> that's what I did :)
[14:55] <bialix> DaggyFixes require you to branch not from the tip revision, but from the point where branches have diverged or earlier
[14:56] <bialix> http://www.monotone.ca/wiki/DaggyFixes/
[14:56] <CaMason> this is what I'm reading
[14:56] <CaMason> good - I'm pleased with my ad-hoc decision
[14:57] <corporate_cookie> the recommended install method for bzr on RHEL is to use the EPEL repo ..but it installs bzr 1.3.1!
[14:57] <corporate_cookie> is there a repo with a more current version ? ...i mean whoa ..thats dusty
[14:58] <bialix> CaMason: as you like
[14:58] <CaMason> this document looks very useful as-a-whole, bialix
[14:59] <bialix> yes, it is
[15:10] <JNRo__> Hi guys, I'm having problems cloning.  The three repos I've tried just seize up midway.  The current one I'm waiting on says "Copying inventory texts:Copied record 262/294"  Is there some way to get more info about what is going wrong?
[15:10] <JNRo__> This happens with repos on lp like fastimport and elsewhere like the one at bugseverywhere.org . Perhaps this is a known problem with high latency connections(3G in my case) and there is some workaround.
[15:11] <slangasek> vila: jml has suggested that you are interested in bugs like 'bzr status' on an OOD condition resulting in a corrupted branch that I can no longer run 'bzr status' on even after cleaning up some space :)
[15:12] <slangasek> ah, which james_w informs me is probably 131111
[15:12] <slangasek> (bug #131111)
[15:13] <vila> slangasek: I wonder why jml said that :-) But what means OOD ?
[15:14] <jml> vila, mostly because I know you like hard problems & are awake :)
[15:14] <vila> jml: haaa, I see :)
[15:14] <jml> vila, OOD = out of disk
[15:15] <vila> So, if enough space if available now, I'm pretty sure there is a dirty trick to trigger rebuilding the dirstate file, I just don't remember it right now :-/
[15:16] <james_w> yeah, I just walked Steve through it
[15:16] <vila> We should really have one official way to force rebuilding it, even as an hidden command
[15:16] <vila> james_w: care to refresh my deficient memory ?
[15:16] <james_w> it's non-obvious though, as you can't even branch it due to the code to read from the working tree if it exists
[15:16] <james_w> mv .bzr/checkout /tmp
[15:17] <james_w> bzr branch . ../temp
[15:17] <james_w> mv ../temp/.bzr/checkout .bzr/
[15:17] <vila> ha yes ! Rebuild a decent dirstate file and then copy it back !
[15:17] <vila> james_w: thanks
[15:17] <james_w> np
[15:27] <slangasek> vila: out of disk
[15:27] <slangasek> right, laggy brain
[15:27] <vila> slangasek: yeah, jml translated already, you're out of trouble no right ?
[15:27] <vila> slangasek: yeah, jml translated already, you're out of trouble now right ?
[15:27] <slangasek> yeah, the whole reason I was running 'bzr status' was to see whether I could throw it away to free up some more disk space ;)
[15:28] <slangasek> so it's all done now, thanks
[15:28] <vila> hmm, yeah, I hate those moments....
[15:31] <bialix> "vila, mostly because I know you like hard problems" -- this remind me about one TV serial with Gregory as main character. but I know that vila is not Greg. (it was supposed to be a joke)
[15:32] <vila> bialix: :-) Unfortunately I know no TV serial with Gregory as main character, any url ?
[15:32] <bialix> vila: hi btw, I'm sure your vacation was great
[15:32] <bialix> House M.D.
[15:32] <vila> LOL, Dr House ! Oh yes, thanks for the comparison :-)
[15:33] <vila> Now I can be grumpy for a good reason :)
[15:33] <bialix> :-)
[15:33] <bialix> I was grumpy about your push --strict, and you just in time going away, so you can't hear my scream
[15:33] <jam> good afternoon vila, good to see you around again
[15:34] <bialix> jam: hello
[15:34] <jam> hi bialix
[15:34] <bialix> jam: we discussed bundling image plugins for Qt into bzr.exe installer. now I have patch
[15:35] <jam> bialix: yeah, I saw that. I was trying to grab a copy of your branch and test it, though I got side-tracked by about 50 other bug reports :)
[15:35] <bialix> np, though will be nice to have it merged before 1.18 is out
[15:36] <vila> I'm almost done with my mail backlog and I saw the threads about push --strict, 1) I'm surprised you don't get the mails related to the merge proposals, 2) I thought (and still think) that adding a config variable is a small price for any power user (and power users should read NEWS :-P)
[15:36] <vila> jam: good morning !
[15:36] <bialix> jam: I'm not sure how it collides with recent zc.buildout work you and sidnei done
[15:36] <jam> bialix: shouldn't conflict much. the zc.buildout stuff is just a wrapper around calling 'setup.py'
[15:37] <bialix> vila: well, i think such big change deserve big red flashing news! but there was not big
[15:37] <vila> jam: I hope we can soon plug kerguelen into my buildbot master
[15:37] <vila> bialix: I really thought power users rarely encounter the context of pushing with uncommitted changes, really
[15:38] <jam> vila: I think you need to talk to sidnei_ about that
[15:38] <jam> I thought it was "real close"
[15:38] <jam> since he has one running himself
[15:38] <jam> vila: http://buildbot.sidneidasilva.com/waterfall
[15:38] <bialix> vila: I disagree
[15:38] <vila> I thought so too two weeks ago :-/
[15:38] <jam> though that is running a bit slow today
[15:39] <bialix> vila: anyway, I found good solution for qbzr now
[15:39] <vila> bialix: I saw that and that's why I didn't answer to the thread
[15:40] <vila> bialix: and, indeed, since there is an interaction, it's better to ask the user
[15:40] <bialix> yes
[15:40] <vila> sidnei_: ping, already there ?
[15:41] <bialix> jam: is it possible to make mysql's file commit messages a bit more "official"
[15:41] <bialix> ?
[15:41] <sidnei_> vila, just woke up *yawn*
[15:41] <vila> sidnei_: have a coffee and come back later then :-)
[15:42] <sidnei_> vila, more like lunch actuallly, slept too much, its 11:40 now :)
[15:42] <bialix> jam: maybe bzr can introduce new (hidden) command-line option for commit to have the way to provide custom revision data to commit?
[15:42] <vila> sidnei_: do you have an ETA for creating a new buildbot slave that can be plugged in my master and the needed associated master modifications ?
[15:42] <sidnei_> vila, wouldn't we use kerguelen for that?
[15:43] <vila> sidnei_: yes, a slave on kerguelen
[15:43] <vila> sidnei_: that's where your slave for http://buildbot.sidneidasilva.com/waterfall is right now, yes ?
[15:44] <sidnei_> vila, yes
[15:44] <vila> instead of switching the exisintg slave to the new master, I thought creating a new one will be eaiser
[15:44] <jam> bialix: I think something like that would be ok. I think it would be difficult to figure out how to pass things in appropriately.
[15:44] <jam> I think you want to inject enough data that just passing it on the command line would be insufficient
[15:44] <bialix> jam: bencode?
[15:44] <jam> so you probably need a separate file
[15:44] <jam> with a specific formatting
[15:44] <jam> bencode would be ok
[15:45] <jam> though I still think it is *terrible* for human consumption
[15:45] <bialix> json?
[15:45] <jam> I think I would prefer a rio formatted file
[15:45] <jam> we don't use json anywhere else in the code
[15:45] <jam> so I would avoid that *for now*
[15:45] <bialix> ok
[15:45] <bialix> I don't used it either
[15:46] <jam> I prefer json to bencode, but that isn't what we use *today*...
[15:46] <bialix> I mention bencode because it good candidate to put things in command-line
[15:46] <jam> and I don't think we are going to convert everything over to it
[15:46] <jam> bialix: sort of, but remember again that it would be awful if you wanted to type any of that
[15:46] <sidnei_> vila, different from real life, buildbot slaves can have many masters *wink*
[15:46] <bialix> I don't know how they compare re speed
[15:46] <jam> also, per-file messages are likely to have "\n" in them
[15:47] <jam> bialix: json has fast C parsers available for python, and they are even bundled in 2.7 or 3.X or something
[15:47] <bialix> ah, ok
[15:47] <jam> simplejson is a nice python package
[15:47]  * bialix sticks with 2.5 for C-extensions and py2exe reasons
[15:47] <abentley> jam: I don't think json supports recording binary data, which is one thing bencode does.
[15:48] <vila> sidnei_: huh ? I think the buildbot.tac defines the slave and contains the master adddress, no ?
[15:48] <jam> abentley: I'm pretty sure you can, though you may have to escape it with base64
[15:48] <jam> certainly I've done raw dumps w/ py_memory_dump into json
[15:48] <sidnei_> vila, yes, but you can run multiple instances of buildbot.tac
[15:48] <abentley> jam: base64 is a way of recording binary data in formats that don't support binary data :-)
[15:48] <vila> sidnei_: well, that's what I call a slave then :)
[15:49] <jam> abentley: so I didn't use any specific hacks (that I can remember) in py_memory_dump
[15:49] <vila> sidnei_: as opposed to the host running the slave I suppose
[15:49] <jam> abentley: ah, I use the "Unicode escape sequence" to format the output
[15:49] <jam> if (c <= 0x1f || c > 0x7e) { // use the unicode escape sequence
[15:49] <jam>     fprintf(out, "\\u00%02x", ((unsigned short)c & 0xFF));
[15:49] <sidnei_> vila, what you mean by that?
[15:50] <jam> abentley: so it seems to work for my purposes... :)
[15:51] <jam> so yes, you need to escape binary data
[15:51] <jam> one way or another
[15:51] <jam> on the plus side, json natively supports unicode types, which bencode does not
[15:52] <vila> sidnei_: by what ?
[15:53] <sidnei_> vila, "as opposed to the host running the slave I suppose"
[15:53] <jam> sidnei_: I think the point is that if you have to run *another instance* that is *another slave*
[15:53] <jam> even if it is on the same machine
[15:53]  * vila just loves jam :)
[15:54] <sidnei_> jam, correct. but of course i will be shutting my master down when we switch to vila's so we only need one
[15:54] <vila> sidnei_: sure, my point was just to allows both slaves to exists during the transition
[15:55] <Tak> hmm, how does one "install" dulwich from lp?
[15:55] <jam> Tak: bzr branch lp:dulwich dulwich; cd dulwich; python setup.py install ?
[15:55] <jam> with maybe a 'sudo' in there as needed
[15:56] <Tak> cool, thanks
[15:56] <sidnei_> vila, sure.
[15:56]  * sidnei_ figures out lunch now
[15:57] <jam> bialix: what version of PyQt is your patch supposed to work with?
[15:57] <jam> so far, it doesn't look like it is finding my imageformats
[15:57] <jam> but I'm still investigating
[15:58] <bialix> jam: 4.4.3
[15:58] <bialix> jam: you said you have upgraded to 4.4.3
[15:58] <jam> is there a difference between that and 4.4.0? (that you know of?)
[15:58] <jam> On kerguelen I'm pretty sure it is 4.4.3
[15:58] <jam> I have 4.4.0 locally
[15:58] <jam> easier to test locally
[15:58] <jam> I'm not even getting a warning, though
[15:58] <bialix> in earlier versions of 4.4.x (artleast I saw it with 4.4.1) PyQt4 was installed in different folder
[15:59] <bialix> jam: can you look into C:\Python25\PyQt4 ?
[16:00] <bialix> does it have plugins folder?
[16:00] <jam> bialix: right, so I think that is what I'm seeing. I have both C:\Python25\Lib\site-packages\PyQt4 (which is where 'import PyQt4" comes from
[16:00] <jam> *and* I have C:\Python25\PyQt4\
[16:00] <jam> which is where "plugins\imageformats" lives
[16:00] <bialix> ok, I can check both locations
[16:00] <bialix> but I can't test it
[16:00] <jam> I'll look at kerguelen
[16:00] <bialix> because I have no older pywt
[16:00] <bialix> *pyqt
[16:01] <jam> sidnei, vila: Are you connected to kerguelen right now?
[16:01] <jam> I'm getting "cannot connect" errors
[16:01] <jam> which is different from "cannot log in because there are too many users"
[16:01] <jam> I believe I left a connection running because my network died overnight...
[16:01] <vila> jam: not connected
[16:01] <sidnei> jam, no, im trying to get lunch :)
[16:02] <jam> sidnei: go eat then, and stop bothering me :)
[16:02] <jam> (or stop being bothered by me?)
[16:02] <vila> sidnei: go go go, and come back before I quit myself :)
[16:02] <jam> bialix: so one question. Why are you setting "os.environ['PATH']" ?
[16:03] <jam> so that py2exe can find the dlls during build time?
[16:03] <bialix> jam: I'm not
[16:03] <jam>             os.environ["PATH"] = path + os.pathsep + qt_dir
[16:03] <jam> that is setting the path
[16:03] <bialix> jam: I think this code has written by Mark Hammond
[16:04] <bialix> and it supposed to workaround PyQt 4.4.1 issue with different install paths
[16:04] <bialix> oh
[16:04] <bialix> I think I remember the same (bad) layout of PyQt even in 4.4.2
[16:04] <bialix> I've stuck with 4.3.1 because it was much simpler to deal with
[16:05] <bialix> now 4.4.3 is the best option IMO
[16:05] <bialix> jam: I'm in process to tweak the search code
[16:05] <jam> bialix: you can wait, and I'll get it working here first, if you prefer
[16:05] <jam> since I have an actual test case :)
[16:06] <bialix> I can wait or write some code
[16:06] <bialix> it will cost the same amount of time
[16:06] <jam> just wait, I think I know what to do, and I can quickly know if it actually works
[16:07] <bialix> actually I'm already write
[16:07] <bialix> wrote
[16:07] <bialix> and now I can wait
[16:09] <bialix> jam: Mark has written that code, revno 3565.5.6, year ago
[16:09] <bialix> jam: I've made it optional, because newer PyQt (4.4.3) does use different install layout
[16:16] <jam> bialix: have you tested that it finds imageformats after building and installing?
[16:17] <jam> (I want to make sure we are installing it where pyqt is going to be looking for it.)
[16:17] <bialix> jam: yes, I'm working with such configuration right now
[16:17] <bialix> pyqt looks in the same directory where exe resides either for plugins or qt.conf where path to plugins set
[16:18] <bialix> I've decided to avoid creating qt.conf
[16:18] <bialix> although with qt.conf we can put imageformats into lib/
[16:19] <bialix> but I don't think it makes too big difference, really
[16:19] <bialix> if we start to bundle more additional pyqt stuff, then it will be better to put it into dedicated folder and create valid qt.conf
[16:20] <jam> bialix: where does qt.conf need to reside?
[16:20] <jam> in 'Bazaar/' or in ~user files?
[16:20] <bialix> in the same folder where bzr.exe is
[16:20] <bialix> in Bazaar/
[16:20] <jam> vila: so... from my home machine, I can log into kerguelen's control page, but I can't get to kerguelen itself
[16:21] <jam> I can ping the ip address
[16:21] <jam> but DNS isn't resolving the 'hosting24' domain
[16:21] <jam> ... :(
[16:21] <bialix> jam: I have tweaked my code to be PyQt 4.4.0 compatible
[16:21] <jam> bialix: so have I ... :)
[16:21] <bialix> I can commit and push it if you like
[16:22] <bialix> well, it should work now with both 4.4.0 and 4.4.3
[16:22] <vila> jam: err, does that mean that the setup is even worse than before ?
[16:22] <jam> bialix: so I tweaked the discovery process, etc here: lp:///~jameinel/bzr/bzr.exe-qtimages
[16:22] <jam> vila: well, I was able to connect to kerguelen *last night*
[16:22] <jam> so I'm not sure what is going on this morning
[16:23]  * bialix pulls
[16:23] <vila> jam: don't look at me, I didn't even try to connect there :-) I just said I wanted a slave there, I'm not sure that counts :-D
[16:24] <jam> hmm... so it seems nslookup on kerguelen.hosting24.com.au works, it is a problem with nslookup hosting24.com.au that fails
[16:24] <jam> and I seem to just not be able to connect to that IP address
[16:24] <jam> I might reboot the machine
[16:25] <jam> vila: can you try connecting?
[16:25] <jam> Before I restart, I want to make sure it isn't a problem on my end
[16:25] <vila> jam: gee, I can try, but I have to find the instructions back first
[16:26] <bialix> jam: +1 on your tweaks
[16:26] <jam> vila: rdesktop kerguelen.hosting24.com.au
[16:26] <jam> I believe
[16:27] <vila> ERROR: recv: Connection reset by peer
[16:27] <vila> I can ping it though
[16:28] <vila> but not the domain
[16:28] <jam> right, so it sounds the same as here
[16:28] <jam> I'll just restart it...
[16:28] <jam> hopefully everything comes back up correctly
[16:34] <CaMason> with a commit for pending merges, what's the best type of comment?
[16:35] <jam> CaMason: personally I like summary messages
[16:35] <jam> of the basic shape of what was merged
[16:35] <CaMason> sounds like a plan to me
[16:35] <CaMason> I'll do that
[16:39] <etank> if the host where my parent branch is stored changes how can i make bzr remember the new location?
[16:39] <jam> etank: "bzr command --remember" usually
[16:40] <jam> bzr push --remember
[16:40] <jam> bzr pull --remember
[16:40] <jam> etc
[16:40] <etank> thanks jam
[16:53] <vxnick> I've used both, but are there any real differences between branches and checkouts?
[16:53] <vxnick> I'm never quite sure which to use for various things
[16:57] <darkadept> I'm having trouble setting up a bzr smart server through apache with fastcgi. I'm getting JailBreak errors and I'm not sure how to go about fixing it. (bzr 1.18dev, python 2.6.2)
[17:05] <jam> bialix: submitted to pqm
[17:06] <jam> darkadept: bug #348308
[17:07] <bialix> jam: thx a lot
[17:07] <jam> vila: I can connect again, now that kerguelen has been restarted.
[17:08] <darkadept> ubottu: thanks. the last comment on that bug has a little patch... i've tried it i'm not quite sure where to put it
[17:09] <vila> jam: seems better here too (I get the login prompt)
[17:09] <jam> darkadept: the comment says to add it to the "bzr-smart" scritp
[17:09] <jam> script
[17:09] <darkadept> jam: hmm i did but it didn't seem to do anything
[17:10] <darkadept> I just appended it to the bottom of the script
[17:10] <jam> darkadept: I don't really know. But I would make sure that you restart apache, etc to make sure any cached scripts have been reloaded
[17:10] <jam> as a monkeypatch it probably just needs to be in the script
[17:10] <darkadept> jam: hmm ok i'll try
[17:13] <darkadept> hmm nope. well i guess i should wait until the bug is fixed. would installing a previous version of bzr fix it?
[17:53] <Noldorin> hello
[17:53] <Noldorin> i'm having trouble getting bzr to push to a server with no CHMOD command
[17:53] <Noldorin> firstly, is it possible?
[17:55] <Noldorin> http://pastebin.ca/1518108
[17:55] <Noldorin> that's my error log
[17:56] <SamB> Noldorin: I don't see any fundamental reason why you couldn't ...
[17:56] <Noldorin> SamB: bzr seems to be locking my repo as i push though
[17:56] <Noldorin> whenever i push
[17:56] <Noldorin> as you can see in the error message
[18:00] <Noldorin> what is bzr doing complaining about a lock it *created* while pushing?
[18:00] <Noldorin> hmm
[18:01] <SamB> I don't know -- what I mean is that it should be possible, by changing the code, to make it work
[18:02] <Noldorin> SamB: ah right fair enough
[18:02] <SamB> which surely is a better state of affairs than "can
[18:02] <SamB> 't possibly be made to work"
[18:03] <SamB> like, say, pushing to your cat or dog would be ;-)
[18:03] <Noldorin> though not quite as well as i had hoped...
[18:03] <Noldorin> heh
[18:03] <Noldorin> SamB: strange thing is that i think i succeeded earlier
[18:03] <Noldorin> on the same server
[18:03] <Noldorin> somehow
[18:05] <SamB> how much earlier ?
[18:06] <Noldorin> SamB: no longer than a week ago
[18:06] <Noldorin> 5/6 days maybe
[18:10] <SamB> same version of bzr, or a different one ?
[18:11] <Noldorin> same
[18:13] <abentley> Noldorin: I think bzr thinks it failed to create the lock, assumes that was because another lock was in place, and then tells you about the "other" lock.
[18:13] <Noldorin> abentley: that sounds like it might well be the cause
[18:13] <Noldorin> abentley: any workaround you might suggest?
[18:24] <SamB> I can't find any specs that mention "site chmod"...
[18:59] <dash> today I have encountered a criss-cross merge
[18:59] <dash> it's an exciting milestone!
[19:00] <dash> the default merge gives me 5 conflicts, lca gives me 1 conflict, weave gives me none
[19:00] <dash> should I feel OK using weave? :)
[19:05] <LarstiQ> dash: have you inspected the outcome? :)
[19:11] <dash> LarstiQ: that sounds too hard. :)
[20:06] <kfogel> Do we know who packages bzr for backports.org (Debian) ?
[20:07] <kfogel> Ah, looks like jelmer... :-)  Context: I'm trying to get savannah.gnu.org to upgrade to 1.17, so we can switch Emacs over to Bazaar on the new 2a format.  However, savannah (quite sensibly) only wants to run packaged bzr.
[20:08] <kfogel> They explain this in an old ticket: https://savannah.gnu.org/support/index.php?106612#comment2
[20:08] <jelmer> kfogel: hi
[20:08] <kfogel> LarstiQ: ^^  (see backscroll)  You and jelmer help package bzr for backports.org?
[20:08] <kfogel> hey jelmer
[20:09] <kfogel> jelmer: I'm wondering if we can get bzr 1.17 backported for Debian.
[20:09] <LarstiQ> I'm not ware of concerted backporting efforts
[20:10] <jelmer> kfogel: Yeah, we should be able to get a new version on backports.org
[20:10] <jelmer> kfogel: (fwiw I've only done the original packaging, not the backports to stable)
[20:11] <kfogel> LarstiQ, jelmer: ah, I just saw your names listed at http://packages.debian.org/lenny-backports/bzr
[20:11] <kfogel> jelmer, should I do anything more to make this happen, or are you now tugging on the marionette strings (or whatever the right metaphor is)?
[20:13]  * LarstiQ can help with packaging on Lenny
[20:13] <LarstiQ> But I don't know how backport works upload wise
[20:14] <jelmer> I'm in the keyring so should be able to upload
[20:14] <kfogel> LarstiQ: Hmmm.  How about I send an email to the group of packagers, including you and jelmer.  I imagine that between everyone, all the necessary skills / accounts / whatever are there.
[20:15] <kfogel> oh wait, maybe the two of you have everything needed between you? :-)
[20:16] <LarstiQ> apparently :)
[20:16] <LarstiQ> kfogel: would it be ok if I do that tomorrow? (wednesday is my day off)
[20:20] <phinze> bzr one liner challenge!  "total SLOC @ a given revision" ;)
[20:21] <Tak> depends on the definition of S
[20:23] <LarstiQ> phinze: bzr export -r rev | sloccount, or something like that
[20:26] <kfogel> LarstiQ: NO.  YOU MUST DO IT IMMEDIATELY, OR THIS WILL GO ON YOUR PERMANENT RECORD.  YOU HAVE BEEN WARNED.
[20:26] <kfogel> :-)
[20:27] <LarstiQ> oh. ok.
[20:27]  * kfogel is glad we've got that cleared up
[20:28] <SamB> jelmer: I has a patch for you: lp:~naesten/bzr-svn/hackz
[20:28] <SamB> (it just adds a docstring)
[20:33] <jelmer> kfogel, :-)
[20:33] <jelmer> SamB, thanks
[20:34] <kfogel> jelmer, LarstiQ: may I add a comment to https://savannah.gnu.org/support/index.php?106951 that you guys are working on this?
[20:39] <jelmer> kfogel, yeah, np
[20:41] <kfogel> jelmer: thanks.  I'll wait to hear from LarstiQ too; don't want to put him out publicly for something without explicit confirmation.
[20:41] <jelmer> SamB, It'd be useful if you could also document the parameters
[20:41] <SamB> jelmer: hmm.
[20:41] <jelmer> SamB, that seems like it's actually the bit you can't get from the implementation so you'd be most interested in
[20:42] <jelmer> SamB, The fact that a method called make_repository() creates a repository seems kindof obvious :_)
[20:42] <SamB> jelmer: well, yesterday I must have been dense
[20:42] <LarstiQ> kfogel: I don't specifcally mind, but for me your energy would be more useful to check in on me tomorrow
[20:42] <SamB> jelmer: yes, but what *kind* is less obvious
[20:42]  * LarstiQ jots it down on his todo list
[20:43] <kfogel> LarstiQ: these things are not mutually exclusive.  I will check in with you tomorrow too.  What time zone are you in?
[20:43] <LarstiQ> jelmer: I see btw you released bzr-svn 0.6.4
[20:43] <LarstiQ> kfogel: In that case, excellent! CEST / UTC+2
[20:44] <SamB> jelmer: so ... how does one document parameters that aren't named in the code?
[20:44] <kfogel> LarstiQ: *nod*  Okay, it will probably be your early or mid afternoon when I get online.
[20:45] <jelmer> SamB: :param foo:
[20:45] <LarstiQ> kfogel: cool. I have an appointment from 13.00 till 15.00, but other than that I should be online
[20:46] <SamB> jelmer: how is that going to mean something when there is no "foo" in the code?
[20:46] <kfogel> LarstiQ: cool, thx
[20:47] <SamB> jelmer: any particular reason why you use just "(self, *args, **kwargs)" here?
[20:48] <jelmer> SamB, yeah, it avoids updating the parameters here if subvertpy changes parameters
[20:49] <SamB> well, I don't think there are any documentation tools that will work with that ;-)
[20:50] <LarstiQ> SamB: you sure?
[20:50] <LarstiQ> SamB: seems to me sphinx could do a reasonable job
[20:50] <LarstiQ> with some instruction on how to document it
[20:52] <SamB> LarstiQ: sphinx works on code ?
[20:52] <LarstiQ> SamB: it was created to document Python
[20:53] <SamB> LarstiQ: it appears to have been created for the *manual*, not in-band API documentation
[20:53] <LarstiQ> SamB: with autodoc, it is a consumer of the in-band docstrings
[20:53] <LarstiQ> SamB: I use it for library documentation at work, as well as a large user guide
[20:54] <SamB> jelmer: what do you use for bzr-svn API docs?
[21:00] <jelmer> SamB, pydoctor
[21:18] <phinze> okay i wonder if there is a way out of this mess i find myself in... i've got parallel subdirs in both trunk and project branches, but i don't think they share a history
[21:19] <jelmer> SamB, usually though, I just read the source code
[21:20] <phinze> i try to merge trunk -> project and i get output like this: http://gist.github.com/161511
[21:21] <SamB> jelmer: any idea why running "pydoctor -c bzr-svn.cfg --make-html" under "~/hacking/bzr-svn/working" gives pydoctor the idea that all the modules to document are within "bzrlib.plugins.svn.working"?
[21:22] <jelmer> SamB, yeah - it's not a proper python module
[21:22] <jelmer> SamB: the source files are in . rather than in e.g. subvertpy/
[21:23] <SamB> jelmer: so why the "working"?
[21:23] <jelmer> SamB, it takes the name of the directory you specify
[21:23] <jelmer> SamB, And bzr-svn.cfg specifies .
[21:24] <jelmer> SamB, if you were documenting subvertpy you would specify the subvertpy directory and it would name it subvertpy
[21:24] <phinze> ...so while the actual diff from trunk is relatively small (add two files, modify three)... the merge wants me to remove the entire features dir and start over in my project branch
[21:24] <phinze> i guess my question is: is there any way out of this?
[21:24] <phinze> or will i have to continue doing a mv/cp dance to get merges with changes in the features subdir properly because i've broken their history
[21:31] <krisives> Is setting EDITOR=nano good enough to make commit messages edit with nano?
[21:31] <krisives> or do I have to do something elsE?
[21:33] <LarstiQ> krisives: unless you also have VISUAL set
[21:33] <krisives> echo $VISUAL doesn't appear to have anything set
[21:33] <krisives> echo $EDITOR shows nano
[21:34] <krisives> Try setting BZR_EDITOR?
[21:34] <LarstiQ> krisives: shouldn't be needed?
[21:34] <LarstiQ> krisives: have you actually tried what happens if you have EDITOR set?
[21:35] <krisives> EDITOR=nano bzr commit works
[21:35] <krisives> So I must have failed to export or something
[21:36] <krisives> So even if I can echo $EDITOR and see nano, why couldn't bzr?
[21:36] <LarstiQ> krisives: the lookup is BZR_EDITOR, editor in config, VISUAL, EDITOR, wordpad.exe, notepad.exe on windows, /usr/bin/editor, vi, pico, nano, joe
[21:37] <LarstiQ> krisives: echo doesn't imply export afaik
[21:37] <krisives> I wish I could man export :D
[21:37] <LarstiQ> krisives: man your shell
[21:37] <krisives> Kinda gotta find it in the bash man
[21:38]  * LarstiQ nods
[21:38]  * krisives giggles at the sound of that
[21:38] <LarstiQ> ftw
[21:38] <LarstiQ> ehm
[21:38]  * krisives gets in the trenches and "mans the shell"
[21:38] <LarstiQ>  / ftw
[21:38] <LarstiQ> right
[21:38] <LarstiQ> :)
[21:38] <LarstiQ> anyway
[21:38] <krisives> Thanks for the (deserved) ridicule :D
[21:38] <LarstiQ> krisives: my .zshrc sets VISUAL and EDITOR to vim as a standard measure
[21:39]  * LarstiQ blinks
[21:39] <LarstiQ> did I ridicule?
[21:39] <Noldorin> hello
[21:39] <krisives> Not really, just that I should have better manned my shell
[21:39] <krisives> You are correct
[21:39] <Noldorin> has anyone has experience getting bzr to work with an ftp server that doesn't support chmod?
[21:39] <Noldorin> krisives: heya
[21:39] <krisives> Noldorin: they don't support chmod for real eh?
[21:39] <krisives> What did they say?!
[21:40] <Noldorin> krisives: yeah, so it seems :(
[21:40] <krisives> Drop them, get new host IMO
[21:40] <krisives> Unacceptable to not allow permissions
[21:40] <Noldorin> "CHMOD is a feature that applies to Linux hosting packages only."
[21:40] <Noldorin> from their email
[21:40] <LarstiQ> ...
[21:40] <Noldorin> yeah, im tempted to
[21:40] <Noldorin> just signed up though :S
[21:41] <LarstiQ> Noldorin: what ftpd is that?
[21:41] <krisives> Only way you're going to get bzr to work on that is to use bzr export afaik
[21:41] <Noldorin> does anyone have any ideas how to get around it, for a start?
[21:41] <Noldorin> LarstiQ: "ftpd"?
[21:41] <Noldorin> hmm
[21:41] <krisives> LarstiQ: he's using a host for ASP.NET
[21:41] <LarstiQ> Noldorin: which ftp server
[21:41] <krisives> Noldorin: ftpd is what runs the FTP server
[21:41] <LarstiQ> krisives: right
[21:41] <Noldorin> ah
[21:41] <krisives> LarstiQ: I suspect it's because it's a windows host on FAT32 or something else without a permission model :(
[21:41] <Noldorin> LarstiQ: i just know it's an ftp server running on windows 2003, hosted by storm internet
[21:42] <LarstiQ> Noldorin: the d is short for 'daemon', unix terminology for detached long running processes
[21:42] <Noldorin> krisives: i can't set the standard unix permissions in the site manager :S
[21:42] <LarstiQ> krisives: sure, but the ftpd could just fake the chmod
[21:42] <krisives> LarstiQ: good point
[21:42] <Noldorin> LarstiQ: yeah, i'm a windows guy mainly - though i am vaguely familiar with daemons
[21:42]  * krisives +1 to LarstiQ
[21:43] <Noldorin> http://pastebin.ca/1518338 - my error log
[21:43]  * LarstiQ heads home
[21:43] <Noldorin> bye
[21:43] <krisives> Bye LarstiQ
[21:43] <Noldorin> LarstiQ: ping me if you have any ideas please! :)
[21:43] <krisives> Thanks for your help :)
[21:43] <LarstiQ> be back in half an hour / an hour :)
[21:44] <Noldorin> ok
[21:44] <Noldorin> hrmm
[21:44] <krisives> Noldorin: you could mount the FTP in Windows as a directory
[21:44] <Noldorin> short of hacking the source
[21:44] <Noldorin> i'm wondering what to do
[21:44] <Noldorin> krisives: interesting suggestion
[21:44] <krisives> If windows thinks it's a thing without permission support you might be able to get away with that
[21:45] <Noldorin> krisives: as far as i understand, permissions in bzr repos are non-essential
[21:45] <krisives> You could also use `bzr export` and manually upload, but that kinda defeats the purpose of bzr
[21:45] <Noldorin> yeah
[21:45] <krisives> Well, yeah, someone could patch the source to only use permissions if available
[21:46] <krisives> IMO that's a lot of work for something very rare
[21:46] <krisives> Your host should provide CHMOD really
[21:46] <Noldorin> yeah, it sucks
[21:46] <krisives> Not preaching, but this is why I use Linux for hosting and in general
[21:47] <krisives> I can get a linux host for dirt cheap that does everything I need, and they are willing to install a package for me, etc.
[21:47] <krisives> Windows hosting is slower, more expensive, and less likely to be feature rich without extra cost or much hastle, usually just short of pure dedicated
[21:48] <Noldorin> yeah
[21:48] <krisives> The source is Python, so theoritically you could patch the source
[21:48] <Noldorin> too bad i'm an exclusively .NET guy
[21:48] <Noldorin> yeah
[21:48] <krisives> If they are isolating the CHMOD into a class you could add a global switch to not do CHMODing
[21:48] <jelmer> phinze, if there's no shared history it's correct the files aren't merged
[21:49] <krisives> Let me pull down the bzr code and check it over
[21:49] <Noldorin> krisives: ok cheers
[21:49] <phinze> jelmer: so what would be the best way forward... should i merge the trunk files over to project and then re-add the extra project files?
[21:49] <emmajane> beuno, ping?
[21:50] <phinze> i'd have a hiccup in the project's history but that would get the trunk <-> project history synced
[21:50] <beuno> emmajane, hi!
[21:50] <emmajane> beuno, I'm back from the holiday weekend. I missed you on Friday.
[21:50] <emmajane> beuno, let me know if you still want to catch up?
[21:50] <jelmer> phinze, basically you should resolve the conflict using either the original files or the files that were merged in
[21:50] <krisives> Off hand anyone know how large the bzr trunk is?
[21:51] <krisives> At 3Mb already :D
[21:51] <beuno> emmajane, I do. In  an hbour?
[21:51] <krisives> (Teach me to fish if you will, where is the size of a trunk listed on LP?)
[21:51] <Noldorin> krisives: 3MB isn't too bad
[21:51] <emmajane> beuno, sounds good.
[21:51] <Noldorin> oh, already
[21:51] <phinze> jelmer: alright let me fiddle -- i just want to get it to a point where every change in features coming from trunk is not a guaranteed conflict
[21:51] <Noldorin> you've only download subdirs?
[21:51] <krisives> We're at 9Mb now
[21:52] <emmajane> beuno, I have a drupal documentation meeting in two hours. so we'll be able to stay focused when we catch up. ;)
[21:52] <jelmer> phinze, in that case, you should resolve using the original files
[21:52] <jelmer> phanatic, those files were moved away I think so you'd have to move them back
[21:52] <phinze> jelmer: sounds like a plan; i'll see what i can do
[21:53] <beuno> emmajane, does that mean yes or no?
[21:53] <emmajane> beuno, do you think we can catch up in an hour? I think we can. :)
[21:53] <emmajane> beuno, we'll have to stay focused though. ;)
[21:54] <Noldorin> krisives: i've emailed back my web host to see what they say..
[21:55] <Noldorin> krisives: in particular regarding my success with a previous repo there
[21:55] <Noldorin> not sure how i managed to do it!
[21:55] <krisives> Is there some reason you have to use that host? If they aren't willing to compromise find a different host that will and give them your business
[21:56] <Noldorin> krisives: yeah i know. it's only that they're cheap, and provided (almost) all of the features i need
[21:56] <Noldorin> if anyone can point me to a great UK host for ASP.NET web spaces, with unlimited bandwidth, and databases, i would be happy to change :)
[21:56] <Noldorin> erm, for a decent price of course
[21:56] <beuno> emmajane, I can do earlier
[21:57] <beuno> in 30
[21:57] <beuno> or 20 even!
[21:57] <emmajane> woo!
[21:57] <krisives> Anyone in here familiar with the bzr source?
[22:00] <jelmer> krisives, somewhat
[22:00] <beuno> emmajane, skype good for you?
[22:01] <krisives> jelmer: think sftp.py is the right place to add a switch for --no-chmod ?
[22:01] <emmajane> beuno, yup. I'll log in.
[22:01] <jelmer> krisives, I think I missed context - what are you trying to do exactly?
[22:02] <krisives> Noldorin has a Windows server that doesn't support CHMOD
[22:02] <krisives> Would be nice to have a --no-chmod flag
[22:03] <Noldorin> yeah
[22:03] <krisives> Says in the source it should actually only be doing it if FTP supports the CHMOD, have you tried using FTP instead of SFTP?
[22:03] <jelmer> krisives, and your windows server is running a ssh+sftp server?
[22:04] <krisives> jelmer: not my server, it's his
[22:04] <krisives> jelmer: just interested in helping with a patch
[22:04] <Noldorin> jelmer: just plain ftp
[22:04] <krisives> Noldorin: have you tried using FTP and not SFTP ?
[22:04] <jelmer> krisives: if it's plain ftp then sftp.py is unrelated
[22:04] <Noldorin> ^^
[22:05] <krisives> Okay, we'll I am also looking at ftp/__init__.py
[22:05] <jelmer> krisives, adding a flag wouldn't work though, you might be able to do a hack to look at an environment variable though
[22:06] <krisives> #453 in bzr/bzrlib/transport/ftp/__init__.py says:
[22:06] <krisives> "Only set permissions if the FTP server supports the 'SITE CHMOD' extension"
[22:07] <krisives> Also appears to catch the exception and doesn't end execution, but just warns
[22:08] <Noldorin> krisives: that's quite interesting
[22:08] <krisives> http://pastebin.com/m2ce7fef0
[22:09] <Noldorin> hmm
[22:09] <krisives> You could try nerfing _setmode by just doing return in it
[22:09] <krisives> And see if it works then
[22:10] <krisives> It's sloppy but would at least help you figure out what's happening
[22:11] <Noldorin> krisives: yeah... i ought to try that
[22:11] <Noldorin> krisives: would i want to submit this as a bug report or feature request though?
[22:11] <Noldorin> for the next version
[22:14] <mobodo> how's the "text" vs "binary" handling done in bzr?
[22:17] <LarstiQ> Noldorin: yes, I think that's fair
[22:17] <Noldorin> LarstiQ: which one though? :)
[22:18] <LarstiQ> mobodo: atm, heuristic check for nul byte in the first 1024kb iirc
[22:18] <mobodo> alright, thanks
[22:18] <Noldorin> krisives: will probably get around to it at some point tomorrow. not too familiar with python, but i'll give it a go
[22:18] <Noldorin> thanks for the help
[22:18] <LarstiQ> Noldorin: we treat them the same, http://bugs.launchpad.net/bzr :)
[22:19] <Noldorin> LarstiQ: ah of course. launchpad bugs for the win.
[22:19] <krisives> Noldorin: I think it's most likely their FTP server closing the connection after too many CHMODs
[22:19] <LarstiQ> krisives: did we figure out the ftpd yet?
[22:20] <Noldorin> LarstiQ: that was a quick journey home btw ;)
[22:20] <krisives> That's Noldorin's thing
[22:20] <krisives> Noldorin: Do you have bzrlib/plugins/transport/ftp ?
[22:20] <LarstiQ> Noldorin: bout half an hour?
[22:21] <Noldorin> krisives: i'm sure it's installed by default by the windows installer.
[22:21] <krisives> I don't use bzr on windows so I have no idea where it goes or whatever
[22:21] <Noldorin> krisives: i wouldn't even have FTP working at all anyway
[22:21] <Noldorin> yeah fair enough
[22:21] <Noldorin> though as i said, i *somehow* managed to get a bzr repo working before with that web host
[22:21] <Noldorin> though i probably clobbered it
[22:21] <krisives> Do you have SFTP access?
[22:21] <Noldorin> krisives: afraid not
[22:22] <LarstiQ> Noldorin: krisives' suggestion of mounting it and then using bzr 'locally' might work btw
[22:22] <Noldorin> krisives: if you're willing, i can give you FTP access to my server if you want to mess around.
[22:22] <Noldorin> krisives: of course, you've been a good help already. wouldn't expect/request it
[22:22] <krisives> Go ahead and PM me access and I'll try my hack
[22:22] <Noldorin> LarstiQ: yeah probably, though i'm not fond of the indirectness
[22:22] <krisives> (Just adding a return to _setmode() )
[22:22] <Noldorin> LarstiQ: i think you were quicker than 1/2 hour btw
[22:23] <krisives> It was about an hour actually on my logs
[22:24] <krisives> (01:43:19 PM) ***LarstiQ heads home
[22:24] <Noldorin> i got DCed, and i don't log, so i can't check :P
[22:24] <krisives> I guess it was about 45 mins
[22:24] <Noldorin> :O
[22:24] <Noldorin> seems i have a poor sense of time
[22:25] <LarstiQ> Noldorin: it's not a permanent fix but might help you get going
[22:25] <mobodo> yay :) I think I have my cgi pretty much working... I can now browse my bzr on the web
[22:25] <Noldorin> LarstiQ: this is true..
[22:25] <krisives> If I `make` bzr I can test it locally inside that dir?
[22:25] <Noldorin> krisives: sure
[22:25] <LarstiQ> mobodo: how did you set that up?
[22:25] <krisives> I am building bzr from source
[22:25] <Noldorin> krisives: i don't see why not
[22:25] <krisives> That's the question I'm asking
[22:25] <LarstiQ> krisives: yes
[22:26] <krisives> LarstiQ: thx
[22:26] <Noldorin> :P
[22:26] <Noldorin> lol
[22:26] <krisives> Do I need to `make` again if I modify a .py ?
[22:26] <LarstiQ> krisives: nope
[22:26] <krisives> Yippie :D
[22:26] <mobodo> LarstiQ: my branch is hosted in my web server, got a php file calling bzr on the branch to list its content
[22:26] <LarstiQ> krisives: only if you touch the C extensions
[22:26] <krisives> Noldorin: if you have the info I can test it
[22:27] <LarstiQ> mobodo: ah :)
[22:27] <Noldorin> krisives: just setting up atm
[22:27] <LarstiQ> mobodo: any reason you didn't want to use loggerhead?
[22:27] <mobodo> LarstiQ: I can't run a server, this is on a web host
[22:27] <mobodo> LarstiQ: I'm not allowed to run a daemon, let alone open ports
[22:27] <LarstiQ> mobodo: ah
[22:27] <LarstiQ> wonder if loggerhead could work in a cgi mode
[22:28] <krisives> Anyone know if the py scripts are compiled on Windows ?
[22:28] <mobodo> LarstiQ: that would probably save me a lot of time :-/
[22:29] <LarstiQ> beuno: ^^?
[22:29] <LarstiQ> krisives: yes/no
[22:29] <LarstiQ> krisives: if you use the all-in-one installer they are py2exed
[22:29] <LarstiQ> krisives: if you use the python based installer, it's just business as usual
[22:29] <krisives> LarstiQ: thx
[22:30] <mobodo> I mean, say you are hosting your stuff on a university server, you're not going to install loggerhead on the server
[22:31] <LarstiQ> mobodo: would you be able to install viewvc though?
[22:31]  * LarstiQ isn't sure what the target platform is
[22:32] <luks> I've written myself http://bzr.oxygene.sk/bzrbrowse/trunk for this exact reason
[22:32] <mobodo> LarstiQ: why do you ask? does it support bzr?
[22:32] <mobodo> luks: well, I've just been doing pretty much the same thing :)
[22:34] <mobodo> LarstiQ: thing is, with svn, you get web browsing for free
[22:35] <LarstiQ> mobodo: iff you have apache with dav_svn
[22:35] <mobodo> but you can't host a svn on a unversity server because they won't let you configure a repository and a web access
[22:35] <mobodo> right
[22:35] <mobodo> the whole point of bzr, to me, was sftp/http access without having a bzr server on the other end
[22:35] <LarstiQ> right
[22:36] <mobodo> If I can install loggerhead, I can install webdav
[22:36] <LarstiQ> so what _can_ you do then?
[22:36] <mobodo> like luks did and like I'm doing.  Use bzr locally to query a .bzr and allow you to browse
[22:37] <mobodo> http://bazaar.enseed.com/browse/ <- is the output of a php file
[22:37] <LarstiQ> so you have python
[22:37] <mobodo> I have php
[22:37] <mobodo> oh, yes, I have python
[22:37] <mobodo> most people do
[22:37] <LarstiQ> if you have bzr you have python :)
[22:37] <mobodo> most universities do
[22:37] <mobodo> and I have a local install of bzr
[22:37] <LarstiQ> mobodo: well, that is the biggest hurdle taken
[22:38] <LarstiQ> mobodo: do you have mod_wsgi?
[22:38] <mobodo> let me check
[22:40] <beuno> emmajane, http://bazaar-vcs.org/WhoUsesBzr
[22:41] <mobodo> I don't think so
[22:42] <LarstiQ> mobodo: mod_python? Or just plain cgi?
[22:42] <LarstiQ> not sure if there are wsgi servers that run from standard cgi
[22:42] <mobodo> I'm not sure - how could I find out? I listed the modules in /etc/httpd/modules, but that doesn't seem to list them all...
[22:43] <mobodo> it's probably not listing the built-in modules
[22:43] <luks> LarstiQ: from wsgiref.handlers import CGIHandler
[22:43] <luks> but loggerhead is going to be slooow over cgi
[22:44] <LarstiQ> luks: k
[22:44] <beuno> emmajane, is the bzr wiki working for you?  it isn't for me
[22:44] <LarstiQ> luks: ah well
[22:45] <emmajane> beuno, define working...?
[22:45] <emmajane> I can see pages in the wiki....
[22:45] <emmajane> beuno, and I can pull up an edit page.
[22:46] <beuno> ok, I don't see them at all  :)
[22:46]  * emmajane pulls up http://bazaar-vcs.org/BazaarUploadForWebDev her favourite page. ;)
[22:46] <beuno> :)
[22:46] <beuno> ok, it works now
[22:47] <beuno> it just needed for me to make a fool out of myself
[22:47] <emmajane> You just had to choose the right first page ;)
[22:51] <LarstiQ> kfogel: from http://packages.debian.org/lenny-backports/bzr I `dget http://backports.org/debian/pool/main/b/bzr/bzr_1.16.1-1~bpo50+1.dsc`
[22:52] <LarstiQ> kfogel: a debdiff then with 1.16 from testing shows Norbert Tretkowski did the backport
[22:52] <LarstiQ> kfogel: I'll poke him tomorrow
[22:52] <LarstiQ> (backport consists of adding a changelog entry and uploading. I can do that! :)
[22:53] <LarstiQ> yay for debdiff
[22:54] <SamB> jelmer: Okay, another patch for you in lp:~naesten/bzr-svn/hackz
[22:56] <jelmer> SamB, thanks
[22:56] <jelmer> SamB, please follow the bzr coding conventions (e.g. indent 4 spaces where it makes sense to do so rather than at the same offset of the opening parentheses at the previous line)
[22:56] <SamB> jelmer: oh, sorry
[22:56] <jelmer> SamB, There shouldn't be a reason to explicitly have those arguments when using *args, **kwargs
[22:57] <SamB> jelmer: well, you try rewriting the documentation for that case, then!
[22:58] <SamB> This code shouldn't break any more than the callers would if you change something ...
[22:59] <SamB> jelmer: and, er, should I put self on the first indented line, then?
[22:59] <jelmer> SamB, I've fixed it and pushed
[23:00] <SamB> ah, nice
[23:00] <SamB> you took out the *args and **kwargs
[23:01] <LarstiQ> jelmer: should I do a bzr-svn 0.6.4 announcement tomorrow?
[23:01] <SamB> jelmer: isn't there something in the bzr coding convention about using 80-character lines ?
[23:02] <jelmer> SamB, yes, where do my changes exceed 80 characters?
[23:02] <jelmer> LarstiQ, please do
[23:02] <SamB> jelmer: not your changes, just the existing code ;-)
[23:03] <LarstiQ> jelmer: k, I will
[23:03] <jelmer> LarstiQ, the main reason for this interim release was that there were some problems with the probing code where bzr-svn would interfere sometimes
[23:03] <jelmer> LarstiQ, even if there wasn't any svn repo involved
[23:03] <LarstiQ> jelmer: ah, I see
[23:04] <LarstiQ> jelmer: I'll read the bugs involved and try to write up a summary
[23:04] <SamB> jelmer: oh, I recently noticed that if you accidentally try to pull from the launchpad webpage for a branch instead of the branch, bzr-svn seems to choke on the resulting 405 ...
[23:05] <jelmer> SamB, which version of bzr-svn?
[23:05]  * LarstiQ heads to bed
[23:05] <SamB> well, the one I just pulled from you, for instance
[23:05] <SamB> I'm not sure if it actually is choking
[23:06] <jelmer> SamB, please file a bug
[23:06] <SamB> okay
[23:12] <poolie> hi all
[23:12] <lifeless> mdke: still here?
[23:13] <SamB> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/409074
[23:19] <jelmer> SamB, thanks
[23:20] <SamB> jelmer: nothings special about that branch, I just picked one from an open tab ...
[23:47] <kklimonda> hey, I was wondering if bzr-svn svn-import and branch commands are supposed to be so slow? I can actually see every commit copied..