Last week Wireshark 1.2.10 was released to fix a few bugs and vulnerabilities. Refer to the release notes for details. A package for Slackware64 13.1 is now available.
QMC2, a QT frontend for MAME, has been updated to 0.2.b16. A package for Slackware64 13.1 is now available.
Packages for Xarchiver, a GTK+ graphical archive manager, and thunar-archive-plugin, a Thunar plugin for creating and extracting archives, have been built and added for Slackware64 13.1. They can be downloaded at the URLs below.
A few days ago the MAME developers released 0.139. I’ve updated the Slackware64 13.1 package to this newest version.
For the longest time I’ve had issues editing crontab entries for the root user when setting the VISUAL environment variable to /usr/bin/vim and using “crontab -e”. The existing crontab would be displayed in the editor. I could make changes and save them. However, the changes weren’t written to actual crontab file for root. I had no such problems when modifying a the crontab for a normal user. This behavior may be specific to Slackware or be due to some quirk with the versions of cron and vim used by Slackware (Slackware uses dcron).
When I first ran across this I remember spending some time trying to find a solution, but didn’t come up with anything. My work around has been to maintain a file with my crontab entries and then run “crontab filename“, which puts the contents of the file in to the real crontab. This approach has served me well for quite some time, but for some reason I decided to dig in to this again today.
Why can I successfully use vim and “crontab -e” with a normal user, but not for root? I discovered that when editing a normal user’s crontab, the inode number for the temporary file created with “crontab -e” did not change between initial open and a save. I tested this by using “stat /var/spool/cron/crontab.xxxxxx” (xxxxxx were some random characters) on the file when it was first created and then again after a save. However, the same test when running “crontab -e” as root showed that the inode number for the temp file changed. Vim was creating a new file with the same name, but it turns out cron requires the file be edited in place.
Reading through Vim’s online help I ran across a paragraph in the “backupcopy” entry that specifically mentions problems with “crontab -e”. The text states the following:
One situation where “no” and “auto” will cause problems: A program
that opens a file, invokes Vim to edit that file, and then tests if
the open file was changed (through the file descriptor) will check the
backup file instead of the newly created file. “crontab -e” is an
example.
Now I was getting somewhere. I added the following to root’s .vimrc:
set bkc=yes
Sure enough after this change the inode for the temp file did not change between initial creation and a save. I am now able to successfully use “crontab -e” to edit root’s crontab.
I don’t know the exact reason why there was a discrepancy between the behavior of “crontab -e” for a normal user and for root, but I have a guess. The crontab binary is suid root. It creates a temp file owned by the user and group executing “crontab -e” in a location to which that user may not have write access. This forces vim to edit the file in place when run as a normal user. However, when run as root vim is able to overwrite the initial temp file with a new one. Setting “bkc” or “backupcopy” to yes in root’s .vimrc forces vim to modify the file in place. See vim’s online help for more information on how that setting works (“:h bkc” from within vim will get you to where you need to go).
GParted 0.6.1 fixed a few critical bugs that existed in 0.6.0, so I’ve created a new Slackware64 13.1 package for GParted. I’ve also modified the build script for this package to allow for different graphical ‘su’ applications when launching GParted. My package is now built to use gksu by default. If a different one is wanted, the easiest thing to do would be to edit the ‘Exec=’ line in the “/usr/share/applications/gparted.desktop” file. If you’re building this yourself using my SlackBuild, you can accomplish the same thing by changing the SU_CMD variable within the build script.
In looking for a graphical ‘su’ program to replace the use of kdesu when running Xfce, I ran across ktsuss and gksu.
I would prefer to use ktsuss, as the requirements for it are much lighter than those of gksu. However, in testing I did not find an option for ktsuss to inherit the environment for the target user (namely, root). This causes problems when running applications that require other programs that reside outside of the original user’s $PATH. For example, when running ‘ktsuss /usr/sbin/gparted’ as a normal user, GParted can’t find programs from e2fsprogs, xfsprogs, etc. because they reside in /usr/sbin/. This is a problem, in my opinion. Even with this limitation, I will still offer a ktsuss package. It does work in many situations.
gksu does not suffer from the environment inheritance problem of ktsuss. However, it has more requirements, such as GConf, ORBit2, and gnome-keyring. I offer packages for all of these, so that isn’t a huge problem.
Packages for both ktsuss and gksu can be downloaded at the links below:
ktsuss-1.4
gksu-2.0.2
libgksu-2.0.12 (a requirement for gksu)
At long last Wine version 1.2 has been released. Get a binary Slackware64 13.1 package here:
Here’s a binary package of Wine 1.2-rc7 for Slackware64 13.1. This may be the final release candidate before the final 1.2 release.
I’ve built a Slackware64 13.1 package for Pidgin, the GTK+ multiple protocol messaging client. I realize Slackware includes a package for Pidgin. However, the one available in the base distribution does not support video and/or voice chat. My package includes that support by way of Farsight2 and libnice.
Download the binary package for Pidgin:
The two additional dependencies not included in Slackware can be obtained here:
(110)
(1)
(2)