• 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. [Continue reading]

  • 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 ;-) [Continue reading]

  • 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.) [Continue reading]

  • Bikeshed

    Don't know what a "bikeshedded discussion" is? This FAQ from FreeBSD explains it well enough. I like this sentence in special: "the amount of noise generated by a change is inversely proportional to the complexity of the change".It's a pity it happens too often in (Net)BSD mailing lists. [Continue reading]

  • 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. [Continue reading]

  • Fixing xv problems

    As you may already know I bought a BenQ FP202W flat panel two months ago, which made me switch from a rather small resolution (1024x768) to a much bigger one: 1680x1050 at 24bpp running on a NVIDIA GeForce 6600GT with the free nv driver. As I did the switch I lost the ability to play videos in X11 full screen mode because the Xvideo refused to work. As you can imagine, this was extremely annoying.For example, mplayer spit out the following:X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0Similarly, xawtv couldn't set up an overlay window due to the lack of the xv extension thus becoming completely unusable.Based on a suggestion from someone I don't remember, I decided yesterday to replace my XFree86 4.5.0 installation with X.Org 6.9 hoping that its nv driver could work better. Guess what, it didn't.But after the installation, and just out of curiosity, I started looking at nv's sources to see if I could discover the problem. I was hopeless to find a solution but I had to try.First of all, I grepped for BadAlloc in the nv directory, something that quickly drove me to the NVAllocateOverlayMemory function. Based on the name, this seemed like a logic place for the failure. I added some debugging messages, reinstalled the driver and effectively this function was being called and returned a null pointer.Some more printf's told me that the problem was being raised by xf86AllocateOffscreenLinear. "Ouch... looks as if the driver cannot allocate enough video memory for such a big resolution... may be difficult to fix", I though. Nevertheless, I continued my quest inspecting this other function and many other code in xf86fbman.c. Along the process, I discovered a minor, unrelated bug probably caused due to a pasto. Overall, the code is quite confusing if you are X-clueless, just as I am.After a couple of hours or so I was looking at the localAllocateOffscreenLinear function. I saw that the first call to AllocateLinear was returning a null pointer, which made me think that the problem was there, continuing the inspection in that direction. That lead to nowhere.At last, and tired of try & error cycles, I returned to the NVAllocateOverlayMemory function. I saw there that calls to xf86AllocateOffscreenLinear function were passing a 32 value, which seemed like a bpp. "Hmm... if I decrease it to, say, 24, it may need less memory and it might work." And indeed it did! That little change enabled xv again in my machine.But the rationale behind the change was wrong. It happens to be that that parameter is not a bpp; it is a granularity. Therefore I assume that the less its value, the better. Some other greps "confirmed" this, as other drivers such as radeon are using a value of 16 (or even less) for that call.Some time later and with xv working properly, I came back to the localAllocateOffscreenLinear function. This made me see that it was always falling back to the second case (below the "NOPE, ALLOCATING AREA" message). "Stupid me; I should have looked there before." This is part of the function:if(gran && ((gran > pitch) || (pitch % gran))) { /* we can't match the specified alignment with XY allocations */ xfree(link); return NULL;}gran is the granularity passed in by the driver and pitch seems to be the screen's horizontal resolution. So, doing some numbers we see that pitch % gran = 1680 % 32 = 16 != 0. Voila! There it is, the real problem. Well, I think this is the problem, but I may be wrong.After all, it looks like as if the problem was a simple bug rather than something related to the card's memory. You can follow this bug for more information as well as to retrieve the proposed patch.Edit (March 6, 21:38): It turns out my patch was not really correct. For more information just check out the bug's audit trail. [Continue reading]