Fedora - Julio Merino (jmmv.dev)

Three productive days on the Kyua front

This being Thanksgiving week in the U.S. and Google giving us Thursday and Friday off, I decided to take Monday to Wednesday off as well to spend some time hacking on Kyua — yes, finally, after months of being inactive. And what a three productive days!

Here comes a little briefing on the three fronts in which I made progress. (This puts on hold the header files series until next Monday... but most of you are probably away anyway. Enjoy the holidays if they apply to you!)

November 28, 2013 · Tags: atf, fedora, freebsd, kyua, lua
Continue reading (about 6 minutes)

A brief look into Fedora's packaging infrastructure

As you probably know, I have been a long-time “evangelist” of pkgsrc. I started contributing to this packaging system when I first tried NetBSD in 2001 by sending new packages for small tools, and I later became a very active contributor while maintaining the GNOME packages. My active involvement came to an end a few years ago when I switched to OS X, but I still maintain a few packages and use pkgsrc in my multiple machines: a couple of NetBSD systems and 3 OS X machines.

February 8, 2012 · Tags: fedora, packaging
Continue reading (about 9 minutes)

Blacklisting a device in HAL

I have an old Aiptek mini PenCam 1.3 MPixels, identified by USB vendor 1276 and product 20554. I want to use this webcam for videoconferencing in the machine I am setting up for this purpose. This machine carries a Fedora 9 x86_64 installation, as already mentioned in the previous post.

Whenever I connect the camera to the machine, HAL detects the new device and then GNOME attempts to "mount" it using gphoto2. The result is that I get a new device on the desktop referring to the camera, which is pretty nice, but it does not work at all: accessing it raises an unexpected error and thus the photos stored in the webcam cannot be seen.

Anyway, I do not care about the photo capabilities of this camera, just about its ability to stream video. Hence, I installed the gspca and kmod-gspca packages from the livna repositories and, according to the gspca driver, my camera is, supposedly, fully supported.

Unfortunately, I was not able to get the /dev/video device: it didn't exist, even with the kernel modules loaded. After some manual investigation on the console (so that gphoto2 couldn't get in the way), I found that the video device really appears but vanishes as soon as gphoto2 attempts to access the camera. I suspect it is not possible to use the photo and video capabilities of the camera at once with the current drivers.

So, how to avoid this problem? I had to tell HAL to omit this device, so that GNOME did not get any notification of its existance and therefore the interface did not attempt to mount the camera using gphoto2. However, there is few documentation on how to do this, so I had to resort to reading the files in /usr/share/hal/fdi/ and guess what to do.

I ended up creating a 10-broken-cameras.fdi file in /etc/hal/fdi/preprobe/ with the following contents:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
 <device>
  <match key="usb.vendor_id" int="1276">
   <match key="usb.product_id" int="20554">
    <merge key="info.ignore" type="bool">true</merge>
   </match>
  </match>
 </device>
</deviceinfo>

What this code snippet does is match the camera device using some of the properties that are attached to it and, once there is a match, appends the info.ignore property to the device description to tell HAL to not use this device any more. In order to set up the matching of a device, you can see the full list of properties of all device descriptors using the hal-device command.

June 29, 2008 · Tags: fedora, linux
Continue reading (about 2 minutes)

Desktop effects with an nVidia card and Fedora 9

I'm setting up a machine at home to act as a videoconferencing station so that my family can easily talk to me during the summer, while I'm in NYC. This machine is equipped with an Athlon 64-bit processor and a nVidia GeForce 6200 PCI-Express video card. I decided to install Fedora 9 in this computer because this is the distribution I'm currently using everywhere (well, everywhere except on the Mac ;-). Plus it just works (TM), or mostly.

The 3D desktop is not something that is really needed for daily work, but I wanted to try it. Unfortunately, I could not get the desktop effects to work the first time I tried. I enabled the livna repositories, installed the nVidia binary drivers and configured the X server to use them. However, telling the system to enable the Desktop Effects failed, and running glxinfo crashed with a "locking assertion failure" message.

Googling a bit, I found a page mentioning that one has to run the livna-config-display command to properly configure the X server. I think I did not do this, so I just ran this manually and later restarted X. No luck.

Fortunately, that same page also contained a snippet of the xorg.conf configuration file that was like this:

Section "Files"
 ModulePath "/usr/lib64/xorg/modules/extensions/nvidia"
 ModulePath "/usr/lib64/xorg/modules"
EndSection

Effectively, my configuration file was lacking the path to the nVidia extensions subdirectory. Adding that line fixed the problem: now the server loads the correct GLX plugin, instead of the "generic" one that lives in the modules directory. I guess livna-config-display should have set that up automatically for me, but it didn't...

The desktop effects are now working :-) Now I figure out why compiz feels so slow... specially because I have the same problem at work with an Intel 965Q video card.

June 28, 2008 · Tags: compiz, fedora, linux, nvidia
Continue reading (about 2 minutes)

lib64 problems

Linux distributions for the x86_64 platform have different approaches when it comes to the installation of 32-bit and 64-bit libraries. In a 64-bit platform, 64-bit libraries are required to run all the standard applications but 32-bit libraries need to be available to provide compatibility with 32-bit binaries. In this post, I consider 64-bit applications to be the native ones and the 32-bit to be foreign.

The two major approaches I have seen are:

lib32 and lib64 directories, leaving lib to be just a symbolic link to the directory required by the native applications. This is the approach followed by Debian. The advantage of this layout is that the lib directory is the correct one for native applications. However, foreign applications that have built-in paths to lib, if these exist, will fail to work.
lib and lib64 directories. This is the approach followed by Fedora. In this layout, the foreign applications which have built-in paths to lib will work just fine, but the native applications have to be configured explicitly to load libraries and plugins from within lib64.

I have found so far two instances where the Fedora approach fails because native 64-bit applications hardcode the lib name in some places, instead of using lib64. One of these were the NetworkManager configuration files, which had an incorrect setup for the OpenVPN plugin and it failed to work. This issue has already been fixed in Fedora 9. The other problem was in gnome-compiz-manager where the application tries to load plugins from the lib directory, but as it is a 64-bit binary, it failed due to a bitness mismatch. This has been reported but is not yet fixed upstream. I'm sure several other similar problems remain to be discovered.

I personally think that the Debian approach is more appropriate because it seems weird that all standard system directories, such as bin or libexec, contain 64-bit binaries but just one of them, lib, is 32-bit specific.

As a side note, NetBSD follows an slightly different approach: lib contains 64-bit libraries and lib32, if installed at all, contains the 32-bit ones.

June 12, 2008 · Tags: fedora, linux
Continue reading (about 2 minutes)

Mad at the Cell SDK

I've been installing the Cell SDK 3.0 on two Fedora 8 systems at home — a PlayStation 3 and an old AMD box — and I cannot understand how someone (IBM and BSC) can publish such an utterly broken piece of crap and be proud of it. Sorry, had to say it. (If you are one of those who wrote the installer, please excuse me, but that's what I really think. Take this as a constructive criticism.)

Before saying that Fedora 8 is not supported and that I should only run this on Fedora 7, shut up. I am sure all the problems are there too, because none of them can be related to the system version.

Strictly speaking, it is not that the installer does not work, because if you follow the instructions it does. But it is a very strange program that leaves garbage all around your system, produces warning messages during execution and the garbage left around will keep producing warnings indefinitely. Plus, to make things worse, the network connection to the BSC — where the free software packages are downloaded from by yum — is extremely unreliable from outside the university's direct connection (that is, from home), which means that you will have to retry the installation lots of times until you are able to download all the huge packages. (In fact, that's what annoys me most.) And this is not a problem that happened today only; it also bit me half a year ago when installing the 2.1 version.

Let's talk about the installer, that marvelous application.

Starting with version 3, the SDK is composed of a RPM package called cell-install and two ISO images (Devel and Extras). When I saw that, I was pretty happy because I thought that, with the RPM package alone, I'd be able to do all the installation without having to deal with ISO images. It turns out that that is not true, as some components only seem to be available from within them (most likely the non-free ones, but I haven't paid attention).

Ah, you want to know what the SDK contains. Basically, it is composed of a free GCC-based toolchain for both the PPU and SPUs, the free run-time environment (the libspe2), a proprietary toolchain, the proprietary IBM SystemSim for Cell simulator and some other tools (a mixture of free and non-free ones). So, as you can see, we have some free components and some proprietary ones. You can, in fact, develop for the Cell architecture by using the free components alone. So why on earth do you need the proprietary ones? Why can't you skip them? Why aren't they available in some nice repository that I can use without any external "installer" and avoid such crap? That's something I don't get. (Maybe it's possible with some extra effort, but not what the instructions tell you.)

OK, back to the installer. So you need to copy the two ISOs in a temporary directory, say /tmp/iso and then run the installer by doing something like:

# cd /opt/cell
# ./cellsdk --iso /tmp/dir install

This will first proceed to show you some license agreements. Here is one funny point: you must accept the GPL and LGPL terms. Come on! I am using Fedora, and I am already using lots of GPL'd components for which I did not see the license. Why do I have to do that? And why do I have to reaccept the IBM license terms when I already did that in the downloads page?

After the license thing, it mounts the images under /tmp/sdk (keep this in mind because we'll get back to it later), probably does some black magic and at last launches yum groupinstall with multiple parameters to install all the SDK components. All right, you accept the installation details and it starts installing stuff. This would be OK if it wasn't for the network connection problems I mentioned earlier; I've had to restart this part dozens of times (literally) to be able to get all packages. So, again, question: why couldn't you simply tell me what to put in yum's configuration, define some installation groups for the free components alone and let me use yum to install those without having to trust some foreign and crappy installer script? Why do you insist on using /opt for some components and uninconsistently between architectures?

And why did I mention /tmp/sdk? Because the yum repositories registered by the installer have this location hardcoded in. Once you unmount the ISO images (that is, when the installation is done), yum will keep complaining about missing files in /tmp/sdk forever — unless you manually change yum's configuration, that is. What is nicer, though, is that yum always complains about one specific repository because it is only available online, yet it also looks for a corresponding image in /tmp/sdk.

At last, there are also some random problems (probably caused by all the above inconsistencies). Once, the script finalized successfully but the SDK was left half installed: some components were missing. Another time, the installer hang in the middle (no CPU consuption at all, no system activity) when it seemed it had finished and had to manually kill it. After restarting it, it effectively had not finished as it had to install some more stuff.

Summarizing... all these problems may not be so important, but they make one feel that the whole SDK is a very clunky thing.

I wish someone could create native packages for the free components of the SDK and import them into the official Fedora (or, please, please, please, Debian) repositories. After all, these are just a native compiler for the PPU, a cross-compiler for the SPUs, the libspe2 and the SPU's newlib. Note that the GCC backends for both the PPU and SPUs are already part of the FSF trees, so it shouldn't be too difficult to achieve by using official, nicer sources.

Rant time over.

November 18, 2007 · Tags: cell, fedora
Continue reading (about 5 minutes)

Posts: Fedora