As part of a reinstall of my work machine I tried to set up a new Windows 7 virtual machine on KVM. Unfortunately a longstanding bug from my previous installation, which I thought I’d fix by a reinstall, surface once again: while trying to shutdown the Win7 machine cleanly, it bluescreens with IRQL_NOT_LESS_OR_EQUAL.
As before Google was less than helpful but at least this time I did find a tiny note on a blog post far far away:
UPDATE (2011.5.2). The Windows 7 BSOD I was getting when performing a shutdown on Scientific Linux or Squeeze was a IRQL_NOT_LESS_OR_EQUAL. I think Iâ€™ve found what causes this. All my VMs are created with i686 as the CPU type in the libvirt xml files (since my old T2400 chip was 32 bit only). Of course now I have a 64 bit capable chip (T7200) and the new versions of qemu-kvm donâ€™t seem to like me specifying a i686 for my Windows 7 32 bit instance. If I change the xml file to use x86_64 instead of i686, I can now (finally) gracefully shut the Windows 7 32 bit VM down.;
Which indeed was exactly my problem: I installed the Windows 32-bit guest on a 64-bit host. Simply deleting the domain, then recreating it with x86_64 architecture in the virt-manager GUI, using the same storage, fixed my problem. Thanks kernelcrash! (and hopefully with yet another link to the solution, Google will be more helpful next time!)
UPDATE 2012-07-09: I took some time to update this to the latest stack on CentOS 6. The policy source code below has changed from 1.7 to 1.10, including some more allow rules mostly for locking and writing log files. I did not yet check it security wise, so reader still beware.
ORIGINAL POST: For work, I needed to set up a Puppet master (part of an effort to modernize our infrastructure). Since this was a new server, it was going to be based on CentOS 6.2. Now because of scalability issues, it is heavily recommended to run this server using Phusion Passenger aka mod_rails. And interestingly enough, passenger is not in the CentOS or EPEL repositories. Check out Bug 470696 for the gory details — I’ll reserve my rant about upstream hipster developers “needing” to copy system libraries for another day.
Fedora 14 was released so I updated my work system. Pretty smooth except for that major “I get this every time” annoyance, which is I lose my misc-fixed semicondensed X.org font which I have been using and loving forever.
Determined to not use hacks like a soupedup miscfs.ttf, or enabling all ancient PCF fonts leading to ugly webpages, I set out to find a solution involving fontconfig configuration, and this time I finally succeeded. With this fontconfig user reference and a lot of careful reading, I now have the following in
<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <dir>/usr/share/X11/fonts/misc</dir> <selectfont> <acceptfont> <glob>/usr/share/X11/fonts/misc/6x13*.pcf.gz</glob> </acceptfont> <rejectfont> <glob>/usr/share/X11/fonts/misc/*</glob> </rejectfont> </selectfont> </fontconfig>
After that run
fc-cache -fv and check with
fc-list Fixed that there is now a Fixed font to choose from. Enable it in your terminal of choice and there you go!
Just a quick followup on the last post: the last bug I encountered was already reported on launchpad. Unfortunately I overlooked it the first time so I made my own patch. Luckily in the process I learned about the differences between repr() and str() in python, so it was still useful time for me!
With these patches, I can finally create a git clone of bugzilla’s bzr repository. Go me!
So I was checking out Bugzilla the other day and noticed that with the 3.6 release they switched to bzr. Yay for DVCS usage, and while bzr is not my preference it is still loads better than the ancient CVS. However I now know and use git, and I figured it would be interesting to see whether converting between DVCSes is easy in practice. So I tried to setup a git repository that should be able to track the bzr upstream. Unfortunately that was not without it’s fair share of problems
I first found the software that converts a bzr clone into a git clone, which is appropriately named git-bzr, on github. This was a ruby project however it turned out that Matej Cepl has rewritten this to simply use shell. You can find this project on gitorious.org. Having cloned that and making the git-bzr executable available in my PATH, git magically learned the ‘git bzr’ command.
Now to convert the bugzilla repository, these commands should have sufficed:
bzr co bzr://bzr.mozilla.org/bugzilla/3.6 bugzilla36 git init bz36git cd bz36git git bzr add upstream ../bugzilla36 git bzr fetch upstream
and that would have been it. However the last step was not as trivial as proposed.
First I ran into a bug where a commit was made on the bzr side that did not involve any files. The git bzr script uses bzr fast-export under the hood, and that plugin did not know how to cope with such a commit. I think it is an artifact of the CVS conversion instead of a real commit, but evidently it is out there in the wild. So I made a rather trivial patch that I don’t know is really correct, but it got me past the first hurdle.
Then, it turned out that bzr supports the concept of multiple authors but git does not. And unfortunately the git side of things not only complains about the bzr fast-export output containing such, but also crashes as well, leading to an unusable repository. There are plans to fix it but that hasn’t happened yet in my git (1.7.1).
Next, bzr fast-export already has a switch called –plain that should prevent multiple authors from appearing in the output stream. I edited my copy of git-bzr to include that switch, reran the commands above and then found out that the switch does not work at the moment, leaving me in the rather unfortunate situation of both sides not being able to fix things so that the other understands… Luckily a patch was attached on the bzr bug that simply discards the other authors (which, I agree, is not really the right thing to do here but…), which got me going yet again.
And now I’m staring at my next error of this seemingly endless saga:
fatal: Branch name doesn't conform to GIT standards: refs/tags/bugzilla-2.23.3\nfrom :4613\n
which probably has something to do with either whitespace or not enough filtering of branch names.
But really, did I expect too much when I started out? I can’t tell. Hopefully this post is obsolete within a year though; I would love a world where everybody could use his/her favorite DCVS to develop with without much thought on interoperability.
I discovered Git while searching for a good distributed version control system. A few years back I was enamored with SVK. I’m fairly certain back when I was looking for such a system that Git already existed; however at the time it was probably way too arcane for me to grasp. It turned out that, despite my post, SVK did have a tendency to confuse itself once it got any real use. So I stopped using it despite the fact that it was a clear win to be able to do offline commits and sync back; in short I liked DVCS but this incarnation was not it.
Then at the end of 2008 I had another look at Bzr and Git (for some reason I dismissed Mercurial pretty soon, but in retrospect that was a mistake). While bzr seemed nice it was so much slower than Git. That, and the fact that the Git branch model somehow fit my brain a lot better made me invest in learning more of Git.
Ever since then I’ve been using Git for personal projects whenever I need version control. With the basics learned, it simply doesn’t get in my way. Most importantly it’s stable. Sure, I’ve succeeded in messing things up, especially when cloning a repository to multiple places (work PC, laptop, home PC) and then pulling and pushing in all directions. However every time I succeeded in cleaning my mess it was clear to me why I got in that strange state to begin with (using obscure command line switches most of the time), why I should avoid doing the things that lead to that state (in general, obscure command line switches are not useful to me), and most importantly why Git does allow that to happen (usually because in rare circumstances it IS the right thing to do).
But I freely admit that learning Git is not easy. And despite recent efforts to make the user interface a lot better, efforts which I think succeeded admirably, people switching from Subversion need time to adjust to a DVCS workflow.
Anyway, so far my history with Git. It is relevant only for the fact that the above is why I started using Git for this project; but now my Subversion-using friends will need to interface with it. So I thought: I’ve chosen an IDE, let’s see how it fares with integrating version control.
It turns out that this is not exactly complete yet. Or even better: the project that is working on Git integration in Eclipse is still in incubation fase, a.k.a. “alpha”.
It actually works pretty well for the first few typical developer steps: you can clone a remote repository, commit some stuff on the local master, and then push it back to the remote repository. You can also view history and logs. However that is pretty much it.
Local feature/topic branches? Nope. Merging? No can do. Pull? Well if it is there, I don’t know where to find it.
To make a long story short: let’s try this again in a year or so. As far as I can see from the outside, there is momentum in the general Eclipse project to move to Git, so I suspect EGit will grow these essential features probably quite soon. But for now, it’s not good enough.
So my recommendation for friends will probably therefore be TortoiseGit. Most of them are familiar with TortoiseSVN, so it will be easy enough to use. I only need to check it out myself and try out a typical Git workflow, before I can really recommend it. And maybe there are better ideas out there? I’ll check out your suggestions if you have any!
So! In a fit of madness I decided to write a new post on this nearly dead blog again.
The reason why: I needed a place to jot down my recent experiences with the combined technologies in the subject. I have been using Pylons for a year now for a spare-time project. I like it a lot, but there is also a lot still in flux with it. One of the things it has going for it is the seemingly limitless combination of Python technologies that you can combine in a project. However this also makes it so that every project has a unique combination and as such has it’s own personal problem space.
A few friends of mine are interested in hacking on this project with me. While I am usually on Linux, their default platform is Windows. This makes it much harder to share such a project since Pylons by default assumes a bit of a Unix like environment, if you will. Sure, it runs fine on Windows and it is (like most Python stuff) cross-platform by default, but things like running bin/paster to setup a project, creating a virtualenv and all that jazz simply was invented on Linux before being ported to Windows, and it shows.
One of the things people expect on Windows, for example, is a nice IDE. Since I did not want to shell out for an IDE, there are not a lot of options. I decided early on that about the only reasonable choice was the the free, cross-platform, Eclipse IDE. This choice was also influenced by the fact that the mostly excellent PyDev is now freely available (you used to need to pay cash for premium features for this plugin). The combination of Eclipse and PyDev provides for a nice Python programming environment on both platforms for people used to using an IDE.
Next up I decided to investigate a relatively simple method of installing the project. My first goal was to make it reproducable. My second goal was to make the initial setup and checkout as easy as possible on both platforms. And my third goal was to make it easy to dive in to my own code instead of dealing with relatively obscure commands.
While checkout out options to make the first goal a reality, I came across zc.buildout. Now this looked liked it would be a whole lot easier to setup on Windows than virtualenv; especially since it promised an explicit goal of reproducability of dependant modules from running a single command. I spent an evening reading the excellent documentation and I did get the reproducability I wanted. I only ran into a stupid wart where the default Pylons setup.py contains a setup_requires on Paster, necessary for the additional paster shell command to work, but which zc.buildout did not put in its eggs path, therefore the Paster egg got installed in my source directory alongside my development egg. See the bug on Launchpad for details. But really it looked like zc.buildout did satisfy my first and third goals.
However things weren’t that good on the second goal. This is also because PyDev has the difficult task of doing Python code completion from within Eclipse. In order to do this, it needs to know the path for all modules for the python interpreter that is to be used to run the project. Now, zc.buildout makes it’s own wrapper for this interpreter that sets the path correctly but apparently it does so in a way that is not compatible with PyDev. Therefore, in Eclipse, all .py files are riddled with red error underlines for undefined imports of all modules correctly installed by zc.buildout. Enter pb.recipes.pydev, which aims to beÂ a zc.buildout recipe that updates the PyDev configuration after running buildout itself. And it works, but it did not do exactly what I wanted: it added the eggs installed by buildout as external libraries, which meant that the paths to those eggs (as written to PyDev’s configuration file) contained the absolute location to my workspace. This was obviously not cross-platform; especially it conflicted with my cross-platform goal, since my configuration file contains stuff that should be in version control.
I then proceeded to create my own hacked version of that recipe and include it in my sources. Amazingly, this worked! I now had a setup on my Windows machine where running two python commands after the initial checkout got me a working Eclipse project! Adding two “Run Configurations” later, I even had it clickable from within Eclipse. Problem solved, right?
Well no, not really. You see, the path to the zc.buildout installed eggs happens to contain platform specific stuff. Once again, I now had a version control problem with the PyDev configuration file — it would be different on each platform just due to this. I discovered this after reproducing the steps so far on my Linux laptop, which then nicely showed a whole lot of differences in that file.
I could have solved this problem by removing the configuration file from versioning. However I would then have to write more instructions to configure PyDev for this project. Also, I did not like having to maintain my own recipe. And finally there was still this zc.buildout wart with Paste eggs in my source directory, which was confusing as well for first time users…
So, after having been pointed to pip by @benbangert, I decided to have a go at it once more. While reading the pip documentation I saw something about bootstrapping a virtualenv. This looked like what I wanted to do! I found the section in the virtualenv documentation about creating a bootstrap script. About half an hour later I had created a bootstrap.py that did the trick: it creates a virtualenv in the current directory, then proceeds to download and install all required libraries from a pip requirements file checked into version control. So that solved my first goal.
To integrate this virtualenv into Eclipse was easier than I expected as well. Apparently PyDev did not always have the ability to associate an interpreter with a project, but it does have that ability now. So in my PyDev project configuration (which was under version control, remember) I hardcoded an interpreter name for running the paster serve command. I also created a Run Configuration for running the bootstrap script, which is to be run using the default interpreter. These tricks allowed me to get to the same state as I had with zc.buildout; starting to develop in Eclipse is essentially now:
- git checkout project
- start Eclipse and import project
- run Bootstrap
- configure PyDev interpreter
The one problem remaining is that step 4 is a lot more involved than it needs to be, therefore I still need an eclipse-instructions.txt to note down all steps in order. But all in all I’m pretty happy with this; especially since the bootstrap script and reproducable setup still works wonders in my usual terminal + VI work environment!
So whew! I’m curious to see how other people who have not been on the journey I made in the past few days will fare using this setup; sometimes you overlook the importance of some small things or misremember a tiny crucial step. I hope I’ll see that soon.
And if you still feel like reading more after this post a.k.a. article, next up: a post about Eclipse and Git. After that, who knows when a next post appears again: no promises at all. Happy hacking!
No, I’m not dead. I just didn’t get around to writing anymore for about one week, which turned into two, which turned into one month… well you get the point. Of course I’m very much not the only blogger starting to write, then giving up. But it seems that once a few months have passed I get interested in writing again, and so here I am, back from the dead.
I don’t think I’ll do a long update post on what’s happened since last April – it would be way too much. A quick bulleted summary of the highlights as I remember them (and I might very well not remember them all!):
- worked through vacation because of our train trip through Eastern Europe in September/October. The work was less nice, but the vaction was superb. Especially Istanbul was a city to remember.
- played through / started on a few DS games on said train trip: New Super Mario Bros. (finished, excellent game!),Â Puzzle Quest: Challenge of the Warlords (fun for a while but repetitive), Hotel Dusk: Room 215 (I am so stuck on this, I need a FAQ) and Pokemon Diamond (which I liked, but not loved — as a non-pokemon fan this is a typical japanese CRPG but the continuous leveling up of new types of pokemon got to me around city #5 or so).
- finished Zelda: Twilight Princess at home. Absolutely brilliant. ’nuff said.
- started on Metroid Prime 3: Corruption and Super Mario Galaxy – both also absolutely brilliant.
- played lots of WoW, still. It’s still a very good game.
- worked very hard for the first few months on our new departmental print server, which still is not put into production However that’s largely my own doing, seeing as we first needed to upgrade to…
- worked very hard for the last two months to enable Fedora 8 installations, which are about to be put into test
- in general had a lot of fun last year as a Linux system administrator
And last but very certainly not least: Maartje and I are going to have a baby next year! We’re both very happy and excited, of course!
So that’s my state of affairs right now. Not entirely sure why I wanted to get that off my chest, but as it’s all good news, why not. Don’t stay tuned for the next update, you never know when it’s going to be…
Yesterday evening I finished Metroid Prime 2: Echoes. And what a game it is! Like the first game, it takes a while before you dig it. But once you do, you’re in for a treat. Expect devious puzzles, backtracking that does make sense (although it admittedly gets a bit cumbersome, especially in the last part of the game), but best of all, a storyline about a single bounty hunter against all the inhabitants of two totally alien worlds. Oh, those, and the pirates that she was originally after…
Truth is I can see why this game is offputting. It’s not exactly easy to control: it uses all of the buttons on the gamecube controller. It doesn’t look inviting; which makes sense considering the theme, but it doesn’t help. And even people that have played lots of games still don’t “get it” quickly because on first sight it appears to be a badly done first person shooter – which it absolutely isn’t.
So, here’s my plea to people who like action adventures; who aren’t afraid to spend some time to learn to love a game; and who have access to a Gamecube: go play this game now! Really! You deserve it.
In other news I had my hands on SSX Blur today. I’m 90% positive now that the reviews complaining about the controls are not valid for me, because after about ~5 minutes of practicing in the practice screen I could get 90% uber recognition. I can only expect this to improve. And man, does the motion control feel nice! Besides, nothing beats drawing hearts in the air with 2 hands! So, I guess that’ll be the game that I’ll buy next, after we finish Zelda: Twilight Princess.
So many games, so little time…
And here I was, planning to finish Zelda: Majora’s Mask this evening; everything seemed to work out (curse that Goth kid’s Goron rollercoaster ride though!) with some practice, and we made it to the final battle. And then this happened:
Yes, that is the final stage of the end boss. Yes, it really crashed.
And of course, this being a console game from around 2000, you don’t get to save for about 2 hours before you get to this point. Which means we’ll have another go at this tomorrow. And I get to roll around like a mad Goron again for about an hour because that Goht kid’s dungeon is really way too much…
Ah well, it’s all part of the joy of gaming I guess