My current, most used set up, includes a laptop and a second screen attached to it. The laptop is always to the left of the second monitor and together they give one big screen with a total resolution of 3046×1050. From time to time, X11 gets confused and shows the same image, with the same resolution, on both monitors.

The tool which can help fix this is xrandr.

First, query X11 to find out what monitors there are:

$ xrandr -q

Once the monitor IDs are known, this fixes things for me:

$ xrandr --output VGA1 --auto --right-of LVDS1

Where LVDS1 is the laptop’s screen and VGA1 is the second screen.

Happy hackin’!

Decided today to upgrade my laptop to Fedora 16, which was released a few days ago. I first switched to Fedora (with XFCE as the desktop environment) from Ubuntu in August, I think. An excellent decision as it is working really great for me. XFCE is also great, really happy that I made this switch.

Anyway, the upgrade from Fedora 15 to 16 went smoothly (although a bit slow, thanks to my shitty internet connection), using the PreUpgrade script/process. I was a bit sceptical about doing an upgrade and not a cleanstall, but gave it a shot after all (note: every time I tried a dist-upgrade with Ubuntu it failed miserably). PreUpgrade was downloading stuff for a bunch of hours and (about) an hour of installing them, the upgrade was… Done. Fedora 16 just booted up and I was using my laptop just as before.

I did the post upgrade steps from the above linked article, but the yum distro-sync step failed; it was complaining something about a “Transaction Check Error” for a libdvdcss package. I simply disabled the rpm.livna.org software source, re-run the distro-sync, it did it’s thing and then re-enabled the source.

The second thing that “wasn’t working” is that Apache and MySQL were not starting on bootup, so I ran chkconfig for both of ‘em:

$ chkconfig --levels 235 mysqld on
$ chkconfig --levels 235 httpd on

Lastly, grub was upgraded to grub2. It was working fine, just that it was showing the grub menu on startup, which is a bit silly given that I’m running only one OS on this machine. Anyway, added the following lines to /etc/default/grub:

GRUB_DISABLE_RECOVERY=true
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=0 # I actually edited this line, from 5 to 0

and ran:

$ grub2-mkconfig -o /boot/grub2/grub.cfg

I also thought for a while that there was an issue with my wifi, that it’s dropping connection randomly, but it only happened once, so I don’t know what to do with it.

Happy hackin’!

I’m currently working on some Symfony2 bundles and I have one Netbeans project for the main Symfony2 app and one project for the bundle. The bundle files are completely separated from the app and they are just linked (ln -s) together. It works great, except for the case when I need to debug some part of the bundle’s code with Netbeans + xdebug. The debugger starts for the “main” project, which is the Symfony2 app, but setting breakpoints with Netbeans (y’know, by clicking the line number) for the bundle doesn’t really work, as those are in the other project and not in the debugged one, rendering the whole debugging useless.

The solution is pretty easy actually: instead of setting breakpoints with Netbeans, use xdebug_break() where you want the break to happen and it will happily be caught by the IDE. After the break happened use the “Step into” (F7) functionality to see what’s going on.

I’ve started to play around with Jenkins yesterday and I kinda don’t like that it’s default home directory is /var/lib/jenkins so I changed it to /home/jenkins, so I’m throwing the steps needed out here for future reference.

First, stop jenkins:

robert@odin:~$ sudo /etc/init.d/jenkins stop

Create the new home directory and move existing stuff from the old home to the new one:

robert@odin:~$ sudo usermod -m -d /home/jenkins jenkins

Now, I didn’t manage to set the ENV JENKINS_HOME to the new home, it was always using the old one, so I edited the init.d script:

robert@odin:~$ sudo vi /etc/init.d/jenkins

and in the “DAEMON_ARGS=…” line change JENKINS_HOME env to --env=JENKINS_HOME=/home/jenkins. In the end the whole line reads something like:

DAEMON_ARGS="--name=$NAME --inherit --env=JENKINS_HOME=/home/jenkins --output=$JENKINS_LOG --pidfile=$PIDFILE"

Update on September 20th: Vranac blogged about how to change the JENKINS_HOME properly

Start jenkins

robert@odin:~$ sudo /etc/init.d/jenkins start

and go to http://server:port/configure and verify that jenkins works as before and is using the new home.

Happy hackin’!

I’ve spent this weekend hacking on some unit tests for Zend\Dojo and I ran into an issue where I need Xdebug to, well, debug. Note, that this is not for debugging a Zend Framework application, but for debugging Zend Framework itself. I am using Netbeans + Xdebug to debug regular code, but debugging unit tests was something completely new for me. Turns out, it’s not entirely different from “regular” debugging.

Greatest help to figure out this was Raphael Dohms’ blog post “Debugging PHPUnit tests in Netbeans with Xdebug”. Almost worked out fine, but Netbeans complained about a missing index file and the autoload of files was… not really working. After a bit of poking around, the solution was to go to File -> Project Properties -> Run Configuration and set the “Index File” to /path/to/zend_framework_2/tests/_autoload.php – no more missing index file and the autoload works too!

Starting the debug session stays the same as explained in Raphael’s post: click “Debug project” (CTRL+F5), go to the terminal and just type something like:

robert@odin:~/www/zf2/tests$ /path/to/phpunit-debug Zend/Dojo/DojoTest.php

Netbeans will pick up the connection and debugging can start!

Happy hackin’!