How to merge trunk conflicts safely in bzr (bazaar.canonical.com/)

Sadly, the openstack community currently uses bzr instead of git. Instead of rebasing, this is the process by which I have to deal with tree conflicts “safely”?

bzr branch lp:trunk_project merge_temp_dir
cd merge_temp_dir && bzr merge ../your_original_branch
vi path_to_the_conflicted_files #and make your merges
bzr resolved
bzr commit -m "resolving commits."
bzr push --overwrite lp~myusername/path/to/my/branch

I hate this. And I’m storing it here so I can reference it in the future.

The universal problem-solving technique

1. Find an error message.
2. google that error message in quotes.

If 2 fails, google substrings of the error message.

Only after several failed iterations of this process should you bug your cool programmer friends. You’ll be glad you did. They’ll be glad you did.

And, if you actually needed to ask your cool programmer friends for help (or discovered the answer yourself in spite of failed searches) you should make a public blog post with the error message itself in the title and the entire problem you experienced (with solution) in the body.

In this way, you are improving the internet and making the next guy’s life easier. Also, writing about the solution will help you remember it yourself next time, so it’s a double-win.

“Package lua5.1 was not found in the pkg-config search path” on OSX

So I was trying to install Lua-GD on my macbook pro, but there was no OSX binary.

I figure, eh, I can build a package. So then I download the source and do the make dance. After a bit I get to:

Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.1' found

And that’s where I got stuck after several googles. The internets were unkind to this problem.

So I stepped away for a bit, and when I got back to the computer I decided I was probably approaching this from the wrong angle. At which point I did a search on macports and found lua-lua-gd.

Ratholes aren’t fun. Sometimes it’s best to take a step back instead of pounding a round peg into a square hole.

Github Setup Commands

(This is mainly because I keep forgetting them and I don’t want to keep making new repositories to see these steps.)

Global setup:

Download and install Git, and then…

git config --global user.name "MY NAME"
git config --global user.email MY@EMAIL.COM

Next steps:

mkdir 
cd MY-NEW-REPOSTORY
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@github.com:GITHUB-USERNAME/MY-NEW-REPOSTORY.git
git push origin master

Existing Git Repo?

cd existing_git_repo
git remote add origin git@github.com:GITHUB-USERNAME/MY-NEW-REPOSTORY.git
git push origin master

How to make wordpress autoupdate work on a debian server

In case you’re seeing a call to action to enter FTP credentials when you attempt to auto-update your wordpress, you just need to log into your server, cd into the blog’s webroot directory, and do this:

sudo chown -R www-data .

(replace www-data with whomever your apache user is if it’s not www-data.)

Yeah, that’s it.

Boot Camp Woes

Apple is retarded for not putting Bootcamp files on their website downloadable by all.

A few weeks ago I installed Boot Camp on my 13″ Macbook Pro. This was mainly to enjoy Civilization 5 while on vacation.

What ensued was 10+ hours of hell. Here are the high points:

  • You need the matching Macbook Pro OS X Install DVD to the hardware version you have. This is very frustrating because I had my girlfriend’s previous-generation 13″ Macbook Pro disc, but couldn’t find my own.
  • Apple is retarded for not putting Bootcamp files on their website downloadable by all.
  • the 13″ macbook pro didnt have a working sound jack even after running bootcamp. The sound drivers are at http://www.cirrus.com/en/products/pro/detail/P1233.html

The fun part is that my next-door neighbor had borrowed my Macbook Pro’s Install Disc a day or two before (nobody informed me). He’d done it to make a master image to avoid just this sort of hell. He was very sorry when he found out my plight. ;(

Java Debian Install

All you need to do to install java on debian is “sudo apt-get install sun-java6-jdk”.

For my internet-using administrative brethren: this is all you need to do on a modern debian box for a modern java install:

sudo apt-get install sun-java6-jdk

The internet is filled with false paths involving

sudo apt-get -u install java-package

and

fakeroot

and

make-jpkg

.

None of that is necessary anymore.

svn: DB_VERSION_MISMATCH: Database environment version mismatch

Of course, this was about 10 hours after where I expected to grab my old repo’s contents…

…or Part 2 of “Could not open the requested SVN filesystem”

Two years ago I ran into a problem with my SVN filesystem and got “Could not open the requested SVN filesystem” as the front-end error.

This appears to be an annoying catch-all error for “shit is broken with your SVN, dawg.”

Last time, it was because I had SVNPath defined in my apache’s httpd.conf file instead of SVNParentPath (when I had many repos in the same root directory.) This time I did not have that problem, but I did have the same error message.

That is annoying.

After several dead-ends, the vital kernel of information came from Mr. Mike Rooney’s suggestion to go to the host server itself and run:

sudo svn ls file:///path/to/local/repo

The two important parts here are that I’m trying to access the bjorked repo from the local filesystem, so the webdav layer isn’t being retarded at me and giving me the same enigmatic error message. The second important part here is that I’m running sudo to get past possible permission problems.

That command produced the following output:

$ sudo svn ls file:///path/to/local/repo/
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/local/repo/'
svn: Berkeley DB error for filesystem '/path/to/local/repo/db' while opening environment:

svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.6 doesn't match environment version 4.4

At this point, I used the tried and true google-the-unique-error-message technique. After googling “svn: DB_VERSION_MISMATCH: Database environment version mismatch” (including the quotation marks for an exact search), I found this blog post that solved my problem.

Here’s the punchline:

$ cd /path/to/myrepo/db
$ db4.4_checkpoint -1
$ db4.4_recover
$ db4.4_archive
$ svnlook youngest ..
$ db4.6_archive -d

BUT…

The double-punchline that screwed me for a while was the fact that the berekley db utils for 4.4 were unavailable via apt-get in modern times. Thankfully, long-time systems-administration bad-ass Ted Reed was here to suggest the following set of commands:

$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/libdb4.4_4.4.20-12_i386.deb
$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/db4.4-util_4.4.20-12_i386.deb
$ dpkg -i libdb4.4_4.4.20-12_i386.deb
$ dpkg -i db4.4-util_4.4.20-12_i386.deb

All of these commands (run as root or through sudo) grab the neccesary files from arcane places and got them installed. After that, the previous blog post’s wisdom could be applied. From there, I was a chmod, a chgrp, and a chown away from actually being able to access my old repository again.

Of course, this was about 10 hours after where I expected to grab my old repo’s contents…