[00:03] 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] poolie: that sounds likely [00:07] mgz: I'll poke my branch [00:08] KombuchaKip: It is questioning whether you forgot to 'bzr add' or 'bzr ignore' some files [00:08] 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] I do not know if there is nautilus integration for bzr [00:11] mgz: hmm [00:11] mgz: the web page seemed already up to date for me, but I poked my branch anyway [00:11] mgz: I think the "hasn't twigged" issue it because lp has started tracking which rev was approved [00:12] mgz: so post-review commits mean the mp is not marked merged, maybe? Hmm, that doesn't sound right. [00:12] spiv: https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev <- what's the latest rev number under 'Recent revisions' for you? [00:12] Oh, of bzr.dev itself. [00:12] Yeah, I think it's fallout from the codehosting issues earlier. [00:13] The "please scan this branch" request from codehosting to the rest of LP got lost due to a timeout. [00:13] so I should wait and not worry? [00:13] The next time someone lands something it should sort itself out. [00:13] +1 for wait and not worry [00:14] 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] (I think the goal is to rescan all the branches touched during the troubled period) [00:18] poolie: yes, seems very likely [00:43] having trouble getting loggerhead to start up on 10.04 installed via apt-get [00:44] it seems the conf file has changed with the init.d script now running serve-branches instead of start-loggerhead [00:44] any place I to find good info about setting up loggerhead? [00:47] here? :-) [00:47] start/stop-loggerhead are officially deprecated, and actually deleted in trunk [00:48] okay, so is there no more /etc/loggerhead.conf file then too? [00:50] …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] so looking to have that same setup, just now how to setup loggerhead in the newer way? [00:53] Hmm, IIUC there is no more loggerhead.conf in the serve-branches world [00:54] all config is supplied as command line options [00:55] hmm, or perhaps I am misunderstanding [00:55] * maxb attempts to figure out what the code is doign [00:57] 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] hmm, I am leaning towards my original assertion: the config file is completely deprecated [00:57] well /etc/serve-branches.conf isnt [00:58] eric_f: ./serve-branches --help ? [01:00] hi maxb === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie! | Release Manager: vila | 2.3b3 has been released === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie! | Release Manager: vila | Hooray for jelmer [01:02] maxb: yeah, looking for something a tad more detailed I guess… [01:08] hi poolie [01:08] eric_f: Anything specific that seems unclear? [01:10] 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] 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] but now I looking at the loggerhead pages in the browser the JS is 404ing [01:12] :-/ [01:16] ah, hm. Appears serve-branches.conf is a debian invention [01:16] yeah and doesn't include all the available options :-( [01:19] eric_f: Well, it's just a convenience for injecting some values into the command line used in /etc/init.d/loggerhead [01:19] You can always tweak the init.d script directly [01:19] and the JS is 404ing for me too [01:20] also looks like the protocol (http) is hard-coded because I am serving over https so all the links are broken :-( [01:27] maxb: maybe I should be on 1.18 or something, 1.17 seems like it has a lot of issues… [01:38] I think that last is fixed in 1.18 [01:38] And the YUI breakage appears to be wholly Debian's fault [01:38] well I just set it to use the Yahoo CDN to fix that for now [01:39] 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:39] Launchpad bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option (affected: 0, heat: 0)" [Medium,Fix released] [01:45] I wonder if you'd do better to just abandoned the packaged version and take 1.18 from upstream [01:47] I'll try to get 1.18 into the ~bzr PPA at some point soonish [01:50] 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] dpkg -L loggerhead [01:53] thanks [02:40] Is http://webapps.ubuntu.com/employment/canonical_BSE/ the job that Jelmer just got? [03:21] 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] 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] and yes, some code paths seemed to invoke different methods of configuration, etc. [07:03] hi all [07:28] * gthorslund yawns: morning vila! [07:52] Hi all [08:02] 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] but I only want to print it out if that token was in the text that was modified [08:03] other than writing a plugin - is there a sensible way to do this? [08:07] mtaylor: bzr merge --preview | grepdiff ... ? [08:08] spiv: aha! grepdiff == friend! === beaumonta is now known as abeaumont_ === jelmer is now known as Guest97522 === Guest97522 is now known as jelmer [09:18] jelmer: _o/ [09:18] vila: good morning! [09:20] jelmer: good morning to you too ! [09:20] hiya vila :) [09:20] hi jelmer [09:20] peitschie_: hi [09:20] 'evening (?) peitschie [09:22] it is indeed :)... about 8:30 atm actually [09:22] >.<... and still my fingers feel like coding [09:28] hello,everyone [09:35] hi hulei [10:20] mgz: fwiw, mumak.net:8080/hudson has a builder for 2.4, 2.5, 2.6, 2.7 and 3.0 [10:20] but for some reason it's not updating [10:57] 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] For extra excitement, this upstream is in subversion, and uses subversion externals to bring in its own embedded stuff. [10:58] 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] But I get a weird error I cannot fathom. Complete process, with version numbers, here: http://pastebin.com/GkPUbAmN [10:59] Am I going about this the right way, or is the extra mess caused by it being in subversion just too much? [11:39] jml: see you've got Python 2.4 results working -> http://mumak.net:8080/job/testtools/42/testReport/ [11:40] I'm out now, but should have some time later to do fixes for some of the new issues I filed [11:44] part of the problem seems to be subunit isn't Python 3 source compat -> http://mumak.net:8080/job/testtools/42/console [11:45] mgz: ahh yes [11:46] mgz: that's definitely an issue that I remember but couldn't be arsed solving at the time [11:51] life is short [11:51] python is hard [11:51] lets drink beer [11:55] Or explain my error message to me! That's almost as good as beer! >:) [12:43] 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] rjek: the "working tree is out of date" warning seems odd [13:15] 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] jelmer: Are you able to replicate the issue? [13:32] maxb: Last time I looked at Loggerhead, I ran away screaming at the complexity. [13:33] huh, really? It's actually surprisingly little code [13:34] At the complexity of setting it up. [13:34] Dependancy madness. [13:34] Although this was /ages/ ago. [13:35] 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] 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] 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] GaryvdM: I see the option. I reject it as a kludgy unnecessary solution [14:13] ok [14:13] Plus Yahoo might take issue with every Debian installation of loggerhead deciding to use their servers [14:13] 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] I'm not sure whether that'll offend Debian purists though [14:17] rjek: I haven't tried replicating the issue yet. [14:17] 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] For loggerhead [14:18] rjek: can you perhaps file a bug against bzr about it? [14:18] maxb: Hi [14:18] maxb: That sounds reasonable. Alternatively, you could just create a branch that was based off an older version of the packaging. [14:20] 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] jelmer: Which would be the most appropriate BTS for me to suffer? [14:30] rjek: filing it upstream in Launchpad is probably the best idea [14:37] jelmer: https://bugs.launchpad.net/bzr/+bug/675561 [14:37] Launchpad bug 675561 in Bazaar "Bizarre behaviour when joining branches sourced from Subversion (affected: 1, heat: 6)" [Undecided,New] [14:40] 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] maxb: Hmm, the current branch should probably be pushed to experimental/, anyway. [14:42] rjek: Actually, this might be related to the fact that the 0 revision is special in a lot of ways. [14:53] 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] morning all [15:02] Hi jam [16:26] i'm currently on revision 7, is it possible to go back and combine revision 2 and 3 into a single revision? [16:27] Explain why you believe you want to perform such an action [16:34] Why would you ever want to do such a thing? [16:35] One might be using the history of a bzr branch as progressive steps in an educational tool [16:36] exarkun: i was gonna do that [16:36] dash: Me too [16:36] but i was going to start over from the beginning and do it right [16:36] 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] Buttons840: no. [16:37] dash: I think I decided looms are a better fit, except actually using looms is a huge pain in the butt. [16:37] Buttons840: General rule: Rewriting any part of history also requires rewriting all history after that point. [16:38] 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] Buttons840: Maybe you can do it with then replay command from the bzr-rewrite. [16:38] maxb: Or finding hash collisions? [16:38] Buttons840: that's the same as branching at that point. [16:39] ... plugin. [16:39] 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] exarkun: hash collisions? bzr revision-ids are not hash based [16:40] maxb: Oh. What are they based on? [16:41] Essentially timestamp + sufficient randomness to ensure that all revisions committed at the same time are still globally unique [16:42] The committer id is included too, serving the dual purpose of making the id more human friendly and further guaranteeing uniqueness [16:42] Why can't you change the contents of a revision then? [16:43] Because if anyone else has a copy of the old revision, they'll keep that [16:43] 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] 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] An uncommit does not delete a revision. It just moves the branch's pointer to tip revision of the branch [16:45] The uncommitted revision persists on disk, but is no longer copied elsewhere during push / branch / etc. operations [16:45] Buttons840: You see tips that are not ancestors of any branches in a repo with bzr heads --dead [16:46] GaryvdM: how does the --dead switch differ from a regular heads call? [16:46] Buttons840: bzr heads shows head of branches [16:47] Buttons840: bzr heads --dead show ones that are not [16:47] bzr heads --dead has to load every revision in the repo to find them, so it is much slower. [17:09] I need some help guys. [17:09] LoadLibrary(pythondll) failedInvalid access to memory location. [17:09] C:\Program Files\Bazaar\PYTHON26.DLL [17:09] C:\Program Files\Bazaar>bzr lp:atrinik [17:09] LoadLibrary(pythondll) failedInvalid access to memory location. [17:09] C:\Program Files\Bazaar\PYTHON26.DLL [17:09] C:\Program Files\Bazaar> [17:10] Ghost101: What version of the installer did you use? [17:11] 2.2.1-3 [17:11] the setup file name is: bzr-2.2.1-3-setup [17:12] I think the installer is the 2.2.1 standalone [17:12] Ok [17:13] Ghost101: I'm not sure - I would try uninstall, and reinstall. === deryck is now known as deryck[lunch] [17:17] Idk either. === deryck[lunch] is now known as deryck [19:44] 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] MTecknology: those repos have incompatible storage formats. [19:46] probably a result of using experimental formats for svn exports to bzr, long ago. [19:48] dash: oh.. can I push them unstacked? [20:25] 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] 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] 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] http://codepad.org/WmMMrWX0 what would explain this diff; there appears to be nothing different? [22:29] like "- hello\n+ hello" [22:30] Buttons840: different line endings, perhaps. [22:36] Or if you're merging from somewhere else that had independently added an identical file? [22:37] 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] I think.. [22:39] spiv: Ah, yes, merging moved the conflicting file out of the way. [22:39] Hmm.. [22:41] In that case, line endings are probably it. === r0bby is now known as robbyoconnor [23:27] Whats the easiest way to get a list of Revision # and the matching commit message from the CLI? [23:28] bzr log? [23:29] ooh nice