Gentoo Linux

General
Development
Edit

News

[4054 total ]
Hanno Böck: LPIC-1

Posted about 23 hours ago by Hanno Böck (hanno)

After passing the second exam at the Linuxtag, I'm now officially allowed to call myself LPIC-1.

Hanno Böck: LPIC-1

Posted about 23 hours ago by Hanno Böck (hanno)

After passing the second exam at the Linuxtag, I'm now officially allowed to call myself LPIC-1.

Diego E. Pettenò: How _not_ to fix glibc 2.10 function collisions

Posted 1 day ago by Diego E. Pettenò (flameeyes)

Following my previous how not to fix post I’d like to explain also how not to fix the other kind of glibc 2.10 failure: function collisions.

With the new version of glibc, support for the latest POSIX C library specification is added; this ... [More] means that, among other things, a few functions that previously were only available as GNU extensions are now standardised and, thus, visible by default unless requesting a strictly older POSIX version.

The functions that were, before, available as GNU extensions were usually hidden unless the _GNU_SOURCE feature selection macro was defined; in autotools, that meant using the AC_SYSTEM_EXTENSIONS macro to request them explicitly. Now these are visible by default; this wouldn’t be a problem if some packages didn’t decide to either reimplement them, or call their functions just like that.

Most commonly the colliding function is getline(); the reason for which is that the name is really too generic and I would probably curse POSIX committees for accepting it with the same name in the C library; I already cursed GNU for adding it with that name to glibc. With the name of getline() there are over tons of functions, with the most different interfaces, that try to get lines from any kind of media. The solution for these is to rename them to some different name so that the collision is avoided.

More interesting is instead the software that, wanting to use something alike to strndup() decide to create its own version, because some system do lack that function. In this case, renaming the functions, like I’ve seen one user propose today, is crazy. The system already provide the function; use that!

This can be done quite easily with autotools-based packages (and can be applied to other build systems, like cmake, that work on the basis of understanding what the system provides):

# in configure.ac
AC_SYSTEM_EXTENSIONS
AC_CHECK_FUNCS([strndup])

/* in a private header */
#include "config.h"

#ifndef HAVE_STRNDUP
char *strndup(const char *str, size_t len);
#endif

/* in an implementation file */
#ifndef HAVE_STRNDUP
char *strndup(const char *str, size_t len)
{
[...]
}
#endif
When building on any glibc (2.7+ at least, I’d say), this code will use the system-provided function, without adding further duplicate, useless code; when building on systems where the function is not (yet) available, like FreeBSD 7, then the custom functions will be used.

Of course it takes slightly more time than renaming the function, but we’re here to fix stuff in the right way, aren’t we? [Less]

Diego E. Pettenò: Tinderbox — Correcting the aim

Posted 1 day ago by Diego E. Pettenò (flameeyes)

While I haven’t been able to do much major Gentoo work lately (but I’m still working on fixing and bumping my own packages), I’m still working hard time on the tinderbox. As I’ve said a few times, my effort never started with the intention of ... [More] being a full blown tinderbox, and only grew up from a few tests to what it is now. The work is hard, long, and heavy, but it gets results, I hope.

Stating from this month and stretching down to October, there will be quite a few packages that will be removed from the tree since they don’t build, some haven’t built in quite a few months if not years, and this should also mean faster emerge --sync (or at least, not excessively longer after a while – the main problem is that the tree is growing, but we have to cut out the dead branches).

Also, most of the issues related to the GCC 4.4 unmasking are getting pretty well known and should be getting fixed or booted out in a short while. The main trackers, for fortified sources, gcc 4.4, glibc 2.10, --as-needed and so on are, yes, pretty huge, but are also being emptied little by little. This hopefully will bring us to a much cleaner, sleeker tree.

Last night I went around fetching all the packages in the tree to make sure the tinderbox wouldn’t go waiting on the download to be completed; this alone was quite a task because it had to execute over 5700 packages (those that are queued up to be installed), and found out quite a few issues by itself; like fetch-restricted packages that didn’t use elog to output the fetch error – so you wouldn’t have a trace of why they failed to fetch! All the packages that require registration to fetch (or for which the download site was unavailable) are now masked in the tinderbox so they won’t be tried (and neither would the packages that depend on them).

There are quite a few obstacles still for a total coverage of the tree by the tinderbox; collisions are one of them, but there are also problems with cyclic dependencies, especially among Python and Ruby packages that are used for testing, and have circular dependencies with another package. All these are currently being looked at by the tinderbox with a huge performance drop. Another problem is with the dependencies that fail to build; for instance mplayer is currently failing to build because of some assembly mess-up; that in turn causes a domino effect with a huge number of other packages that tries to merge mplayer in.

To reduce the amount of stuff that will fail to merge, I’m also going to take measures for packages to be masked when I know they will cause other stuff to fail; this is the case of mplayer for instance, but also of PHP’s pear that fails (without any kind of error message) for every and each package.

Hopefully, one day most of the tree will build file and will not require me to do this kind of work… [Less]

Nathan Zachary: Buddhist Wisdom for Difficult Times (Part III)

Posted 3 days ago by Nathan Zachary (kalos)

We should find the truth in this world through our difficulties, through our suffering. This is the basic teaching of Buddhism. Pleasure is not different from difficulty. Good is not different from bad. Bad is good; good is ... [More] bad.
                    --Shunryu Suzuki Roshi
The first part of the quote seems to say that the through the tough times we can find what is real, and what is true. Roshi indicates that this sentiment is the fundamental principle of Buddhism. Though I don't know that it is the basic teaching of Buddhism, it is certainly an important pillar thereof. It is an interesting idea in that many people don't see anything positive stemming from periods of suffering. I have to wonder if it is a culturally / environmentally-inspired negativity that inhibits one from seeing anything good during tragedy, or if it is more of an aspect of human nature.

The most interesting part to me, though, is the next part of the statement. Pleasure and difficulty being one and the same is an idea that I don't believe one is willing to readily accept. Put concretely, if one was given a choice of something pleasurable (e.g. an exquisitely prepared meal) or something inherently difficult (e.g. financial struggles), it is strange to think that he or she would view the two options as being the same. However, Roshi might be trying say that we should view the positivity or negativity of either situation as pivoting on the same aspect--our perception of the event. This encourages an active and dynamic approach to truth-seeking and perception; one cannot simply sit back and watch a tragedy or great time happen. In order to fully understand our circumstances, we need complete immersion in not only our situation, but also in our perception of the situation. Then, maybe we can see the truth and the greater meaning in what is happening to us. Then, we can fully appreciate the pleasure from one moment, and the pain from another. In the end, is life a huge and continuing juxtaposition of pleasure and pain, or as Roshi indicates, are they the same steady stream?

|:| Zach |:| [Less]

Alex Legler: LinuxTag: The flyers

Posted 3 days ago by Alex Legler (a3li)

Due to popupar demand: Here are the flyers we handed out at LinuxTag:

Gentoo Flyer LinuxTag 2009 – English (PDF)
Gentoo Flyer LinuxTag 2009 – Deutsch (PDF)

Feedback for the next edition is appreciated!

Daniel Gryniewicz: Back? Was he gone?

Posted 3 days ago by Daniel Gryniewicz (dang)

Due to a number of reasons, I ended up taking a couple of weeks off from Gentoo.  I didn't go cold turkey; I kept reading my bug mails, but nothing else.  I was hoping the time off would give me a clear idea of whether I wanted to continue with ... [More] Gentoo, or if I should just give up and close that chapter of my life.

Of course, nothing is ever that easy.  I ended missing it somewhat, but also enjoying not having to deal with the crap.  So, my stated time is up, and for the benefit of everyone involved, I should probably make my mind up.  So *drumroll* I'm coming back.  (You read the title, yes?)

I'm going to try to scale back my involvement a bit, to hopefully avoid the burnout I had before.  This means I'll be officially leaving some of the herds I'm in, and orphaning some of the packages I maintain.  I'm going to stay with the Gnome herd and the fd.o herd, tho, because that's the software I use most.

As of now, I'm back on IRC, but I have to rebuild my dev box (I put Fedora on it, to play around), so I won't be able to get much done for the next couple of days.  I don't plan on reading -dev@ or -core@, although I'll read -dev-announce@.  We'll see what happens.

Oh, and all you people with hal bugs?  I'll get to them, I promise. [Less]

Steve Dibb: writing lds-scriptures docs

Posted 3 days ago by Steve Dibb (beandog)

Yesterday, I was at home, and I sat down at the computer wanting to work on something. It was Sunday, so I felt like working on one of my church projects. I pulled up nephi.org and started poking around, then I thought about getting the ... [More] lds-scriptures 3.0 release ready to go. I wasn't really in the mood to start fussing over database exports (I have to clean up the Access ones still, prepare the XML ones, and make sure the CSV ones are correct), but I did get the bug to work on the documentation a bit.

Now, when I first started working on this -- years ago, I forgot how many -- I started writing the documentation in DocBook format. And I'm so glad I did. I'm kind of amazed, looking back, that I managed to pull it off, considering how little I knew back then. I do remember, though, that putting the original scriptures release was a lot of hard work for me. I specifically wanted to learn more how to use the console, so I used a very old Dell laptop (a Pentium 1, I think) with Gentoo on it, and would only use the console to do everything. That translates to a lot of work when you're accessing PostgreSQL, MySQL and SQLite 2 and 3 all at once on the command line, but it was worth it. It really taught me a lot more about the small and large differences between each database, and how to export stuff and transfer it between the two. Not to mention just learning lots more SQL in general.

I also wrote the DocBook XML just using vim. So, yesterday, I opened up the original file, and started poking at it. The documentation isn't complex, by any means, but for a total noob to all of this, I think I did pretty well back then.

Writing documentation is one thing I take very seriously, as I think it stands as sort of a legacy over time. As long as there's a copy floating around somewhere on the web or in an old package, people will read it. As such, I put a lot of pressure on myself when writing docs of any kind. I just wanna get it right, because I know that chances are that I'll probably never come back and update it once the project is finished, so it'll be that way for a long time.

What happens though, is that the process just wears me out. It's not that it's a lot of work, it's that I just pour a lot of energy into this. On top of that, this is a project I feel really meticulous about -- not only is it religious material, but I'm documenting how I've created a database schema for the standard works of the scriptures.

Anyway. It's just one of those few projects that I really can't work on it for more than an hour at a time or so, and just get a small amount of work done before I need take a long break again. Which probably explains why I've been putting this one project off for so long, for which I feel really bad.

I have no idea why I'm writing this either, I just thought it'd be interesting to write about. I hope I can get this done soon. It really is the last leg. The schema is done, even though in my mind I fret over it and look over it and double and triple-check the whole thing making sure I didn't miss anything. I can, of course, do a release update if I really did miss something, but this is one of things where I just want everything to be just right.

I realize it sounds kind of corny, only because I've always kind of been confused by the concept, but I guess this would be one of those "for God" things. Like, "skating for God" comes to mind (important point: that's not me or my video -- I'm not that good at skating, heh. Just found it on youtube.). I've grown up Christian, but I didn't really get a good feel for what other denominations other than our own was like -- something I deeply regret to this day (Even though I live in Utah, I didn't move here til I was about 22. I grew up in Missouri, Indiana and Georgia). As such, I wouldn't say I have intolerance for other religions, just a bit of social curiosity. What seems normal, culturally, to others in their faiths, seems a bit odd to me. I really wish I had a chance to grow up, around, and with people of other faiths more.

The whole concept kind of just clicked for me though -- it's basically just trying to do the very best you can with your limited talents and skills, and have the work dedicated to the Lord -- or more specifically, to building up His kingdom on earth.

It may seem like "skating for God" would be, in that vein, pretty irrelevant, but the fact of the matter is that anytime you build yourself or anyone else up, you are building the kingdom of God (Cue a quote from some religious talk I can vaguely remember). That's the real reason this is taking so long, quite honestly, is that all this is for Him. It's a dedicatory work.

Well, I really didn't intend to go off on a tangent like that, but now you know how I feel about some of the stuff I work on.  I'm still not really sure how I feel about it, or how this all mixes together.  In fact, merging a religious lifestyle and a cultural lifestyle has always been a confusing topic for me.  I actually like the way evangelists carry it in their lives so much, and make it such a positive aspect of their life all the time, and so freely talk about it.  There's definitely some characteristics like that I'd like to apply in my life. [Less]

Diego E. Pettenò: Identifying pointless .la files for plugins

Posted 3 days ago by Diego E. Pettenò (flameeyes)

At this point I expect most users to know that .la files are evil and they are often useless and that removing them can save you from having to do work when packages drop them, either upstream or in Gentoo. Unfortunately, most developers tend to be ... [More] overly conservative and keep them around even when not needed even remotely.

One of the cases for which I have said times and times again that .la files should be removed is for plugins; the .la files for plugins are useful when you use libltdl to wrap around plugins loading (and not even needed), but are totally pointless when using the straight dlopen() call.

Unfortunately even when that’s the case, it’s hard for ebuild developers to feel confident that the files are unneeded, so here it comes a practical case study to identify when they are not used at all. First step is to decide which package to test; I’ll go with eog since I have noticed this before and I know they are not used.

The eog package installs some .la files:

% qlist eog | fgrep .la
/usr/lib64/eog/plugins/libreload.la
/usr/lib64/eog/plugins/libstatusbar-date.la
/usr/lib64/eog/plugins/libfullscreen.la
Now we can see that the eog/plugins directory is where it’ll be looking for plugins, so we’ll start eog through strace and see if it tries to load any of that:

% strace -e open eog |& fgrep eog/plugins
open("/usr/lib64/eog/plugins/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 14
open("/usr/lib64/eog/plugins/reload.eog-plugin", O_RDONLY) = 15
open("/usr/lib64/eog/plugins/statusbar-date.eog-plugin", O_RDONLY) = 15
open("/usr/lib64/eog/plugins/fullscreen.eog-plugin", O_RDONLY) = 15
A quick look at the strace outout can let us see that it’s not loading the plugins at all; indeed in this case eog was started without any plugin enabled, and it only opened the .eog-plugin files, which are ini-like files describing the plugins and their information; I’ll write more about this in the future when I’ll resume my posts about plugins which I’ve been slacking off from for a while. So let’s enable some plugins (all three of them!) and try again.

% strace -e open eog |& fgrep eog/plugins
open("/usr/lib64/eog/plugins/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 14
open("/usr/lib64/eog/plugins/reload.eog-plugin", O_RDONLY) = 15
open("/usr/lib64/eog/plugins/statusbar-date.eog-plugin", O_RDONLY) = 15
open("/usr/lib64/eog/plugins/fullscreen.eog-plugin", O_RDONLY) = 15
open("/usr/lib64/eog/plugins/libreload.so", O_RDONLY) = 16
open("/usr/lib64/eog/plugins/libstatusbar-date.so", O_RDONLY) = 16
open("/usr/lib64/eog/plugins/libfullscreen.so", O_RDONLY) = 16
Now it looks better: it loads the .so directly; what does this mean? Simple: the package is most likely using dlopen() and not at all the libltdl wrapper. The .la files are not looked at, at all, so they can be removed without thinking twice.

With this method you can ensure that the .la files are just and only a side effect of using libtool rathre than something that is actually used by the software; to do that, though, you’ve got to make sure that the .so is at least loaded, otherwise you might not have loaded plugins at all (see the first output above).

Another common mistake is to consider the .la files needed or not depending on libltdl linking; this is not true in either case: software not linking to libltdl might make use of the .la files (kdelibs 3 for instance have their internal libltdl modified copy), and software using libltdl might not need .la files (PulseAudio for instance, that does not install .la files at all, in Gentoo).

This post brought to you by having so much work to do that just 2% of my actual mind was free! [Less]

Stuart Longland: I’m Baaaaaaack…

Posted 4 days ago by Stuart Longland (redhatter)

It has been a while, but I can safely say I have returned.  Not sure what the next step is… looking for paid employment I guess, but I have passed all subjects this semester, which should mean that I am now qualified in IT and Electrical ... [More] Engineering as a graduate.

After the last exam, I could not run out of the building fast enough.  6.5 years of studies has certainly taken its toll on my mental state.  Anyway… I wound up traveling northern and central NSW with my father and his girlfriend for the last fortnight — got back home yesterday.  I am currently putting together some photos, and I’ll have a slide show ready for the next BOSQ meeting.  I’ll put a link up to the photos when they’re done processing (the aging PIII 550MHz webserver here takes a while to resize over 500 photos, most 10Mpixel in size).

Where did we go?  We camped at:

Dalmorton (abandoned settlement on the old Grafton-Glen Innes road) — overnight
Glen Innes — overnight
Bingara — overnight
Waa Gorge (pronounced “war”, part of Mt. Kaputar National Park… you’re not supposed to camp here, but it was late in the day, and the road in/out passes through private property with many gates) — overnight
Mt. Kaputar National Park — 3 nights
Coonabarabran — 2 nights
Port Macquarie — 3 nights
Dorrigo — overnight
Grafton — overnight
Brooms Head — overnight

In that time:

We explored a number of walking tracks at Mt. Kaputar, Dorrigo and Brooms Head.
Did some sight seeing at Port Macquarie and Coonabarabran.
Checked out the sandstone caves in the Pilliga State Reserve
Got bogged on a forestry road in state forest just north of Coffs Harbour (thanks go to the Clarence Valley State Emergency Service for pulling us out of that muddy mess)
HanoiCalc got a bit of work done — it works now.
I checked into three nets:

Ipswich & District 80m Net (3.585MHz LSB) from Waa Gorge
AWNOI Net (3.595MHz LSB) from Mt. Kaputar
Coffs Harbour & District 2m Net (146.650MHz FM) whilst waiting for the SES to arrive

We learned:

Setting up the annex and awning on a hard-floor camper trailer for an overnight stay is a pain in the bum.
My camp stretcher doesn’t fit in the camper itself, and only barely fits in the annex.
Holden (or Zupps) decided to put a really low tow hitch on the back of my father’s car… meaning we had to either find rocks/blocks of wood/bricks to back the car’s back wheels on to, or dig a hole just near the jockey wheel in order to unhitch from the trailer
Just because a road is marked on a GPS or paper based map, does not mean that it is in drivable condition, nor does it necessarily mean the road’s actual route bares any resemblence to the marked route.
The NRMA do not assist people who are bogged, they refer you to the SES instead.  (I hope some of the fees we’re paying are helping fund the SES for their troubles!)
My HF radio, which is normally very touchy on 10m… works fine on that band up in the higher altitudes — I suspect a temperature-related issue.

What now?  Well… as I say, I’ve got to find some employment somewhere.  I now officially become “unemployed” according to the damn lies^W^Wstatistics.  Potential employers in the Brisbane area, should contact me directly.

This also means I should have some time to dedicate towards Gentoo.  My last attempt at stage builds got sidetracked by a need to study and also hit technical issues (something in glibc’s build kept hard-locking boxes).

Also on the agenda here is a proper port of Gentoo to the Lemote Yeeloong.  The little netbook has been running well under Debian, with Gentoo sitting in a chroot environment… now that I’m no longer using the machine for daily studies, I think the time is ripe to start looking into reloading the machine.  Zhang Le did a great job incorporating Lemote’s patches into a mirror of the Linux/MIPS git tree, which I’ve been using to build my kernels… 2.6.30-rc4 has been quite stable.

I’ve also been looking at the ARRL handbook, with the view of upgrading my license to the Advanced level.  Then I’ll be paying for a 5-year license before the ACMA/WIA decide to up the fees again.

So, much to do, and a mountain of bugs in Bugzilla with my name on them… Ohh joy. [Less]