[00:00] <zachera> ok
[00:00] <zachera> imported
[00:00] <zachera> whats next
[00:00] <zachera> :D
[00:00] <zachera> create /aristaeus in /var/subs/trac ?
[00:01] <LarstiQ> zachera: point trac at the svn repo you just created, yes
[00:02] <zachera> sweet
[00:02] <zachera> hang on
[00:02] <LarstiQ> zachera: either use the trac-admin tool, or set 'repository_dir' under [trac] to the correct location
[00:02] <zachera> it worked
[00:03] <LarstiQ> good
[00:03] <LarstiQ> zachera: so, solved now?
[00:03] <zachera> not quite
[00:03] <zachera> the website style isnt showing up
[00:03] <zachera> lol
[00:03] <LarstiQ> zachera: may I ask btw why you came here for help? Since this doesn't involve bzr at all.
[00:03] <zachera> because i installed bazaar in the first place
[00:04] <LarstiQ> how did you get the idea to do that? Assembla is svn only afaik?
[00:07] <zachera> It's simple.
[00:07] <zachera> I saw the words "Bazaar" and "Version Control" and installed it. :P
[00:07] <LarstiQ> Aha :P
[00:08] <zachera> IT WORKEDDDDDDD
[00:08] <zachera> hahaha
[00:08] <zachera> :D
[00:09] <LarstiQ> good
[01:33] <fynn> What's the canonic (pun not intended) way to perform a message-less commit?
[06:37]  * fullermd watches launchpad ladle out a tarball at <3k/s...
[15:07] <Odd_Bloke> jelmer: Are there any instructions on using the Debian bzr packaging team's branches available?
[15:30] <Odd_Bloke> jelmer: I just hit http://paste.pocoo.org/show/88477/.  Any thoughts?
[18:21] <bazaar> hi, is it possible to find out the revision a specific file was added?
[18:23] <Jc2k> bazaar: you should be able to do bzr log filename to see all the revisions  that touched a given file, and hence you should be able to see the one that added it...
[18:23] <Jc2k> (i think)
[18:23] <bazaar> i'll try that.
[18:23] <bazaar> worked. thanks.
[18:23] <LarstiQ> yes, and in most cases it will be the first one, so --limit 1 will work too
[18:24] <Jc2k> oh, i didnt realise it was oldest first or i would have suggested that ;)
[18:35] <LarstiQ> Jc2k: switchable with --forward
[18:41] <fynn> Hey. What's the canonical way to perform a message-less commit?
[18:41] <fynn> (A commit with no commit message.)
[18:44] <LarstiQ> fynn: that's normally guarded against
[18:44] <LarstiQ> I don't think you can get around that without resorting to using bzrlib
[18:45] <fynn> LarstiQ: yeah, I'm asking because some developers asked for this feature.
[18:45]  * LarstiQ isn't in the position to check the code right now
[18:45] <fynn> that's OK, I might do that myself. it's Python after all :)
[18:45] <fynn> it's just that some people asked for it, and I didn't find any way to do it, so I asked to make sure I didn't miss anything.
[18:45] <LarstiQ> fynn: hmkay, it seems like a very bad idea to me :) But yes, a custom plugin shouldn't be too hard.
[18:46]  * LarstiQ nods
[18:46] <LarstiQ> fynn: be aware that the commit message is a property of a revision, you can not change it afterwards.
[18:46] <LarstiQ> fynn: so if they want to punt till later, they can't.
[18:46] <fynn> it's just that some developers work on semi-private branches, and they make a lot of personal commits
[18:46]  * LarstiQ just wildly guesses as to why they'd want that.
[18:47] <LarstiQ> fynn: what happens with those personal commits later on?
[18:47] <fynn> well, they get merged.
[18:47] <fynn> but I'm thinking about that article someone gave here yesterday
[18:47] <LarstiQ> ok, so they just want to describe the entire package of work during merge time?
[18:47] <fynn> about Loom
[18:47] <fynn> yeah, exactly.
[18:48] <LarstiQ> right, I can see that.
[18:48] <fynn> should I take a look at Loom?
[18:48] <fynn> or is there a builtin way of doing that?
[18:49] <LarstiQ> fynn: do what exactly? Merging is a core bzr capability.
[18:51] <fynn> LarstiQ: hm, OK, I'll take a better looks at what _can't_ be done via vanilla merging, before I assume I need Loom :)
[18:51] <fynn> although Loom does look very interesting: http://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/annotate/head:/HOWTO
[18:53] <LarstiQ> yes, that it is :)
[18:53] <LarstiQ> but I haven't gotten further than "cool!", haven't actually used it myself yet
[19:07] <fynn> LarstiQ: is there a way to create an alias that would run a shell command?
[19:07] <fynn> like the ! aliases in git?
[19:24] <LarstiQ> fynn: bzr aliases are restricted to bzr afaik. Do you have an example of such a git alias?
[19:27] <fynn> LarstiQ: sure:
[19:27] <fynn>  git config --global alias.ci '!git commit -m "`date`"'
[19:29] <fynn> this causes `git ci` to commit the current changes with a message equal to the output of DATE(1)
[19:29] <LarstiQ> fynn: right, I see.
[19:48] <fynn> as far as I can see, the easiest way of doing that on bzr would be to write a plugin that would provide that command.
[19:58] <arj> hi, I tried upgrading remove sftp tree but it failed and now I have a backup.bzr dir
[19:58] <arj> how do I remove that and try again?
[19:59] <Flare183> When I try to push one of my infobot projects I get this error: bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Erichardson183/ubuntu-bots/flarebot/.bzr/branch-format: Unable to handle http code 502: Bad Gateway
[19:59] <Flare183> Why do I get this error?
[20:01] <Flare183> dres: Can you help me?
[20:03] <LarstiQ> fynn: yes, though extending current alias support with ! shouldn't be too hard
[20:09] <fynn> LarstiQ: yeah, probably :)
[21:40] <muntyan_> hi guys. is it easy to have multiple branches inside one repository, and have those branches synchronized between multiple repositories?
[21:40] <muntyan_> to achieve something like svn but without a real central server
[21:51] <lifeless> muntyan_: yes
[21:52] <muntyan_> lifeless: any docs about it? i was googling around, and just found that what i want is actually impossible
[21:52] <muntyan_> some stuff about shared repositories and whatnot
[22:31] <LeoNerd> Hi guys.. I have a slightly odd question. I'm looking at wrapping bzrlib in perl for some perl code.. I've found Inline::Python which basically seems to Just Work. Just with one problem.
[22:32] <LeoNerd> Given an object reference to a python object, I can call methods on it, but not access bare attributes. Some of the bzrlib stuff needs these, in places. Anyone any ideas around it?
[22:47] <lifeless> LeoNerd: teach Inline::Python about __getattr__
[22:47] <LeoNerd> Oh.. is that a method on python objects anyway though?
[22:47] <LeoNerd> Could I  $object->__getattr__("attrname")  ?
[22:47] <lifeless> LeoNerd: (there is no such thing as bare attribute access - foo.bar is getattr(foo, "bar") under the hood
[22:48] <lifeless> and getattr calls into foo.__getattr__("bar") - using getattr(foo, "bar") is the standard though
[22:48] <LeoNerd> Yes.. but that form I can do for free
[22:49] <LeoNerd> Wrapping getattr() as a plain perl function is More Work
[22:49] <lifeless> well, up to you
[22:49] <lifeless> probably just doing foo.__getattr__("bar") will work
[22:50] <spiv> Actually, getattr calls __getattribute__.
[22:50] <lifeless> ah
[22:50] <lifeless> thanks :)
[22:50] <LeoNerd> OK. But that's just a plain object method on the object, right?
[22:50] <spiv> A pure-python translation of getattr (and type.__getattribute__) is surprisingly messy! :)
[22:51] <LeoNerd> so e.g. at the perl level, I could   my $repository = $revision->__getattribute__("repository");  and it would work?
[22:51] <lifeless> LeoNerd: its on the class I think
[22:51] <spiv> LeoNerd: If you can make Inline::Python use the getattr builtin function, that would be best I think.
[22:51] <LeoNerd> spiv: That requires Much Voodoo
[22:51] <LeoNerd> Anyone who works on Inline::Python has to know a lot about both perl and python's C-level representations
[22:51] <LeoNerd> There's not many who do
[22:52] <spiv> LeoNerd: well, I mean, use its API to invoke getattr, rather than the (presumably hard) task of fixing Inline::Python.
[22:52] <lifeless> LeoNerd: another thing you could do is write a small python helper module
[22:52] <LeoNerd> lifeless: I've pondered that.
[22:52] <LeoNerd> I also pondered just adding a 'get_repository' method to Revision
[22:52] <LeoNerd> So I can call it :)
[22:53] <LeoNerd> spiv: Yes, but that means I have to export getattr. It seems Inline::Python doesn't let you just plain export that function; I'd have to write my own which calls it, that it then exports for me.
[22:53] <LeoNerd> Seems messy that way
[22:57] <spiv> LeoNerd: that seems like a large gap in Inline::Python!
[22:58] <LeoNerd> Yes. A horrendous one
[22:58] <LeoNerd> but as I said, very narrow field of people who could fix it
[22:58] <spiv> LeoNerd: A quick glance at the docs I found with google suggest you could do it with py_call_function
[22:58] <LeoNerd> It requires someone who is an expert in both perl and python; who knows a lot about the sorts of things programs in each language would do, _and_ who knows about the C-level representations internally.
[22:59] <LeoNerd> Given enough hackery, I could justabout make such objects respond to hash fetch representations... i.e.  $obj->{key}
[22:59] <LeoNerd> But knowing what to call into python to do that; no idea
[23:00] <spiv> LeoNerd: the "package" arg would need to be '__builtins__'
[23:00] <LeoNerd> spiv: Ohsure.. there's a number of hackish ways to do it.. I've got a list of four or so candidates.
[23:00] <LeoNerd> I'd like to know the best of these, or how to do a Real Solution. but as I said, a real one probably involves C-level hackery
[23:01] <spiv> LeoNerd: it doesn't seem so hard to make a perl helper called py_getattr(obj, attr_name) than invokes getattr(obj, attr_name) then?
[23:02] <LeoNerd> Not at all..
[23:02] <LeoNerd> $object->__getattribute__("foo")   seems already to do it though.
[23:02] <LeoNerd> sub getattr { some perl level hackery };   then  getattr($object, "foo")  being another
[23:03] <LeoNerd> A third would be to override specific cases; so     class bzrlib.Revision: def get_repository(self): return self.repository;
[23:03] <LeoNerd> Then I can  $revision->get_repository()
[23:03] <LeoNerd> The first two of these require much annoyance at every single callsite.
[23:03] <LeoNerd> The latter requires adjustment of every one of bzrlib's API points that I want to call.
[23:08] <poolie> this is silly, let's just talk here
[23:10] <spiv> poolie: Hi :)
[23:10] <poolie> hm it's a bit disturbing that in the month 8.10 is meant to release neither of my machines will boot reliably :/
[23:10] <lifeless> so
[23:10] <poolie> so lifeless i saw your mail, and i have the numbers
[23:10] <lifeless> I finished the conversion by hand and sent stats
[23:10] <lifeless> I haven't altered the cron job in any dimension
[23:10] <poolie> i was wondering if i should restart the cron job which seems to be blocked atm
[23:10] <lifeless> so if it was left enabled it should be continuing
[23:10] <poolie> maybe because the lock file wasn't removed?
[23:10] <lifeless> could be
[23:11] <lifeless> there should be disk space to run
[23:11] <lifeless> note that ~/run can get kinda full easily :>
[23:12] <poolie> i'll check on that too
[23:12] <poolie> so for myself today i was going to do more packaging of 1.8, and see about automating packaging of bzrtools and maybe other plugins
[23:12] <poolie> and work on the review queue
[23:12] <lifeless> anyhow, when I get back to this, I think we have solid progress - a significant drop in uncompressed data size
[23:13] <lifeless> LeoNerd: the silly poolie refers to is a voip epic failure.
[23:13] <poolie> yes
[23:14] <poolie> Inline::Python may also be silly ;-)
[23:14] <LeoNerd> It's... not bad.
[23:14] <LeoNerd> It's quite cute apart from this annoyance on attrs
[23:16] <poolie> lifeless: so today was going to be sacrificed to administration demons?
[23:17] <lifeless> yes
[23:18] <spiv> On Friday I did a couple of reviews, and also some improvements to HPSS client-side error translation (removing duplication and bizarreness in bzrlib/transport/remote.py especially).
[23:20] <poolie> cool
[23:20] <poolie> it is a bit bizarre still
[23:20] <poolie> it would be nice to have less of the return values handled per-rpc
[23:21] <poolie> what's on the menu today?
[23:22] <spiv> Right.  That's actually caused at least one bug in bzrlib/remote.py, in RemoteBzrDir.__init__.  So next on my hit list is fixing that bug by refactoring that file so that the "try: self._client.call(...) except ErrorFromSmartServer, err: self._translate_error(err, ...)" blocks are repeated everywhere.
[23:22] <spiv> Er,
[23:22] <spiv> *aren't* :)
[23:23] <spiv> (The flaw in RemoteBzrDir.__init__ is that it does a HPSS call without catching ErrorFromSmartServer)
[23:23] <poolie> woo
[23:23] <spiv> I think I should do more reviews today as well, the queue is pretty large.
[23:24] <poolie> it is
[23:24] <poolie> i should too
[23:24] <spiv> Much of that is Aaron's shelving stuff which I'm looking forward to having merged, but I'm not sure I know an awful lot about the relevant code.
[23:24] <poolie> maybe lifeless can when he's done with paperwork
[23:25] <poolie> so i think a review from an interested (relative) layman is better than no review at all
[23:25] <poolie> maybe just asking questions etc
[23:25] <spiv> Ok.
[23:26] <poolie> ok, we can sit down now
[23:26] <poolie> have a good day :)
[23:31] <spiv> poolie: thinking of administrivia
[23:31] <poolie> mm?
[23:31] <spiv> poolie: the mailing list tagging regexes still need some tweaks
[23:31] <poolie> do you have any expenses etc outstanding yourself?
[23:31] <poolie> are you referring to the utf8 thing?
[23:32] <poolie> it's probably technically possible to write a regexp for it
[23:32] <spiv> poolie: the [Success!] mails (and also my [bzr-usertest:MERGE] mails) got tagged everything else
[23:32] <poolie> ah, ok
[23:33] <spiv> The utf8 thing just plain sucks, and needs mailman support to fix; in theory mailman could decode the unicode I think and run the regex on that :)
[23:33] <poolie> mm
[23:34] <poolie> though arguably you might also want to examine the uninterpreted form
[23:34] <spiv> The [Success!] one is probably a straightforward tweak to fix.  For things like [bzr-usertest:MEGE] I guess we want to settle on a convention for "please review this code, but don't bother bundlebuggy with it"
[23:34] <poolie> spiv, i thought bb left the [merge] behind in the success mails?
[23:34] <poolie> i guess not
[23:34] <poolie> do you want to change this?
[23:34] <spiv> It does, but somehow they are still mistageed.
[23:35] <spiv> Well, I got mail from someone saying "I didn't want to receive those two patches"
[23:35] <poolie> actually what i meant was, will you fix this or should i?
[23:35] <spiv> Oh, I see.  I don't know that I have the rights to fix it?
[23:36] <spiv> I didn't realise there was a possibility that I might :)
[23:47] <spiv> poolie: ok, I can't think of an improvement to the regexes, I've replied on the list to the complaint I got.