Gnome - Julio Merino (jmmv.dev)

Where does Gnome use file monitoring?

One of the readers of my post yesterday, wonders where Gnome uses the file monitoring APIs. Well, the answer is: everywhere. Here are some examples: Nautilus monitors all open folders so that it can update their contents whenever the underlying file store changes. Say you are viewing the Documents folder and you save a new Document from within OpenOffice into that folder. You definitely want Nautilus to show it immediately, without having to manually hit Refresh from the menu.The trash applet monitors the trash folders and updates its icon from empty to full whenever one of these folders ceases to be non-empty.The panel monitors the applications directory to notice when new applications get installed. This allows it to update the Applications menu immediately as soon as a new program gets installed into the system.The GTK file open/save dialogs monitor the directory they are viewing for the same reason as Nautilus. (Actually, I'm unsure about this point. My Linux installation is an old Ubuntu 8.04 LTS that does not have GIO, so I can't verify in recent ones. However, this makes perfect sense and if not implemented, it should be!)The background switcher control panel monitors the folders containing images to be able to show new installed backgrounds. (I'm not sure about this either. It doesn't happen in my Linux installation, but it also makes sense.)Media players such as Rhythmbox and Banshee allow you to point them to a folder containing music and have an option to automatically add music to the library as soon as it pops up in such folder.Potentially, any document editor, picture viewer, etc. monitors the documents opened in them so that these applications can notice external notifications to those files. This is useful to prevent overwriting a file with an out-dated in-memory copy. For example: you are taking some notes with GEdit. On a separate terminal window, you quickly edit the notes file with Vim to add a new note. When you go back to GEdit, you want the editor to tell you that the file has changed out of its control and offer you a choice: e.g. reload or ignore? And many, many more other situations that I'm surely missing... As you can see, it is fairly important to get the file monitoring subsystem working flawlessly. Otherwise, all these tiny details don't work and the end user experience is undermined.

April 21, 2010 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

New gio-fam package

As briefly outlined in the previous post, new versions of Glib provide GIO, a library that intends to be a low-level file system API on top of the POSIX interface. This library provides an interface to asynchronously wait for file system change notifications including the creation, deletion and modification of files. The monitoring functionality in GIO is modular: it is backed by different loadable plugins that implement OS-specific functionality. In particular, GIO uses an inotify module in Linux and a FAM module everywhere else. Up until now, the devel/glib2 package in pkgsrc provided a build-time option to specify whether to build the GIO FAM plugin or not. Given that this plugin is built as a shared object that is loaded dynamically at run-time, having a build-time option for this is clearly wrong: it gives no choice to those relying on binary packages (e.g. end/new users). Furthermore, it adds a dependency on the ugly-FAM at the very bottom of the huge Gnome dependency chain. (As already stated, FAM is outdated and hard to set up.) So, based on this, I've just removed all FAM support from devel/glib2 altogether and packaged its loadable module as sysutils/gio-fam. Now waiting for a clean rebuild of the Gnome packages to see if the desktop now works on my machine by avoiding FAM/Gamin.

April 20, 2010 · Tags: <a href="/tags/gnome">gnome</a>, <a href="/tags/netbsd">netbsd</a>, <a href="/tags/pkgsrc">pkgsrc</a>
Continue reading (about 2 minutes)

File system monitoring, Gnome and NetBSD

A few days ago, I decided to start using NetBSD, as well as Gnome on NetBSD once again, mostly because the lack of their use makes my skills feel rusty in many different areas. While NetBSD has surprised me in a good way (I am running it on a Macbook Pro and things like wireless and DRI work), Gnome has not. There are tons of broken things that prevent a smooth user experience. One of these broken things is the monitoring of changes in the file system. Actually, this has never worked 100%. But what is this and why does it matter, you ask? Well, file system monitoring is an internal component of the Gnome infrastructure that allows the desktop to receive notifications when files or directories change. This way, if, say, you are viewing the Downloads folder in Nautilus and you start downloading a file from Epiphany into that folder, Nautilus will realize the new file and show it immediately without requiring a manual refresh. How to monitor the file system depends on the operating system. There are basically two approaches: polling and asynchronous notifications. Polling is suboptimal because the notifications are usually delayed. Asynchronous notifications are tied to the operating system: Linux provides inotify, NetBSD provides kqueue and other systems provide their own APIs. In the past, Gnome monitored the file system by a combination of FAM, a system-level service that provides an API to file system monitoring, and GNOME VFS, a high-level layer that hides the interaction with FAM. This approach was good in spirit (client/server separation) but didn't work well: FAM is abandoned. Does not support kqueue out of the box.FAM runs as root. FAM is too hard to set up: it requires rpcbind, an addition to /etc/services, a sysctl tweak, and the configuration of a system-level daemon.To solve some of these problems, a drop-in replacement for FAM was started. Gamin, as it is known, still does not fix everything: Gamin is abandoned.Supports kqueue out of the box, but does not work very well.Actually, Gamin itself does not work. Running the tests provided by the distfile in a modern Linux system results in several test failures. Anyway. Did you notice the abandoned pattern above? This is important: in the new world order, Gnome does not use FAM any more. The new structure to monitor files is: the low-level glib library provides the gio module, which has some file system monitoring APIs. The GVFS module provides higher level abstractions to file system management, and relies on gio for file system monitoring. There is no more GNOME VFS any more. The key point is: gio uses inotify directly; no abstraction layers in between. FAM support is still there for platforms without inotify, but as it is not used in Linux any more, it rots. Linux developers will never experience what it is to have a system that needs to use FAM to get this functionality to work. At last, let's look at the status of all this in NetBSD: The FAM package was patched to support kqueue. Although this kinda works, it is not perfect. Also, as mentioned above, FAM is, I'd say, the package with the hardest installation procedure of the whole Gnome platform. The Gamin packages are nicer than the FAM package regarding their configuration. However, when using Gamin instead of FAM, all sorts of bugs appear in Gnome (it actually gets stuck during startup for me). The breakage of the unit tests does not provide any confidence, and the fact that Gamin is abandoned, the idea of fixing it doesn't make me thrive.The glib2 package depends on FAM. This is ugly; really ugly. I had to shout WTF when I saw this, seriously.Seeing the direction gio/gvfs take, it is obvious that things can only get worse in the future. If time permits, I'm planning to work on improving this whole situation. Ideas include: Splitting the FAM gio module out of the glib2 package. Ideally, this would happen upstream.Implement a gio backend for kqueue.Check if the core packages still using gnome-vfs have a more recent version that uses gvfs instead and, if so, update them. Can't promise you anything other than, if I get to work on it, I will keep you posted!

April 20, 2010 · Tags: <a href="/tags/gnome">gnome</a>, <a href="/tags/netbsd">netbsd</a>
Continue reading (about 4 minutes)

Software bloat, 2

A long while ago — just before buying the MacBook Pro — I already complained about software bloat. A year and two months later, it is time to complain again. I am thinking on renewing my MacBook Pro assuming I can sell this one for a good price. The reasons for this are to get slightly better hardware (more disk, better GPU and maybe 4GB of RAM) and software updates. The problem is: if I am able to find a buyer, I will be left without a computer for some days, and that's not a good scenario. I certainly don't want to order the new one without being certain that I will be paid enough for the current one. So yesterday I started assembling some old components I had lying around aiming at having an old but functional computer to work with. But today I realized that I also had the PlayStation 3 with Fedora 8 already installed, and that it'd be enough to use as a desktop for a week or so. I had trimmed down the installation to the bare minimum so that it'd boot as fast as possible and to leave free resources for testing Cell-related stuff. But if I wanted to use the PS3 as a desktop, I needed, for example, GNOME. Ew. Doing a yum groupinstall "GNOME Desktop Environment" took quite a while, and not because of the network connection. But even if we leave that aside, starting the environment was painful. Really painful. And Mono was not there, at all! It is amazing how unusable the desktop is with "only" 256MB of RAM; the machine is constantly going to swap, and the disk being slow does not help either. I still remember the days when 256MB was a lot, and desktop machines were snappy enough with only half of that, or even less. OK, so GNOME is a lot for 256MB of RAM. I am now writing this from the PS3 itself running WindowMaker. Which unfortunately does not solve all the problems — and the biggest one is that it is not a desktop environment. Firefox also requires lots of resources to start, and doing something else in the background still makes the machine use swap. (Note that I have disabled almost all of the system services enabled by default in Fedora, including SELinux.) If I finally sell my MBP, this will certainly be enough for a few days... but it's a pity to see how unusable it is. (Yeah, by today's standards, the PS3 is extremely short on RAM, I know, but GNOME used to run quite well with this amount of RAM just a few years ago.)

February 28, 2008 · Tags: <a href="/tags/bloat">bloat</a>, <a href="/tags/gnome">gnome</a>, <a href="/tags/ps3">ps3</a>, <a href="/tags/software">software</a>
Continue reading (about 3 minutes)

A letter to NetBSD

Dear NetBSD, It is almost five years since we first met and I still remember how much I liked you at that time. Despite your 1.5 release had slow disk performance when compared to the other BSDs, I found in you an operating system that just felt right. You focused on clean and well designed code among many other goals; sincerely, I didn’t come to you looking for portability because I never had anything else than i386 machines. All these feelings turned into love after installing and experimenting with you: the system was minimal, well documented and made sense. As you know, I soon left FreeBSD and migrated my machines to you.

September 23, 2006 · Tags: <a href="/tags/gnome">gnome</a>, <a href="/tags/netbsd">netbsd</a>, <a href="/tags/pkgsrc">pkgsrc</a>
Continue reading (about 5 minutes)

GNOME on NetBSD needs YOU!

A few pkgsrc developers and I have been working hard for years to bring the GNOME Desktop to this packaging system and make it work under NetBSD. We are quite happy with the current results because the packages are updated very frequently and everything works. Well, almost. There are still several missing details that really hurt the end user experience and need fixing. If things continue as have gone until now, we will always be one step (or more!) behind other operating systems such as Linux and FreeBSD. Linux, of course, gets full support from the GNOME developers because they do their daily work on it. FreeBSD, on the other hand, has more people working on the port and therefore have more manpower to resolve all the portability problems; they are doing a nice work. In our case, it is clear that we do not have enough manpower to keep up with the huge task that porting GNOME is — we are very few people working on it. Just consider that GNOME is composed of around 100 packages and that there are new major releases every 6 months (minor ones coming much faster). This updating task imposes a lot of stress on us that prevents us from working on the remaining pending items. If we were able to work on all these issues, we could have a fully-functional GNOME Desktop on top of NetBSD. I belive this is a key area to improve NetBSD's visibility: if we had a complete desktop evnrionment, more users could come and use NetBSD for their daily tasks. Eventually, this could attract more developers who would start contributing to the system itself. So... I've prepared a list of GNOME-related projects that details the major items that need to be addressed to have a complete GNOME Desktop installation on top of NetBSD and pkgsrc. I've tried to detail each project as much as possible, explaining the current problem, why solving it could benefit NetBSD and how to get started. Should you need more information, I've also written some generic guidelines about GNOME packaging and porting. And, of course, you can contact me to get more details and take one of the projects! I'm willing to mentor you to make them success. You can certainly make a difference to the current status of things. Let me add that I've have learned a lot about many different areas from my contributions to pkgsrc and NetBSD. You can seize the opportunity to learn new exciting stuff too; don't be shy! Oh... and if GNOME on NetBSD is not of your preference, please see our complete list of proposed projects; I bet you will find something of your interest!

September 1, 2006 · Tags: <a href="/tags/gnome">gnome</a>, <a href="/tags/netbsd">netbsd</a>, <a href="/tags/pkgsrc">pkgsrc</a>
Continue reading (about 3 minutes)

Recent GNOME fixes

A week has almost passed since someone told me that D-Bus' session daemon was broken in NetBSD. I curse that day! ;-) I've been investigating that problem since then and (very) beleatedly fixing some issues in other GNOME programs during the process. D-Bus' session daemon did not work under NetBSD because it couldn't authenticate incoming connections; that was due to the lack of socket credentials. After some of days of investigation — which included discovering that NetBSD does indeed support socket credentials through LOCAL_CREDS — and multiple attempts to implement them, I finally got D-Bus session daemon to authenticate appropriately. This served me to fix gnome-keyring too, which was broken for the exact same reason, and gnome-keyring-manager, the application I was using to check whether gnome-keyring worked or not. At last I also finally sat down and solved an annoying problem in the gnome-applets package that caused the Sticky Notes applet to crash when adding a new note; this had been happening since 2.12.0 if I recall correctly. I am sure that the root of this problem was also producing incorrect behavior in other panel applets. For more details check these out: dbus: #7798 - Generalize kqueue supportdbus: #8037 - Improve debugging messages in exchange_credentialsdbus: #8041 - Add LOCAL_CREDS socket credentials supportgnome-keyring: #353105 - Implement LOCAL_CREDS socket credentialsgnome-applets: #353239 - Get rid of AC_DEFINE_DIRgnome-keyring-manager: #353251 - Better handling of null paths Ouch... and GNOME 2.16 is around the corner... I'm afraid of all the new problems to come!

August 28, 2006 · Tags: <a href="/tags/gnome">gnome</a>, <a href="/tags/netbsd">netbsd</a>
Continue reading (about 2 minutes)

GNOME 2.14.3 hits pkgsrc

Last night I finished updating the GNOME meta packages in pkgsrc to the latest stable version, 2.14.3. Yes, I had to take a break from Boost.Process coding (which is progressing nicely by the way; check the docs). The meta packages had been stalled at 2.14.0 since the big update back in April which shows how few time I've had to do any pkgsrc work — well, you can also blame the iBook with its Mac OS X, if you want to ;-) Luckily the packages are now up to date, but I hope they'll not get stalled at this version for too long: 2.16.0 is around the corner (due in one-two months!). I must thank Matthias Drochner and Thomas Klausner for all their work in the GNOME packages during this period of time. Although they did not touch the meta packages, almost all of the components were brought up to date very promptly after each stable release; in fact, I just had to update a dozen of packages on my own to get a complete 2.14.3 installation, aside from tweaking the meta packages. Let me finish with a call for help: the biggest thing missing (in my opinion, that is) in GNOME under NetBSD right now is HAL. It shouldn't be too difficult to get to work but will certainly require several days of discussion and coding. Shall you want to help here (which basically boils down to adding a kernel driver and porting the userland utilities), feel free to contact me for more details.

August 7, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

X11 and the Win keys

For quite some time I've been having issues with the Windows keys in my Spanish keyboard under X11. I like to use these as an extra modifier (Mod4) instead of a regular key (Super_L), because it is very handy when defining keybindings. The X11 default seems to treat them as Super_L only. For example, trying to attach Win+N as a keybinding to one of the actions in the GNOME Keyboard Shortcuts panel resulted in the Super_L combination instead of Mod4+L, hence not working at all. Fortunately, I found how to fix that within GNOME a while ago. It is simply a matter of enabling the "Meta is mapped to the left Win-key" option in the Keyboard configuration panel. But... I was now forced to use Fluxbox while I rebuild some parts of GNOME and the modifier was not working because the system was using X11 defaults again. After inspecting /etc/X11/XF86Config and some of the files in /usr/X11R6 I found how to enable this behavior in the regular X11 configuration files, bypassing GNOME. It is a matter of adding the following line to the keyboard section of XF86Config: Option "XkbOptions" "altwin:left_meta_win" I guess this works the same for X.Org.

August 6, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

Disabling bitmapped fonts

A week ago or so I reinstalled NetBSD — 3.0_STABLE, not current — on my machine, finally replacing the previous unstable and out-of-control system. I had to do it to get some work done more easily than on Windows and to be able to keep up with my developer duties. After a successful and painless installation, I built and installed Firefox and Windowmaker, both of which come handy from time to time (specially while rebuilding the entire GNOME Desktop). However, launching Firefox under a plain Windowmaker session greeted me with extremely ugly fonts. The GTK interface was OK, but web pages were rendered horribly in general. It was simply unusable. At first I thought it had to do with the anti-aliasing configuration, but several attempts to change its details only resulted in worse fonts. The same happened when dealing with DPI settings. So what was happening? It turns out that Firefox was using bitmapped fonts instead of vector ones — and you know how ugly these look if they are not rendered in their native size. Firefox was asking Fontconfig (X's font configuration and access library) to provide a font from the Serif family, without caring about which it could be. Fontconfig then provided it with a bitmapped font. (I still don't know why it preferred those over any other.) The nice thing is that you can tell Fontconfig how to match generic font names to the fonts you really have. And this effectively means that you can force it to never use bitmapped fonts. All I had to do was to create a custom local.conf file in Fontconfig's configuration directory (/etc/pkg/fontconfig in my case):<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <include>conf.d/no-bitmaps.conf</include> </fontconfig>The curious thing is that GNOME seems to take care of this on its own because Firefox uses nice fonts under it even if you do not touch Fontconfig files. Oh! Be aware that NetBSD has two Fontconfig installations: one from the native XFree86 installation and one from pkgsrc. These are configured in different directories: /etc/fonts and PKG_SYSCONFDIR/fontconfig respectively. Don't know if this issue also happens in other operating systems if Fontconfig is not manually configured...

June 25, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.14.0 hits pkgsrc

After three weeks of intense work, I am pleased to announce that GNOME 2.14 is now available in pkgsrc, the NetBSD Packages Collection. As happens with all other major GNOME releases, this one provides a set of polishments, cleanups and several new features over the 2.12 series. You can find more information in the official release page (linked above). I am happy to say that this release works fairly well under NetBSD. There are still some rough edges (that is, programs that crash on startup or do not work as expected) but there shouldn't be much regressions from the previous version. I think I will prepare a list of known broken stuff in case people wants to help because fixing everything requires a lot of manpower. To give you some approximate numbers, the process consisted of 80 package updates, 8 new packages and 16 revisions of the new and updated packages. Some more may come in the following days. As usual, updating from older versions is not exactly easy using pkgsrc. I suggest you to either build the whole new release in a sandbox using pkg_comp or zap all your installed packages to reinstall from scratch. How to install it? Just use the meta-pkgs/gnome package to install everything that is part of the official GNOME distribution or choose meta-pkgs/gnome-base if all you want is a minimal desktop. Please report any problems you find using send-pr(1). You can also check out the official announcement. Have fun!

April 2, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Fixing GNOME's trash under NetBSD

For a very long long time (probably since forever), the trash icon in GNOME has not worked in NetBSD. You'd drag files onto it and they were appropriately deleted but, unfortunately, the trash did not update its status to reflect the removed files. If you opened the folder, it appeared empty despite ~/.Trash contained the deleted files. As you can image this was very annoying as it made the trash near to useless. However, and by pure luck, some days ago I noticed that the trash icon showed some files on my machine. For a moment I thought that the problem had been fixed with GNOME 2.14.0. But I was wrong: ~/.Trash didn't contain the files shown in the trash window; the files were really stored in /vol/data/.Trash-jmmv. So why was it picking up the files from one directory but not from the other one? I started by looking for the .Trash string in gnome-vfs which led me to a piece of code that returns the trash directory for a given volume. I first thought that there could be a problem detecting the home directory so I added some debugging messages there; everything looked correctly. After digging some more and thanks to the test/test-volume test utility, I ended up in the libgnomevfs/gnome-vfs-filesystem-type.c file. This contains a table called fs_data that maps each file system name to a description and to a boolean. The boolean indicates whether the file system is supposed to hold a trash or not. As you can imagine, ffs was not part of this list, so the code felt back to the default values that specify that there was no trash. Solving the issue was trivial. I just had to add the appropriate file system names to the table, rebuild gnome-vfs and experience the trash icon to its full power :-) The issue is reported in bug #336533 and is already commited to pkgsrc. Therefore, it will be part of the forthcoming pkgsrc-2006Q1 stable branch.

March 29, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME and the dbus daemon

It is a fact that dbus is becoming popular and that many parts of GNOME are starting to use it. Nowadays, some applications even fail to start if dbus is not present (e.g. epiphany). Unfortunately, things do not work out of the box when installing GNOME from sources — or when using an "uncustomized" OS; see below — because there is nothing in GNOME that launches a dbus-daemon session at startup. Therefore, the user is forced to either:Change his ~/.xinitrc to do exec dbus-launch gnome-session instead of the traditional exec gnome-session.Edit his gdm configuration files to launch dbus-daemon before gnome-session.As you can see, both "solutions" are cumbersome because they break the previous behavior and because they require the user to take extra steps to get things working. Of course, in the disordered Linux world, distributions such as Ubuntu or Fedora Core include customized and rather complex X startup scripts that launch dbus-daemon during a session setup. Non-dbus-enabled systems (such as NetBSD) could ship modified gdm packages to avoid this problem, but users could still hit a problem when using the traditional startx or other session managers such as xdm or kdm. I do not need to mention that some systems (e.g. NetBSD again) will not ever include — unless things change dramatically — a call to dbus-daemon in their standard X11 scripts. A possible solution is to modify the gnome-session utility to spawn a dbus-daemon process on its own, just as it does with gconf or gnome-keyring. This way the user needn't remember to start dbus on his own as the GNOME session manager will do it automatically. With this in place, GNOME magically works again in these dbus-agnostic systems. And yes, this solution is already implemented. It has kept me busy for two days but you can find the code in bug 336327. I hope to get some positive feedback and integrate it into pkgsrc until an official gnome-session release does it (if ever). If it is not integrated... well, I guess I'll have to go the gdm-patching route. By the way, I have to say this: more than 300 lines of C code to do something that can be achieved in less than 10 lines of shell script... people seem to like to make their lives more complex than need be ;-)

March 27, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.14.0 released

OK, I know this comes late but I had to publish it. GNOME 2.14.0 was published a few days ago. As happens with all other major releases in the 2.x series, this one comes with several improvements and tons of bug fixes. Note that these are not "very big" changes; they can be seen as minor refinements over the previous version, aiming for a better user experience. You can check this review for more information. I have alread played with this version in its full power: I installed Ubuntu Dapper to get it up and running in few hours, resulting in a fully working desktop environment. (I think I'm leaving KDE again ;-) Now I'm dealing with the update in pkgsrc; I've almost got the gnome-base package up to date, so I hope to be able to boot into this new version tomorrow or so. Thanks to the currently running package freeze, I can work on the update without interferences for a period of two weeks in which I hope to get the new version running, shake out some bugs and feed some patches back. I hate to see some packages such as gnome-vfs2 or libgtop2 with lots of local patches, as they are almost unmaintenable. (I know, I know... the freeze is aimed at solving bugs. But I do this big update now that I have some-but-not-much free time or I won't be able to do it.)

March 19, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Linux problems: binary redistribution

thomasvs (who appears in Planet GNOME) is running a post titled How not to solve a problem in his blog. He talks about the aggressive tone used in a page from Autopackage's wiki and how it can cause a bad impression of that project. (I was going to reply to his post in his blog but commenting is unsupported... so posting this here.) That "Linux problems" page talks about many issues that arise when trying to redistribute software in binary form for the Linux platform. It outlines many real problems that users face when using binaries not specifically built for their installation and how it prevents developers from creating binary-only versions of their programs that will work anywhere. That page is certainly a good read. It contains a lot of technical interesting details of how ABI compatibility is broken often. (But you know, Linux is just a kernel so some of them may be unsolvable, unfortunately.) You need to have suffered these problems to understand the tone of the page (which might be improved to be a bit more polite). It is frustrating to see how people continues to do "incorrect" things that cause pain to third parties. OK, OK, this is because those people are not aware of the issues... but hey, that's what that page is for, to inform them! I already expressed my concerns here and here. They are not about binary portability, but I feel they are somewhat related.

March 11, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.12.2 in pkgsrc

It has taken a while but, finally, GNOME 2.12.2 is in pkgsrc. As always, this new version comes with multiple bug fixes and some miscellaneous new stuff. Enjoy it.

January 20, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

GStreamer 0.10 in pkgsrc

I've uploaded GStreamer 0.10, the base plugins set and the good plugins set to pkgsrc. This new major version is parallel installable with the prior 0.8 series; this is why all the old packages have been renamed to make things clearer. Fortunately, this version was easier to package because it does not need a "plugin registry" as the previous one did (i.e., no need for install-time scripts). Even though, the split of the plugins in different distfiles (base, good, bad, et. al.) make it a bit more complex. Let's now wait until someone packages Beep Media Player's development version and we'll be able to enjoy its features (assuming it works fine, of course...). I have to confess that I'm losing interest in maintaining the GNOME-related packages in pkgsrc. They take me too much time, time that I'd rather spend on other NetBSD-related tasks. This is why this update has been delayed so much...

January 18, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

Applications vs. windows

One of the things that I’ve come to love about Mac OS X is the way it handles the active applications. Let’s first see what other systems do in order to talk about the advantages of this approach. All other desktop environments—strictly speaking, the ones I’ve used, which include GNOME, KDE and Windows—seem to treat a single window as the most basic object. For example: the task manager shows all visible windows; the key bindings switch between individual windows; the menu bar belongs to a single window and an application can have multiple menu bars; etc.

January 6, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 3 minutes)

Updating the pkgsrc GNOME packages

A while ago, somebody called John asked me to explain the process I follow when I update the GNOME packages in pkgsrc. As I'll be doing this again in a few days (to bring 2.12.2 into the tree), this seems a good moment for the essay. Here I go: The first thing I do is to fetch the whole distribution from the FTP site; i.e., the platform and desktop directories located under the latest stable version. I have a little script that does this for me, avoiding to fetch the distfiles that haven't changed since the previous version. Once this is done I generate a list of all the downloaded distfiles and adjust the package dependencies in meta-pkgs/gnome-devel/Makefile, meta-pkgs/gnome-base/Makefile and meta-pkgs/gnome/Makefile to require the new versions; this includes adding any possible new stuff. I do this manually, which is a quite boring task; however, writing a script could take much more time. Afterward, I use cvs diff -u meta-pkgs/gnome* | grep '^+' over the modified files to get a list of the packages that need to be updated. As the list of dependencies in the meta-packages is sorted in reverse order — i.e., a package in the n-th position uses packages in the 1..n-1 positions but not any in the n+1..N ones — this command creates a useful "step by step" guide of what needs to be done. Then, it is a matter of updating all the packages that need it, which is, by far, the longest part of the process. I go one by one, bumping their version, building them, installing the results, ensuring the PLIST is correct, and generating a log file in the same directory that will serve me during the commit part. I also have a little script that automates most of this stuff for a given package — and, thanks to verifypc, this is relatively quick :-) In the last part described, there are some packages that always scare me due to the portability problems that plague them over and over again. These include the ones that try to access the hardware to get information, to control multimedia peripherals, to manage network stuff, etc. I don't know why some packages break in similar places in newer versions even if the mainstream developers have been sent some patches to fix the stuff in previous versions. </rant> Once I've got the updated gnome-base package installed, I zap all my GNOME configuration — ~/.gconf*, ~/.nautilus*, ~/.metacity*, ~/.gnome* and a lot more garbage — and try to start it. At this point, it is mostly useless, but I can see if there are serious problems in any of the most basic libraries. If so, this is the time to go for some bug hunting! When the gnome-base package works, I continue to update all the other missing packages and try to package the new ones, if any. Adding new stuff is not easy in general (portability bugs again) and this is why some of the dependencies are still commented out in the meta-packages. Anyway, with this done, I finally start the complete desktop and check if there are any major problems with the most "important" applications. Again, if there are any, it is a good time to solve them. So all the updates are done, but nobody guarantees that they work, specially because I do all the work under NetBSD-current. So I generally (but not always... shame on me!) use pkg_comp to check that they work, at the very least, under the latest stable release (3.0 at this point). The last part is to commit all the stuff in a short time window to minimize pain to end users. Even though I have left log files all around and prepared the correct entries for the CHANGES file, this often takes more than an hour. Unfortunately, end users always suffer, either because the packages break on their platform, because our packaging updating tools suck or simply because I made some mistake (e.g., forgot to commit something). But this is what pkgsrc-current is for, isn't it? ;-) And, of course, another thing to do is to review all the newly added local patches, clean them up, adapt them to the development versions of their corresponding packages and submit them to GNOME's bugzilla. This is gratifying, but also a big, big pain. Well, well... this has been quite long, but I think I haven't left anything out.

January 5, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 4 minutes)

File previews in Nautilus

Yesterday's evening, I was organizing some of my pictures when I noticed that Nautilus wasn't generating previews for any of them. This annoyed me so much that I decided to track down the issue, which I've done today. The first thing I did was to attach a gdb session to the currently running Nautilus process, adding some breakpoints to the functions that seemed to generate preview images; I located them using grep(1) and some obvious keywords. This wasn't very helpful, but at least I could see that the thumbnail generation routine checks whether the file is local or not (because Nautilus lets you set different preferences for them). With this in mind, I resorted to the traditional and not-so-elegant printf debugging technique (which, with pkgsrc in the middle, is quite annoying). Effectively, a call to gnome_vfs_uri_is_local was always returning false, no matter which file it was passed. It was clear that the problem was in gnome-vfs itself. So I switched to the gnome-vfs code, located that function and saw that it was very short: basically, all it does is delegate its task to another function that depends on the method associated to the file — you can think of the method as the protocol that manages it. As I was accessing local files, the method in use was the file method (implemented in modules/file-method.c), so the affected function was, how not, its do_is_local. As it is a bit complex (due to caching issues for efficiency), I added some more printfs to it to isolate a bit more the problem, which drove me to the filesystem_type function implemented in modules/fstype.c. And man, when looking at this function I quickly understood why it was the focus of the problem. It is so clumsy — portability-wise — that it is very easy for it to break under untested circumstances: it is composed of a set of mutually exclusive ifdefs (one for each possible situation) to determine the file system name in which a file lives. And you guessed right: NetBSD 3.x didn't match any of them, so it resorted to a default entry (returning an unknown file system type) that is always treated as remote by the file method code. The solution has been to workaround the detection of one of these special cases in the configure script to properly detect statvfs(2) under NetBSD. This is just a hack that adds to the uglyness of the original code, but fixing this issue properly will require a lot of work and the willingness of the gnome-vfs maintainers to accept the changes. I will ask for a pull-up to the pkgsrc-2005Q4 branch when I've been able to confirm that this does not break on other NetBSD versions. Now have fun watching your images again! ;-)

January 1, 2006 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 3 minutes)

GNOME 2.12.1 hits pkgsrc

As usual, the latest stable version of the GNOME Platform and Desktop, 2.12.1, has been integrated into pkgsrc. It has been a tough job due to all the affected packages and comes a bit late, compared to all the previous updates, but I hope you'll enjoy it. Please see the official announcement for more information.

October 16, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

Local sockets' permissions

A few days ago, I was trying gamin under NetBSD which unfortunately didn't work at all. The first problem I encountered was that it complained about the excessive permissions given to newly created local sockets (those stored in the file-system, also known as "Unix sockets" historically). After analyzing the issue, I saw that those files were given 777 permissions, regardless of the user's umask. Strangely, the code was explicitly checking for this mode after creation, so I was probably missing something.

August 24, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

pkg-config: Sanity-checking package dependencies

A while ago, I posted a series of pkg-config related messages: 1, 2 and 3. They were intended to give some background knowledge about that program, to let me easily explain something else: how pkg-config can be used to sanity-check packages — that is, to ensure that the libraries they depend on are the correct ones. In pkgsrc, direct dependencies are specified by including special buildlink3.mk files. These files have a default version specification in them, so that a reasonable value is kept somewhere centralized. For example, in the current tree, when you include glib2's buildlink3.mk file, you get a dependency such as glib2>=2.6.1. So far so good.

May 21, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Recent pkgsrc changes

Eww, it has been a very long while since I wrote the previous post, and even more since I did any serious changes in pkgsrc. Real life tasks get in the middle and take too much time (fortunately, this stressful period is about to end). However, during the last few days, I've been able to work a bit on pkgsrc, so I'd like to comment the changes I've done. First of all, GNOME has been brought up to 2.10.1, the latest stable release in the 2.10 branch. It should fix many bugs — specially one that has been bothering me a lot in Epiphany, as it failed to automatically open files after their download. Note this has been possible, mainly, due to all the updates Matthias Drochner has done; otherwise, I wouldn't have had the time to do everything at the moment.

May 20, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.10.0 hits pkgsrc

After more than a week of work, I've finally updated the GNOME packages in pkgsrc to the latest and newest stable version; that is, 2.10.0. You can read more information in the announcement e-mail I sent to the tech-pkg list.

March 22, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

pkg-config: Mixed state in some libraries

A reply to my previous pkg-config introductory post outlined a real "problem" with "mixed-state" packages. These packages provide pkg-config metadata files in some situations; i.e., not always. This is a quite common situation in libraries that did not use pkg-config in the past, but have been recently converted to do so. Some examples are OpenSSL or the X libraries (which are being converted to the GNU toolchain by Freedesktop.org). But why is this a problem? Basically because software developers are not aware of this and simply look for the pkg-config metadata files. E.g., when they need OpenSSL, they simply ask for the openssl.pc file through pkg-config; in case of failure, they assume the library is not there, but this assumption can be perfectly wrong. When this happens, those programs should also check for the libraries in a direct manner, bypassing pkg-config.

March 15, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.10.0 released

The GNOME Project has just released the 2.10.0 version of its Desktop Environment. This is a new major release of the 2.x branch, which is source and binary compatible with all previous versions in the 2.x series. Aside lots of fixes, improved translations and code cleanups, which are typical in minor releases, this one includes several new features and utilities designed to make your desktop experience better than ever. You can see a summary of changes here, and in case you are impatient to see it working, just download and try the live cd.

March 9, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

pkgsrc: Yesterday's changes

It has been a while since I've done any "big" changes in pkgsrc, basically because I've been quite busy with VCS Made Easy during the past month. To make things worse, I've got back to university and there is a lot of work to do. But anyway, yesterday I was able to finish two major changes I had going on. The first one was the update of GNOME to 2.8.3, which was released past Wednesday. This version features several bug fixes and minor improvements, as you can expect from any minor release. Hopefully, 2.10 will be released in less than three weeks; but that will require a lot more of work.

February 27, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME Panel easter eggs

Today I reinstalled GNOME from scratch on my machine due to a mistake I made yesterday (which blew away half of it). After starting it, I saw a problem I had never noticed before. I have been able to solve it, although I haven't figured which is the root cause yet. Anyway, while looking for where the problem was, I discovered three easter eggs in the GNOME Panel module. If you don't like spoilers, stop reading now.

January 26, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Tracking down a deadlock

Yesterday's night, I packaged Vino, a VNC server that integrates seamlessly with GNOME. After creating the package, I ran vino-preferences and saw it crash with the following assertion: assertion "next != 0" failed: file "/home/jmmv/NetBSD/src/lib/libpthread/pthread_run.c", line 130, function "pthread__next" Hmm, threading problems... so I started looking at Vino's code to see where the problem could be. Saw it was using threads, but it was not after half an hour or so until I noticed that they were disabled by default. Oh, well. Then I wondered "what? threading problems and the program is not using them?".

January 5, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 3 minutes)

Epiphany's scrolling

For a long time, I've been believing that Epiphany, the GNOME web browser, was broken when installed through pkgsrc. And I was starting to hate it. The problem I had was that trying to scroll the page using the keyboard resulted in a cursor moving around the document, instead of scrolling the whole page. Believe me, extremely annoying behavior, since it jumped across columns unexpectedly. My diagnostic was that I had hit some kind of compatibility problem between Epiphany and the version of Mozilla I had installed through the mozilla-gtk2 package. This belief was increased this morning when I noticed that the configuration script was not finding some header files properly. I reviewed it and fixed some problems, but the problem did not disappear.

January 4, 2005 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Latest releases and news

These days, I'm very busy working with a friend in a game which we have to have "finished" by next Friday (it's university work). Basically, it is a three-dimensional Pacman with multi-player support, licensed under the GPL and written in C++. It will be released on Sourceforge.net in a while, so keep tuned ;) Anyway, the purpose of this message is to publish some recent news, as I had no time during the week to do so:

December 11, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Good user interfaces

First of all, let me apologize for not posting in several days. Unfortunately, this situation will continue as my time is quite limited because of university stuff... Anyway, to the point of this post. A few days ago I found an interesting article that talks about free software and good user interfaces; you can read it here. It starts giving a summary of what a good UI should be, why free software can design good interfaces (comparing UI design to code design) and whether commercial companies help or hurt this process.

November 6, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.8.1 released

The 2.8.1 version of the GNOME Desktop has been released today. This is the first minor release of the 2.8 branch, providing lots of bug fixes and minor improvements, such as new and updated translations. 2.8.2 will be published next month, if everything goes well. Time to start working in the update of the packages in pkgsrc ;-)

October 26, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

Portability: unsetenv('FOO') vs. putenv('FOO')

(This happened last Friday, but I've had not enough time to write about it.) After fixing the Evolution Data Server crashes (let's call it E-D-S for simplicity), I noticed a strange problem caused by it. The GNOME Clock applet showed the right local time before it was clicked, but, after the calendar was shown (by clicking on the text), the time got changed to UTC and there was no way to reverse it (other than killing the applet).

October 25, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 3 minutes)

The libexec and libdata directories

Some time ago, a Linux-guy asked me what the libexec and libdata directories present on a BSD system (placed under /, /usr, or other top-level hierarchies) are, because he had never seen them before in his Linux box. So here is a detailed explanation. libexec is a directory that contains daemons and utilities that can't be used directly by the user. Simply put, they rely on other programs to launch them. For example:

October 24, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Fixing Evolution Data Server crashes

Yesterday, I packaged evolution-webcal (which was a trivial task), but, as I expected, it didn't work. In fact, I realised that neither the contacts view nor the calendar view of Evolution 2.0 were working at all. I could see the components, but I couldn't interact with them. So I started to debug the problem. In the console, there were several warnings printed out by Evolution that told it couldn't activate some bonobo component coming from Evolution Data Server. Uhm... ok; I searched through the code for that message, noted which function it was in and launched Evolution through gdb, adding a breakpoint in that function.

October 20, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 4 minutes)

FAM and kqueue

The File Alteration Monitor, or FAM for short, is an utility that monitors changes made to files and directories and delivers asynchronous notifications to applications interested in them. GNOME uses it to keep Nautilus windows in sync with the on-disk contents, among other uses. For example, if you have your home folder open, and you do touch ~/foo from a terminal, you can see how the folder immediately updates its status to show the new file.

October 17, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 3 minutes)

The AM_GCONF_SOURCE_2 macro

GConf comes with an m4 file to ease its usage from third party configure scripts; it provides a macro, known as AM_GCONF_SOURCE_2, which provides many features (and most importantly, encapsulates all GConf related stuff). Among these, it is used to determine the directory where .schemas files should be installed, a setting that can be fine-tuned by the end user through the --with-gconf-schema-file-dir argument. However, many configure scripts use this macro incorrectly. That is, they call it from the configure script to detect the presence of gconftool-2, but later, in Makefile.am files, they don't use the variables defined by the macro.

October 1, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.8.0 hits pkgsrc

After more than two weeks of work, I've been able to commit to the pkgsrc tree all the required changes to bring the GNOME Desktop to its 2.8.0 version. The update has resulted in 73 new entries added to the doc/CHANGES file; of these, 2 are new packages, 70 are package updates and 1 is a removal of a meta package. Quite a bit, eh? ;-) Unfortunately, not all the official components that form the GNOME Desktop are in pkgsrc yet; these include gnome-nettool, gnome-system-tools, gnome-volume-manager, gnomemeeting, vino, ximian-connector and evolution-webcal. This is because I have had not enough time to work on them, and I expect they'll carry multiple portability issues. If you want to help, there's always pkgsrc-wip where you can add any of these missing packages!

September 21, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

GNOME 2.8 published

According to the release schedule, the GNOME Project is pleased to announce the 2.8 version of its GNOME Desktop. You can find the official annoucement here, as well as the discussion in FootNotes. I've been using the first release candidate (2.7.92) for around two weeks, and all I can tell is that it's marvelous (well, almost) ;-) Lots of bugs have been fixed, some of them regarding to portability to NetBSD (which I filed). It also has several new features and applications, like Evolution 2.0, Vino or the GNOME System Tools, just to name a few.

September 15, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

To rely or not to rely on the PATH

It is quite common for a program to need to execute other programs at run time. This can be done in two ways: specifying the full path to the binary or relying on the current path. So which approach is correct? It depends on what you are trying to do. If the program you need to execute is not a required dependency of your program, using the path to locate it is correct; however, let the user set up a full path in the configuration file, if applicable, so that he can forget about the path. For example, suppose your program can provide extra functionality if the zip command is installed. As it is optional, you can't know its location at configuration time, so it is safe to use the path.

September 6, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.7.4 released

The GNOME project has just published the 2.7.4 version of its desktop environment. This version is the last one with "big" changes; the branch has now entered the API/ABI freeze and the module and feature freeze. Further versions will not include new features; just new translations, fixes and general polishment. Check the 2.7 start page for more information.

July 24, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

My solution for the 'shared directories' problem

The previous post explained a problem in pkgviews WRT directories used by a program where other packages can install files; the most typical example are directories holding plugins. It also outlined two possible solutions, or better said, workarounds. I'll explain my solution here, which is already implemented but waiting for approval. The idea is to "configure" programs at run time to let them access the view from where they are executed. This is very easy to do: we just have to patch all programs that have this problem so that they use a global environment variable, say PKG_VIEWBASE, that points to the root directory of the view being used. Picking the XMMS example again, the program could be modified to search for its input plugins from ${PKG_VIEWBASE}/lib/Input, falling back to its depot directory if the variable is not set.

July 14, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

GNOME 2.6.2 released

The GNOME Project has just released the 2.6.2 version of its desktop environment, probably the last release of the 2.6 stable branch. The official announcement provides more information, including a list of changes since the previous version. Furthermore, I've just updated all the GNOME packages in pkgsrc to their respective versions in this new release. That is, you can easily install GNOME 2.6.2 with the simple cd pkgsrc/meta-pkgs/gnome && make install command... and on multiple platforms! This may be a good reason to try this excellent package system today ;-)

June 28, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 1 minute)

Helping pkgsrc (through pkgsrc-wip)

I suggested you yesterday to contribute to a free software project. I know choosing one can be difficult, so this post is to give you a suggestion: help the pkgsrc project. pkgsrc is The NetBSD Packages Collection. Despite its name, it works on many other operating systems, like Linux, Solaris or MacOS X, to name some. pkgsrc provides a package tree from where you can install any kind of program. It takes care to download the sources, configure and build them and install the results. It also handles all required dependencies. To start using pkgsrc, you must get a copy of the package tree and learn how to use it. The pkgsrc manual contains all this information, and the website (linked above) provides a summary of what's needed to get started.

June 24, 2004 · Tags: <a href="/tags/gnome">gnome</a>
Continue reading (about 2 minutes)

Posts: Gnome

Featured software

Featured posts