[00:58] <spiv> Good morning.
[01:16] <poolie> hi there spiv
[01:16] <poolie> mkanat, hi?
[01:16] <mkanat> Hey poolie!
[01:46] <lifeless> moin
[02:35] <poolie> spiv, where is the 'tc qdisc' thing documented?
[02:35] <poolie> i can't find it in the doc directory
[02:39] <spiv> Hmm
[02:40] <spiv> I guess it's just documented on the wiki, not in the doc directory.
[02:41] <spiv> i.e. http://wiki.bazaar.canonical.com/SmartPushAnalysis1.4
[03:30] <swathanthran> i did one commit over the trunk, now i see the changes from upstream needs to be merged, now i prefer to "move" my commit to another branch and keep the trunk clean. what should i do?
[03:35] <spiv> swathanthran: how about "bzr branch -r -2 . ../clean-trunk"?
[03:37] <spiv> Or alternatively "bzr branch . ../new-branch && bzr pull --overwrite upstream-url"
[03:42] <swathanthran> ok, my free net time is over now, so will those methods lose the downloaded-but-not-merged changes? (All i did was a commit over the trunk and "bzr pull" ended saying "these branches have diverged.. use merge to reconsile them"..
[03:44] <spiv> No, they won't lose any data.
[03:44] <swathanthran> thats great:) thanks..
[03:46] <swathanthran> so now, i should do bzr merge on clean-trunk?
[03:47] <swathanthran> i did bzr branch -r -2 . ../clean-trunk
[03:48] <spiv> clean-trunk will have all but the last commit from your original branch
[03:48] <spiv> If you want to keep it as a mirror of the upstream trunk then pull rather than merge.
[03:49] <spiv> (Also, you probably want to use a shared repository for these branches to save space and time)
[05:05] <lifeless> spiv: ping; hey :- are you in the middle of a patch at the moment ?
[05:25] <spm> bzr workflow question. have pristine branch of trunk; bzr merge <proposed> ; a bug is found, updates pushed to same place merge from place as new revno. Do I bzr revert and re-merge; or simply bzr merge again and bzr will DTRT?
[05:25] <lifeless> revert and remerge
[05:25] <spm> cool; that's what I've been doing, but did wonder. ta
[05:25] <lifeless> be nice if running merge again Just Worked but I'm pretty sure it will currently Just Hit You Hard
[05:26] <spm> heh
[05:31] <spiv> lifeless: was in the middle of lunch, actually :P
[05:32] <lifeless> spiv: :) I meant a slightly larger scope than that :>
[05:34] <spiv> I am fairly deep in 522637 atm :)
[05:34] <lifeless> bug 522637
[05:34] <lifeless> awesome
[06:02] <lifeless> james_w: so, I don't have dh_make installed
[06:02] <lifeless> nevermind
[06:02] <lifeless> PEBCAK
[07:59] <vila> hi all
[08:00] <fullermd> Well, there goes the neighborhood...
[08:02] <vila> fullermd: hey ! long time no see :)
[08:03] <fullermd> I've been hiding out.  Safer that way.
[08:05] <poolie> hi there vila
[08:05] <vila> hey poolie
[08:05] <vila> poolie: I just sent the rfc/summary about config locks
[08:07] <poolie> hey, thanks
[08:09] <poolie> that's pretty good
[08:09] <poolie> i think even a little more overview could be good, next time
[08:10] <vila> ok
[08:13] <vila> poolie: hmm, just reading your doc-testing mp, I think the dependency for --parallel=fork is testtools, not subunit
[08:15] <poolie> isn't testtools always required?
[08:15] <poolie> to run selfttest
[08:16] <vila> it is
[08:16] <poolie> in other words i think you need testtools to run selftest at all
[08:16] <poolie> but if you want to run --parallel then you will also need subunit
[08:17] <vila> yes you need testtools anyway, I can't remember if subunit is a soft dependency or not
[08:17] <vila> poolie: why ?
[08:17] <lifeless> hai
[08:17] <poolie> because we use subunit streams between the subprocesses and the master
[08:18] <vila> oh yes, sorry, I didn't check for_for_tests, nevermind
[08:19] <vila> fork_for_tests
[08:28] <poolie> hi vila
[08:43] <lifeless> http://whatthecommit.com/
[08:46] <fullermd> So, we need a plugin...?   :p
[08:46] <lifeless> yes
[08:46] <lifeless> yes we do
[08:47] <fullermd> The sobering (or drunkening, really) part is that doing that would probably improve the quality of commit messages in a non-trivial percentage of cases...
[08:48] <lifeless> bah
[10:36] <GaryvdM> It's not often that you see 2 identical mp
[10:36] <GaryvdM> https://code.edge.launchpad.net/~jelmer/bzr-pipeline/missing-lplib/+merge/25843
[10:36] <GaryvdM> https://code.edge.launchpad.net/~gz/bzr-pipeline/no_launchpadlib_needed_601466/+merge/29156
[10:41] <lifeless> james_w: hai
[12:04] <Automaattimarsu> anyone here familiar with checking newest revision from bzr branch with hudson when trying to do continous integration?
[12:10] <GaryvdM> Automaattimarsu: Maybe vila may be able to help you.
[12:11] <GaryvdM> Automaattimarsu: What's wrong?
[12:51] <Automaattimarsu> GaryvdM: its just the lack of instructions pretty much everywhere connected to hudson and its plugins. No apis anywhere or anything
[12:51] <Automaattimarsu> or atleast I cant find any
[12:55] <Automaattimarsu> I'm trying to get it so, that hudson would check the bzr revision from my trunk and if there are any changes, it would run a new build and restart the server o.0
[12:59] <maxb> Automaattimarsu: I don't know much about Hudson. Perhaps you could execute `bzr revno` ?
[12:59] <maxb> Or perhaps `bzr revision-info` to detect a change even if it is a push --overwrite which doesn't change the revno
[13:09] <vila> Automaattimarsu: most of it is automatic, what is your specific need ?
[13:12] <vila> Automaattimarsu: ha, yes, running on new commits only right ? Hmm, I haven't dig that so far (I'm happy with 'Poll SCM' with '@daily' for schedule) but it should be a hudson thing not specifically a bzr one
[13:13] <vila> Automaattimarsu: the help there mentions a "push" trigger and a link https://hudson.dev.java.net/build.html
[13:14] <vila> GaryvdM: hi :)
[13:14] <GaryvdM> Hi vila
[13:34] <Automaattimarsu> vila: hudson doesnt have bzr scm by default does it?
[13:35] <Automaattimarsu> if it does, whats its syntax
[13:35] <Automaattimarsu> i havent been able to find that anywhere D:
[13:35] <vila> Automaattimarsu: haaaa, you need to install the plugin first
[13:35] <Automaattimarsu> is it the one from launchpad?
[13:36] <vila> not at all, the hudson one, search in manage husdon/plugins
[13:36] <Automaattimarsu> i do have hudon plugin for bazaar
[13:36] <vila> ha, ok
[13:36] <Automaattimarsu> hudson*
[13:37] <Automaattimarsu> but I couldnt find any documentation on how the Poll SCM works
[13:37] <vila> then in your job description you should have a Source Code Management section
[13:37] <Automaattimarsu> since the default one only handles CVS
[13:37] <vila> and there there should be a Bazaar choice available
[13:37] <Automaattimarsu> yeah i have bazaar there o_o
[13:38] <vila> Automaattimarsu: easy to miss if you looked there *before* installing the plugin ;)
[13:38] <Automaattimarsu> true
[13:39] <Automaattimarsu> i read somewhere that the default (hudson) plugin always returns false on revision change checks o.o
[13:40] <vila> Automaattimarsu: how it's implemented is a bit unclear to me, but I suspect they use a generic solution that requires keeping the source tree on the master
[13:40] <vila> generic here means working for any SCM
[13:41] <Automaattimarsu> hmm
[13:41] <Automaattimarsu> Guess I'd need to check it after some changes are made
[13:42] <vila> Automaattimarsu: But how do check what the plugin is returning ? It looks quite opaque to me...
[13:42] <vila> s/how do/how do you/
[13:42] <Automaattimarsu> vila: i just checked some of the issues on the plugin page
[13:42] <vila> ha
[13:43] <Automaattimarsu> :D i'll leave how they managed to get that information to the ones that are smarter than me
[13:43] <vila> Automaattimarsu: hehe, I hoped you were smarter than me then ;)
[13:43] <Automaattimarsu> if i was, i'd recon i would not be here asking questions lol
[13:44] <vila> being smart doesn't imply knowing everything, asking questions *is* smart :)
[13:44] <Automaattimarsu> guess so :P
[13:45] <Automaattimarsu> im a bit new to this bzr thing to begin with, let alone hudson
[13:45] <Automaattimarsu> silly technologies
[13:46] <vila> fir silly values including smart ? =)
[13:46] <vila> s/fir/for/ typo-in-joke rule striking
[14:02] <GaryvdM> vila: do you not use the bzr plugin for babune?
[14:02] <vila> GaryvdM: I do use it of course :)
[14:03] <vila> GaryvdM: but it's a hudson plugin not a bzr plugin, or did I misunderstood your misunderstanding ? :-P
[14:03] <GaryvdM> No - thats what I meant.
[14:04] <GaryvdM> vila: Something you said made me think so.
[14:35] <GaryvdM> Hi jam
[14:36] <GaryvdM> I have a windows installer which I think is a release candidate.
[14:36] <GaryvdM> Going to test it, and then upload to lp.
[14:36] <GaryvdM> :-)
[14:38] <GaryvdM> http://dl.dropbox.com/u/4494367/bzr-2.2b3-2-setup.exe
[14:44] <GaryvdM> jam: This is how I specified the release tags: http://bazaar.launchpad.net/~garyvdm/bzr-windows-installers/maybe/revision/126
[14:45] <GaryvdM> jam: Ian did most of it, just had to do the last little bit.
[15:33] <jam> GaryvdM: you should be using Ubuntu-one for your hosting :)
[15:33] <jam> anyway, glad it is working.
[15:33] <jam> I'm not super happy with the syntax, but it is reasonable
[15:34] <GaryvdM> jam: I'm not happy with the syntax either, any suggestions?
[15:34] <jam> well, #1 is you should be using "revision='tag:foo'" rather than "revision = 'tag:foo'" :)
[15:34] <GaryvdM> Ok
[15:35] <jam> I wonder if for our purposes using a property sort of thing for:
[15:35] <jam> bzrtools.copy_write(tag='release-2.2.0') and fastimport.copy_write(revno=275)
[15:35] <jam> (or revno='275')
[15:36] <jam> the idea is that 'tag' and 'revno' could directly translate themselves into "tag:XXX"
[15:36] <jam> rather than saying: revision="tag:release-2.2.0"
[15:36] <GaryvdM> Ok
[15:36] <jam> I would probably rename "revision" to "revision_spec" or "revspec"
[15:36] <jam> since it isn't a revision-id, etc
[15:37] <GaryvdM> Are you ok with me putting out a build with some dev plugins?
[15:37] <GaryvdM> svn etc...
[15:38] <jam> GaryvdM: well, I don't really like doing it, but if jelmer doesn't make a release of bzr-svn which is compatible with bzr2.2 we don't have much of a choice
[15:38] <jam> hey jelmer, you've had 4 months, what's up with that? :)
[15:39] <GaryvdM> I'm getting this error: http://pastebin.org/384461 with my 2.2b3 build, but not the bzr.dev build.
[15:40] <jam> mgz: ^^
[15:40] <jam> GaryvdM: the specific error was turned into a warning, or maybe even into just a test-suite failure
[15:40] <jam> however, I think it really does indicate that the doc strings are getting stripped
[15:40] <jam> and we need to watch out for that
[15:41] <jam> as we don't want to ship bzr and have "bzr help explorer" fail
[15:41] <GaryvdM> jam: But qlog does have help, so I think it is to do with -OO
[15:41] <jam> It is sort of a shame we can't keep the error to help us
[15:41] <jam> GaryvdM: that's my point and why I mentioned mgz :)
[15:42] <GaryvdM> jam: I saw some code that turned on -OO for bzr, but off for plugins.
[15:42] <GaryvdM> Trying to locate it...
[15:42] <jam> GaryvdM: https://code.launchpad.net/~gz/bzr/installer_plugin_script_timestamp_rounding/+merge/29157 is part of the issue
[15:42] <jam> GaryvdM: its in setup.py
[15:42] <jam> the issue is that if you get the timestamps wrong
[15:42] <jam> at install time
[15:42] <jam> then at run-time the .pyo gets rebuilt on-the-fly
[15:42] <jam> and since bzr.exe is running as -OO everything gets stripped
[15:43] <jam> also note that manually installed plugins (stuff in BZR_PLUGIN_PATH) will also end up stripped always
[15:43] <jam> which we don't really want
[15:43] <jam> though we can configure plugins to use the new '__doc__ == """' syntax
[15:43] <jam> sorry
[15:43] <jam> __doc__ = """
[15:43] <jam> syntax
[15:44] <GaryvdM> jam: configure, or change the code?
[15:45] <jam> vila: ping about https://code.launchpad.net/~vila/bzr/cleanup-docs/+merge/29211
[15:45] <jam> GaryvdM: you have to change the plugin
[15:45] <jam> so instead of
[15:45] <jam> class cmd_foo(...):
[15:45] <jam>   """My docstring
[15:45] <jam> they do
[15:46] <jam> class cmd_foo(...0:
[15:46] <GaryvdM> ok - got you...
[15:46] <jam>   __doc__ = """My docstring
[15:46] <jam> look at bzrlib/builtins.py for the example
[15:46] <jam> I'm not 100% sure what the answer is for the 2.2 release
[15:46] <jam> we may just back out the change
[15:46] <jam> we may go around and push changes to all plugins we can find
[15:47] <GaryvdM> back out -OO?
[15:48] <jam> right
[15:49] <GaryvdM> mgz: Do you have metrics on how much -OO improves the cold start?
[15:52] <vila> jam: ping
[15:52] <vila> jam: pOng
[15:52] <jam> vila: the '|--|' thing seems to be pretty pervasive in our codebase, I'm not sure how you say "I couldn't find where it is used"
[15:52] <jam> (Perhaps not in index.txt itself, but in lots of other files)
[15:53] <vila> jam: I suspect I searched the _build hierarchy which may not copy doc/developers
[15:54] <vila> jam: or I search doc/en instead of doc/
[15:55] <jam> vila: I don't really know the answer. I also don't know why '--' is important, though perhaps it was an editing artifact
[15:55] <jam> somebody edited the docs and it inserted the --
[15:55] <jam> and then somebody cleaned it up to rest so that it kept the unicode char
[15:56] <jam> http://en.wikipedia.org/wiki/Dash
[15:56] <vila> yeah, that's my point, if it makes html prettier, makes it html specific
[15:56] <vila> now that I know where to look I can try to find an alternative
[15:57] <vila> jam: yeah, looks like doc/developers is not taken into account in the shinx build
[15:57] <jam> vila: "en dash is used to compare things, em dash is used to demarcate a parenthetical thought"
[15:58] <jam> so it isn't just about html prettiness
[15:58] <jam> though I don't know if non typographical humans know the difference
[15:58] <vila> jam: then the rest spirit would be to detect it, not require an artifact
[15:58] <vila> especially a unicode one :)
[16:01] <vila> jam: and I think all readers won't mind reading -- instead of an em dash
[16:02] <vila> jam: but more to the point: it's a blocker so the easiest thing was to get rid of it
[16:03] <vila> jam: argh, rest recognizes unicode : http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html (search for em dash) but doesn't seem to provide an alternative
[16:05] <jam> vila: so you can put a literal em dash in your text (after setting the text encoding properly), but you can't supply an ascii variant?
[16:05] <jam> though I'll mentioned
[16:05] <jam> we did it just fine by pulling it out to an insert glyph-here command
[16:06] <jam> and I don't know why texinfo is being unhappy
[16:06] <jam> it doesn't support non-ascii?
[16:07] <vila> jam: I need to check again but from memory, yes, unicode was causing problems
[16:07] <jam> vila: sounds like a texinfo bug
[16:07] <jam> given that it is an international project, not supporting i18n for your preferred documentation seems limiting
[16:08] <jam> vila: anyway, -- is fine with me, though why not just do '-' is beyond my understanding
[16:08] <vila> kind of out of scope here :)
[16:08] <jam> vila: perhaps, but we can treat it as a bug on their end
[16:08] <vila> sure, once I get a working texinfo writer I'll be more demanding
[16:09] <vila> But I need to reconsider anyway since there *are* uses
[16:09] <vila> I should at least look at them
[17:11] <GaryvdM> Night all - Bed early tonight
[19:19] <janisozaur> in svn I can "svn log -r BASE:HEAD", it shows the commit logs between what I have locally and what server has. how can I achieve the same in bzr?
[19:56] <mgz> missed garyvdm... will respond anyway so he can read the log
 It's not often that you see 2 identical mp <- oh man, I checked for bugs before doing that, but didn't think to look for unmerged proposals
 I'm getting this error: http://pastebin.org/384461 with my 2.2b3 build, but not the bzr.dev build. <- this is showing you've not got the complete fix for bug 600803 in yet, there's your qbzr file is getting recompiled
[19:58] <mgz> the docstring problem and hard error is actually quite useful here to find that
[19:59] <mgz> but as jam says, it might be best to back the -OO thing out for this release still, as there are still going to be a few cases where plugins will lose their help
[20:00] <jam> mgz: well, we could ensure that all plugins being bundled into 2.2 will have the docstrings fixed
[20:00] <jam> not as easy as just rolling back your change, but better *progress* :)
[20:00] <mgz> well, that's not the problem once the installer bug is fixed
[20:00] <lifeless> mornink
[20:01] <mgz> they'll be compiled with optimize=1 and no longer recompiled at runtime
[20:01] <jam> mgz: except for the stuff people start manually installing, which may be new versions of the bundled plugins
[20:01] <jam> which would fail again
[20:01] <jam> hi lifeless
[20:01] <mgz> the only issue is BZR_PLUGINS with source, rather than installed, plugins
[20:01] <mgz> right.
[20:02] <mgz> can someone kick aaron to merge jelmer's bzr-pipeline proposal and reject mine?
[20:03] <jam> abentley: kick ^^
[20:03] <mgz> just so it doesn't get written for a third time ;)
[20:04] <abentley> jam: ow
[20:04] <jam> abentley: soft pat and cookies
[20:09] <mgz> hm, trying to assign the bug to jelmer gives me a funky pink "Constraint not satisfied" error
[20:09] <lifeless> wow
[20:09] <lifeless> screenshot + bug file please!
[20:12] <mgz> http://float.endofinternet.org/temp/launchpad_constraint_not_satisfied.png
[20:13] <lifeless> yeah
[20:13] <lifeless> thats not meant to happen. Bug filing time! bugs.launchpad.net/malone
[20:13] <mwhudson> that's like the worst error message ever
[20:13] <lifeless> it will help to know if you're on edge or production, too.
[20:13] <mwhudson> and launchpad is all too happy to give it out :(
[20:13] <lifeless> mwhudson: stop being so positive.
[20:21] <mgz> that was edge, just tried production and it worked.
[20:27] <lifeless> right - please file :)
 right - please file :) <- Timeout error ... (Error ID: OOPS-1648C1494)
[20:38] <mgz> I'll get that bug filed in the end.
[20:44] <lifeless> argh
[21:13] <xnox> when i do $ bzr merge -r 8..9 ../trunk/ to backport a fix, how can I make bzr reuse commit message?
[21:15] <mgz> That's a cherrypick, not the same revision, so you probably don't want to reuse the exact message but instead say "Cherrypick fix for..."
[21:17] <xnox> mgz, true except that the log message are long and descrptive (../trunk/ is svn with very large commits)
[21:17] <xnox> I've ended up copy pasting the output from $ bzr log =)
[23:37] <mgz> lifeless: who was it you said was interested in launchpad bug mail issues?
[23:38] <mgz> I found bug 474615 which is basically my gmail filtering problem.