[00:03] <KombuchaKip> I just pushed to my launchpad bzr repo after initializing it. I am now about to make a commit after binding to the remote repo. I am prompted with "Unknown files exist in the working tree. Commit anyway?". What does this mean?
[00:07] <spiv> poolie: that sounds likely
[00:07] <spiv> mgz: I'll poke my branch
[00:08] <maxb> KombuchaKip: It is questioning whether you forgot to 'bzr add' or 'bzr ignore' some files
[00:08] <KombuchaKip> maxb: Yeah, I see it just means there are some files in the repo that aren't under source control. Is there a way to see that besizes running bzr status, via nautilus plugin?
[00:09] <maxb> I do not know if there is nautilus integration for bzr
[00:11] <spiv> mgz: hmm
[00:11] <spiv> mgz: the web page seemed already up to date for me, but I poked my branch anyway
[00:11] <spiv> mgz: I think the "hasn't twigged" issue it because lp has started tracking which rev was approved
[00:12] <spiv> mgz: so post-review commits mean the mp is not marked merged, maybe?  Hmm, that doesn't sound right.
[00:12] <mgz> spiv: https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev <- what's the latest rev number under 'Recent revisions' for you?
[00:12] <spiv> Oh, of bzr.dev itself.
[00:12] <spiv> Yeah, I think it's fallout from the codehosting issues earlier.
[00:13] <spiv> The "please scan this branch" request from codehosting to the rest of LP got lost due to a timeout.
[00:13] <mgz> so I should wait and not worry?
[00:13] <spiv> The next time someone lands something it should sort itself out.
[00:13] <spiv> +1 for wait and not worry
[00:14] <mgz> was a bit concerned as I did a merge with pqm and thought everything was fine as I got the all-ok email... but then the website stayed as it was.
[00:14] <spiv> (I think the goal is to rescan all the branches touched during the troubled period)
[00:18] <mwhudson> poolie: yes, seems very likely
[00:43] <eric_f> having trouble getting loggerhead to start up on 10.04 installed via apt-get
[00:44] <eric_f> it seems the conf file has changed with the init.d script now running serve-branches instead of start-loggerhead
[00:44] <eric_f> any place I to find good info about setting up loggerhead?
[00:47] <maxb> here? :-)
[00:47] <maxb> start/stop-loggerhead are officially deprecated, and actually deleted in trunk
[00:48] <eric_f> okay, so is there no more /etc/loggerhead.conf file then too?
[00:50] <eric_f> …I'm migrating our old 8.04 server to 10.04 and we have lighttpd running on the old server as the proxy for which loggerhead was going through
[00:50] <eric_f> so looking to have that same setup, just now how to setup loggerhead in the newer way?
[00:53] <maxb> Hmm, IIUC there is no more loggerhead.conf in the serve-branches world
[00:54] <maxb> all config is supplied as command line options
[00:55] <maxb> hmm, or perhaps I am misunderstanding
[00:55]  * maxb attempts to figure out what the code is doign
[00:57] <eric_f> maxb: okay, looks like I got loggerhead to come up and its serving through lighty, any idea where there would be good docs for describing the options for serve-branches?
[00:57] <maxb> hmm, I am leaning towards my original assertion: the config file is completely deprecated
[00:57] <eric_f> well /etc/serve-branches.conf isnt
[00:58] <maxb> eric_f: ./serve-branches --help ?
[01:00] <poolie> hi maxb
[01:02] <eric_f> maxb: yeah, looking for something a tad more detailed I guess…
[01:08] <maxb> hi poolie
[01:08] <maxb> eric_f: Anything specific that seems unclear?
[01:10] <maxb> jam: Hi. I'm looking at loggerhead, and it looks to me like loggerhead.conf.example and loggerhead/apps/config.py are yet more stuff only used by the deceased start-loggerhead
[01:11] <eric_f> maxb: well after reading this I figured out how to hide certain branches: http://theoryl1.wordpress.com/2010/05/22/bazaar-loggerhead-on-ubuntu-10-04/
[01:11] <eric_f> but now I looking at the loggerhead pages in the browser the JS is 404ing
[01:12] <eric_f> :-/
[01:16] <maxb> ah, hm. Appears serve-branches.conf is a debian invention
[01:16] <eric_f> yeah and doesn't include all the available options :-(
[01:19] <maxb> eric_f: Well, it's just a convenience for injecting some values into the command line used in /etc/init.d/loggerhead
[01:19] <maxb> You can always tweak the init.d script directly
[01:19] <maxb> and the JS is 404ing for me too
[01:20] <eric_f> also looks like the protocol (http) is hard-coded because I am serving over https so all the links are broken :-(
[01:27] <eric_f> maxb: maybe I should be on 1.18 or something, 1.17 seems like it has a lot of issues…
[01:38] <maxb> I think that last is fixed in 1.18
[01:38] <maxb> And the YUI breakage appears to be wholly Debian's fault
[01:38] <eric_f> well I just set it to use the Yahoo CDN to fix that for now
[01:39] <eric_f> I found this patch http://launchpadlibrarian.net/23586834/relative-url.diff via https://bugs.launchpad.net/loggerhead/+bug/260547 but not sure where that branch.py file would exist on my system?
[01:45] <maxb> I wonder if you'd do better to just abandoned the packaged version and take 1.18 from upstream
[01:47] <maxb> I'll try to get 1.18 into the ~bzr PPA at some point soonish
[01:50] <eric_f> maxb: sounds good, for now I want to see if I can just patch 1.17 and wait for the PPA for 1.18. Do you know where the .py files for loggerhead go when installing from the PPA?
[01:52] <maxb> dpkg -L loggerhead
[01:53] <eric_f> thanks
[02:40] <Odd_Bloke> Is http://webapps.ubuntu.com/employment/canonical_BSE/ the job that Jelmer just got?
[03:21] <thomi_> Hi, I'm trying to work out if it is possible, using python-bzrlib to plug in a custom bzr authentication scheme? The docs seem to suggest not, but I'd like to make sure. Any ideas?
[03:34] <jam> maxb: I'm not sure about the details. but I know the loggerhead codebase has been pretty confused as to whether it was a standalone app, or a plugin
[03:35] <jam> and yes, some code paths seemed to invoke different methods of configuration, etc.
[07:03] <vila> hi all
[07:28]  * gthorslund yawns: morning vila!
[07:52] <GaryvdM> Hi all
[08:02] <mtaylor> esoteric bzr question - I'm wanting to grep contents of a merge for a token, and if it's found print out the filename it was found in
[08:02] <mtaylor> but I only want to print it out if that token was in the text that was modified
[08:03] <mtaylor> other than writing a plugin - is there a sensible way to do this?
[08:07] <spiv> mtaylor: bzr merge --preview | grepdiff ...  ?
[08:08] <mtaylor> spiv: aha! grepdiff == friend!
[09:18] <vila> jelmer: _o/
[09:18] <jelmer> vila: good morning!
[09:20] <vila> jelmer: good morning to you too !
[09:20] <peitschie_> hiya vila :)
[09:20] <peitschie_> hi jelmer
[09:20] <vila> peitschie_: hi
[09:20] <jelmer> 'evening (?) peitschie
[09:22] <peitschie_> it is indeed :)... about 8:30 atm actually
[09:22] <peitschie_> >.<... and still my fingers feel like coding
[09:28] <hulei> hello,everyone
[09:35] <peitschie_> hi hulei
[10:20] <jml> mgz: fwiw, mumak.net:8080/hudson has a builder for 2.4, 2.5, 2.6, 2.7 and 3.0
[10:20] <jml> but for some reason it's not updating
[10:57] <rjek> Morning.  I'm trying to create a bzr branch that "embeds" a branch from elsewhere, so my project can have its own local copy with my patches applied to it, and so I can easily pull from the embedded branch's upstream and merge changes (ie, so I can track it)
[10:58] <rjek> For extra excitement, this upstream is in subversion, and uses subversion externals to bring in its own embedded stuff.
[10:58] <rjek> I've tried branching it, and then using bzr join to additionally branch its externals, and then branching the result of that into my project.
[10:58] <rjek> But I get a weird error I cannot fathom.  Complete process, with version numbers, here: http://pastebin.com/GkPUbAmN
[10:59] <rjek> Am I going about this the right way, or is the extra mess caused by it being in subversion just too much?
[11:39] <mgz> jml: see you've got Python 2.4 results working -> http://mumak.net:8080/job/testtools/42/testReport/
[11:40] <mgz> I'm out now, but should have some time later to do fixes for some of the new issues I filed
[11:44] <mgz> part of the problem seems to be subunit isn't Python 3 source compat -> http://mumak.net:8080/job/testtools/42/console
[11:45] <jml> mgz: ahh yes
[11:46] <jml> mgz: that's definitely an issue that I remember but couldn't be arsed solving at the time
[11:51] <lifeless> life is short
[11:51] <lifeless> python is hard
[11:51] <lifeless> lets drink beer
[11:55] <rjek> Or explain my error message to me!  That's almost as good as beer! >:)
[12:43] <gthorslund> rjek: I've got no experience of svn with bzr, but if you're lucky it might be possible to clean of some dust from jelmer ;-)
[13:12] <jelmer> rjek: the "working tree is out of date" warning seems odd
[13:15] <rjek> jelmer: Nod.
[13:31]  * maxb ponders this Savannah request. On the one hand, I've never *yet* set up an actual non-trivial Loggerhead install. On the other, I really want to do so at $work anyway.
[13:32] <rjek> jelmer: Are you able to replicate the issue?
[13:32] <rjek> maxb: Last time I looked at Loggerhead, I ran away screaming at the complexity.
[13:33] <maxb> huh, really? It's actually surprisingly little code
[13:34] <rjek> At the complexity of setting it up.
[13:34] <rjek> Dependancy madness.
[13:34] <rjek> Although this was /ages/ ago.
[13:35] <maxb> jelmer: Ah, I had a question for you. I want to prepare a loggerhead package for 1.18, but the complexity is that the current packaging branch already contains revisions from trunk that are not on the 1.18 branch. So I need to back them out. I was planning on doing a separate commit of 'bzr merge -r 429..420' and then merging that into the packaging branch. Sound sane?
[13:37] <maxb> Also, I need to figure out the stupid situation with YUI - it's excluded from the Debian package, but a suitable Debian packaged equivalent is *NOT* provided instead. Which is just ridiculous
[14:09] <GaryvdM> maxb: there is a option in loggerhead to make it link to yui from a yahoo server. Maybe you could exclude yui from the package, and turn on that option.
[14:10]  * GaryvdM tries to find the option.
[14:12] <maxb> GaryvdM: I see the option. I reject it as a kludgy unnecessary solution
[14:13] <GaryvdM> ok
[14:13] <maxb> Plus Yahoo might take issue with every Debian installation of loggerhead deciding to use their servers
[14:13] <maxb> I think the right solution is just to let YUI 3 be embedded in the loggerhead package until someone wants to fully maintain it in Debian
[14:13] <maxb> I'm not sure whether that'll offend Debian purists though
[14:17] <jelmer> rjek: I haven't tried replicating the issue yet.
[14:17] <GaryvdM> Any one here know much about zope page templates (SimpleTLS.) I'm trying to add a xmlns prefix for svg, but it excludes it from the rendered page. Any ideas how to make it not?
[14:18] <GaryvdM> For loggerhead
[14:18] <jelmer> rjek: can you perhaps file a bug against bzr about it?
[14:18] <jelmer> maxb: Hi
[14:18] <jelmer> maxb: That sounds reasonable. Alternatively, you could just create a branch that was based off an older version of the packaging.
[14:20] <jelmer> maxb: I also think it's reasonable to just include YUI3 in the package for the moment. Including it could certainly be considered a bug if other Debian packages (which ones?) also include it, but we can fix that some other time.
[14:29] <rjek> jelmer: Which would be the most appropriate BTS for me to suffer?
[14:30] <jelmer> rjek: filing it upstream in Launchpad is probably the best idea
[14:37] <rjek> jelmer: https://bugs.launchpad.net/bzr/+bug/675561
[14:40] <maxb> jelmer: the reason for not basing on an older version of the packaging is then I'd have to push --overwrite to alioth, which feels nasty
[14:42] <jelmer> maxb: Hmm, the current branch should probably be pushed to experimental/, anyway.
[14:42] <jelmer> rjek: Actually, this might be related to the fact that the 0 revision is special in a lot of ways.
[14:53] <rjek> jelmer: Ah, I've hit a bug that you said would rarely happen back in 2008 :)
[14:55]  * rjek tries to work out with bzr init && bzr ci -m "Create empty branch" --unchanged
[15:02] <jam> morning all
[15:02] <GaryvdM> Hi jam
[16:26] <Buttons840> i'm currently on revision 7, is it possible to go back and combine revision 2 and 3 into a single revision?
[16:27] <LeoNerd> Explain why you believe you want to perform such an action
[16:34] <rjek> Why would you ever want to do such a thing?
[16:35] <exarkun> One might be using the history of a bzr branch as progressive steps in an educational tool
[16:36] <dash> exarkun: i was gonna do that
[16:36] <exarkun> dash: Me too
[16:36] <dash> but i was going to start over from the beginning and do it right
[16:36] <Buttons840> i don't know if i'll actually make the change or not; i'm just currious how it would be acheived?  is it possible?
[16:36] <dash> Buttons840: no.
[16:37] <exarkun> dash: I think I decided looms are a better fit, except actually using looms is a huge pain in the butt.
[16:37] <maxb> Buttons840: General rule: Rewriting any part of history also requires rewriting all history after that point.
[16:38] <Buttons840> right, but you could uncommit back to the revision of concern and then rebuild the remaining revisions -- probably not worth the effort, but possible still?
[16:38] <GaryvdM> Buttons840: Maybe you can do it with then replay command from the bzr-rewrite.
[16:38] <exarkun> maxb: Or finding hash collisions?
[16:38] <dash> Buttons840: that's the same as branching at that point.
[16:39] <GaryvdM> ... plugin.
[16:39] <maxb> Buttons840: Yes, entirely possible - *if* you are willing to do all that and have the history then be diverged from any other branches that may exist
[16:39] <maxb> exarkun: hash collisions? bzr revision-ids are not hash based
[16:40] <exarkun> maxb: Oh.  What are they based on?
[16:41] <maxb> Essentially timestamp + sufficient randomness to ensure that all revisions committed at the same time are still globally unique
[16:42] <maxb> The committer id is included too, serving the dual purpose of making the id more human friendly and further guaranteeing uniqueness
[16:42] <exarkun> Why can't you change the contents of a revision then?
[16:43] <maxb> Because if anyone else has a copy of the old revision, they'll keep that
[16:43] <maxb> And if the way it was changed happens to result in inconsistencies in future revisions, you have a snowballing problem of subtle data corruption
[16:44] <Buttons840> am i correct in my understanding that a revision is never deleted, even in an uncommit?   if so, how can i see all revisions
[16:44] <maxb> An uncommit does not delete a revision. It just moves the branch's pointer to tip revision of the branch
[16:45] <maxb> The uncommitted revision persists on disk, but is no longer copied elsewhere during push / branch / etc. operations
[16:45] <GaryvdM> Buttons840: You see tips that are not ancestors of any branches in a repo with bzr heads --dead
[16:46] <Buttons840> GaryvdM: how does the --dead switch differ from a regular heads call?
[16:46] <GaryvdM> Buttons840: bzr heads shows head of branches
[16:47] <GaryvdM> Buttons840: bzr heads --dead show ones that are not
[16:47] <GaryvdM> bzr heads --dead has to load every revision in the repo to find them, so it is much slower.
[17:09] <Ghost101> I need some help guys.
[17:09] <Ghost101> LoadLibrary(pythondll) failedInvalid access to memory location.
[17:09] <Ghost101> C:\Program Files\Bazaar\PYTHON26.DLL
[17:09] <Ghost101> C:\Program Files\Bazaar>bzr lp:atrinik
[17:09] <Ghost101> LoadLibrary(pythondll) failedInvalid access to memory location.
[17:09] <Ghost101> C:\Program Files\Bazaar\PYTHON26.DLL
[17:09] <Ghost101> C:\Program Files\Bazaar>
[17:10] <GaryvdM> Ghost101: What version of the installer did you use?
[17:11] <Ghost101> 2.2.1-3
[17:11] <Ghost101> the setup file name is: bzr-2.2.1-3-setup
[17:12] <Ghost101> I think the installer is the 2.2.1 standalone
[17:12] <GaryvdM> Ok
[17:13] <GaryvdM> Ghost101: I'm not sure - I would try uninstall, and reinstall.
[17:17] <Ghost101> Idk either.
[19:44] <MTecknology> Any ideas what's up with this?...  bzr: ERROR: KnitPackRepository('lp-56956304:///~canonical-isd-hackers/drupal-teams/5.x-trunk/.bzr/repository') is not compatible with    CHKInventoryRepository('lp-56956304:///~ubuntu-drupal-devs/drupal-teams/7.x-dev/.bzr/repository') different rich-root support
[19:46] <dash> MTecknology: those repos have incompatible storage formats.
[19:46] <dash> probably a result of using experimental formats for svn exports to bzr, long ago.
[19:48] <MTecknology> dash: oh.. can I push them unstacked?
[20:25] <maxb> MTecknology: There is no way to ask bzr to ignore a server side stacking policy on first push, but, IIRC, after the first failure, things are left in such a state that if you reattempt the push, the right thing will happen
[20:26] <maxb> Of course, the real question here is why does the project have a dev focus branch with different rich-root support to what you're working on?
[20:30] <MTecknology> maxb: the current focus is for Drupal 5.x; I'm reworking it for Drupal 7.x. I was able to push again
[22:29] <Buttons840> http://codepad.org/WmMMrWX0   what would explain this diff; there appears to be nothing different?
[22:29] <Buttons840> like "- hello\n+ hello"
[22:30] <spiv> Buttons840: different line endings, perhaps.
[22:36] <soren> Or if you're merging from somewhere else that had independently added an identical file?
[22:37] <spiv> soren: assuming that diff was generated by "bzr diff", no, because it says "modified file" rather than showing a whole file being deleted then a whole new file being added.
[22:37] <spiv> I think..
[22:39] <soren> spiv: Ah, yes, merging moved the conflicting file out of the way.
[22:39] <soren> Hmm..
[22:41] <soren> In that case, line endings are probably it.
[23:27] <Adam|Lunch> Whats the easiest way to get a list of Revision # and the matching commit message from the CLI?
[23:28] <bob2> bzr log?
[23:29] <Adam|Lunch> ooh nice