[01:19] <mkanat> mwhudson: Hey hey. Have there been any more hangs of loggerhead?
[01:19] <mkanat> mwhudson: That is, since my last comment in the bug.
[01:20] <mwhudson> mkanat: not sure, let's ask spm!
[01:20] <mwhudson> spm: hello
[01:20] <mkanat> mwhudson: Okay! :-)
[01:20] <spm> mwhudson: yo!
[01:20] <spm> mkanat: hey hey!
[01:20] <mkanat> spm: Hey hey. :-)
[01:21] <spm> of course asking me when I'm back after a 4 day weekend is cruel....
[01:21] <mkanat> spm: lol
[01:21] <mwhudson> mkanat: nothing in the log since the 19th
[01:22] <mkanat> mwhudson: Well, that's an improvement.
[01:23] <mkanat> mwhudson: Perhaps we should close the extant bug with a slightly updated summary, and open a new one for these different hangs.
[01:26] <mwhudson> grar
[01:26] <mwhudson> mkanat, spm: hello again
[01:26] <spm> yo
 mwhudson: Perhaps we should close the extant bug with a slightly updated summary, and open a new one for these different hangs.
[01:27] <mwhudson> i guess that makes some sense
[01:30] <mkanat> mwhudson: Okay. I'll do it.
[01:37] <boombatower> is a setup.py and such required for bzr plugin...it seems not since I can run my plugin from home dir without one...but online docs says that you should run the setup command when installing
[01:37] <boombatower> is that just a good case since most/many have a setup
[01:37] <boombatower> or is it required
[01:42] <mwhudson> mkanat, spm: again again?
[01:43] <Peng> boombatower: You can dump it in the plugins directory however you want. It doesn't have to be setup.py.
[01:44] <spm> mwhudson: wet string problems?
[01:44] <boombatower> Peng: ok, thx
[01:52] <mwhudson> that last one was just me typing the wrong thing :(
[01:52] <mwhudson> spm: but yes
[01:54] <Peng> Wet strings?
[02:03] <spm> Peng: is how NZ is connected to the intartubes. on good days, all 5 strings are in operation. some days they dry out.
[02:04] <mwhudson> spm: my isp disconnected me two days early before our move
[02:04] <mwhudson> so i'm connected via 3g
[02:04] <spm> that was generous of them!
[02:04] <mwhudson> which is freaking slow
[02:04] <spm> heh
[02:05] <mwhudson> ~dial up speed
[02:06] <igc> hmm
[02:07] <spm> mwhudson: so... it's an improvement from what you had before?
[02:08] <mwhudson> spm: i don't think someone from .au can be _that_ smug
[02:08] <mwhudson> spm: if you were in finland or japan or something...
[02:09] <spm> mwhudson: it's taken *decades* of practice to get this smug. Rightly or wrongly is irrelevant.
[02:09] <mwhudson> spm: point conceded
[02:09] <spm> hahahahaha
[03:21]  * igc lunch
[05:01] <micahg> how do I make bzr svn only commit locally until I push?
[05:22] <james_w> micahg: you need to unbind
[05:40] <micahg> is there a way to get a bzr-svn branch so that I have the history locally?
[05:50] <james_w> micahg: did you use "bzr branch?"
[05:50] <micahg> james_w: no, I ran bzr init on an svn checkout
[05:50] <james_w> ah
[05:50] <james_w> you've just created a bzr branch with none of the history from svn then
[05:50] <micahg> james_w: how can I import?
[05:50] <micahg> I can see with bzr log
[05:51] <james_w> if you use "bzr branch svn-checkout bzr-branch" then you will have the whole history locally
[05:53] <micahg> thanks james_w
[06:09] <micahg> james_w: is there a way to have both .svn and .bzr control the folder?
[06:09] <Peng> micahg: Depends on what you mean.
[06:09] <Peng> micahg: You've done that already -- they're just completely independent.
[06:10] <micahg> well, when I branched the svn checkout, I get no svn dir
[06:12] <Peng> That is correct. You got a bzr branch.
[06:12] <Peng> You do know that bzr can operate directly on svn checkouts, right?
[06:12] <Peng> cd svn_checkout; bzr status
[06:12] <Peng> Obviously that doesn't give you local history, though.
[06:12] <micahg> I tried that, but the history isn't local
[06:12] <micahg> right...
[06:12] <luke-jr> james_w: Peng: pretty sure not
[06:13] <luke-jr> 'bzr init' in a Subversion WC just activates bzr-svn
[06:13] <spm> micahg: do you mean that bzr would have the .svn/ in it's tree and vice versa; svn would have the .bzr in it's?
[06:13] <micahg> spm: i guess so
[06:13] <Peng> luke-jr: Not what?
[06:14]  * micahg was just hoping to add local history to my svn checkout
[06:14] <spm> micahg: ew! :-)
[06:14] <luke-jr> Peng: it wouldn't create an independent Bazaar branch
[06:14] <luke-jr> micahg: bzr branch svn://.../
[06:14] <micahg> hmm, it's not going to overwrite when I push, will it?
[06:15] <Peng> luke-jr: That is correct.
[06:15]  * micahg was reading the FAQ and got scared
[06:15] <luke-jr> micahg: Subversion doesn't allow overwrite, and even if it was a Bazaar upstream, you'd need to put --overwrite
[06:16] <luke-jr> pushing will just push the commits up
[06:16] <luke-jr> but if you're going to push, you should probably configure the Subversion server to allow Bazaar to fudge the commit dates
[06:17] <micahg> does it push all the commits as one or individual ones?
[06:17] <micahg> what do you mean fudge commit dates?
[06:51] <ronny> micahg: by defaul svn enforces the commit date to equal the time it was commited to svn, but allowing bzr to edit them would allow to fit them to the time you commited them in bzr
[09:10] <poolie> hi
[09:10] <poolie> https://bugs.launchpad.net/bugs/497595
[09:14] <Peng> Nice.
[09:14] <Peng> ...I just got an OOPS opening that bug! :D
[09:15] <Peng> Oh, it's read-only now? Is it supposed to OOPS, though?
[09:16] <lifeless> Peng: no
[09:16] <lifeless> #launchpad
[09:25] <bialix> heya bzr
[09:28] <Peng> lifeless: :D
[10:40] <poolie> hi igc
[10:40] <poolie> could you fix https://bugs.edge.launchpad.net/bzr/+bug/512835
[10:40] <poolie> you could probably do it a bit faster than me
[10:40] <igc> poolie: sure
[10:54] <poolie> thanks
[10:55] <jml> poolie, you've probably noticed, but I've transfered tribunal maintainership to you. hope the delay hasn't sucked the momentum out of thing.
[10:55] <jml> s
[10:55] <poolie> not at all
[10:55] <lifeless> jml: I don't think it has, from my obsservation
[10:55] <poolie> i'm flattered
[10:55] <poolie> thanks
[10:56] <poolie> wish you were here
[10:56] <jml> good to hear.
[10:56] <jml> poolie, thanks :)
[11:22] <mkanat> The upstream Bugzilla migration to bzr is pretty close now.
[11:23] <mkanat> We have our server all set up and configured, I just have to get a Bugzilla release out of the way so that we don't have that hanging over us immediately after we switch.
[11:23] <mkanat> I wrote a script that will sync a single bzr commit back to CVS, also, for a particular branch.
[11:23] <mkanat> So we'll be using that to mirror stuff back to CVS.
[11:23] <mkanat> It's here, right now, in somewhat-incomplete form: https://bug517131.bugzilla.mozilla.org/attachment.cgi?id=423332
[11:29] <poolie> mkanat: woo
[11:29] <mkanat> :-)
[11:30] <mkanat> I also wrote a silly plugin that makes sure that the committer is identical to the currently-logged-in user, which is here if anybody ever wants it: http://bzr.mozilla.org/bzr-plugins/enforcecommitter/files
[11:30] <mkanat> (This works for us because our SSH user names are all email addresses.)
[11:31] <mkanat> The plugin breaks uncommit, though. :-(
[11:31] <mkanat> Which is probably okay for us, but I didn't know how to deal with the uncommit case well.
[11:31] <lifeless> mkanat: you could check to see if the new tip  is in the ancestry (when the username does not match)
[11:32] <mkanat> lifeless: Ohh, that's a good idea.
[11:32] <mkanat> lifeless: What's the fastest and most canonical way to do that? revid_to_revno or whatever it's called?
[11:33] <mkanat> Also, pulling the username out of the revid seemed hacky, but I didn't see any other way to get it for an uncommitted change.
[11:34] <lifeless> mkanat: branch.repository.get_revision(revid).committer/authors
[11:34] <mkanat> lifeless: Rock!
[11:35] <mkanat> lifeless: The API docs don't list the members of each class, only the methods.
[11:36] <mkanat> Ohhh, no, they do!
[11:36]  * mkanat totally missed that.
[11:42] <lifeless> maybe not consistently, but we try
[11:43] <mkanat> Yeah. repository is there in BzrBranch.
[11:43] <mkanat> "committer" and "authors" aren't there in Revision, though.
[11:46] <lifeless> ok
[11:46] <lifeless> so I won't fix that right now
[11:46] <lifeless> but if you file a bug, tagged doc, saying that the members of Revision are not in the API docs someone will likely do it
[11:46] <mkanat> lifeless: Okay. :-)
[14:15] <MTecknology> My cron task keeps giving me this - No handlers could be found for logger "bzr" - I haven't been able to figure out why yet
[14:17] <MTecknology> I'm doing bzr pull..
[14:19] <ronny> MTecknology: that usually happens if bzr fails to hook in a logfile for the logger due to permission errors
[14:19] <ronny> MTecknology: unfortunately i dont remember the file position
[14:20] <MTecknology> ronny: ~/.bzr.log?
[14:21] <ronny> MTecknology: possible
[14:21] <MTecknology> ok... sudo must not be running this in the users environment
[14:21] <MTecknology> thanks
[14:23] <Morbus> g'day. i've created a pre-commit bzr plugin hook, and placed it in the *branch server*'s system-wide plugin directory, as I want it applied to all commits.
[14:23] <Morbus> how can i tell if it's being called, when it doesn't seem like it's working? ;)
[14:23] <lifeless> jam:
[14:24] <lifeless> 01:23 < pitti> lifeless: python -c 'import apport.crashdb; help(apport.crashdb)' describes the CrashDatabase of apport
[14:24] <Morbus> my .bzr.log shows that its checking the plugin directory that i placed it in, but not that it's being called or anything.
[14:24] <lifeless> 01:23 < lifeless> pitti: thanks
[14:24] <lifeless> 01:23 < pitti> lifeless: in essence, you init it with a .db filename (sqlite), and keep calling check_duplicate()
[14:24] <lifeless> 01:23 < lifeless> pitti: does it really need a db ?
[14:24] <Morbus> i've placed it in usr/lib/python2.4/site-packages/bzrlib/plugins/example.py - should it be its own dir?
[14:24] <lifeless> Morbus: well, *commit* is not seen by servers, as they generally only see people pushing
[14:24] <lifeless> Morbus: so you probably want a Branch pre tip change hook
[14:24] <Morbus> lifeless: how does the email plugin work then?
[14:25] <Morbus> i have an the bzr-email plugin, on the branch server, sending out commit messages.
[14:25]  * Morbus looks at the source.
[14:25] <lifeless> Morbus: branch post tip change hook
[14:25] <Morbus> so, as the plugin is written now, with pre-commit, i'd have to force all my committers to put it on their machines?
[14:25] <lifeless> jam: 01:25 < pitti> lifeless: look at /usr/share/pyshared/apport/report.py, def crash_signature()
[14:26] <lifeless> Morbus: yes
[14:26] <Morbus> lifeless: http://bazaar.launchpad.net/%7Ebzr/bzr-email/trunk/annotate/head%3A/emailer.py
[14:26] <Morbus> could you tell me what line the emailer is doing this post tip change hook thing?
[14:27] <Morbus> oh, it's in http://bazaar.launchpad.net/%7Ebzr/bzr-email/trunk/annotate/head%3A/__init__.py
[14:27] <Morbus> i see it. line 94.
[14:30] <Morbus> lifeless: thanks for the help
[15:13] <mistrynitesh> after branching out kubuntu-docs from launchpad, when I give 'bzr status' it shows most of the files under 'removed' a few under 'modified' and a few under 'unknown', but this is not the case when I see them at launchpad.net using web-interface
[15:17] <lifeless> Morbus: my pleasure
[15:18] <lifeless> mistrynitesh: right affter branching it shows changes ? thats unusal
[15:18] <mistrynitesh> I am quite a noob at bzr
[15:20] <mistrynitesh> when I give 'bzr branch lp:kubuntu-docs' it asks for the password, then downloads the files and gives the message: branched 160 revisions
[15:20] <mistrynitesh> so I guess its good till then
[15:55] <mgedmin> just a second ago I said to myself, happily: "bazaar rules!  I can commit these modifications I made on the production server into the local checkout and then pull them into my main branch"
[15:56] <mgedmin> and then bazaar crashes with an internal error so I can't commit :(
[15:56] <mgedmin> it's quite an old version (1.3.1, ubuntu hardy)
[15:57] <beuno> mgedmin, it's very old, any answer will probably come with "upgrade to a newer version"
[15:57]  * mgedmin has a definition of "stable software" which means "the version in the last Ubuntu LTS and the version in debian stable both work reasonably well"
[16:02]  * fullermd includes "doesn't crash" in his definition   8-}
[16:03] <mgedmin> that's part of "works reasonably well" in my book
[16:03]  * mgedmin finds a workaround
[16:03] <maxb> LTS / stable is valuable... but sometimes using years-old versions of software just isn't the right thing to do
[16:04] <mgedmin> true
[16:04]  * maxb glares at his company's oldstable boxen
[16:04] <mgedmin> then again yak-shaving is also not always the right thing to do
[16:04] <maxb> Well... PPAs rock too :-)
[16:05] <mgedmin> when you're debugging a problem and you use a debugging tool and then modify a debugging tool and then use a version control system to remember the modifications, adding a ppa and upgrading the version control system just overflows my stack
[16:05] <mgedmin> strangely, going on irc and talking about it doesn't
[16:05] <mgedmin> I'm not complaining, mind
[16:05] <mgedmin> well, okay, I am complaining ;)
[16:06] <mgedmin> I just don't expect/want anybody to do anything about it
[16:06] <mgedmin> the problem will be solved naturally as time passes and new debian/ubuntu lts'es come out
[16:06] <fullermd> "...  so then I had to hack my new Asus motherboard to add some toggle switches, so I could toggle in a bootloader...   and THEN I finally could read the recipe I wanted in the first place."
[16:20]  * awilkins used a PPA when he backported patches to MythTV
[16:21] <awilkins> An automatic way of doing PPA versions just by slapping a button on a Bazaar branch page would be awesome
[16:21] <awilkins> Patch, push, PPA
[16:26] <froze> Hello all, new to bzr - been using svn for years, like what I see. I have a question, my apologies in advance if is redundant. Is there any way to make a bzr repo talk to an svn checkout?
[16:30] <rubbs> froze: I'm not understanding your question, what are you trying to do?
[16:30] <LenZ> froze: Welcome to bzr :)
[16:30] <rubbs> oh yeah, welcome
[16:30] <LenZ> froze: You can use bzr to talk with a remote SVN repo as if it were a SVN client, if that's what you mean.
[16:30] <bialix> talk to an svn checkout... heh
[16:31] <LenZ> froze: There is a bzr-svn plugin for that.
[16:31] <LenZ> froze: http://bazaar-vcs.org/BzrForeignBranches/Subversion
[16:54] <awilkins> froze, You can use Bazaar on an SVN checkout if you have the bzr-svn plugin, although you may find it more useful to take a Bazaar checkout of a Bazaar branch of a branch of the SVN repo ..
[16:54] <froze> sorry, got called away. I was hoping for the reverse, I have acounts on machines where svn is avail but not bzr, I have data in a bzr repo, I would like to access the bzr repo with an svn client. Tried searching, but only get accessing svn host with bzr client, not hte other way around.
[16:55] <awilkins> Ah, no, I don't believe there is such a thing - you want an SVN server for Bazaar repositories
[16:55] <awilkins> There is such a thing for MS TFS AFAIK, but not Bazaar
[16:56] <awilkins> froze, what kind of machines are these accounts on?
[16:56] <awilkins> froze, you can in principle just run Bazaar from your home folder as long as the machines meet the requirements
[16:56] <froze> pretty much what I suspected. seems to me that this feature would allow for almost fully transparent migration of svn users to the bzr world.
[16:57] <froze> HPC acounts on DOE and DOD machines that restrict what software you can use etc...
[16:57] <awilkins> froze, Ah, so things like "noexec" set on the home folder?
[16:58] <awilkins> froze, Bazaar will work from the pure Python so if you can run scripts it may be doable
[16:58] <froze> no, just regulations on use. don't want to violate the terms of use as these machines are essential to my research.
[16:58] <fullermd> With certain machine owners, you don't worry so much about 'noexec' on the partition, as following the policy to prevent 'exec' on YOU   :p
[16:59]  * awilkins goes to catch his train
[16:59] <awilkins> .quit
[16:59] <froze> fullermd: is that a "In Soviet Russia..." joke reference?
[17:00] <fullermd> Not explicitly, though it is the same pattern.
[17:04] <LenZ> froze: Well, you could probably cheat, depending on how "advanced" your svn users are :) Rename the bzr binary to "svn" and configure it to perform checkins on the remote repo directly :)
[17:08] <froze> LenZ: That would be an option on my local machines, I was looking for a way around remote site use restrictions - as I like the decentralized VCS concept.
[17:08] <LenZ> froze: I'm not aware of a plugin that would make bzr mimic a SVN server.
[17:09]  * froze wonders how hard that would be to code up...
[17:09]  * froze slaps self in face *too much work to do already* ;-)
[17:40] <fullermd> Well, you could use bzr-svn to push your bzr stuff into a svn repository, and use that as the "branch" for working from where you only have svn...
[17:40] <fullermd> And keep using bzr on real bzr stuff elsewhere; just use the svn to interface.
[17:42] <jelmer> LenZ: There is some initial work in bzr-svn to support a "bzr svn-serve" command
[17:43] <jelmer> LenZ: it's incomplete though
[17:43] <LenZ> jelmer: Awesome :)
[21:17] <lifeless> jam: welcome to the warrm
[21:27] <jam> :)
[21:36] <lifeless> jam: http://www.handdrawngames.com/DesktopTD/Game.asp earlier versions, same author; includes multiplayer
[21:41] <jam> lifeless: http://www.popcap.com/games/free/pvz/
[21:43] <lifeless> jam: yah
[23:29] <NfNitLoop> So Ubuntu (KDE?) has this bzr tray notification thing going on...   and I'm not quite grokking the reason for it.
[23:29] <NfNitLoop> I do 'bzr commit', and it tells me... that I just committed.
[23:30] <NfNitLoop> I do 'bzr pull' and it tells me that there are new revisions in my local branch.  (No, really?)  :p
[23:34] <Kamping_Kaiser> sounds like something a gui has setup (iirc olive does that)
[23:35] <RAOF> NfNitLoop: If there are other people on the network, and they've got bzr-avahi loaded you'll also get notifications of *their* commits.
[23:37] <NfNitLoop> RAOF: Aaaaah, ok. That's cool.
[23:37] <Kamping_Kaiser> that would be cool at a dedicated hackathon i can imagine it driving me insane at something like lca
[23:38] <NfNitLoop> Yeah, I'm sortof all for *reducing* the number of interrupts in my workday. :p
[23:38] <NfNitLoop> I already get e-mail and coworkers popping in and support requests and going down the garden path of some tangentially related bug... :p