/dev/blog

After fiddling around with rpmbuild for quite a while, I stumbled upon yum-builddep. It’s basically a tool to install all packages required to rebuild an RPM package from the SRPM. So if you want to install all “BuildRequires” mentioned in the spec file of a package, invoke

yum-builddep <package name>

The source RPM for the specified package must be available in the yum repository or it can be a local source RPM file.

yum-builddep itself it part of the yum-utils package. You can install it with yum

yum install yum-utils

q.v. yum-builddep manpage

Just a little memory hook:

When a Xen DomU hangs at “Checking for hardware changes”, it is probably due to a dead xenconsoled process on the Dom0. This happens from time to time but

[root@xen ~]# /usr/sbin/xenconsoled

should immediately fix the hanging DomUs.

Sometimes it’s very useful to know which git branch you are working on right from the command prompt. There are many solutions out there, but most of them include python and some awk or grep magic which can time a serious amount of time when you cd into a reasonably large git tree.

But you can also take advantage of the __git_ps1 function, provided by /etc/bash_completion.d/git in the git package. Add this line to ~/.bashrc:

export PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '

This setting helps you keep track of which branch you are in at a given time. If you are in a git working directory, it shows the current branch as part of the prompt:

[user@host directory-name (master)]$

If you do not have the bash-completion package installed, you must manually source the git completion script prior to using __git_ps1(). To do this, add

source /etc/bash_completion.d/git

to ~/.bashrc.

You might also want to display when there are changes in your work tree or the git index:

[user@host directory-name (master*)]$
[user@host directory-name (master+)]$
[user@host directory-name (master%)]$

• * indicates that a tracked file was modified
• + indicates that a tracked file was modified and staged (with git add)
• % indicates that you have untracked files in your tree

To do so, simply add these lines in your ~/.bashrc, right before the line modifying your prompt:

export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true

See the comments at the beginning of /etc/bash_completion.d/git for more details.

Every X server internally manages an ACL (Access Control List) of those hosts, that are allowed to connect. The server only authorizes connections from X clients, whose host is on that list and rejects access to all others. The xhost program is used to add or revert access to the X server for specified hosts. It’s also possible to specify a user and a hostname pair.

Host-based Control (xhost)

To see if access control is enabled, type xhost. It displays the current ACL:

$ xhost
access control enabled, only authorized clients can connect
SI:localuser:user
SI:localuser:gdm
SI:localuser:root

If the access control is disabled, it prints:

$ xhost
access control disabled, clients can connect from any host

To disable the access control type xhost + which allows any host to access your X server. You probaly don’t want to do this because it allows the world to open windows on your screen and grab the keystrokes you type.

To enable the access control again type xhost - and only authorized clients/hosts are allowed to do the things mentioned above.

A simple example

Now let’s do something useful, e.g. grant another user on the local machine access to our X server. It’s pretty easy:

$ xhost +SI:localuser:anotheruser
localuser:anotheruser being added to access control list

And after that, anotheruser should show up in the ACL:

$ xhost
access control disabled, clients can connect from any host
SI:localuser:anotheruser
SI:localuser:user
SI:localuser:gdm
SI:localuser:root

To revoke the access right for anotheruser, use

$ xhost -SI:localuser:anotheruser
localuser:anotheruser being removed from access control list

For granting access to users on different hosts, have a look at the xhost manpage or the examples provided on http://linux.about.com/library/cmd/blcmdl_xhost.htm.

When an upgrade includes changes to a default configuration file, the package will write either a .rpmnew or a .rpmsave file instead of overwriting the configuration file on your system. Which file a package creates is up to the discretion of the package maintainer.

From “Dealing with .rpmnew and .rpmsave files” By Bruce Byfield:

An .rpmnew file contains the new default configuration file and leaves your original configuration file untouched. By contrast, and .rpmsave file is a copy of your original configuration file, which has been replaced by the new default file.

The following script can be helpful to find (and possibly merge) those files with your original configuration

for a in $(find /etc /var -name '*.rpm?*'); do diff -u $a ${a%.rpm?*}; done

You may also want to check on yum-merge-conf, a yum plugin to merge configuration files.

Sometimes, packages you never actually use get installed as dependency by yum (or even during initial installation by anaconda). package-cleanup is a great tool that helps you find packages not required by other packages. It it part of the yum-utils package which can easily be pulled with yum:

# yum install yum-utils

1. Find and review “unused” packages

You can find packages not required by other packages with

# package-cleanup --leaves

These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages.

2. Find and review “lost” packages

You can find orphaned packages (i.e. packages not in the repositories anymore) with

# package-cleanup --orphans

This will also show packages which have been partially uninstalled but where the “%postun” script failed.

q.v. package-cleanup manpage

Changing the system volume with a lirc enabled remote can be a pain in the arse if you don’t know what to look for. If you do, it’s quite simple:

There is a package called ‘pulseaudio-module-lirc’ (PulseAudio’s Wiki for module-lirc) that contains the volume control module for the PulseAudio sound server.

Install the package via yum

# yum install pulseaudio-module-lirc

and enable it

# echo "load-module module-lirc" >> /etc/pulse/default.pa

Here is a sample ~/.lircrc entry configured to forward signals to PulseAudio. Note that you may have to change the remote name and button names to match those in you /etc/lirc/lircd.conf.

begin
   remote = [your remote name]
   prog = pulseaudio
   config = volume-down
   button = [your vol_down button name]
   repeat = 0
end

begin
   remote =  [your remote name]
   prog = pulseaudio
   config = volume-up
   button = [your vol_up button name]
   repeat = 0
end

begin
   remote =  [your remote name]
   prog = pulseaudio
   config = mute-toggle
   button = [your mute button name]
end

Available configs include: volume-up, volume-down, mute, mute-toggle and reset.

Eventually, you have to reload PulseAudio:

# killall pulseaudio && pulseaudio -D

Update:

If you happen to have multiple PulseAudio sinks, you may want to modify /etc/pulse/default.pa like this

[...]
load-module module-lirc sink=[your sink name]
[...]

where you can get the sink name from PulseAudio manager ‘paman’ (flip to the ‘devices’ tab, and copy the name of the sink that you want the lirc module to control).

Just upgraded. Looks really nice…

More screenshots available here: https://fedoraproject.org/wiki/F13_screenshots_library

Resources:
http://lists.fedoraproject.org/pipermail/announce/2010-May/002815.html
http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html

I already wrote a little article, how to boot a FreeDos via PXE. Of course, you can boot Fedora (or CentOS) in like manner.

Read more…

There are basically two ways of getting the Omnikey CardMan 4000 to work: You can either use the original driver from HID (without CT-API support) or the free version from OpenCT

Read more…