Tux news - Linux ubuntu fedora gentoo gnome news

Planet Gentoo (20 unread)

Diego Pettenò: PAM authentication for paranoids

Posted: January 5th, 2009, 12:28pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pBefore I resume working on span class=capsPAM/span (I need to implement a change to pam_lastlog to fix a href=https://bugs.gentoo.org/show_bug.cgi?id=244816a pernicious bug/a), I wanted to just write a quick entry for the paranoid of you who still use span class=capsPAM/span for system login./p pSince, as you most likely already know, a href=http://www.win.tue.nl/hashclash/rogue-ca/span class=capsMD5/span is once again considered insecure/a, one obvious concern would be the fact that passwords saved in span class=capsMD5/span on a system are not secure either. For this reason if you’re using Linux-PAM, you can make use of the span class=capsSHA512/span hashing of system password keys, which a href=http://blog.flameeyes.eu/2008/08/05/pam-delays-and-hashesI already wrote about/a./p pRemember that to use that you have to make sure your Linux-PAM (sys-libs/pam) is built against a recent enough version of glibc. Unfortunately the version of pambase with this feature hasn’t hit stable yet, the bug above is blocking it, and I’m going to have to hack at pam_lastlog to fix that./p pWhat I didn’t write last time, is that you can easily spot if your system is using md5 passwords by using this simple command from root:/p div class=typocodeprecode class=typocode_default # fgrep '$1$' /etc/shadow/code/pre/div pOf course one has to access your code/etc/shadow/code file to breach your passwords, so your system has to have been compromised before, but it’s still not nice if they can find out what your basic passwords are./p pMoving on./p /div
Diego Pettenò: For A Parallel World. Case Study n.5: parallel install

Posted: January 3rd, 2009, 9:01pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pAfter a longish time, here for you a new chapter of my widely read series a href=http://blog.flameeyes.eu/tag/foraparallelworldFor A Parallel World/a, improving buildsystems to reduce build time on modern multiprocessor, multicore systems./p pThis time, rather than the usual build failures, I’m going to speak of a parallel install failure. Even though one can think of install as a task that rarely can fall into problems like race conditions and the such, and even though it’s probably the part that gets less boost when using parallel make on a multicore system (since it’s usually I/O bound rather than span class=capsCPU/span bound), it’s actually one very fragile part of many packages./p pOne of the common failures is due to old codeinstall-sh/code script used to simulate the codeinstall/code command on systems too old to have a span class=capsPOSIX/span-compatible one, and which is also used to create directories recursively if codemkdir -p/code is missing. For a series of reason, this hits pretty often on FreeBSD, but this is beside the point. This can be easily solved by replacing the old faulty script with an updated copy out of automake or libtool, which does not have problems at all./p pA few times, the problem is instead due to a broken codeMakefile.am/code. Let’s take a practical example from some software I fixed recently after being called in action by nixnut: a href=https://bugs.gentoo.org/show_bug.cgi?id=249165gramps/a . Please note that if you look at the bug now you’re going to spoil the post, since it contains the solution straight away, while I’m going to explain it step by step./p pLet’s start from the reported build log:/p div class=typocodeprecode class=typocode_default test -z /usr/share/gramps/docgen || /bin/mkdir -p /var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen /usr/bin/install -c -m 644 'gtkprintpreview.glade' '/var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen/gtkprintpreview.glade' /usr/bin/install -c -m 644 'gtkprintpreview.glade' '/var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen/gtkprintpreview.glade' /usr/bin/install: cannot create regular file `/var/tmp/portage/app-misc/gramps-3.0.3/image//usr/share/gramps/docgen/gtkprintpreview.glade': File exists make[3]: *** [install-docgenDATA] Error 1 make[3]: *** Waiting for unfinished jobs..../code/pre/div pAs usual, the first thing we’re looking for when there is a parallel build (or install) failure are repeated commands. As I’ve shown in a href=http://blog.flameeyes.eu/2008/08/29/for-a-parallel-world-case-study-n-2-misknowing-your-make-rulesCase Study n. 2/a, when the same command is repeated multiple times it’s often due to mistakes in the Makefiles, thus before thinking of a problem with the dependencies, I check for that. It’s way more common especially on automake-based build systems./p pSo indeed we can see there are two calls to the codeinstall/code command for the file codegtkprintpreview.glade/code (this also shows us that it’s not a problem of old and faulty install-sh script since the call is directly to the system command). Contrary to what happens when it’s a build rule that is wrongly expressed in the makefile, the double-call during install phase is usually present both using parallel jobs and not. The difference is that when the two calls happen sequentially, the second just overwrites the results of the first; wastes time but it’s successful. On the other hand when parallel jobs are used, the two calls are often enough happening at the same time, and thus we have a race condition./p pOkay so next step as usual is to look at the incriminated Makefile.am:/p div class=typocodeprecode class=typocode_default [snip] docgen_DATA = \ gtkprintpreview.glade dist_docgen_DATA = $(docgen_DATA) [snip]/code/pre/div pHere we’re at the core of the problem. The codegtkprintpreview.glade/code file is part of the sources, and it has to be installed as part of the codedocgen/code class of files (thus in code$docgendir/code). But the data installed in that path is listed twice, once in the codedocgen_DATA/code variable and one in codedist_docgen_DATA/code, causing the file to be installed twice on two independent targets. Since the two targets are independent, when using parallel jobs they both will run at the same time the same command./p pLet me try to explain what the mistake has been. By default the sources are packaged up in the final tarball, if they are not generated by rules from the make process; sometimes you wish files that are built by make to still be distributed, and thus you either have to use codeEXTRA_DIST/code or prefix codedist_/code to the class of the installed files, to explicit that the files have to be distributed. Unfortunately the gramps developers didn’t know automake well enough, and thought that codedist_docgen_DATA/code worked quite a lot like codeEXTRA_DIST/code (maybe it actually used codeEXTRA_DIST/code in the past, for what I know), and thus duplicated the variable content./p pThe solution? Just replace the use of codedocgen_DATA/code with codedist_docgen_DATA/code and remove the second definition, the problem is solved at the source./p /div
Tobias Klausmann: A tale of too many parameters

Posted: January 3rd, 2009, 3:12pm CET by Tobias Klausmann (klausman)

pWith 2.6.28 came ext4, which I've been using on several not-so-important filesystems for a while now. Also, I had switched the root file system on my laptop to non-encrypted quite a few months ago. I do recognize the problem of stolen laptops and had started running an encrypted rootfs years ago, but I lent my laptop to my flatmate and didn't want to bother her with the whole cryptfs thing. Anyway, I thought I'd kill two birds with one stone and switch back to ext4 on a crypted volume. Shouldn't be all that hard, right?/p pThe first problem I ran into is that very few live CDs support ext4. No matter, I can mount a backup disk and the laptops disk in my amd64 workstation, copy stuff around, not that hard. I also made sure I had an ext4-capable 2.6.28 on the laptop. So I copied the stuff to a spare disk, created the crypto volume, made a filesystem, copied everything back and re-activated the initrd script for cryptofs. Put the disk back into the laptop and… it didn't work./p pcryptsetup told me that there was no slot available with the passphrase I had entered. Had I mistyped something? Ok, back to the amd64 workstation. Hm. The config of the kernel looks ok, all the cryptmodules are there. So I replaced all the binaries with those from laptop installation (the passphrase I used wasn't wrong). I figured that maybe I did something wrong with the kernel after all and decided to rebuild it from scratch. But I can't build a 32-bit kernel on the amd64 machine because it's a pure 64-bit installation there[1]./p pFortunately, my router/fileserver is a PIII so it can build a kernel for my Pentium-M laptop. Also, it already has a cryptofs-aware kernel. I mounted everything as needed, chrooted into the filesystem and started rebuilding the kernel. But at the very end of the kernel build, there's a call to awk which resulted in a SIGILL. Ok, so then I changed out of the chroot, did a make mrproper and proceeded to build the kernel with the fileserver's toolchain. That went well and I also copied over a different version of cryptsetup to try out./p pUsing the new kernel (and cryptsetup), I istill/i had no joy. I even added strace and sundry other programs to the initrd (which was getting cramped). I saw crypsetup open the device, read the first few blocks and then decide it didn't like it. Was cyptsetup arch-aware? I couldn't imagine that the on-disk format depended on the arch used to make the cryptodev and filesystems[2]. That couldn't be the problem since I could read the filesystem on both my amd64 and the PIII fileserver./p p Had I manipulated the wrong kernel all the time? I renamed the kernel image on-disk (to vmlinuz-2.6.28a) and changed the grub config to call the new kernel. Upon boot, I used grubs edit command and sure enough, the new kernel name. So the grub.conf was used as it should be, what about the kernel? I booted the renamed kernel and istill/i cryptsetup refused to open the filesystem./p pIn desparation, I decided to build an dynamically linked cryptsetup, hoping that some code blob was missing and the linking infrastructure would do a better job of telling me iwhat/i was missing./p pSuccess at last, I could open the cryptodev with the correct passphrase! Apparently, something in the interface between cryptsetup and the kernel changed with 2.6.28 and neither of them thought it fit to tell me in an understandable way. Interestingly, the fileserver never showed any of this behaviour (and yes, I switched to 2.6.28 there a while ago)./p pHome free? Not really. The kernel refused to mount the rootfs since it wanted CONFIG_LSF to be set (that's Large Single File support). Ok, so I rebuilt the kernel iagain/i. No joy. I was getting a tad annoyed by this point. Fortunately, I took the time to make some tea and when I was staring at the tea infusing, it hit me: had I copied the new LSF-aware kernel to the changed name in grub.conf (vmlinuz-2.6.28a)? No, I hadn't. Fixed that and finally everything worked./p pNow you've read this post over the course of maybe a few minutes. Keep in mind that for every single change, I had to ipull the disk from the laptop, shutdown the other machine, plug the disk into that machine, boot it, make the change, shut the machine down, put the disk back in the laptop, boot the laptop, doesn't work, repeat. Also, I had to do stuff like fixing typos, do some (ultimately useless) reordering in the initrd, checksumming, etc. In all, I spent several hours trying to fix this simple matter./p pLesson learned: Don't change too many things at the same time or you'll never know which one spit in your soup./p pFootnotes: /p ol liYes, I know, I could have. But it would have been more effort (or at least it seemed that way at the time)./li liStuff like that used to be the case way-back-when. Good riddance./li /ol h2Comments/h2 piKevin Bowling/i writes:/p blockquote pTake a look here for my and another Gentoo user's ext4 experience. a href=http://www.kev009.com/wp/2008/12/how-to-upgrade-to-ext4-in-place/http://www.kev009.com/wp/2008/12/how-to-upgrade-to-ext4-in-place/a/p pMine was fairly painless, but I'm not trying to do encryption (laptop disks are slow enough already!). The other Kevin's was a bit more involved but he is doing crazy encryption stuff like you :-P./p /blockquote piBranko Badrljica/i writes:/p blockquote pI'm deferring having encrypted notebook disks to the moment when it will be possible to do it with GPU, not CPU./p pAs it is now, it taxes CPU quite considerably. This might be acceptable for some apps that are not that CPU intensive, but becomes bottleneck when you decide to stretch that multitasking a bit.../p /blockquote pWell, my laptop isn't the thing I do heavy computing on. Mostly, it's a rather oversized MP3-Player, fallback storage for my digital camera, trusted access point for Internet and fallback machine when my main workstation croaks. As such, I don't mind the impact of cryptofs on the overall performance. In other words: even with a crypted disk, it's fast enough for what I need./p
Diego Pettenò: Free virtualisation - not working yet

Posted: January 3rd, 2009, 3:27am CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pIf you’ve been following my blog for a while you probably remember how much I fought with VirtualBox once it was released to get it to work, so that I could use OpenSolaris. Nowadays, even with some quirks, VirtualBox Open Source Edition is fairly usable, and I’m using it not only for OpenSolaris but also for a Fedora system (which I use for comparing issues with Gentoo), a Windows install (that I use for my job), and a Slackware install that I use for kernel hacking./p pObviously, the problem is that the free version of VirtualBox come with some disadvantages, like not being able to forward span class=capsUSB/span devices, having limited type of hardware to virtualise and so on. This is not much of a problem for my use, but of course it would have been nicer if they just open sourced the whole lot. I guess the most obnoxious problem with VirtualBox (OSE at least, not sure about the proprietary version) is the inability to use a true block device as virtual disk, but rather having to deal with the custom image format that is really slow at times, and needs to pass through the span class=capsVFS/span./p pFor these reasons Luca suggested me many times to try out kvm instead, but I have to say one nice thing of VirtualBox is that it has a quite easy to use interface which allows me to set up new virtual machines in just a few clicks. And since nowadays it also supports VT-x and similar, it’s not so bad at all./p pBut anyway, I wanted to try kvm, and tonight I finally decided to install it, together with the a href=http://virt-manager.et.redhat.com/virt-manager frontend/a although there are lots of hopes for this, it’s not yet good enough, and it really isn’t usable for me at all. I guess I might actually get to hack at it, but maybe this is a bit too soon yet./p pContinue reading on my blog for the reasoning, if you’re interested./p pOne thing I really dislike of the newer versions of VirtualBox is that it went the VMware route and decided to create its own kernel module to handle networking. They said it’s for performance reasons but I’d expect the main reason is that it would allow them to have a single interface between Linux, Windows, Solaris and so on. The span class=capsTUN/span/TAP interface is Linux-specific so supporting that together with whatever they have been doing on the other operating systems is likely a cost for them. Although I can understand their reasoning, it’s not that I like it at all. More kernel code means more code that can crash your system, especially when not using the Open Source Edition./p pInterestingly enough, the RedHat’s Virtual Machine Manager is instead doing its best to avoid creating new network management software, and uses very common pieces of software: dnsmasq as span class=capsDHCP/span server, the Linux kernel bridging support, and so on. This is very good, but it also poses a few problems: first of all, my system already runs a span class=capsDHCP/span server, why do I have to install another? But it’s not just that; instead of creating an userspace networking bridging software, like VirtualBox does, it tries to use what the kernel provides already, in the form of the bridging support and iptables to forward requests and create span class=capsNAT/span zones. This is all fine and dandy, as it reduces the feature duplication in software, but obviously requires more options to be enabled in kernels that might not otherwise have it enabled at all./p pAs it happens, my system does have bridging support installed, but not iptables nor masquerade targets and similar. Up to now I never used them so it had no reason to be there. I also sincerely can’t understand why it does need it if I don’t want a span class=capsNAT/span, but it doesn’t seem to allow me to set up the network myself. Which would include me being able to just tell it to create a new interface and add it to a bridge I manage myself, leaving to me all the details like dhcp, and thus not requiring iptables at all./p pAlso, even though there is a way to configure an span class=capsLVM/span-based storage pool, it does not seem to allow me to choose directly one of the volumes of that pool when it asks me what to use as a virtual disk. Which is kinda silly, to me./p pBut these are just minor annoyances, there are much bigger problems: if the modules for kvm (kvm and kvm-amd in my system) are not loaded when virt-manager is loaded, it obviously lack a way to choose span class=capsKVM/span as hypervisor. This is nice, but it also fails to see that there is no qemu in the system, and tries to use a default path, that is not only specific to RedHat, but also very not existing here (code/usr/lib64/xen/bin/qemu-dm/code, on x86-64, just checking the uname!), returning an error that the particular command couldn’t be found. At least it should probably have said that it couldn’t find qemu, rather than the particular path. It would have also been nice to still allow choosing kvm but then telling that the device was missing (and suggested loading the modules; VirtualBox does something like that already)./p pTo that you have to add that I haven’t been able to finish the wizard to create a new virtual machine yet. This because it does not check the permission to create the virtual machine embefore/em proposing you to create one, so it let you spend time to fill in the settings in the wizard and emthen/em fails telling you don’t have permission to access the read/write socket. Which by default is accessible only by root./p pEven though it’s obvious by the 0-prefix that the software is still not production-level, there are also a few notes on the way the interfaces are designed. While it’s a good idea to use Python to write the interface, since it allows a much faster test of the code and so on, and speed is not a critical issue here, as the work is carried out by C code in the background, every error is reported with a Python traceback, one of the most obnoxious things to do for users. In particular for the permission problem I just listed, the message is a generic error message: “Unable to complete install: ‘unable to connect to ’/var/run/libvirt/libvirt-sock’: Permission denied’”; what is the user supposed to know here? Of course virtualisation is not something the user at the first tries with Linux is going to use, but still, even a power user might be scared by errors that appear this way and have attached a traceback (that most users would probably rationally link with “the program crashed” like bug-buddy messages, rather than “something wasn’t as the software expected”, which is what happened./p pOn a very puny level, instead, I have to notice that just pressing Enter to proceed to the next page on the wizard fails, and using span class=capsESC/span to close the windows too. Which is very unlike any other commonly-used software./p pSo to cut the post short now, what is the outcome of my test? Well, I didn’t get to test the actual running performance of span class=capsKVM/span against VirtualBox, so I cannot say much about that technology. I can say that there is a long road ahead for the Virtual Machine Manager software to become a frontend half as good as VirtualBox’s or VMware’s. This does not mean that the software was badly written, at all. The software by design is not bad at all; of course it’s very focused on RedHat and less on other distributions, which explains lots of the problems I’ve noticed, but in general I think it’s going the right way. A more advanced setup for advanced users would probably be welcome by me, as well as an span class=capsISO/span images management like the one VirtualBox has (even better if you can assign an span class=capsISO/span image to be of a specific operating system, so that when I choose “Linux”, “Fedora” it would list me the various span class=capsISO/span for Fedora 8, 9, 10 and then have a “Other” button to take a different span class=capsISO/span to install, if desired./p pI’ll keep waiting to see how it evolves./p /div
Diego Pettenò: Bundling libraries for despair and insecurity

Posted: January 2nd, 2009, 5:30pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pemI’ve been told quite a few times that my posts tend to be too long, and boring for most basic users, so for a time I’ll try to use the “extended content” support from Typo, and see how people react. What this means is that the blog post is just summarised on feeds, and on aggregators like Planet, while the complete text can be read by accessing the article directly on my blog./em/p pWhen I started my work a href=http://blog.flameeyes.eu/2008/01/21/and-what-about-imported-librariesreporting bundled libraries/a almost an year ago, my idea had a lot to do with sharing code and just to the side to do with the security issues related to bundled libraries. I had of course first hand experience with the problem, since xine-lib has (and still in part had) bundled a lot of libraries. When I took over maintainership of it in Gentoo, it was largely breaching policy, and the number of issues I had with that was huge. With time, and coordination with upstream (to the point of me becoming upstream), the issues were addressed, and nowadays most of xine-lib bundled libraries are ignored in favour of the system copies (where possible; some were largely modified to the point of not being usable, but that’s still something we’re fighting with). Nowadays, the 1.2 branch of xine-lib already doesn’t have a FFmpeg copy at all, always using the system copy (or an eventual static copy built properly)./p pBut nowadays I started to see that what is obvious to me about the problems with bundled copies of libraries is not obvious to all developers, and even less obvious to “power users” who proxy-maintain ebuilds and just want them to work for them, rather than complying with Gentoo policies and standards. Which is why I think that sunrise and other overlays should always be scrutinised carefully before being added to a system./p pAt any rate, for this reason I’m going to explain in this post why you should not use bundled internal copies of libraries for packages added to Gentoo, and why in particular these packages should not be deemed stable at all./p pThe first issue to discuss is why do upstreams bundle libraries, since knowing the reasoning behind that is often helpful to identify whether it makes sense at all to keep them or not. The first most obvious answer is: to reduce dependencies. For a long time this was the major reason behind xine-lib usage of internally bundled libraries. As it turns out, with time this reason became moot: distributions started packaging xine-lib directly reducing the number of users wishing to build it from sources; even those wanting to build xine-lib from sources would find all the needed libraries in the distributions, most of the times. When this is the sole reason for libraries building, upstream should be very well open to add a configure option (or anything similar to that) to use the system copy, optionally or by default, with fallback to the bundled copy./p pA second reason might be that the library is being unstable when it comes to span class=capsAPI/span; this is probably the first reason why FFmpeg is often bundled in software rather than using the copy on the system; while this is a concern that makes more sense then the one before, it’s still mostly a moot point since it really just requires to fix the issue at the source: get the original project to maintain span class=capsAPI/span compatibility, to provide an span class=capsAPI/span compatibility layer, or to finalise its span class=capsAPI/span. Even when it cannot be helped, because the span class=capsAPI/span is in flux, maintained software fears not the span class=capsAPI/span break; it might be a bit of an hassle but in general it’s feasible to keep the use and the library in sync./p pThirdly, more worrisome, is when the library is modified, slightly or heavily, after bundling; in this case using the system copy might be quite a burden because it will lack the specific changes as made by the project. In this case there is a lot of work involved, sometimes more work that it can be taken care by distributions, and requires coordination of the project’s upstream together with the higher level upstream. This is what happened with xine-lib and FFmpeg: the copy in the xine-lib sources was heavily modified to suit both the build system and the interface requirements of xine, which made it also very difficult to update the internal snapshot. All the interface changes needed have then been pushed upstream to FFmpeg, and the buildsystem changes were made moot by using the default buildsystem (with needed changes pushed upstream) embedded in autotools; and then FFmpeg was entirely removed from xine-lib’s sources./p pNow, on the other hand, the disadvantages of using bundled libraries are probably worse: code duplication means that there is more data to process (both at build time to compile and at load time to store in memory), there is more space used by the binaries, and there are duplicated bugs that need to be fixed twice. A lot of time in xine-lib the problems with decoding something with FFmpeg were solved by just using a newer FFmpeg; why keeping one then?/p pThe most important issue though is about security: when a vulnerability is found in a library like zlib, fixing the library alone is not enough: while that fixes the majority of the software in a system, it’s not going to fix those who bundle it, both a href=http://blog.flameeyes.eu/2008/12/18/software-sucks-or-why-i-dont-trust-proprietary-closed-source-softwareclosed-source/a and open source. For instance, take a href=https://bugs.gentoo.org/show_bug.cgi?id=251109;dzip/a it uses an ancient internal version of zlib; if somebody knows the format well enough, it’s far from impossible to craft a dzip file that contains a deflated stream that can executed malicious code./p pFor this latter issue alone, I’d say that any software bundling source code is not good enough to go stable on its own. Of course sometimes one has to bend the rules because of past mistakes, for instance even though Ruby a href=https://bugs.gentoo.org/show_bug.cgi?id=253276bundles stuff/a, we cannot stop newer versions to go stable; this problem is not a regression. But strongshould/strong stop other broken software from entering portage or at least the stable tree./p pBut it’s not just security, subtle bugs might actually be quite a problem. For instance, you might remember all Java applications failing when libX11 was built with span class=capsXCB/span support some time ago. The problem was due to some stricter checks in libxcb compared to what libX11 have been checking before, but the source of the problem was Xinerama. The problem with that was that Sun bundled an internal copies of libXinerama sources in the span class=capsJRE/span sources, and even though libXinerama was since then fixed regarding that particular issue (the crash with span class=capsXCB/span), it was never updated in the span class=capsJRE/span before the issue became a nuisance for users./p pA very similar issue, also involving span class=capsX11/span (just by chance, it’s not that all the issues involve span class=capsX11/span) is a href=http://bugs.freedesktop.org/show_bug.cgi?id=17431this particular bug in Xorg/a that is triggered when launching span class=capsSDL/span-based applications, because libSDL a href=https://bugs.gentoo.org/show_bug.cgi?id=246177bundles ancient versions of span class=capsX11/span libraries/a./p pAs I said earlier, unbundling is rarely easy; there are subtle issues to be checked out, for instance one has to check if there are changes at all beside eventual build-system related things (for instance to avoid using a full-fledged ./configure), but altogether it’s usually not tremendously impossible. Of course one has to stop thinking “Oh my, what if a library changes and the software breaks?”, otherwise the task gets impossible. Software changes, software bitrots. It’s not by bundling internal copies of libraries that you can stop that. When the compiler gets upgraded, you’re going to have your software break, and you should fix your software; if the C library cleans up the includes, your software might not compile or might misbehave, deal with it. Sometimes the bundled libraries implement protocols and formats that need to work together with some other piece of software; if that changes, the bundled libraries are just going to break further./p pstrongYour software is rarely special enough that you can be exempted from following the rules./strong Even OpenOffice is using lots of system libraries nowadays!/p pBundling and modifying libraries is just like forking a project, and a href=http://lwn.net/Articles/282261forking might not always be the best approach/a sometimes with dead upstream for a project, forking is your only hope; but even in those cases there are nice ways to bundle libraries. If you look at the way a href=https://bugs.gentoo.org/show_bug.cgi?id=253269nmap bundles libdnet/a, you can see that they not only document all the changes they made to the library, but also provides splitted down and commented patches for the various changes, making it possible to adapt it to their need./p pFor proprietary software packages, of course, the matter is different, since you cannot usually unbundle the libraries yourself; but it’s a good idea to ask upstream nicely if they can use system copies instead of internal ones. Mind you, some might be happy to fix their packages not to be vulnerable any longer. Although I guess lots of them might actually prefer to keep them as they are since it’s a cost to them. One more reason not to trust them, to me./p pSo bottom line, if you’re working on an ebuild for a new piece of software to submit for Portage addition, please look well to see if the software is bundling libraries, and if it is, don’t let it enter portage that way. And if you’re a developer who wants to push some ebuild to the tree, also remember to ensure that it complies with our policies and doesn’t bundle in libraries./p /div
Christian Faulhammer: Emacs Daemon and 23 release schedule

Posted: January 2nd, 2009, 3:04pm CET by Christian Faulhammer (fauli)

img src=http://planet.gentoo.org/images/opfer.png width= height= alt= align=right style=float: right;pIn the beginning: A happy 2009 to everyone!/pp Last thing first: We are nearing another iteration of the a href=http://www.gnu.org/software/emacsGNU Emacs/a release cycle. After having to wait many years (about five if I remember correctly) between the two major release 21 and 22 which only brought minor improvements (though they were much needed, especially the GTK+ port), 23 will likely see light in 2009 backed by a new release team consisting of Chong Yidong and Stefan Monnier (Richard Stallmann stepped back earlier this year as Emacs' maintainer, but still is an active developer). This is a much shorter waiting period than hoped, so let's support upstream by testing the pretest versions (defined snapshots from upstream's development tree): As usual, the Gentoo GNU Emacs team will provide these snapshots in a timely manner as app-editors/emacs-cvs-23.0.9x ebuilds. Of course you can stick to the live ebuild (~app-editors/emacs-cvs-23.0.9999) that is in Portage for years now and I am sure a lot of bugs found during the development cycles is due to our active user base and this ebuild. Anyway, I wanted to talk about the news in Emacs 23, some are really exiting and users are desperately waiting for some for years. Most importantly a new font and character handling backend has been added, so Emacs is fully Unicode compatible (without bad hacks as before where the internal format was different, now it is an extended UTF-8) and supports the XFT extension (there is a short a href=http://www.gentoo.org/proj/en/lisp/emacs/xft.xmlguide/a in our project space). The other big extension is the multi-tty interface, thus you can use the same Emacs session on a terminal in text mode and in X. Running Emacs as a server lets you connect to it from anywhere you want on any display type./p pThis is related to the Daemon mode I also want to talk about: Ulrich Müller (ulm) wrote the a href=http://packages.gentoo.org/package/app-emacs/emacs-daemonapp-emacs/emacs-daemon/a package, which installs an init script for GNU Emacs. This makes use of the new Emacs daemon function. Yes, we are getting nearer to replace the init process with Emacs on your system ;)! Honestly: This helps your productivity. An Emacs server is started in the background and you connect to it through the emacsclient program, giving you a text mode Emacs or an X window (see multi-tty). Go to your /etc/init.d directory and create a symlink for every user that will run Emacs:/p pre ln -s emacs emacs.emuser/em/prep Now run »/etc/init.d/emacs.emuser/em start« and/or add emacs. to the default runlevel (rc-update). Have a look at the file /etc/conf.d/emacs to see how you can customize your setup, e.g. you can add command-line options you need. You may also create individual /etc/conf.d/emacs.emuser/em files for »multiplexed« user configuration. So now Emacs is running, but no window is open on your desktop. When you need it, it pops up and you can close it without losing your server socket for Emacs, so lost file associations (for example opening PDF or image files with emacsclient while having no active server) are from the past now. /ppOf course there have been more changes, but too much to list them in every detail here, so have a look at the NEWS (type C-h n in Emacs) file shipped with Emacs to find out if there is anything interesting for you./p
Christian Faulhammer: Emacs Daemon and 23 release schedule

Posted: January 2nd, 2009, 2:03pm CET by Christian Faulhammer (fauli)

img src=http://planet.gentoo.org/images/opfer.png width= height= alt= align=right style=float: right;pIn the beginning: A happy 2009 to everyone!/pp Last thing first: We are nearing another iteration of the a href=http://www.gnu.org/software/emacsGNU Emacs/a release cycle. After having to wait many years (about five if I remember correctly) between the two major release 21 and 22 which only brought minor improvements (though they were much needed, especially the GTK+ port), 23 will likely see light in 2009 backed by a new release team consisting of Chong Yidong and Stefan Monnier (Richard Stallmann stepped back earlier this year as Emacs' maintainer, but still is an active developer). This is a much shorter waiting period than hoped, so let's support upstream by testing the pretest versions (defined snapshots from upstream's development tree): As usual, the Gentoo GNU Emacs team will provide these snapshots in a timely manner as app-editors/emacs-cvs-23.0.9x ebuilds. Of course you can stick to the live ebuild (~app-editors/emacs-cvs-23.0.9999) that is in Portage for years now and I am sure a lot of bugs found during the development cycles is due to our active user base and this ebuild. Anyway, I wanted to talk about the news in Emacs 23, some are really exiting and users are desperately waiting for some for years. Most importantly a new font and character handling backend has been added, so Emacs is fully Unicode compatible (without bad hacks as before where the internal format was different, now it is an extended UTF-8) and supports the XFT extension (there is a short a href=http://www.gentoo.org/proj/en/lisp/emacs/xft.xmlguide/a in our project space). The other big extension is the multi-tty interface, thus you can use the same Emacs session on a terminal in text mode and in X. Running Emacs as a server lets you connect to it from anywhere you want on any display type./p pThis is related to the Daemon mode I also want to talk about: Ulrich Müller (ulm) wrote the a href=http://packages.gentoo.org/package/app-emacs/emacs-daemonapp-emacs/emacs-daemon/a package, which installs an init script for GNU Emacs. This makes use of the new Emacs daemon function. Yes, we are getting nearer to replace the init process with Emacs on your system ;)! Honestly: This helps your productivity. An Emacs server is started in the background and you connect to it through the emacsclient program, giving you a text mode Emacs or an X window (see multi-tty). Go to your /etc/init.d directory and create a symlink for every user that will run Emacs:/p pre ln -s emacs emacs./prep Now run /etc/init.d/emacs. start and/or add emacs. to the default runlevel (rc-pdate). Have a look at the file /etc/conf.d/emacs to see how you can customize your setup, e.g. you can add command-line options you need. You may also create individual /etc/conf.d/emacs. files for »multiplexed« user configuration. So now Emacs is running, but no window is open on your desktop. When you need it, it pops up and you can close it without losing your server socket for Emacs, so lost file associations (for example opening PDF or image files with emacsclient while having no active server) are from the past now. /ppOf course there have been more changes, but too much to list them in every detail here, so have a look at the NEWS (type C-h n in Emacs) file shipped with Emacs to find out if there is anything interesting for you./p
Diego Pettenò: The canonical target

Posted: January 1st, 2009, 6:00pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pI’ve already written about the common mistake of a href=http://blog.flameeyes.eu/2008/10/11/you-dont-want-to-canonicalise-that-and-im-not-referring-to-ubuntuusing AC_CANONICAL_TARGET/a in software that is not intended to be used as compiler. Since I’m now using my tinderbox extensively, I’ve thought it might have been a good idea to try checking how many packages actually do call that, that shouldn’t./p pThe test is really a quick and dirty bashrc snippet:/p div class=typocodeprecode class=typocode_default post_src_unpack() { find ${S} -name configure.ac -o -name configure.in | while read acfile; do acdir=$(dirname $acfile) pushd $acdir autoconf --trace AC_CANONICAL_TARGET 2gt;/dev/null gt; ${T}/flameeyes-canonical-target.log if [[ -s ${T}/flameeyes-canonical-target.log ]]; then ewarn Flameeyes notice: AC_CANONICAL_TARGET used cat ${T}/flameeyes-canonical-target.log fi popd done }/code/pre/div pThis provides me with enough information to inspect the software, and eventually provide patches to correct the mistake. As I said this is a very common mistake, and I’ve fixed quite a few packages for this. Not only it wastes time to identify the target system, but it also provides a totally misleading code--target/code option to the configure script that confuses users and automatic systems alike; if we were to write a software to generate ebuilds out of the source tarball of a software with some basic common options, it would probably be confused a lot by the presence of such an option./p pSince the whole build, host and target situation is often confusing, I’d like to try explaining it with some images, I think that might be a good way to show users and developers alike how the three machine definitions interact between each other. Since this is going to be a long post, in term of size, rather than content, because of the images, the extended explanation won’t be present in the feed./p pContinue reading on my site for that./p pTo try explaining this in a very visual way, let’s say we have only three systems, a PowerBook laptop, a standard x86 computer, and a build service using x86-64 servers. The choice of PoweBook as smallest device has been conditioned by the fact it was the only decent image I could find on a href=http://www.openclipart.org/OpenClipart/a for a system that would have been easily seen as having a different architecture than the other two. I would have liked an span class=capsARM/span board, but it was wishing too much./p pThe first obvious case is having a native compiler, no cross-compiling involved at all:/p pimg src=http://blog.flameeyes.eu/files/autotools-bht-scenario1.png title=Non-crosscompiled native compiler //p pIn this case, both gcc’s codeconfigure/code script, the codepowerpc-linux-gnu-gcc/code compiler and the codehellow/code program are executed on the same system: the laptop. This is the standard case you have on a Gentoo system when building stuff out of most ebuilds. In this case host, build and target machines are all one the same: strongpowerpc-linux-gnu/strong./p pThen there is a very common case for embedded developers, cross-compilers:/p pimg src=http://blog.flameeyes.eu/files/autotools-bht-scenario2.png title=Non-crosscompiled cross-compiler //p pIn this case gcc’s codeconfigure/code (and thus build) is executed on a PC system, which also will run the codepowerpc-linux-gnu-gcc/code compiler, but the codehellow/code program is still executed on the laptop. Host and build machines are strongi686-pc-linux-gnu/strong while target is strongpowerpc-linux-gnu/strong./p pThe next scenarios is uncommon for standalone developers but is somewhat with binary distributions for smaller systems:/p pimg src=http://blog.flameeyes.eu/files/autotools-bht-scenario3.png title=Crosscompiled native-compiler //p pIn this case there is a build service that starts up the build for the compiler, that will then be executed by the laptop directly. In this case the build machine is strongx86_64-pc-linux-gnu/strong while both host and target are strongpowerpc-linux-gnu/strong./p pThe final scenario involves all three systems at once and shows exactly the difference between the three machine definitions:/p pimg src=http://blog.flameeyes.eu/files/autotools-bht-scenario4.png title=Crosscompiled cross-compiler //p pIn this case the build service prepares a cross-compiler executed on a PC that will build software to run on the laptop. The build machine is strongx86_64-pc-linux-gnu/strong, the host machine is strongi686-pc-linux-gnu/strong and the target is strongpowerpc-linux-gnu/strong./p pNow, this works pretty well and sleek for compilers, but what about other software? In most cases you got just two systems involved at most, one that will run the software and one that will build it, so there is no need for a target definition, it’ll all be completed between build and host. And this is why you should not be calling codeAC_CANONICAL_TARGET/code unless you can figure out a far-fetched scenario where you can involve three computers with three different architectures, like in the last scenario./p /div
Gunnar Wrobel: layman-1.2.3 is out

Posted: January 1st, 2009, 9:02am CET by Gunnar Wrobel (wrobel)

img src=http://planet.gentoo.org/images/wrobel.png width= height= alt= align=right style=float: right;The next a href=http://layman.sourceforge.netlayman/a version has been released and fixes a few minor bugs: ul liSupport setting the terminal screen width (a href=http://bugs.gentoo.org/show_bug.cgi?id=253016#253016/a)/li lilayman -S fetches each overlay twice (a href=http://bugs.gentoo.org/show_bug.cgi?id=253241#253241/a)/li /ul I can't seem to get layman bug free these days. I already wanted to mark the newer version stable months ago. Let's hope there'll be a longer bug free period now ;)
Gentoo News: Get involved: Bugday coming up Saturday

Posted: January 1st, 2009, 1:02am CET by Gentoo News ()

img src=http://planet.gentoo.org/images/larry_the_cow.jpg width= height= alt= align=right style=float: right;pbWhat:/b Gentoo contributors get together to help each other fix bugs /ppbWhere:/b irc.freenode.net, #gentoo-bugs /ppbWhen:/b Saturday, January 3, in a timezone near you /ppbWhat do you need to bring?/b/pulliA Gentoo system, an Internet connection and an IRC client/liliYour bug. If you don't have one, we will find you one to suit your area of interest and your skills/liliYour favorite editor/liliA way to test that your bug is fixed (asking people counts!)/liliYou bdon't/b need to know C, C++, or bash/li/ulpbWhat's a bug?/b Gentoo's way of tracking change requests. A change request can be anything from I've found a typo in foo to I've built this really useful program called bar but there's no ebuild for it. Bugs have various levels of helpfulness, from identifying the existence of a problem to localizing the problem to providing the patch to fix it. /pp There are bugs in documentation such as man pages as well as ebuilds and the source code that Gentoo distributes. These bugs are problem reports. Bugs for things Gentoo doesn't do yet but you think should be done are feature requests. bBugday is more about fixing problems than adding features/b, but you won't be turned away if you want help with a new feature. /ppbWant to know more about Bugday?/b It's held on the first Saturday of every month. It's an opportunity for everyone to contribute to making Gentoo better, and eventually you might even become a Gentoo developer. See the a href=http://www.gentoo.org/proj/en/bugday/index.xmlBugday project page/a for more details. /ppbBugday is about community spirit/b. Gentoo is a community—there is no me and them, there is only we, so instead of lobbying for them to fix your particular bug, work together to fix it! Bugday is an opportunity to get help to help yourself. /pp If you've been wanting to get involved but weren't sure how, Bugday is a great way for you to see what goes on in making a distribution and get involved in Gentoo. /ppa href=http://forums.gentoo.org/viewtopic-t-721883.htmlDiscuss this!/a/ppspanRoy Bamford contributed the draft for this announcement./span/p
Jeremy Olexa: Today#8217;s rant: What is #8216;bikeshedding#8217; ?

Posted: December 31st, 2008, 7:08pm CET by Jeremy Olexa (darkside)

div class=snap_previewbr /pI knew the general concept of this word but it was thrown around today so I decided to research it./p blockquotepstrongParkinson#8217;s Law of Triviality/strong (also known as the strongbicycle shed/strong example, and by the expression strongcolour of the bikeshed/strong) is C. Northcote Parkinson#8217;s 1957 argument that organisations give disproportionate weight to trivial issues. a href=http://en.wikipedia.org/wiki/Color_of_the_bikeshedsource/a/p/blockquote pMade famous in software development by Poul-Henning Kamp (FreeBSD dev)/p blockquotepem#8220;The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.#8221; /ema href=http://www.bikeshed.com/source/a/p/blockquote pSeems to be true to me. We shouldn#8217;t needlessly argue about trivial details./p pI leave you with this..Is there a software development group in existence that does not bikeshed?:/p blockquotepstrongFutile investment of time and energy in marginal technical issues, often including annoying propaganda./strong (as defined by a href=http://en.wiktionary.org/wiki/bikesheddingWiktionary/a)/p/blockquote pI doubt it, but is it always a bad thing? Comments?/p nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;a rel=nofollow href=http://feeds.wordpress.com/1.0/gocomments/jolexa.wordpress.com/199/img alt= border=0 src=http://feeds.wordpress.com/1.0/comments/jolexa.wordpress.com/199/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/godelicious/jolexa.wordpress.com/199/img alt= border=0 src=http://feeds.wordpress.com/1.0/delicious/jolexa.wordpress.com/199/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/gostumble/jolexa.wordpress.com/199/img alt= border=0 src=http://feeds.wordpress.com/1.0/stumble/jolexa.wordpress.com/199/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/godigg/jolexa.wordpress.com/199/img alt= border=0 src=http://feeds.wordpress.com/1.0/digg/jolexa.wordpress.com/199/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/goreddit/jolexa.wordpress.com/199/img alt= border=0 src=http://feeds.wordpress.com/1.0/reddit/jolexa.wordpress.com/199/ //a img alt= border=0 src=http://stats.wordpress.com/b.gif?host=jolexa.wordpress.comamp;blog=4115754amp;post=199amp;subd=jolexaamp;ref=amp;feed=1 //div
Christian Faulhammer: app-emacs/gentoo-syntax 1.10 released

Posted: December 31st, 2008, 1:03pm CET by Christian Faulhammer (fauli)

img src=http://planet.gentoo.org/images/opfer.png width= height= alt= align=right style=float: right;p The Gentoo GNU Emacs team just released version 1.10 of a href=http://packages.gentoo.org/package/app-emacs/gentoo-syntaxapp-emacs/gentoo-syntax/a which is a minor update in general but has some interesting new features:/p ul liSupport EAPI 2 (to be found in Portage 2.2 and 2.1.6)/li liMake use of the menu to make it easier for beginners/li liThe code has been revamped and reworked in some important parts (not user-visible)/li liUpdate some eclasses (no PHP4 support anymore and some more changes to other exisiting eclasses)/li liSupport the new eclasses bzr and gems/li /ul p Enjoy! We will get it into stable as soon as possible. /p
Josh Saddler: Graphics shuffle

Posted: December 31st, 2008, 9:01am CET by Josh Saddler (nightmorph)

img src=http://planet.gentoo.org/images/nightmorph.jpg width= height= alt= align=right style=float: right;pOn Christmas Eve, a special present arrived from UPS: the HIS Radeon X1950 Pro I purchased on eBay. For the week prior to Christmas I removed the discrete nVidia 7600GT and ran off the integrated nVidia Geforce 8200 chip in my motherboard. Utter pain!/p pDrawing the screen, whether compositing was on or off, was painfully slow. Running any kind of game was out of the question. UT2004 was impossible. I managed to gain a bit of 2D speed by adding codeGlyphCache/code and codeInitialPixmapPlacement/code options to codexorg.conf/code, but the desktop was still slow as molasses. Made using the computer quite painful. I can personally verify all the reports that nVidia's drivers for the Geforce 8000 series suck balls are quite true. The only thing I gained was being able to run the framebuffer console at 1440x900, my monitor's native resolution. The Geforce 8200 supports this framebuffer mode; the 7600GT only supports up to 1024x768. Not that it matters once Xorg is launched. Anyway, that was a miserable failure, so I was really happy when the HIS Radeon card showed up./p pTo be honest, I spent a few more bucks on it than I'd like. With shipping, it was about $51. But I figured this could be a tech toy for the next several months. After this fall's a href=http://blogs.gentoo.org/nightmorph/2008/10/29/hardware_successdebacle/a with that HIS RadeonHD 4670, I picked up an older R500 card for half the cost, and this one is at the top of the line for its generation. It should have been an upgrade on my nVidia 7600GT even with the FOSS drivers. With all the documentation ATI has released, the developers of the FOSS driver (xf86-video-ati in my case) were able to get working 2D and 3D acceleration some months ago. So, emboldened by all the articles and forums posts over at a href=http://www.phoronix.comPhoronix/a on the exciting things happening to the FOSS Radeon/Xorg/Mesa stack, I gave it a whirl./p pstrongThe Good/strong/p pstrong1./strong There is indeed 3D acceleration. It's partly usable.br / strong2./strong The 2D acceleration is the fastest of any chip I tried, faster than even the 7600GT with the proprietary driver. Once I switched from XAA to EXA acceleration, it was even faster!br / strong3./strong Running at my monitor's native resolution at the framebuffer console is possible.br / strong4./strong It was nice to be able to remove all proprietary kernel modules.br / strong5./strong The whole desktop stack loads a bit faster, with less modesetting flicker.br / strong6./strong 3D performance is actually better with the FOSS drivers than it is with ATI's Catalyst (fglrx) driver./p pAll the stuttering and lockups I'd run into with the RadeonHD 4670 card a few months ago? Yeah, I now believe those weren't hardware issues at all, but shitty, emshitty/em fglrx driver code. I ran into emthe exact same thing/em when trying to use fglrx with the X1950 Pro. UT2004 was a constant stutter-fest. Absolutely unusable. When it comes to the proprietary vs. FOSS drivers for usability, there's no contest. FOSS wins across the board./p pstrongThe Bad/strong/p pstrong1./strong Keywording 70 packages or so in codepackage.keywords/code is a tedious chore. I was after the latest X-server, Radeon, and Mesa updates, which necessitated moving to ~arch for most of the required X packages.br / strong2./strong I can't switch virtual terminals. The monitor shuts off if it's running on anything but VT7 once X is loaded. Apparently I'm not the only one to a href=http://www.phoronix.com/forums/showthread.php?t=14651experience this issue/a with this card.br / strong3./strong Poor 3D performance. I had to turn down all settings to minimums in UT2004, though I kept the resolution maxed. And even with all the minimizing, framerates grew pretty choppy throughout the game. Though the R500 performance has come a long way in the Radeon driver, it's still nowhere near the level offered by my 7600GT and the proprietary nVidia driver. I dunno if the RadeonHD driver would offer any improvement; it shares a large part of its codebase with the Radeon driver.br / strong4./strong The gotchas involved with switching from the proprietary nVidia driver to a href=http://bugs.gentoo.org/show_bug.cgi?id=238686anything else/a. If you switch from one proprietary driver to an open-source driver, or a proprietary (nVidia) to proprietary (ATI), you'll have to manually delete a few libGL files, as the symlinks get shattered in a way that eselect doesn't know how to handle. Let's hope that bug gets fixed soon./p pstrongThe Ugly/strong/p pstrong1./strong The fan. I think the video card's fan may have been damaged in transit. I took out the card after just a week because the noise from the fan was so damned annoying. Now, it's not that it's particularly loud; it's not all that much louder than the system fans (which are pretty quiet even when at max). No, what really grated on me was the emhideous/em noise character of this fan. I've asked for a href=http://www.silentpcreview.com/forums/viewtopic.php?t=51575some help/a from folks in the know, so we'll see where this goes. Too bad too; it uses the same IceQ cooler that the 4670 uses, and the 4670's cooler was amazing. I couldn't hardly hear it no matter the load on the card. It had a smooth, pleasant noise character, blending right in with my system fans at low RPMs.br / strong2./strong Running into the ALSA and OpenAL updates at the same time I was trying to upgrade my hardware and its drivers. ALSA a href=http://bugs.gentoo.org/show_bug.cgi?id=234184cannot compile/a. Bug still not fixed./p pThe new OpenAL version seems to be from a different upstream, one who has no idea what he's doing as far as documentation goes. I had a working config file for .0.0.8, and 1.5.304 broke it. There's nothing but an extremely sparse sample config to suggest what to do. No matter what I put in the new .ini-style config file, I couldn't make it pick up my microphone. When it finally did seem to be able to identify codeplughw:0,0/code, it then petulantly died with the message that the requested buffer size was too large. Based on IRC logs I found via Google, upstream suggests that's ALSA's fault, not OpenAL. Whatever, man. All I know is that the previous versions of OpenAL have always worked regardless of my ALSA version. The new one doesn't. So I added 1.5 to codepackage.mask/code and downgraded. Presto, working microphone. Just the thing for the upcoming UT2004 tourney.br / strong3./strong Spending $50 just a week before ATI releases the long-awaited R600/R700 programming documentation. Yeah, I'm kicking myself a bit. I'm wishing that I still had that HIS RadeonHD 4670, something that should have better performance than even an X1950 Pro, no matter which drivers are used. But as it is, the FOSS driver devs don't really expect to get a working driver with any kind of OpenGL acceleration for another few months. Approximate feature parity with the R500's emcurrent/em driver codebase is expected in another 8 months or so. So it'd be a long wait, but one that I'm starting to think is worth it.br / strong4./strong Did I mention the fan? I can't stick that thing back in the case until I've found a emcheap/em solution to silencing the beast. It's not worth pouring a lot of money into it. I mean, if money is being tossed about, I may as well pick up a emsilent/em low- to mid-range 4000 card off NewEgg (again)./p p* * */p pThe X1950 Pro is currently stored in the closet. I'll dig it out again once I find some solutions to various bugs. Or when more 3D performance improvements are merged. I'd like to use it for UT2004 as well as general desktop work, but I need better 3D performance. And I need to fix that fan! Maybe I can find a decently priced Arctic Cooling Accelero S1 rev 2 someplace./p pI'm also really looking forward to the coming KMS and GEM support for R500 cards, hopefully that will all be merged into the 2.6.29 kernel. Just a few more months . . ./pdiv class=item_footerpsmalla href=http://blogs.gentoo.org/nightmorph/2008/12/31/graphics-shuffleOriginal post/a blogged on a href=http://b2evolution.net/b2evolution/a./small/p/div
Diego Pettenò: Avoid LDPATH pollution

Posted: December 30th, 2008, 2:35pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pThere is one thing I noticed working on my linking collision script. While most of the software properly creates subdirectories to put plugins in, so that they don’t clash with others and it does not pollute the span class=capsLDPATH/span space, there are quite a few packages that don’t do that at all and install their plugins straight into the libdir./p pNot only that, some packages install static archive versions of their own plugins, with no good reason since they are never linked in statically, but always dlopen’d./p pPlease don’t pollute span class=capsLDPATH/span, if you can, make sure the plugins are installed in “pkglibdir” (that is code/usr/lib/packagename/code) and make sure that they only install the shared object file, and eventually the libtool archive if the software uses libltdl to load them. The static archive is almost always unneeded and just a waste of time./p pAlso please remember that if you install core libraries in a path outside of the standard libdir (which is very good if the libraries are not to be linked against!), you should probably make sure that there is a proper runpath in the executables. What runpath does is to tell the linker to look for libraries in a path that is otherwise not accessible through the standard configuration files (code/etc/ld.so.conf/code). A common mistake here is to install an env file that makes codeLDPATH/code (or even worse codeLD_LIBRARY_PATH/code) to the directory where the core internal libraries are installed./p pWhile this works, it does not make much difference than having it in the standard library path: both the runtime linker and the link editor will use the path from the configuration file anyway, so the library is not going to be hidden like you’d want it to for a private library. On the other hand, if just the executable provides their own runpath, then the two linkers will ignore the libraries altogether./p pSo please, be careful with what you push in the library path, okay?/p /div
Zhang Le: glibc doesn't build with linux-header-2.6.28 on loongson

Posted: December 29th, 2008, 2:44am CET by Zhang Le (r0bertz)

img src=http://planet.gentoo.org/images/r0bertz.png width= height= alt= align=right style=float: right;Actually I was intended to send this to LKML, but just before I was about to send I found there was already some discussions about this: a href=http://marc.info/?l=linux-sparcamp;m=122956478603612amp;w=2http://marc.info/?l=linux-sparcamp;m=122956478603612amp;w=2/a. So instead I decided to just post it here.br /br /To make long story short, please take a look at these two files first:br /br /a href=http://sourceware.org/cgi-bin/cvsweb.cgi/libc/string/endian.h?rev=1.10amp;content-type=text/x-cvsweb-markupamp;cvsroot=glibchttp://sourceware.org/cgi-bin/cvsweb.cgi/libc/string/endian.h?rev=1.10amp;content-type=text/x-cvsweb-markupamp;cvsroot=glibc/abr /This file will become part of /usr/include/endian.h.br /br /a href=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/byteorder.h;h=29f002d73d989c577f0e79a8100d6fb7e0abb188;hb=bc2aa80e18a1b43ea2b8066500006b729c4ba4a7http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/byteorder.h;h=29f002d73d989c577f0e79a8100d6fb7e0abb188;hb=bc2aa80e18a1b43ea2b8066500006b729c4ba4a7/abr /This file will be /usr/include/linux/byteorder.hbr /br /Obviously, this test in linux/byteorder.h will fail:br /div blockquote#if defined(__LITTLE_ENDIAN) amp;amp; defined(__BIG_ENDIAN)br /# error Fix asm/byteorder.h to define one endiannessbr /#endif/blockquote/divBecause linux/types.h will include sys/types.h, which will in turn include endian.h, and in endian.h both of them are defined, but as a value not a flag.br /br /It seems that there is an inconsistency on handling __LITTLE_ENDIAN/__BIG_ENDIAN between Linux and glibc. Linux treats them like a flag, while glibc treats them like a value. glibc uses __BYTE_ORDER to determine the endianness.br /br /This problem must be solved, or any userland program including kernel headers which include {asm,linux}/byteorder.h will fail to build, e.g. glibc.br /br /It seems to me that the most straight forward way, but also very intrusive way is to make the handling of these two marco consistent in the two projects. That'll be a very large changeset. Also it will suddenly change a convention in a project that has already been followed for a long time. So I don't think people will accept this.br /br /How this problem will be solved is still remained to be seen.br /br /EDIT: someone reported that it worked well on ~amd64. So I modified the title and removed the last sentence. I will see if this problem still exists on my x86 notebook.br /br /EDIT 2: I confirm that this problem does not exists on x86. I will find out what exactly is going on loongson, or rather mips. :)div class=feedflare a href=http://feeds.feedburner.com/~f/r0bertz?a=i7QTOimg src=http://feeds.feedburner.com/~f/r0bertz?i=i7QTO border=0 //a a href=http://feeds.feedburner.com/~f/r0bertz?a=2DSioimg src=http://feeds.feedburner.com/~f/r0bertz?i=2DSio border=0 //a a href=http://feeds.feedburner.com/~f/r0bertz?a=Wu66oimg src=http://feeds.feedburner.com/~f/r0bertz?i=Wu66o border=0 //a a href=http://feeds.feedburner.com/~f/r0bertz?a=DkW0oimg src=http://feeds.feedburner.com/~f/r0bertz?i=DkW0o border=0 //a a href=http://feeds.feedburner.com/~f/r0bertz?a=cx8oOimg src=http://feeds.feedburner.com/~f/r0bertz?i=cx8oO border=0 //a a href=http://feeds.feedburner.com/~f/r0bertz?a=VpDTOimg src=http://feeds.feedburner.com/~f/r0bertz?i=VpDTO border=0 //a /divimg src=http://feeds.feedburner.com/~r/r0bertz/~4/496913170 height=1 width=1 /
Gunnar Wrobel: layman-1.2.2 is out

Posted: December 29th, 2008, 12:02am CET by Gunnar Wrobel (wrobel)

img src=http://planet.gentoo.org/images/wrobel.png width= height= alt= align=right style=float: right;The next a href=http://layman.sourceforge.netlayman/a version has been released and fixes a few minor bugs: ul lilayman -L: better use of screen real estate for source URLs (a href=http://bugs.gentoo.org/show_bug.cgi?id=251032#251032/a, submitted by Martin von Gagern)/li liExecute subprocesses in a shell. (a href=http://bugs.gentoo.org/show_bug.cgi?id=247792#235165/a)/li lilayman/overlays/git.py (GitOverlay.sync): app-portage/layman - 'layman -S --quiet' yields git: 'pull-q' is not a git-command. (a href=http://bugs.gentoo.org/show_bug.cgi?id=247964#247964/a)/li /ul Thanks to all the contributers!
Diego Pettenò: Blockers abuse

Posted: December 28th, 2008, 3:18pm CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pI’ve already written about some of the a href=http://blog.flameeyes.eu/2008/12/20/why-a-tinderbox-is-not-enough-not-even-twodifferences between my and Patrick’s tinderboxes/a, one of which is that my tinderbox does not only install one package, but tries to install all of them at once. This is a necessity for me to have enough material to work on with my a href=http://blog.flameeyes.eu/2008/12/24/library-on-a-collision-course-on-the-screenlibrary collisions script/a, and still have so many side effects that makes it funny to work with./p pThe first problem is that sometimes packages don’t get merged together because of file collisions, which most of the time are caused by packages that install commands with name too generic, and some other times because they regenerate files that should not be present in the final image (like iconv’s codecharset.alias/code that gets generated on Gentoo/FreeBSD systems with no good reason at all)./p pThe second problem derives from the way the first problem is handled. When two packages install a file with the same name, rather than renaming one of them or both, it’s customary to actually “fix” the problem by adding blockers to each of the two packages so that they cannot get installed together. While it’s certainly better to have it expressed that way rather than having the merge to fail emafter/em the compilation and install phases, it’s not really a solution since it still disallows having the two packages on the same system. While this is acceptable for packages like the different GhostScript implementations that apply for the same task, this is not much of a solution when the packages are entirely independent one from the other and have very different tasks./p pI also have found one particular package (pnet) which had a a href=https://bugs.gentoo.org/show_bug.cgi?id=189806very funky solution to the collision/a between that and boehm-gc, considering that it was eminstalling/em a private copy of that. Obviously this was not the proper fix by a mile’s look./p pIf you have two packages that block each other you have a few different ways to deal with that; if they provide the same function, you might as well install them with a prefix and then write an eselect module to choose between one or the other (which is something that ghostscript could very well be doing); if they only install executables with generic name, they might be changed to prefix the command name with the package name. But sometimes these commands are not to be used by the users at all, and are rather internal commands used by the scripts for processing; in those cases, it would be a nice idea to make those get into code/usr/libexec/$PN//code so that they are taken out of the users’ path, and won’t collide one with the other./p pWhile dealing with packages that install colliding files is not so easy, there is need for developers to deal with them in a less “works for me” way, and think more of the general picture, as it is, there are enough packages in the tree that blocks each other with no real good reason, and this is upsetting./p /div
Stuart Longland: Gentoo/MIPS uClibc Stages

Posted: December 27th, 2008, 4:38am CET by Stuart Longland (redhatter)

img src=http://planet.gentoo.org/images/redhatter.png width= height= alt= align=right style=float: right;pHi all#8230;/p pWell, after a long hiatus, I#8217;m working on new stages for the Gentoo/MIPS port. These new ones will be based on uClibc, and are a compliment to the existing glibc-based stages. At the moment, the initial seed environment is still being cross-compiled from my i686 host, and for now I#8217;m focussing on mipsel but will soon turn my attention to MIPS./p pThese stages initially will not operate with a page size of 16KB or more, so unfortunately aren#8217;t much good for Lemote users (a href=http://bugs.busybox.net/show_bug.cgi?id=9I#8217;m working with the uClibc people on this/a) but Cobalt and SGI users will soon once again be able to use uClibc as their system libc. The new stages will be based on uClibc 0.9.30#8230; which is yet to be keyworded./p
Diego Pettenò: Reinventing the wheels for fun and....

Posted: December 26th, 2008, 12:41am CET by Diego Pettenò (flameeyes)

img src=http://planet.gentoo.org/images/flameeyes.png width= height= alt= align=right style=float: right;div pSo it’s Christmas day, and I’m skimming through the 32+ MB of logs generated by my a href=http://blog.flameeyes.eu/2008/12/24/library-on-a-collision-course-on-the-screenelven script/a and I found some nice nuggets:/p div class=typocodeprecode class=typocode_default Symbol getopt_long@@ (32-bit UNIX System V ABI Intel 80386) present 35 times /usr/bin/graph /usr/bin/ebzipinfo /usr/bin/spline /usr/bin/double /usr/bin/uupick /usr/bin/autotrace /usr/bin/uustat /usr/sbin/ndtpd /usr/bin/ode /usr/sbin/ndtpcheck /usr/bin/ebrefile /usr/bin/uucp /usr/sbin/ndtpcontrol /usr/bin/uulog /usr/sbin/uuxqt /usr/bin/ebzip /usr/bin/faad /usr/bin/lha /usr/lib/libsox.so.1.0.0 /usr/sbin/uucico /usr/bin/ebinfo /usr/sbin/uuconv /usr/bin/plot /usr/bin/tek2plot /usr/lib/libc.so.5 /usr/bin/uuname /usr/bin/uux /usr/bin/ebstopcode /usr/bin/stklos /usr/bin/cu /usr/bin/plotfont /usr/bin/ebfont /usr/bin/ebunzip /usr/bin/pic2plot /usr/sbin/uuchk Symbol strncasecmp@@ (32-bit UNIX System V ABI Intel 80386) present 5 times /usr/bin/xpilots /usr/bin/gargoyle-agility /usr/lib/libc.so.5 /usr/bin/xedit /usr/bin/xpilot Symbol strnlen@@ (32-bit UNIX System V ABI Intel 80386) present 5 times /usr/bin/tarsync /usr/lib/libCw.so.1.0.0 /usr/lib/libmba.so.0.9.1 /usr/lib/python2.5/site-packages/numarray/_chararray.so /usr/bin/linksys-tftp Symbol stricmp@@ (32-bit UNIX System V ABI Intel 80386) present 5 times /usr/bin/qemacs /usr/lib/libraidutil.so.0.0.0 /usr/lib/openbabel/2.2.0/inchiformat.so /usr/lib/libxerces-c-3.0.so /usr/lib/libIL.so.1.0.0/code/pre/div pNow if you ignore the references to the old compatibility codelibc.so.5/code you can still find that there are quite a few programs that reinvent the wheel, reimplementing some functions that the C library already provides. Now, this would be fine and dandy if the implementation was subtly different, or was done with some particular purpose in mind, like glib’s functions, but I really can’t find the reason for the situation above to happen./p pThese are usually smaller functions, but still there is no reason for them to be present since anyway it’s more than likely that most of their use is replaced away by the compiler itself; more interesting is their presence in shared objects, since that would interpose around other calls, although this most likely won’t happen on glibc based systems since they provide versioned symbols which wouldn’t then interpose by default. That’s still a problem for *BSD systems though./p pThis has a much lower priority in my list than identifying all libraries bundled by various packages (even when they cannot be fixed, because they are proprietary or something else), because these are unlikely to turn out being security issues. On the other hand, the idea of doing such pointless duplication of common functions might as well caus security issues to be hidden, for instance if a package was to reimplement codemktemp/code, then it would most likely be a problem./p pAnyway for those interested to find out what’s duplicating code in their system, the new hit parade, derived directly from a href=https://bugs.gentoo.org/show_bug.cgi?id=251464the Bug/a shows SQLite3 trying to climb up the ladder, together with boehm-gc. Why people can’t understand that there are libraries in the system already?/p /div
Thomas Anderson: gentoofan23

Posted: December 25th, 2008, 5:06pm CET by Thomas Anderson (gentoofan23)

div class=snap_previewbr /pAfter testing with Markus, I#8217;ve stabilized linux 2.6.27 for amd64. Markus has stabilized it for x86. A few notes:/p p1) You#8217;ll likely need to upgrade nvidia-drivers, because we needed to stabilize new versions of that/p p2) openafs 1.4.8 and qc-usb-messenger went stable with it as well, so upgrade that./p p3) I fixed up lirc-0.8.3-r2 so it now has compatibility with 2.6.27./p pSo that#8217;s my Christmas present to Gentoo users.Have fun with it!/p nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;a rel=nofollow href=http://feeds.wordpress.com/1.0/gocomments/gentoofan23.wordpress.com/3/img alt= border=0 src=http://feeds.wordpress.com/1.0/comments/gentoofan23.wordpress.com/3/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/godelicious/gentoofan23.wordpress.com/3/img alt= border=0 src=http://feeds.wordpress.com/1.0/delicious/gentoofan23.wordpress.com/3/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/gostumble/gentoofan23.wordpress.com/3/img alt= border=0 src=http://feeds.wordpress.com/1.0/stumble/gentoofan23.wordpress.com/3/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/godigg/gentoofan23.wordpress.com/3/img alt= border=0 src=http://feeds.wordpress.com/1.0/digg/gentoofan23.wordpress.com/3/ //a a rel=nofollow href=http://feeds.wordpress.com/1.0/goreddit/gentoofan23.wordpress.com/3/img alt= border=0 src=http://feeds.wordpress.com/1.0/reddit/gentoofan23.wordpress.com/3/ //a img alt= border=0 src=http://stats.wordpress.com/b.gif?host=gentoofan23.wordpress.comamp;blog=3388004amp;post=3amp;subd=gentoofan23amp;ref=amp;feed=1 //div

← Planet Arslinux Planet Debian-FR →

Feeds

Planet Gentoo (20 unread)

Posted: January 5th, 2009, 12:28pm CET by Diego Pettenò (flameeyes)

Posted: January 3rd, 2009, 9:01pm CET by Diego Pettenò (flameeyes)

Posted: January 3rd, 2009, 3:12pm CET by Tobias Klausmann (klausman)

Posted: January 3rd, 2009, 3:27am CET by Diego Pettenò (flameeyes)

Posted: January 2nd, 2009, 5:30pm CET by Diego Pettenò (flameeyes)

Posted: January 2nd, 2009, 3:04pm CET by Christian Faulhammer (fauli)

Posted: January 2nd, 2009, 2:03pm CET by Christian Faulhammer (fauli)

Posted: January 1st, 2009, 6:00pm CET by Diego Pettenò (flameeyes)

Posted: January 1st, 2009, 9:02am CET by Gunnar Wrobel (wrobel)

Posted: January 1st, 2009, 1:02am CET by Gentoo News ()

Posted: December 31st, 2008, 7:08pm CET by Jeremy Olexa (darkside)

Posted: December 31st, 2008, 1:03pm CET by Christian Faulhammer (fauli)

Posted: December 31st, 2008, 9:01am CET by Josh Saddler (nightmorph)

Posted: December 30th, 2008, 2:35pm CET by Diego Pettenò (flameeyes)

Posted: December 29th, 2008, 2:44am CET by Zhang Le (r0bertz)

Posted: December 29th, 2008, 12:02am CET by Gunnar Wrobel (wrobel)

Posted: December 28th, 2008, 3:18pm CET by Diego Pettenò (flameeyes)

Posted: December 27th, 2008, 4:38am CET by Stuart Longland (redhatter)

Posted: December 26th, 2008, 12:41am CET by Diego Pettenò (flameeyes)

Posted: December 25th, 2008, 5:06pm CET by Thomas Anderson (gentoofan23)