Showing 46 posts
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.
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.
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.
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.
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.
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!
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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:
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.
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 ;-)
(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).
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.