Suddenly the admin page looked slightly different (round corners in opera, that kind of rubbish), yet still exactly the same.
Oh well. They have a better updates overview now though. So I also decided to update the theme. Which restored a stupid
“swear at wordpress” box that I molested in the previous version. “Oh yeah, now I remember…”. (note that this is simply the theme
that has that stupid box there).

WordPress 3.0 Pixel Theme v2.0.2 with stupid welcome box

… when trying to insert an image here I found out that the new wordpress actually destroyed the image upload dialog.
Obviously it’s only broken in the Opera version I’m using, so it’s probably them… but still… *rage*…

In other words, a good time to try out what they call Child Themes.
If done correctly this supposedly prevents further updates to the theme from reintroducing this box. Unless they do something
silly of course, like adding a new box in a different template.
Here goes!

First we create a dir for the theme, it can be named whatever you like.
Then we create a style.css file.

The style file can be very empty, basically it imports the parent theme and optionally overrides things:

Make sure to correctly name the template (case sensitive) that you base the theme on, in our case pixel.

Well, so far so good, but this doesn’t actually change anything. What we want to get rid of is a stupid box that apparently is in the
welcome.php file of the pixel theme. In fact, welcome.php pretty much is the entire thing that annoys me.
So let’s create our own welcome.php file:

Easy huh?

Now you can go to the Admin panel -> themes and then you’ll see your child theme right there.

BenV's WordPress Pixel Child Theme

However, things never work as intended, so this fails. *sigh*. Nice try WordPress.
When we look into this matter, we notice that the pixel theme doesn’t really have a welcome.php template.
What it does have is a sidebar.php template, which includes the welcome.php from its own template path.
In order words: we can’t override welcome.php (until they fix the Pixel theme), but we have to override the sidebar.php file.

Here goes:

Yay! It works!

Interesting. Suddenly I reminded myself of some Slackware updates that probably installed a new version of boost yesterday, replacing my own version.

Oh well, since it seems to be the libtorrent part that’s bugging, I might as well upgrade it:

(or you could have used slackbuild.pl, it’s easier )

After upgrading the package, deluge starts again. Wheee.

New features include “automatic database optimization support”, which you can enable by putting define('WP_ALLOW_REPAIR', true); in your wp-config.php file.
The rest you’ll run into yourself, it’s a ton of new stuff and fixes but some cool stuff like a built-in image editor and easier embedding of your favorite youtube junk.

Needless to say the automatic upgrade failed AGAIN for me:

Fortunately, my previous patch still works. Get it here if you want.

After patching that single line the automagic upgrade ended with: WordPress upgraded successfully. Jeeeej.
However, they still left the timeout at 60 seconds in the newer version

Failers. They deserve a 56k6 modem for their servers so they can find out about these issues themselves

Either patch it manually:

• Edit wp-admin/includes/file.php and change line 448 to a more reasonable default.
• The line sould become something like: $response = wp_remote_get($url, array('timeout' => 600));

Or use this patch:

When I tried adding the above patch as a download (using the download monitor plugin) I got this failure:

What the fuck guys, this is a TEXT file. Grepping through the sources I find the wp-admin/includes/file.php file to be the nazi. Apparently I’m not allowed (as site admin) to pass this current_user_can( 'unfiltered_upload' ). Security hardening, yeah… against idiots perhaps.
I’m expecting an update of either wordpress or the download monitor plugin soon.
Meanwhile I simply uploaded the file manually and added an existing download. Pfffrt, the hassle.

Anyway, I decided to upgrade my 0.9.15 installation since it still glitches every now and then.
With glitches I mean “The music played by mpd suddenly sounds as if you have quad damage in quake 3 arena and filter out most of the music frequencies”. You know, when you shoot a quad damage rocket through a hallway, that kind of sound. Restarting pulseaudio always fixes this. (I’ve been running into this glitch ever since I started using pulse). Seems to occur randomly though… sometimes when the server is busy, sometimes when switching from a .mod file to a .mp3 file, sometimes just when the lights turn on. You know the kind of glitch.
Other than I kind of enjoy pulseaudio, even though it’s a struggle to get going. It does allow our server to stream to other servers and stuff like that, which is very cute. Oh, and per application volume levels and mixing etc… also good.
This pulseaudio installation runs on our local server — in daemon/server mode — btw, on which we have connected our amplifier and speakers as to enlighten our office/game room/throne chamber.

So for compiling version 0.9.16 the first thing I ran into was libsndfile that was outdated. Version 1.0.17 was too old, so I ran slackbuild on the new libsndfile v1.0.20.tar.gz. Out came a package, upgrade, voila.
Next, I noticed the pulseaudio configure output telling me:

I kinda wondered why, since my system definately runs udev. In config.log we find:

Aha.
New challenge!
Let’s see if we can grab the official slackware udev sources and get them to run a newer package! Today the latest udev is udev version 1.4.6.
So I changed the udev.Slackbuild to pick version 1.4.6

Running udev.Slackbuild now soon brought another set of issues to my attention. The first being that the slackware patch for the rule generator breaks.
Without looking too much at the script I simply manually patched it and created a new diff. Here it is:
rule_generator.diff.gz - Version 0.1 - SHA: cf73f104543ce989fd11b383c440405110e915a2

Running the slackbuild now gave me a new error:

It never takes me long to realize that this error stems from the new kernel I installed earlier. (did I mention that linux 2.6.31 is released? ).
Google brought me this, which informs us about something that should have been in 2.6.31 if you ask me. Fine, we’ll fix it ourselves.
Another slackbuild run takes us past this error and gives us a new udev package. Inspecting the new package I noticed a /libexec directory that shouldn’t be in the root of the package. Meh, probably explains the configure: WARNING: unrecognized options: --with-libdir-name.
So we change the udev.Slackbuild again with some new configure options (stolen from their own INSTALL file):

Btw, can someone explain to me why I always manage to fuck up the file order to diff? (my patches normally come out reversed )
Here’s the complete file if you want it:
udev.Slackbuild - Version 1.4.6 - SHA: d550e146bdf34d1ad0e256936a94b7f9b7d62fd2

So after building and upgrading the package, it even restarted without glitches. Woei.
Back to pulseaudio!

Running configure now correctly informs us about udev being YES. HAL->udev compat still said “no” though. I don’t care for now, let’s see if it works.
My slackbuild.pl ran the make part and showed a ton of “leer coden, mongool” warnings (people should simply disable warnings if they don’t handle them if you ask me).
Regardless of the warnings the compilation completed and I now have a shiny new package.
After upgrading and restarting pulseaudio, there’s even sound coming out of my speakers when I hinted mpd to play. Woei.

So after the latest local root exploit thing, and testing it on some machines during har2009, I figured it might be nice to get the patch into my kernels. Running a webserver usually means you’re at risk after all, especially when it’s running wordpress

So I grabbed the latest kernel that had that patch and went for the usual make menuconfig ordeal. After half an hour of selecting “yes”, “maybe”, “I guess so”, and
some XEN options (CONFIG_PARAVIRT_GUEST=y, CONFIG_XEN=y, CONFIG_HVC_DRIVER=y, CONFIG_XEN_BLKDEV_FRONTEND=y, CONFIG_XEN_NETDEV_FRONTEND=y, CONFIG_XEN_KBDDEV_FRONTEND=y, CONFIG_HVC_XEN=y, CONFIG_XEN_BALLOON=y, CONFIG_XEN_SCRUB_PAGES=y, CONFIG_XENFS=y, CONFIG_XEN_COMPAT_XENFS=y) I built the thing.
As I usually build bzImages I also did so here. make bzImage modules modules_install.
Half an hour later I had a shiny bzImage. Let’s try it on a test domain!

I copied the bzImage to /boot, changed the kernel = "/boot/vmlinuz-xen-old" option to the new place, and GO!
This is what it told me:

Huh, where’s my console?
Checking xm list it seemed to be there… but paused… and with constantly increasing ids. Waaait a minute!
Checking the log files (xend.log in this case) revealed a secret:

Note the ‘WARNING’ line. Crashed?!
Gee, that’s … interesting. Why? Took me 5 minutes to find the other log file, but xend-debug.log had a magic line:
ERROR Invalid kernel: xc_dom_find_loader: no loader found
… great. Another why.
In case you’re wondering, the increasing status in ‘xm list’ was caused by the on_crash = 'reboot' line in the xen host config.
I quickly destroyed the doman and changed it to a oneshot try: on_crash = 'destroy'

After some searching another hint presented itself. Aren’t they nice?
This hint was: “Xen is a retarded piece of cancer and can’t decypher the bzImage format, try vmlinux instead”. Aha!
Back to the kernel, make vmlinux, copy, and another try to boot it. Obviously this was way too simple. It still crashed.
Checking my old kernel that works for both dom0 and domU with file I noticed that gz should at least work.

Some more details about the crashing domains can be found using xm dmesg
It gave me something like:

As you can see, that’s really useful…..

A useful page with some info can be found here. It confirms that a gz kernel should work (but bz probably doesn’t) since I’m still running Xen 3.2. However, I can’t find a good reason for why it won’t work.

Google to the rescue! Hard to find a useful keyword, since most xen kernel issues seem to be similar, but eventually I found this tidbit:
tiny kernel patch.
Weird that this should be needed, one would hope that basic shit like this would work after 8 kernel versions, but obviously they’re all retards when it comes to this.
Thanks Jeremy Fitzhardinge for the patch!
Just for quick reference, this is the actual patch:

So much for ‘vanilla’.

However, it boots now:

and a lot more yadieyada until it hits a new wall: root device.
Well, that sounds solvable.

In fact, here’s a solution. What you say?
“AAAAH, I GET NOTHING, IT WON’T EVEN CRASH ANYMORE, JUST NO OUTPUT???!”
Ah yeah, I forgot to mention: they changed the console device as well as the block device. So here’s a solution for both issues:
Edit your xen host config file and make it so:

(xvda1 is what used to be sda1, you can figure out the rest).

And after all this: HAHA! Success is mine!
Except of course for the undeniable fact that my domU has a fucked up fstab and all, but no issues there
Now go mess up your own system! Oh, I see… you already did. Good luck fixing it

Update

I just tested a testing kernel — 2.6.31-rc8, and it seems like they fixed it. Probably has been fixed in the testing branch for quite a while now, but still not in stable 2.6.30
Let’s hope they release 2.6.31 soon.

As for the upgrade, once again I had to manually increase their timeout to more than 60 seconds.
Just for reference:
Edit wp-admin/includes/file.php with your favorite editor and change line 448 so it has a more reasonable timeout, I put it to 300:

I felt like updating my shit today. Somehow I enjoy updates so I do it whenever I see interesting stuff.
So glancing through the slackware changelog I noticed a new Apache2 version (2.2.12 with a bunch of security updates). Meh, not my favorite piece of garbage to upgrade, but local upgrades were easy enough and also the remote (slackware 11, custom builds) ones went without hickups.

Then there was a new version of Irssi - 0.8.14. Fine, updated that too. Good to see it didn’t break my scripts

Meanwhile I checked out if the apache upgrade broke my notes, but it didn’t. While on the notes page I decided to write this little snippet,
and found out that also WordPress had a new release – 2.8.3. More security stuff.
And the codecolorer plugin that I use for the code snippets also had an update.
Updating wordpress was easy enough btw, just go to admin – tools – upgrade and hit the upgrade automatically button. I like features like that in a product.
Note that this failed at least two times because of a 60 second timeout on the download. Guess they need to invest in faster servers
“Download failed.: Operation timed out after 60 seconds with 1226456 bytes received”…. too bad they don’t give me other options when that happens.
And while I’m moaning about their ‘automagic upgrade’, how about some ajax progress indicators etc guys?
In case you also run into the timeout issue:
Don’t bother downloading the file yourself and putting it in the /your/wordpress/path/wp-content/ dir. Hitting the button over and over will
only swamp their servers even more and won’t make it any better either.
I tried increasing the php timeout on the sockets, but that didn’t seem to help. Pity guys, real shame… in fact, it angers me. *grumble*morons*grumble*
You might as well go for the manual upgrade.

At some point I got pissed enough to grep and read through the source for half an hour (AAARGH MY EYES) and distill this patch:
Edit wp-admin/includes/file.php with your favorite editor and change line 448 so it has a more reasonable timeout, I put it to 300:

Now it finally worked

While on the update tour I also updated my MPD to version 0.15.1, although I’m running the git
version of course, but that went fine (through slackbuild.pl of course).

Well, that’s enough updates for today. Time for some coding on slackbuild I think