Gentoo on SWiK

Davide Italiano: Feeling bad

Tue, 19 Aug 2008 18:59:14 -0700

We suck. Gentoo sucks. Really.
We (300 devs) aren’t able to implement features that 10 developers implemented in a year.
Gentoo Council can’t make decisions.
Gentoo/Freebsd and Gentoo/Irix (Gentoo/Alt in general) aren’t projects from what users will benefit.
Portage is a mess of spaghetti procedural code with no underlying design (and be careful, –jobs will surely break your system).
Gento developers are trying to hide other devs work.
And every gentoo dev is a lier. Because gentoo itself and its features don’t exist. They’re only in your mind. Or in an island in the pacific sea. With Jim Morrison and the Area 51 aliens. And me probably.

I’m depressed. I’m depressed of seeing things like this.
This isn’t the way to stop the “war” and the fud. IMHO.

Daniel Drake: Followup notes on XO alternate desktops

Tue, 19 Aug 2008 06:57:59 -0700

Some followup notes from our alternate Linux desktop on XO work:

The README included with the script provides some more specific instructions.
Your SD card needs to be a minimum of 4GB capacity, because these distributions install more than 2GB by default. We could probably find some smaller distributions, although we require some relatively recent components for some part of the system (e.g. X), so finding a distribution that is both modern and small might be a challenge.
There are ongoing efforts to create a significantly smaller distro to run on the internal flash, but that is an early project at the moment.
We heavily recommend using a SD card that is advertised as fast, extreme, ultimate, or whatever! I was previously sceptical of cards advertised in this way - are they actually significantly faster? The answer is YES - we have a ‘non-extreme’ Kingston card and it is so much slower than the others. Installation took 4 times as long. I’m not sure a good way of benchmarking these, the standard “hdparm -t” test showed similar figures on both slow and fast cards.
I’ve spent most of my time with Fedora. On the whole, it works very well for a machine that is understandably lower spec than most. I do recommend slimming down the services though - turn off all the NFS daemons, cups, bluetooth daemon, pcscd, kerneloops, … In fedora this is done with the ’service’ command for a one-time stop, and ‘chkconfig’ to prevent things starting at boot.
When you run a lot of big applications, the machine does really slow down. Sometimes the mouse cursor freezes for a while. Perhaps we should experiment with swap space, currently I have none.
Sound does not work. In Fedora, it doesn’t work at all, probably a PulseAudio bug. I’m hoping that applying the system updates will fix this, but the Fedora infrastructure is down at the moment. In Ubuntu, sound works at the login screen (you hear the welcome sound) but not after you login.
On the postive side: wireless works, suspend works (most of the time), mouse and keyboard are good, gnome-power-manager dims the screen when idle, etc. It really acts as a normal fully usable distro with a few quirks identified above.

Gentoo Linux Documentation -- The Xfce Configuration Guide

Tue, 19 Aug 2008 05:51:26 -0700

Daniel Drake: Regular Linux desktops on the XO

Mon, 18 Aug 2008 22:09:35 -0700

Me and Bobby Powers have spent a few hours smoothing out the process of getting fully-featured Linux desktops to boot on the XO laptop. On the whole, OLPC developers have been pretty good at getting code upstream, so only a few fixups are needed to get things operational on the XO.

The only caveat is that you need a 4GB (or larger) SD card. The XO itself only has 1GB of storage, which is not big enough for the standard installs of the distributions that we’ve been playing with.

We’ve got Fedora 9 and Ubuntu Intrepid Alpha 3 working. Here is the process, using Fedora 9 as an example:

First, download the regular CD/DVD installation media for your distribution. For Fedora 9, you go to http://fedoraproject.org/en/get-fedora. Burn that to CD/DVD.

Next, find a regular PC that is capable of reading SD cards. We’re using a standard desktop plus a USB card reader. Boot that PC from the CD/DVD installation media that you burned earlier. Proceed through the installation as usual, but when asked where you would like to install the operating system, select the SD card.

Choose to setup the disk partitions manually. Do not do any fancy partitioning, just choose one partition that fills up the card. You don’t need to add any swap space.

Select the ext3 filesystem and choose to not install a bootloader.

Wait for installation to complete, and shut down the system.

Next, you need a PC running Linux. This can be the same PC as the one you used to install onto SD, assuming that one has Linux installed on it’s hard disk too. It doesn’t really matter which distribution, as long as you have git and regular development tools installed, and the SD card mounted at a known location.

On this PC, run the following:

# git clone git://dev.laptop.org/users/dsd/XO-alt-distro

Next, become root and run the script.

# sudo su -
# cd ~dsd/XO-alt-distro
# ./sd_fixup fedora-9 /media/disk

It will now download and compile the OLPC kernel, and perform a few other necessary tweaks to your SD card.

When the script has completed, unmount the SD card and plug it into an XO. Boot the XO, and say hello to your fully-functional Linux desktop.

In future, we plan to publish filesystem images of SD-installed distributions, so that you can avoid much of the above. To simplify further, we could also write a tool which runs on the XO which downloads said filesystem image and flashes onto SD.

Update 19/08/2008: Posted some additional notes

Remi Cardona: Intel driver update

Mon, 18 Aug 2008 16:09:23 -0700

Hi all,

Just a quick update to let you know that I've just put x11-drivers/xf86-video-i810-2.4.1 to Portage.

Overall, I'm not very happy with this release. It's definitely not as smooth as 2.3.2 which turned out to be very solid. So please test it out with a recent xorg-server (read, 1.4.2) and let me know in bugzilla if anything breaks.

Again, be prepared to continue the bug hunt in FreeDesktop's bugzilla as my Intel Powers (tm) are very limited. It just so happens that half a dozen Intel developers also roam there, so all in all, it's a good place to file bugs. Just add "remi at gentoo dot org" as a CC on those bugs so I can keep track of the issues.

Thanks

Diego Pettenò: Same-ABI and any-ABI dependencies

Mon, 18 Aug 2008 13:09:29 -0700

Two really-desired features of Portage, that are important for, respectively, desktop and embedded use cases, are multilib and cross-compilation. Both of these, to be properly implemented, require Portage to discern between same-ABI and any-ABI dependencies.

This concept has been called in the past Linked-in and Executed dependencies, but I don’t like that name at all as it makes sense only for those who actually know what the two concept expects. Actually, I don’t like this name either because it confuses the term ABI as the calling convention of an architecture, and the term ABI as the compiled interface of a software library. If anybody can make sure we find a simple term for the calling convention type of ABI, it would be quite nice in my opionion.

Another good reason to get rid of the terms Linked-in and Executed dependencies is that abstracting well enough the concept, one can easily see the same code and mechanisms to be used to describe the dependencies of extension modules like Python’s and Ruby’s, that depend on the version of the interpreter they are built and ran against.

With good enough support, this would allow to handle dependencies for multiple Python and Ruby versions at once without needing strange and silly hacks like the ones present in the ruby eclasses. And would have solved the problem of PHP extension versions that caused to split them in dev-php4 and dev-php5.

Why is this distinction needed for both multilib and crosscompile? Well, let’s start with the multilib case, and see how it works.

Let’s say you want to install mozilla-firefox-bin, which is 32-bit. It will require a series of libraries built 32-bit like GTK+ and similar, but it will also require the launcher script. That launcher script does not need to be built with 32-bit ABI, as it does not interface directly with Firefox. The libraries will be a same-ABI dependencies, while the script will be an any-ABI dependency.

Even better, the script, being a script, could be declared to not have an absolute ABI, something alike RPM’s “noarch”. This would make it much easier to handle dependencies on data packages (icons, documentation, scripts).

But any-ABI dependencies can easily apply to non-scripts, that is binary packages. Let’s take for instance CUPS and the software that Canon makes available for Pixma printers. The software is only available for 32-bit systems, as it relies on some binary files that Canon does not give the sources of. On the other hand, it does not interface with CUPS through library calls, it’s instead a filter that gets executed to convert the PostScript data coming from CUPS to a format that the printer will understand. The Pixma software would then have an any-ABI dependency on CUPS, and a same-ABI dependency on the libraries it links to, like GTK+.

On cross-compiled environments, this merged with the ROOT variable support would make it much easier to build a system’s root with the minimal amount of software needed, and would solve the problem related to Perl’s cross-compiling.

A few packages need autoconf to be present in the system, but none of them need anything more than being able to execut them. When cross-compiling, there is no need to have a copy of autoconf built for the ABI of the system you’re building, you just need a copy of it that you can execute. This makes it an any-ABI dependency. Not asking a CHOST-built autoconf, Portage won’t be asking for a CHOST-built Perl either, and that would save you the headache, because Perl cannot be cross-compiled.

This of course will require a lot of changes, especially EAPI related, and finding a new, decently good syntax, for ABI-specific dependencies. In particular, there are a few issues that needs to be addressed before one can even think of implementing this:

there has to be a way for profiles to tell Portage the ABIs a system can handle; an amd64 multilib profile will advertise support for x86_64 and x86 ABIs for instance, an x86 Gentoo/FreeBSD profile would advertise support for x86/FreeBSD and x86/Linux ABIs (through the Linux compatibility layer);
there has to be a way to let packages inject further ABI specifications, like I said above, Ruby and Python are two perfect examples; a system that has Ruby 1.8 and Ruby 1.9 installed, will advertise support for both ABIs, while a system with just Python 2.5 will advertise that single ABI;
cross-compiling still would require some work, maybe a replacement for crossdev could use a prefix like cross- or something like that, it would need someway to express cross-compiling tools and libraries versus cross-compiled tools and libraries;
by default, the packages should be available on any native ABI, maybe a meta-ABI “native” would allow to say “whichever ABI the profile accept”; it could somehow cross-over with the meaning of KEYWORDS, especially for cross-compiled environments;
different ABIs will have different paths for installation: on amd64 multilib systems, the 32-bit libraries are currently installed by the 64-bit sides on /lib32 directories, while the binaries are mixed in /bin; on a Gentoo/FreeBSD system, you most likely want to install everything prefixed in a /linux directory, while for cross-compiling support, you’d install in the SYSROOT (/usr/$CHOST prefix); as you can guess, here it would be very nice to import at least part of the extensions the Prefix project have to allow handling rbitrary prefixes; it might not need further enhancements to support Solaris and the rest (but I could write something about that), but at least it would work to have support for the arbitrary prefix in tree.

There are probably a tons other problems, and I have no clear idea on how this should be implemented as it is, but at least this could be a starting point for some discussion in this sense, and maybe Zack or Marius might catch on this and start prototyping some interaction.

TIP Postfix Setup for Local Mail Only - Gentoo Linux Wiki

Mon, 18 Aug 2008 05:06:10 -0700

Образ диска QEMU c Gentoo Linux - Форум разработчиков электроники - Electronics developers forum

Sun, 17 Aug 2008 07:05:33 -0700

Gentoo Lisp Project

Sun, 17 Aug 2008 02:05:15 -0700

Himerge

Sun, 17 Aug 2008 00:08:34 -0700

Haskell Graphical Interface for Emerge (Gentoo Portage system).

Steve Dibb: mplayer + dvdnav + dvdread svn ebuilds

Fri, 15 Aug 2008 21:07:33 -0700

I updated the mplayer and dvdnav ebuilds in my small overlay, and added one for dvdread now, which has been split into a separate package. I haven’t had time in the past while to keep an eye on what’s been going on, but I do know that the heavy flurry of development has stopped, and that the installer works better. Plus, the software works fine for me.

My overlay isn’t in layman right now, so if you want to check it out, here’s the skinny:

svn co http://overlays.gentoo.org/svn/dev/beandog/

Have fun and lemme know if there’s any problems.

Tobias Klausmann: Other pursuits

Fri, 15 Aug 2008 13:08:52 -0700

Some have wondered what I've been up to lately. What with no blog posts and all. Well, I've acquired some hardware that is on the expensive side and tends to consume larger amounts of time. Here's a picture:

Aside of that I've been busy doing some benchmarking and comparison of version control systems with an eye on replacing CVS for the Gentoo portage tree. It's not an easy matter to bench and time consuming even for the mere benchmarks themselves. I want to get this a s right as possible, so I'm taking my time.

Oh, and I ride that motorbike a lot :)

Sune Kloppenborg Jeppesen: Iwlwifi problems with 3945

Fri, 15 Aug 2008 11:07:26 -0700

I'm now back from a long period abroad on vacation and work.

Since my ARP issue I've experienced further problems with iwlwifi. Fresh after a reboot I have no problems but shortly after starting any large download, download speed will drop to around 100kb/s. It was both an issue with iwlwifi-1.2.3, hardened-sources-2.6.24-r3 and 2.6.25-r3. It seems like several other people are experiencing this in one form or another. Similar issues with ipw3945 have been reported here, here and here.

For now I've simply plugged in my good old Atheros AR5212 802.11abg NIC and configured Madwifi.

WPA performance is still way below maximum speed but it'll do until the new OpenWRT Kamikaze release later this month.

*SIGH* Now I'm again able to trigger some Kamikaze bug that cause the WRT54G box to reboot under high trafic. I really do look forward to the new Kamikaze release :)

Update: My card is a 3945 and I'm using latest iwl3945ucode-2.14.1.5 in portage.

HOWTO Lightweight package selection (using Xfce and suitable for office usage) - Gentoo Linux Wiki

Mon, 11 Aug 2008 07:05:28 -0700

102/365 - August 14, 2008

Thu, 14 Aug 2008 18:07:52 -0700

meddygarnet posted a photo:

For FGR - NERD

To explain this a little bit, I'm compiling an update of QT for our Gentoo installation.

Documentation Gentoo -- Mise en place d'un système de messagerie multidomaine avec postfix

Wed, 13 Aug 2008 18:05:01 -0700

mysql imap libwww maildir sasl ssl

Diego Pettenò: Yamato on its way

Wed, 13 Aug 2008 14:08:46 -0700

Today I ordered the new box, that, as I said, is called Yamato. I’ll get on the reason for this particular name in a little :)

I got the money available with a short term loan; thanks to everybody who has (and might) chip in, in order (up to now) Raimund, Anton, Federico, William, Jürgen, Jim and Marcel, if I didn’t have at least some availability it wouldn’t have been possible for me to place the order.

So, what are the specs of the famous “expensive” computer? (at least for US standards) Two Opteron 2350 (Barcelona), Tyan Thunder n3600B motherboard, 16 GB of registered RAM, cheap-o-graphics X1550 video card (there is an embedded XGI but afaict it does not support dual DVI which is a requirement for me—the only one basically), a chassis, the cheapest black DVD burner, and a decent Active PFC PSU.

My original plan included a 3Ware hardware RAID card and 3×500GB Seagate HDs, which costed around €700 by themselves. But then, I can consider that in the future. As for why not using software RAID, well, I’ve been told to not rely on that at all. Actually, the motherboard I have should support “firwmare-based” RAID5, but even that. Who knows, at any rate I can consider the rest in the future, when I got a job to pay for that, rather than having to ask.

New disks or not, the idea for Yamato was for me to use the system installed in Enterprise as a basis, and going on with that, that’s why the name. The USS Yamato was, in Star Trek TNG, the twin sister starship of the flagship USS Enterprise, Galaxy class. The new box would have had a system cloned from Enterprise; in this case it will have the same system as I’ll be using the same disks.

The only thing will have to reconfigure the kernel from scratch as the only thing to remain the same will be the architecture (but the one I have now is just an UP kernel), the network card that is still Marvell, and the two cards that I’ll be importing from Enterprise (WiFi and Sound), and of course changing all the references to “enterprise”.

I hope my wire transfer will be received by Friday (SEPA transfer), so that the order can be shipped on Monday. I didn’t get the express shipment, as it would have costed €100 more alone, and I’m relying on standard UPS taking from three to four days usually. If I’m lucky, by the 22nd I’ll have the package here, and in the night Yamato should be up. It would be perfect because I’ll probably be in the hospital starting the 25th, and if Yamato is already up and running, I can coordinate its work from there too.

But my development work is not entirely stopped, so more posts will follow about topics I hinted at in the past weeks.

Diego Pettenò: What did Enterprise do?

Wed, 13 Aug 2008 05:07:33 -0700

Now that enterprise died, I am pointing toward a high-end system. I can understand it is difficult to accept that I don’t just get the cheapest box I can find at the local store, and be done with it.

Why is this? Well the first problem is that in Italy, prices are something very strange. It’s not unexpected for me to find components at half the price, or less, when looking them up in other European shops. In particular, in the local shops a good enough PSU rated 450W like the one I had before would cost me €140. Consider I paid mine €100 two years ago. I could get it from Germany paying less for it, included shipping, that I would get it from Italy, but, I’m not sure it’s the PSU itself, I don’t count on it. Why? Because there is a burning plastic smell when Enterprise is on, and it does not come from the PSU.

So rather than getting a new PSU, waiting to see if it’s the motherboard, or the CPU, or the memory, and then get one of those at a time, paying multiple time the shipment, I’m keen on replacing the box entirely. I was actually already planning on the update, the problem here is the timing: if it wasn’t happening while my health is in this status, I would have had enough availability to just replace Enterprise straight away.

But why am I spending €1300 on a system rather than spending, say, $600 to get the cheapest Intel quadcore available? First is, I don’t think I can get much for such a price, US prices are quite lower, even considering taxes, than the prices in Italy. I checked out newegg before, and the prices were almost half the prices on European shops, so it means a quarter of the prices of Italian suppliers. Unfortunately they don’t ship overseas. Of course I could just get it sent to me through some loophole, but again: getting it through customs would cost me between 40-50% of the nominal price shipment costs included, and it’d be impossible to get warranty out of it. And it’s not very good for most consumer-grade hardware, not having warranty.

On the other hand, a cheap Intel quadcore with a decent amount of memory could work well as a workstaiton, the problem is that Enterprise has never been your usual workstation.

Enterprise not only worked as my workstation, and used to be my media center, but most of all, it’s a development box. I’m not just rebuilding projects I work on, but I’m rebuilding many times the whole of portage. When I updated first to GCC 4.3, the first thing I did was rebuilding world; when glibc 2.8 was released, I rebuilt world; when a new autoconf or automake version is released, I rebuild world. Why? Because I can usually fix or at least give a good indication how to fix those problems.

The faster these rebuild are, the faster I can fix the problem, the faster they enter portage, usually. But it’s not just that.

For instance, Enterprise had a massively more aggressive --as-needed support: I force it through GCC specs. The result is that it stressed out linking, working around libtool brokenness and similar issues.

But this could warrant a multicore system, why going high end? Well, together with the standard system in /, Enterprise had a series of chroots, one handles the updates for the vserver where my blog is (but also xine’s Bugzilla, which is something useful for F/OSS, not just me), others handle corner-cases tests. Those are the ones building for instance a system with OpenPAM instead of Linux-PAM to see which parts of portage can work with it. Or testing cowstats with PIE enabled, to find programs that relay on the fact that they don’t need data relocations outside shared libraries.

It’s kinda like a tinderbox but it isn’t a tinderbox. It was a system that was almost never idling.

And, one thing I haven’t done, or improved in a few months, to be honest, is working on the linking collisions detection. The reason why I stopped doing that is that even using postgresql it takes a long time. And it wasn’t specifically testing for possibly embedded libraries yet.

While I do like devoting my time to Free Software development, a faster box means I can make better use of my time, which, considering my health problems, is probably a good thing (doing the same stuff in less time means I have more time to spend on other things, like going in and out of hospitals, or relaxing if I don’t feel good enough). Maybe I’m selfish but I’d rather spend money on a fast system with users’ help, than spending little money on a cheap system, and being forced to work less on Free Software so that I can handle hospitals and relax time.

So, thanks to all the users helping me with this, I’m doing my best to try securing the money for ordering the box ASAP so I can let it resume its tasks while I’m in the hospital too. And as soon as my health stops the downslide, I’ll be working on Free Software again.

TracNginxRecipe – The Trac Project – Trac

Tue, 12 Aug 2008 15:05:02 -0700

Diego Pettenò: Enterprise down...

Tue, 12 Aug 2008 02:07:18 -0700

So today I woke up to find a nasty surprise. At almost an exact year since my first hospitalisation (the year will be this night), Enterprise died.

I think it might just be the PSU giving up, as it does not turn on even the led light on the mainboard, but at this point, I’d say “who knows?”. My mother seen a “flash of light”, heard a BIIP from the UPS, and the computer turned off. I cannot turn it back on.

The UPS did likely cut the whole power as the external HD also was turned off when I woke up, but the HD itself is fine. the UPS is also charged, so that’s not it.

It’s the worst timing ever for my computer to break down. Not only I have my SSH key for the vserver on it (I can get it out probably, but that’s beside the point), but I also cannot do my job without that. Okay, it was planned already that I wouldn’t be working until after surgery, but it’s a bit of a problem if I cannot replace Enterprise in the mean time.

I was already planning on a replacement (which will obviously be called Yamato), and I have a components list I can look at right now, from Alternate (K&M does not carry Opterons, nor I can find those in Italy). The problem is that it’s around €2K.

So if anybody is willing to help me gathering the money, I’d be certainly happy, as I won’t be able to do work until middle of september, if not even later, and without Enterprise, I cannot do any kind of F/LOSS work, that means no Gentoo, no xine, no optimisation of smaller projects. If I can get the money, I’d be doing even more work on that as it will take very little time to run the build on Yamato.

Sorry for the request, but this really looks to me like an emergency, as it happened at the very worst time :/

Update: cutting out the hardware RAID 5 support I can get the price down to €1300 which is much more feasible.

Gentoo Linux Documentation -- Virtual Mailhosting System with Postfix Guide

Mon, 11 Aug 2008 11:04:45 -0700

Diego Pettenò: Improving autotools-based buildsystems

Sun, 10 Aug 2008 11:04:46 -0700

When I’m composing this blog post (a few days in advance of its publication), I just took a little forced break (because I’m missing some tool I can’t find) from hacking at autotools buildsystems.

In particular, I’m hacking at Lennart’s projects, mostly because I bumped libasyncns and noticed I could make the ebuild simpler if I changed a few things in there.

My target with this hacking session is to update the build systems to the latest version of autoconf (2.62), making use of some new features that can make it easier to handle the packages during ebuilds. I’ll be discussing here some of the changes because, first, I know Lennart won’t mind if I dissect his autotools-fu ;) and second because it makes a nice “documentation” to show how to properly use autotools. If you want to check the changes I actually made, you can find all the repositories on my git server ; Lennart’s projects are the ones under 0pointer directory.

The first feature I wanted to make use of was the presence of htmldir and docdir variables in the newer versions of autoconf (2.60 and later, if I recall correctly, certainly not 2.59). These two variables allow to declare in Makefile.am some files as text or HTML documentation, letting the user (or the ebuild) choose where to install those through --docdir and --htmldir options at ./configure. This is what allows me to skip dodoc and dohtml commands in the ebuild, as the build system will take care of installing everything.

Another useful feature of the newest versions is that the AC_HEADER_ASSERT macro now provides a --disable-assert option that can be used to disable the assert() function calls in software without having to add manually -DNDEBUG to your flags. Unfortunately this does not work perfectly as it expects that every source file includes config.h before any other include (the same requirement exists for AC_SYS_LARGEFILE for what it’s worth), but luckily Lennart’s projects are well written. Not all projects support disabling assert(), even though it’s supposed to be just a debug facility, a few projects don’t take extra measures ot make sure the code continue working fine and safe without them.

But there are more things I changed, to improve the readability, and not only of autotools. For instance I replaced the custom CFLAGS testing code with code that uses CC_CHECK_CFLAGS macro, which is available in the attributes.m4 macro file available on xine-lib’s repository (that macro file was originally developed by me for unieject and has been now copied over multiple projects.. I always try to keep it in sync). This makes it possible to cache the result of the tests on availability of CFLAGS, and allows for new compilers, supporting a GCC-like commandline, to work out of the box. Similarly, C99 language checks are replaced with AC_PROG_CC_C99 that takes care of discovering how the compiler supports C99.

More tied to Lennart’s code is the creation of a ZP_LYNX_DOC macro, in its own macro file, instead of adding on all the configure.ac files the code to handle --disable-lynx and the conditional. It is very useful to factor out these common pieces of code in their own macros, as it allows to just copy a file over when you need to fix them, or improve them, rather than having to cut copy and paste code, with the risk of making bigger mistakes.

And a suggestion for those of you who want to test an autotooled package out of git or another development repository: if it’s possible, use autoreconf -is instead of the standard autoreconf. This avoids copying over the macro and support files from /usr/share to your work directory, symlinking them instead. This reduces disk occupation and should also be faster to re-generate.

Unfortunately for now autoreconf does not seem to support extra extensions to autotools, like intltool or gtkdoc and you have thus to choose between executing them by hand, or using the bootstrap scripts that the developers provided (which is bad in ebuilds).

What autoreconf should be is a standardised bootstrapping script that takes care of using the right tools with the right options for one’s project. Unfortunately with the existance of tools like intltool and similar, that extend the basic autotools syntax, and don’t seem to be “accepted” by upstream, it starts to become overly useless. I suppose an option would be to create a generic, installable, autoreconf-syntax semi-compatible script that could be used instead of the various custom bootstrap and autogen scripts for the projects.

Anybody with some free time to start hacking at that? :)

Diego Pettenò: Autotools, targets and hosts

Sun, 10 Aug 2008 11:04:46 -0700

Following my posts about autotools improvements, I’d like to write a short post about another quite often misused macro provided by autoconf, that I had to fix in lscube too.

The macro in question is AC_CANONICAL_TARGET, which is used to provide the --host/--build and --target options to ./configure. What is the problem with that macro? Well in most cases you don’t want it at all, and you want to use, if anything, AC_CANONICAL_HOST (which is not even needed, for most cases) that only provides --host and --build options.

Why is this? Well, the problem is that the --target option is used only for compilers and other tools generating machine-dependent code. The meaning of the three names are as follows:

the build machine is where you’re compiling the code (that is, building the source); it’s almost impossible that build doesn’t refer to the machine running ./configure;
the host machine is where the project will run once built, when this differs from build, we’re crosscompiling;
the target machine is the machine the software is going to generate code for, if this differs from host you’re building a cross-compiler.

Diego Pettenò: Locales, NLS, kernels and filesystems

Sat, 09 Aug 2008 12:04:51 -0700

One issue that is yet to be solved easily by most distribution (at least those not featuring extensive graphical configuration utilities, like Fedora and Ubuntu do), is most likely localisation.

There is an interesting blog post by Wouter Verhelst on Planet Debian that talks about setting locales variables. It’s a very interesting reading, as it clarifies pretty well the different variables.

One related issue seems to be understanding the meaning of the NLS settings that are available in the kernel configuration for Linux. Some users seem to think that you have to enable the codepages in there to be able to use a certain locale as system locale.

This is not the case, the NLS settings in there are basically only used for filesystems, and in particular only VFAT and NTFS filesystems. The reason of this lies in the fact that both filesystems are case-insensitive.

In usual Unix filesystems, like UFS, EXT2/3/4, XFS, JFS, ReiserFS and so on, file names are case sensitive, and they end up being just a string of arbitrary characters. On VFAT and NTFS, instead, the filenames are case insensitive.

For case sensitivity, you need equivalence tables, and those are defined by different NLS values. For instance, for Western locale, the character ‘i’ and ‘I’ are equivalent, but in Turkish, they are not, as ‘i’ pairs with ‘İ’ and ‘I’ with ‘ı’ (if you wish to get more information about this, I’d refer you to Michael S. Kaplan’s blog on the subject).

So when you need to support VFAT or NTFS, you need to support the right NLS table, or your filesystem will end up corrupted (on Turkish charset, you can have two files called “FAIL” and “fail” as the two letters are not just the same). This is the reason why you find the NLS settings in the filesystems section.

Of course, one could say that HFS+ used by MacOS is also case-insensitive, so NLS settings should apply to that too, no? Well, no. I admit I don’t know much about historical HFS+ filesystems, as I only started using MacOS from version 10.3, but at least since then, the filenames are saved encoded in UTF-8, which has very well defined equivalence tables. So there is no need for option selections, the equivalence table is defined as part of the filesystem itself.

Knowing this, why VFAT does not work properly with UTF-8, as stated by the kernel when you mount it as iocharset=utf-8? The problem is that VFAT works on a per-character equivalence basis, and UTF-8 is a variable-size encoding, which does not suit well VFAT.

Unfortunately, make oldconfig and make xconfig seem to replace, at least on my system, the default charset with UTF-8 every time, maybe because UTF-8 is the system encoding I’m using. I guess I should look up to see if it’s worth to report a bug about this, or if I can fix it myself.

Davide Italiano: Summer gifts

Fri, 08 Aug 2008 13:04:29 -0700

Today is 08/08/08. And this is funny. Seriously. Here there are two gifts for you and some random updates. Before, I want to thank everyone gave me feedback during these days about g/fbsd, mainly on irc. This means that someone read the ugly blagpost I wrote.
However, recently I wrote a short draft about how to install g/fbsd 7.0 on your box. The “guide” is quite similar to 6.2’s one, but some steps were radically changed, so I suggest to use the new one if you want to perform a new install. I want to tell you that this documentation is completely experimental, so there {c,sh}ould be some errors. As for all my work, for this guide feddbacks arre welcome and very appreciated (and also bugreporting).

The guide can be found on my devspace, here .

In addiction, Firefox and mozilla-related stuffs _actually_ doesn’t compile on g/fbsd 7.0. However there’s a quick fix to “solve” this problem. Create a script called /usr/bin/objformat and put in these lines:

#!/bin/bash if echo __ELF__ | cc -E - | grep -q __ELF__ ; then echo aout ; else echo elf ; fi

It’s enough, however there ins’t a proper way to fixx mozilla, and this because the team have to update their Makefiles to guess the object format in a more ‘modern’ way, not using that “freebsd-4″ old thing anymore.

That’s all.
Cheers

dav

Gentoo Linux Documentation -- The Xfce Configuration Guide

Thu, 07 Aug 2008 13:14:42 -0700

Links to Other Free Software Sites - GNU Project - Free Software Foundation (FSF)

Sun, 18 Nov 2007 05:26:01 -0800

stunning list of fsf recommended operating systems (not only *nix!) and 100% floss software/information

Gentoo Linux Documentation -- QuickStart Guide to Mutt E-Mail

Thu, 07 Aug 2008 13:04:23 -0700

Steve Dibb: quick and dirty opendns howto for gentoo (using openrc)

Thu, 07 Aug 2008 09:04:44 -0700

If, like me, you don’t trust your ISP’s nameservers to be patched and working correctly (or for them to sell you out to advertisers by redirecting broken links or whatever), then here’s a quick solution to setting up your box to use OpenDNS servers instead.

Using this assumes three things though:

You don’t have anything in /etc/conf.d/net
You are a DHCP client
You are using sys-apps/openrc

Anything besides that, you’ll just have to figure it out yourself, though the commands should be close. BTW, someone correct me if I’m wrong.

Add this to /etc/conf.d/net:

dhcp_eth0=”nodns”
dns_servers_eth0=”208.67.222.222 208.67.220.220″

If eth0 is not your primary NIC, then you’d have to change that.

Then just restart net.eth0 (/etc/init.d/net.eth0 restart) and you should see this in /etc/resolv.conf:

nameserver 208.67.222.222
nameserver 208.67.220.220

Diego Pettenò: Flags and flags

Thu, 07 Aug 2008 08:05:08 -0700

This post, and probably a few more posts that will come to be, is being written about a day before it’s actually being posted. The reason for this is that, as I’ll be probably be hospitalised at the end of August, I want to have something going on so I don’t need to write during the hospitalisation.

I was reflecting tonight with Mark (Halcy0n) that for having hardened features on GCC 4.x you shouldn’t, in general, need any particular support in the compiler. What hardened would be doing for the modern compilers is creating new “spec files” that tell the compiler which flags to use by default. This would force the compiler to always generate PIE (Position Independent Executable) code and SSP (Stack Smashing Protection).

In general, to have the same features it would be enough to properly set CFLAGS and CXXFLAGS. The idea is that once you put -fPIE in your flags, all the code that Portage built would be PIE, and if you set -fstack-protector in your CFLAGS (and not CXXFLAGS because SSP is known not to cope properly with C++ code), you expect your system to be built with stack protector turned on.

The problem is, reality and theory don’t seem to coincide. The problem is that a huge lot of ebuilds ignore your flags entirely, others strip them, and might strip -fPIE and -fstack-protector, and quite a few mix CFLAGS and CXXFLAGS, using the former to build C++ code and the latter to build C code. The result is that you end up with something different than what you asked for.

Even worse, there are packages that save your CFLAGS in their -config files, letting your custom flags creep into other projects that might not want them.

So the result is that if we want to make it much easier for everybody to enable hardened, we should be making sure that the behaviour of ebuilds is standardised on the policy of respecting the flags set by the user, not filtering them unless really needed, and even then letting most of the non-optimisation flags through. And to actually use the correct variable depending on the language used.

What are the problems? The first is obviously upstreams that don’t want users to use their own flags for building their code (MPlayer, anyone?), then there is at least the problem of broken build systems that either don’t understand the difference between CFLAGS and CXXFLAGS or don’t support custom flags at all.

If you wish to help, there is an easy way to actually find where the flags are mixed up. As the most obvious problem is CFLAGS used for building C++ code (rather than the other way around), you can add -Wno-pointer-sign to your CFLAGS. When the variable is misused, it turns out this error:

cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++

When you see that, it’s time to report it against bug #234011 so that the maintainers know they need to fix something in the build system to keep the two variables separated.

As to how to fix this, on custom build systems it’s difficult to say, on autotools-based systems, the problem might be in the configure.ac, if code similar to this is present:

CFLAGS="${CFLAGS} -DSOMETHING"
CXXFLAGS="${CFLAGS} -DSOMETHING"

An alternative is that the build system is adding to _CXXFLAGS the value of a variable reported by one of the foo-config scripts that are bugged and report the flags used to build the source package rather than just the flags needed to get their include directories right. In that case the bug lies in a different package, and is there that it has to be fixed.

Hopefully, this kind of fixes will become routine and new packages won’t be added to the tree if they mix CFLAGS and CXXFLAGS… I can always dream, can’t I?

But yes this is another point of my checklist when creating an ebuild, if the new ebuild is not needed immediately and upstream fails to understand CFLAGS and CXXFLAGS differences, then I avoid adding it at all. I hope other developers will start considering this, too :)

Oh yeah I’m sorry I’m actually filing bugs now without providing a fix immediately. The reason why I stopped providing fixes right away is that first of all I’m opening a huge amount of bugs when I find them, rather than waiting to have time to debug and fix them, and I have not enough time for myself to take care of that stuff too, and I’d rather explain how to fix them and then see them fixed by the actual maintainers. And also, I think I have bugs with patches still waiting on maintainers, so…