Monthly Archives: May 2005

Beagle/Best tweaks

Here’s a couple of beagle changes I’ve been working on.

The first adds functionality to index KDE application launchers, and show their icons in Best. The icons fit in quite well, so some eye-candy is required:
Best + KDE, sitting in a tree,...

Thanks to Diego Pettenò (Flameeyes from Gentoo) for help with locating KDE stuff on disk. The icons don’t seem scaled perfectly, I’ll look into this soon. Also, Best just uses icons from kde’s default theme. If anybody knows how to extract the name of the users chosen icon theme, please let me know.

Next up, I’ve added some tooltips to the Best search results so that more information can be shown. You can’t see the mouse cursor in the example below (import didnt capture it), but it’s quite obvious where it should be.
Tooltip info

The tooltips look a bit naff as they are missing the black border you normally get. This is due to Mozilla bug 238052 – fixed in future versions.

In addition to the tooltip above, you can hover over the icon to reveal the mime-type, and you can hover over the “beagle-testing” folder name to see the absolute path of that folder. Other tiles have been modified in different ways, for example, the Blog tile gives you a tooltip showing you the URL you would get to if you clicked on it.

Gamin 0.1.0

Gamin 0.1.0 was released on Thursday. It’s very similar to the testing snapshot that I produced, but has a couple more fixes on top of that, so its worth upgrading.

inotify 0.23-6 or newer is required. A Gentoo ebuild is available in Gentoo Bug 92573. If you install it, please use the debug use flag, otherwise you’ll be useless when it comes to bug-fixing (see here for debugging procedures).I don’t think it will be included in portage yet, as we don’t currently have any kernels which provide the required inotify version. If you are a gentoo-sources-2.6.11 user, you can find instructions on how to update your inotify version in this post.

A quick check indicates that I can still reproduce the problems I described in GNOME Bug 171201. However, I’m now wondering if some of the problems are GNOME’s fault rather than gamin. This also ties into what some people have said, where the desktop updating breaks easily but nautilus file-browsing works all the time. It appears that the desktop is periodically polling gamin for updates, whereas file-browsing just waits for an event to be signalled. I’m going to investigate this, so if anyone has any idea where the Desktop polling code actually lives, please let me know. I figure that its in nautilus somewhere.

Gamin fixing update

Ok, so a number of people told me about their gamin problems. Some of these, particularly referencing glitches when unplugging USB, seem to be kernel related instead. For now, please use the icon to unmount the USB disk before you unplug. By the way, I run Linux 2.6.12-rc4 and do not experience any glitches even when unplugging during a file transfer. You might want to try it as perhaps “live-unplugging” is safer there.

In a comment, I also mentioned a HAL problem I have: My USB disk only mounts the first time I plugged it in. This is unrelated to gamin, but the Gentopia guys were quick to diagnose it as a HAL 0.4 problem which is solved in HAL 0.5 (present in their overlay). So, if you are experiencing no icon appearing for your USB drive, check with “mount” that it has been mounted. If it hasn’t been mounted, you have the same issue that I do, which is unrelated to gamin.

As for success with the snapshot, well a few people have said it’s been fine, and a few have pointed me to GNOME Bug 171201 where there are some issues described, amongst a lot of confusion of which inotify version to use with which day of gamin CVS. Anyway, I was unfortunate enough to reproduce the issue mentioned there – namely that my desktop and computer:// stopped automatically updating – after restarting the session about 12 times.

You’ll read on the GNOME bug that gamin debug logs are required to diagnose this sort of thing. So, if you were like me and merged the snapshot ebuild without the +debug USE flag, then please merge it again now with the flag set. Then kill gam_server and restart your session.

To debug gamin, you just send it the USR2 signal then it logs to a file at /tmp/gamin_debug_xxxxxxx (it will only do this if you built with USE=”debug”):

# kill -USR2 $(pidof gam_server)

I’m going to be enabling the debug log (as above) when I start each session from this point onwards, but the GNOME bug suggests it may be sufficient to only enable logging once you spot the breakage.

So, please (re)build with the debug flag, and keep an eye out for any breakage. Thanks for the great response so far.

Sorting out gamin brokenness: Testers needed

EDIT: Removed links as this is now fixed upstream and in portage

So, many of us enjoy GNOME’s super-efficient integration with inotify via gamin and hal, which allows nautilus to show file updates in real-time, as well as file browsers automatically opening when a CD is inserted, or usb stick is plugged in, etc.

However, the above has been a bit broken for a while. Gentoo Bug 74285 has the details – basically, the media change notification stuff sometimes works once if at all, but then never again in that session.

The fix is a total rewrite of the inotify backend inside gamin. Unfortunately, due to major changes in gamin cvs, this isn’t easy to backport into the latest release (0.0.26). So it looks like using a CVS snapshot of gamin may be in order.

The plan is to test out the CVS snapshot that I have produced, which will then be added to portage when Linux 2.6.12 is released, assuming we don’t find any big bugs in the snapshot.

I’ve produced a gamin snapshot(link removed) from GNOME developer CVS as of right now, with patches from GNOME Bug 303612 and GNOME Bug 303615 applied.

If you are a GNOME+gamin+hal+inotify user, here’s what you can do to help test this:

  1. Get the snapshot ebuild from (link removed) and put it in your overlay directory under app-admin
  2. emerge the snapshot ebuild:
    # emerge --digest =gamin-
  3. Patch your kernel with inotify 0.23-7. This will involve first reverting the inotify patch included in gentoo-sources-2.6.11 which can be found here. Note that this is the inotify included with 2.6.11-r7 and 2.6.11-r8. If you are using an older version, now would be a good time to upgrade. You can then patch with inotify 0.23-7 which can be found here:
    # cd /usr/src/linux
    ##download the patches
    # patch -p1 -R -i 4800_inotify-0.22-3.patch
    # patch -p1 -i inotify-0.23-rml-2.6.12-rc3-7.patch
  4. Recompile and reinstall your kernel in the usual way
  5. Reboot, start GNOME, and you are done.

To test it, open nautilus on your home directory. Then open a terminal, with both windows visible on screen. In the terminal, create/rename/delete some files, and ensure that nautilus is updated in real-time.
Next, insert a cdrom, and make sure that an icon appears for it on the desktop and the computer:// display is also updated. Use the icon to eject the cdrom, then put it back in again. Check that the icon reappears and computer:// is also updated again. Feel free to do the same with any USB storage you have to hand.

Please leave feedback here – even if it works perfectly! If we get enough testing, we’ll be able to finally solve this.

Writing udev rules update

After almost a year, I finally published an update to my Writing udev rules document. I’m still amazed at the amount of email this brings me – please remind me not to leave it so long next time, going through so much built-up email was quite an effort! Now I just need to reply to it all.

If you are using udev out-of-the-box and don’t know about its customization abilities, you should give this document a quick read.

ebuild shell blows me away

Since I initially raised the topic of using an ebuild to build from a custom source location (rather than unpacking from the tarball as it normally would), a few people have questioned me — is there really a way it can be done without modifying the ebuild at all?

Well, the answer is YES! I’ve just done it.

This is largely thanks to portage-cvs’ ebuild shell capabilities. This really is a fantastic piece of work.

Here’s a quick proof-of-concept example. Note that portage-cvs is required for this.

For many packages, you might say that I can easily point it to use my own set of sources instead of the tarball by simply hacking a value of ${S} to point at my own sources, and not running the ebuild’s src_unpack at all.

Well, what about the ebuilds that do useful things in src_unpack after unpacking the tarball? It would be nice if we didn’t have to also skip them.

Again, I’m using gamin as an example. gamin-0.0.26-r6.ebuild has a src_unpack function which looks like this:

src_unpack() {
	unpack ${A}
	cd ${S}

	# patch to work with inotify 0.21
	epatch ${FILESDIR}/${P}-inotify_use_fd.patch

So, this is a pretty standard scenario, a tarball unpack and a small patch fix being applied afterwards.

Now onto the real task. You need to install two files:

  1. Install the ebuild-env script somewhere in your PATH (e.g. /usr/local/bin) and make it executable.
  2. Install my ebuild.bashrc in the home directory of your non-root user.

Next up, we’ll obtain some gamin sources. The target scenario is where you have already got gamin sources lying around in your home directory and you’ve hacked on them somewhat, but for the sake of this demonstration, we’ll put them in place ourselves. Here’s a link to gamin 0.0.26 from the Gentoo mothermirror: gamin-0.0.26.tar.gz.

From your home-directory of your non-root user, extract the tarball as normal.

# tar xzf gamin-0.0.26.tar.gz
# cd gamin-0.0.26

Enter the pseudo-ebuild-environment shell:

# ebuild-env

At this point, you can run commands that you normally would inside ebuilds (inherit, unpack, epatch, use_enable, etc) – but don’t do this right now, some of them require some hackery to get going and we should keep the environment clean.

Now run use-ebuild to prepare the environment for working with gamin-0.0.26-r6.ebuild. use-ebuild is a function included in my ebuild.bashrc – it finds the ebuild you specify, sets up some environment variables such as ${P} and ${FILESDIR}, sources the ebuild, and sets ${S} to be the location where you called use-ebuild from (in this case, our locally unpacked gamin sources in our homedir).

# use-ebuild gamin 0.0.26-r6
QA Notice: ECLASS 'eutils' illegal conditional inherit in /gamin-0.0.26-r6
QA Notice: ECLASS 'multilib' illegal conditional inherit in /gamin-0.0.26-r6

Ignore the QA notices for now. You may notice a few other odd messages appearing in this demonstration. I’m ignoring the non-critical ones for now. The important part is that the ebuild has been sourced and the environment has been modified accordingly.

So now lets unpack the ebuild, like this:

# src_unpack
 * Would normally unpack:
 * Applying gamin-0.0.26-inotify_use_fd.patch ...  [ ok ]

Notice that the normal stage of unpacking the tarball from /usr/portage/distfiles was skipped, it just worked on the sources it found in the current directory. Notice also that the rest of src_unpack was executed as normal – i.e. the patch was applied.

Compilation through the normal portage processes is just as easy

# src_compile

Portage will now run econf and emake with all the other useful voodoo which comes with it.

And thats all there is to it. I haven’t tried src_install or merge onto live filesystem yet, but you can see I’m a good deal of the way there.

I’ve had to include some hackery in the ebuild.bashrc file to replicate the portage environment closely. At the moment, I’ve included the bare minimum to get the gamin example to work. Don’t be suprised if it fails with other packages right now, but you’ll probably find it easy to fix – it only took me 10 minutes to write the whole script.

Many thanks to ferringb for writing the ebuild-shell functionality. I’m very impressed with how simple it was for me to chain onto portage in this fashion. I’ll add this example to the development platform page soon.