And hopefully when they do, it’ll sound like this:
And hopefully when they do, it’ll sound like this:
I picked up the Humble Indie Bundle 14 the other day, which included Shadow Warrior – so I’m all keen to give it a shot on Linux, but when I launched it, I got this DBUS issue:
r3dux [ ~/Games/ShadowWarrior ]$ ./ShadowWarrior.bin.x86 process 9383: arguments to dbus_connection_open_private() were incorrect, assertion "address != NULL" failed in file dbus-connection.c line 2664. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted (core dumped)
I’m running 64-bit Arch, and I noticed there was a lib folder – so I thought that would be a good place to start experimenting, and I was right! =D
To get Shadow Warrior to launch, you need to remove the libSDL2 and libOpenAL library (.so) files – but have your Linux distro’s versions installed. I did this by renaming the lib folder to old-lib, creating a new lib folder to take its place, and then trying to launch, getting an error, and copying a lib from the old-lib to the lib folder, which by the time the game would launch gives me:
r3dux [ ~/Games/ShadowWarrior ]$ ls lib libfmodevent-4.44.50.so libfmodex-4.44.50.so libtheoradec.so.1 r3dux [ ~/Games/ShadowWarrior ]$ ls old-lib libSDL2-2.0.so.0 libfmodevent-4.44.50.so libfmodex-4.44.50.so libopenal.so.1 libtheoradec.so.1
I have libSDL2 and all lib32-sdl* packages installed, but I have only the native 64-bit version of OpenAL installed (which did not get copied into the remastered ‘lib’ folder) and not the lib32 variant – and yet the game launches and works! So give that a shot – works for me =D
I’m running Arch Linux with a Nvidia graphics card, and after doing a system update back in March 2014 any kernel past 3.10.x would cause X / Xorg to fail to start; instead there’d be a black screen and the fans on the graphics card would spin up to full speed so my machine sounded like a hovercraft. I initially got around this by running the linux-lts (Long Term Support) kernel, until that too exhibited the exact same issue and I was forced to boot the system from USB, chroot into it and switch out the nvidia driver for nouveau (the open-open source, 2D accelerated nvidia driver).
However, as I happen to quite like accelerated 3D graphics and occasionally playing games, I’ve been digging around for a fix for this for ages – and it turns out that the fix (which is now added to the Arch Nvidia wiki page) is to add the following kernel parameter to your bootloader’s kernel line:
If you’re using GRUB, when menu shows up just move the selection to Arch or your Linux distro exhibiting the issue, then hit the e key to edit the line, and change the linux kernel loading line from, for example:
linux /boot/vmlinuz-linux root=/dev/sda8 rw
To include the rcutree kernel parameter, something like this:
linux /boot/vmlinuz-linux root=/dev/sda8 rw rcutree.rcu_idle_gp_delay=1
At which point you can hit F10 (again, assuming you’re using GRUB) to boot using your newly added kernel parameters. Don’t worry if your kernel loading line identifies your partition by UUID value instead of plain ‘ol /dev/sdx – that’s fine and mine does too (I changed it to /dev/blah to make the line shorter) – just add the parameter and try your luck – hopefully your distro will now boot into X without issue, and you can stop swearing and cursing like a drunken sailor. Or perhaps that was just me.
Further reading about the issue on the nvidia development website: https://devtalk.nvidia.com/default/topic/567297/linux/linux-3-10-driver-crash/4/.
P.S. If you need to chroot into your Arch system to change the drivers also, then here’s a quick run-down of the process. Make a bootable USB from the Arch ISO (I could only get this to work by using the dd command from another Linux distro – Rufus and UNetBootin would make a USB I couldn’t boot from – google or search this site for “dd iso usb” for instructions), then, when you’ve booted into the live USB/CD-ROM or what-not, run the following commands (the “<---- optional" lines are optional, don't actually enter that into your files, obviously!):
# Create a directory that we'll mount our Arch / partition to mkdir /mnt/arch # Mount the directory and chroot into it! mount /dev/sdaX /mnt/arch <--- replace X with the partition containing your Arch / partition, mine's /dev/sda8 - but yours likely isn't! arch-chroot /mnt/arch #Now do all your pacman stuff, for example: #To go from nouveau to nvidia you might use (don't include the lib32 things if you're not using them! I use them for Steam): #pacman -Rdds nouveau-dri xf86-video-nouveau mesa-libgl lib32-nouveau-dri lib32-mesa-libgl #pacman -S nvidia nvidia-libgl nvidia-utils lib32-nvidia-libgl # #Or, to go from nvidia to nouveau you might use: #pacman -Rdds nvidia nvidia-libgl nvidia-utils lib32-nvidia-libgl #pacman -S nouveau-dri xf86-video-nouveau lib32-nouveau-dri # Also, if you're going TO nouveau then you should create the file /etc/X11/xorg.conf.d/20-nouveau.conf with contents: #Section "Device" # Identifier "nvidia card" # Driver "nouveau" # Option "GLXVBlank" "true" <---- optional #EndSection # # And if you're going TO nvidia then you should create the file /etc/X11/xorg.conf.d/20-nvidia.conf with the contents: #Section "Device" # Identifier "Nvidia Card" # Driver "nvidia" # VendorName "NVIDIA Corporation" # Option "NoLogo" "true" <---- optional #EndSection # Regardless of which of the above files you create, get rid of /etc/X11/xorg.conf - we should use the xorg.conf.d files now! # Just to be safe, make sure you aren't blacklisting any modules by checking for files in /etc/modprobe.d/ which contain "blacklist nouveau" or "blacklist nvidia" # If you want to make sure /boot/grub/grub.cfg contains the rcutree kernel parameter we've been discussing, now's the time to do it... # Finally, exit the chrooted environment and reboot exit systemctl reboot
With any luck you’ll have now transitioned the drivers successfully and have a fully working system – fingers crossed, good luck!
Back in the day, I decided to use the stray random quotes plugin to place a random quote at the bottom of each page. It worked, and still does. Only, if you clicked on a quote it didn’t refresh – instead it said ‘Loading…’ and then placed an error in my web server log like this (not that it looked like you could even click on a quote anyway – the mouse cursor didn’t change to the ‘pointy-finger’):
PHP Fatal error: Call to undefined function get_stray_quotes() in <path>/stray_ajax.php
I’ve known it didn’t work for ages, but not especially cared, and then this morning I’m putting off doing actual work, so I fixed it.
The problem was that like many people, I’ve moved the file wp-config.php outside of the web-facing folder, so instead of living in /var/www/ it actually lives in /var/. Stray_random_quotes tells you that if you’ve moved your wp-config.php then you need to provide the modified path in stray_ajax.php itself, right near the top – so do so!
The first two lines of stray_ajax.php should now read:
// If your 'wp-content' directory is not in the default location you have to enter the path to your blog here. Example: '/home/www/public_html/wp' $changedDir = '/var/';
That should do ‘er – now, stray_ajax.php should be able to call wp-config, which will allow it to call get_stray_quotes().
When monkeying with wp-config, I saw that it was calling wp-settings, but the call was failing because they expect to be in the same folder, only as mentioned – wp-config.php is up a level from wp-settings.php (which holds no credentials), so, to fix this:
– Edit /var/wp-settings.php and right at the bottom, change the path to the wp-config.php file to be:
/** WordPress absolute path to the Wordpress directory. */ if ( !defined('ABSPATH') ) define('ABSPATH', dirname(__FILE__) . '/www/'); <------ changed this from '/' to '/www/' /** Sets up WordPress vars and included files. */ require_once(ABSPATH . 'wp-settings.php');
Evince crashing with a libcairo segfault like this?
evince: segfault at 0 ip 00007f1af3de6640 sp 00007fffb9e0af38 error 4 in libcairo.so.2.11200.2[7f1af3d6e000+f4000]
It’s a libcairo2 1.12.2-2 issue – which you can thankfully fix by downgrading libcairo2 to a 1.10.2 incarnation – here’s how…
First check you have an alternate version to downgrade to. To do this in Synaptic select the libcairo2 package then click on the Versions tab at the bottom, or you can do the same check via a swift apt-cache policy libcairo2 as shown below:
$ apt-cache policy libcairo2 libcairo2: Installed: 1.12.2-2 Candidate: 1.12.2-2 Version table: *** 1.12.2-2 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages 100 /var/lib/dpkg/status 1.10.2-2ubuntu2 0 500 http://packages.linuxmint.com/ debian/upstream amd64 Packages
In this case the older (but functional) package 1.10-2-2ubuntu2 is available. Let’s assume there’s an older package you can use – if not, go get one from elsewhere.
Uninstall libcairo2 using any manner you like – this will also force removal of things like Evince as dependencies, unless you see anything spectacular that you know you need just let it.
Then in Synaptic, search for libcairo2, select it (i.e. click on it), then from the Synaptic menu choose Package > Force Version and choose the older, working package, and install it.
Next, you’ll want to lock to that version so it doesn’t get upgraded (at least until there’s a newer working version), so again from the menu just select Package > Lock Version.
Finally, reinstall what was ailing ya and everything should work fine. In my case at least, this means I can reinstall the Evince PDF viewer and it’ll now print to PDF without segfaulting – Huzzah! =D
I’ve no doubt you can do this entire process from the command line, but it’s easy and works through Synaptic so I’ll leave that as an exercise for the reader.
As an added bonus, if you’re experiencing slow display and/or corrupted text in Iceweasel or Chromium then the downgrade should fix that up too. You can read more about which here.