Aggregatore notizie

What: Larry the cow t-shirt graphics contest ...

Where: irc.freenode.net, #gentoo-artwork

Starts: Wed, Sep 01, 2010

Ends: Sun, Oct 31, 2010

Introduction:

Larry the cow is our prized mascot and he is not getting the respect he deserves. Just about every other Linux distribution, their mascot is adorned on t-shirts and other types of schwag, but not our Larry, he cannot even decide his gender. Please help up fix this terrible injustice by entering our contest and provide Larry the graphics he deserves. For more information visit this Forum Post.

The top 3 contestants will receive three t-shirts in their design, donated by the Gentoo Foundation. The judging panel includes Dawid Węgliński, Alex Legler, and your host David Abbott.

Requirments:

Preferred format is scalable vector graphics (SVG) but any of the industry standard vector graphics formats will be accepted.

How to Enter?

Please email your graphics to artwork@g.o

1. By making a submission to the contest, you agree to give unlimited, non-exclusive rights to the Gentoo Foundation for your submission.
2. This may include relicensing or trademarking the content the if required to protect it from unfair commercial usage.
3. You may, at your own discretion, also provide the content to any other party under some form of open license (including, but not limited to the full range of Creative Commons licenses, including re-sampling)
4. The Foundation needs to be informed of any future licensing.

Greetings! Today we have an excellent interview of two fine gentlemen, Mr. David Gallo and Mr. Cassius Adams from SevenL Networks Inc., conducted by our very own Joshua Saddler.

For those of you that have been around awhile, you will recognize the company represented in this interview. SevenL Networks Inc. has been an infrastructure sponsor for over six years now. David and Cassius took some time to fill us in on their use of Gentoo throughout their extensive operations. We hope you enjoy reading the complete interview which you will find here.

Discuss this!

What? Free and Open Source Software Conference (FrOSCon) - 5th year

When? 21st, August 2010 - 22nd, August 2010

Where? Hochschule Bonn-Rhein-Sieg | Grantham-Allee 20 53757 | Sankt Augustin, Germany

FrOSCon 5 is almost here, and Gentoo will be there!

Free Software and Open Source – these are the topics of FrOSCon. Many exciting programs with talks, workshops and an exhibition, supported by LUUSA and FrOSCon e.V. The Saturday night social event gives you the opportunity to exchange opinions with other visitors, speakers or volunteers.

Whether you're a developer, user, or simply curious, be sure and stop by our Gentoo booth. We will have Gentoo and Larry t-shirts, plus much more! See you there!

Long live Gentoo! As the quantity and quality of this year's entries will attest, Gentoo is alive, well, and taking no prisoners!

Thanks to everyone who entered the contest. There were 103 total entries using 7 different window managers and desktop environments.

The Winners

1. Nickname: Chopinzee. Desktop: E17 built from the official EFL overlay.

2. Nickname: whtwtr. Name: Shawn H. Desktop: Compiz window manager with the Xfce panel.

3. Nickname: GentooApologetin. Desktop: Custom Xfce.

4. Nickname: shpaq. Name: Michał Laszuk. Desktop: Gnome with the Gant icon theme.

5. Nickname: nm. Desktop: dwm (simplicity is elegance).

For all the specifications and cool details please visit the main Gentoo screenshots page. Make sure to check out all the entries!

discuss this!

LinuxTag 2010 runs from June 9th to June 12th in Berlin, Germany. With more than 10,000 visitors last year, it is one of the biggest Linux and open source events in Europe.

You will find the Gentoo booth at Hall 7.2a, Booth 203a. Come and visit us! You will meet many of our developers and users, talk with us, plus get some of the Gentoo merchandise you have always wanted.

Discuss this!

Alex Legler contributed the draft for this announcement.

After the success of the 2009 Screenshot Contest the Contest Team is doing it again!

Gentoo Users, Developers, and Staffers are encouraged to submit their sweetest screenshots. Please head over to the 2010 Contest Page for all of the details.

You can visit this forum post for comments and suggestions. OK enough talk, get started tricking out that desktop.

On June 26th we again invite you to take part in this year's bike ride: "Gentoo White Nights in Russia". Gentoo White Nights is a nighttime bike ride along the most beautiful city in the world - St. Petersburg - in the most magical time - the White Nights.

As last year's experience showed, it's possible to ride in the rain, so the event will take place regardless of weather. The event will take place during the night from 26th to 27th June this year. The starting point is the Moskovsky railway station at 10:00 PM. If you'd like to join the Gentoo White Nights, contact Andrey Surganov or Alexey Shetsov.

Andrey Surganov contributed the draft for this announcement.

Bookkeeper, Accountant, or CPA

And that means? We are looking for help from the Gentoo Community to help us in Accounting/Finance. We are in the process towards the goal of tax-exempt status with the United States Internal Revenue Service as a non-profit corporation. If this is your background, we could really use your help.

Please contact trustees@gentoo.org or visit Gentoo Foundation for details.

Today we have an interview with Andrzej Wasylkowski, and since August 2005 he has been a PhD student at the Software Engineering Chair at Saarland University, Saarbrucken, Germany. His research field is software engineering, with strong focus on program analysis techniques and their application to automatic defect detection.

One of the projects he is involved in is checkmycode, which is a service that allows you to compare your code with the "wisdom of the crowds", over 200 million lines of C code from the Gentoo Linux distribution.

Please continue on and read the complete Andrzej Wasylkowski interview and learn all about the project and its use of Gentoo!

Gentoo has been accepted for its 5th consecutive year in the Google Summer of Code! GSoC pays college students $5000 to work full-time on an open-source project for a summer. Check out our GSoC 2010 homepage if you are interested in this year's GSoC for Gentoo. We particularly encourage applications from students who aren't already involved in Gentoo development—many of our students become Gentoo developers after a successful summer.

Interested students can browse Gentoo's project ideas. Student applications will be accepted starting March 29.

Developers, if you'd like to apply to be a mentor, you can do so on the webapp. Please read the mentoring guide before applying.

I was looking around for desktop search frameworks today, specifically something with a gtk frontend and that required the fewest resources to run.

I discovered Pinot, a dbus-based file index/monitor/search tool. It even comes with a minimal gtk+ interface. I found few reviews on Pinot, and even fewer recent reviews comparing it to other search frameworks like Strigi, Tracker, and Beagle. I also discovered Catfish, a lightweight frontend to several different search services. There's not much out there on integrating Catfish and Pinot, so I forged ahead and wrote my own code, then did some trial-and-error experiments.

All ebuilds are available on my overnight overlay. Instructions for adding the overlay are on the wiki.

Writing the ebuilds

The only ebuild I found for Pinot is sadly out-of-date, and is completely incorrect. Also, it depends on libtextcat, and I never found an ebuild for that.

So, I wrote my own ebuilds for the latest versions of Pinot and libtextcat.

Not content with Pinot's minimal gtk+ interface, I decided to try Catfish, a PyGtk frontend for several different search engines, including Pinot. Catfish is made by the same developer of Midori, a well-respected lightweight WebKit browser. While Catfish's development has been stalled for two years, I figured it was worth a shot, since its user interface is friendlier than Pinot's.

Catfish, like Pinot and libtextcat, is not in Portage, but there is an open bug for its inclusion. However, the ebuild for the latest version needed updating, as it didn't include Strigi or Pinot. So I rewrote it and added descriptive metadata.xml entries for Catfish's and Pinot's USE flags.

There's still a bit of work left on the Catfish ebuild, since there's a QA warning about not leaving precompiled Python object files in /usr/share/catfish. However, the application itself works perfectly. Just need to clean up the install process so that the bytecode doesn't clutter up the filesystem.

Pinot

On first run, Pinot will take a long time to index your files. I pointed it at my user's /home/ directory, which contains 51,000+ files, totaling 9.3GB on a Reiser3 filesystem with tail enabled. That operation took probably half an hour, and that's on a fast SSD! All of Pinot's indexes and databases take up 455MB, bringing my total /home/ usage to about 9.7GB. Pinot typically used about 50% of my CPU while doing so, sometimes dropping down to the 20s and 40s.

However, since Pinot is on a fast SSD, and it's running off a 2.3Ghz dual-core Athlon backed by 4GB RAM, I didn't notice any performance hit while indexing. I'm not running any special kernels or schedulers (like BFS) either; just vanilla-source-2.6.35.4. There was no noticeable lag or slowdown, despite viewing two Thunar windows, working with four terminals, and browsing nine Firefox tabs. My system was only laggy when compiling Pinot and its dependencies.

Once my /home/ was indexed, I searched around. Queries were pretty much instantaneous. There's no easy way to measure the speed of each query, since it's much too fast to time with a stopwatch. That's probably mostly because of the SSD -- as it is, without a desktop indexer/search app, most similar queries take less than a second. Once the initial filesystem index is complete, Pinot drops back to just monitoring directories if you've told it to do so, relying on the inotify feature in the kernel. That drops CPU and memory usage to zero, as near as I can tell. Nice!

Pinot's greatest advantage on my system, at least, is not its speed, but its usefulness for easily finding deeply buried files and folders.

Interestingly, even though Pinot by default is not supposed to index Git, CVS, or SVN repositories, it seems to ignore that setting. Searching for "catfish" turns up a document named catfish tricks and all the ebuilds and git logs that have "catfish" in the title. Apparently Pinot's regex filter isn't very reliable. I probably need to add in another asterisk to disable searching or indexing of any files within a git directory.

Catfish

Catfish mostly works as expected, though it defaults to using "find" rather than "pinot" as its search engine. I haven't yet found a way to set it to use Pinot as the default search provider. Catfish is quick to load, and its layout is fairly intuitive. Sometimes, however, it will just stop working with Pinot, and even though Pinot has indexed my entire home directory, Catfish won't return any search results, though I can get those results by using Pinot's interface. The rest of the time it works great.

Besides offering a friendlier UI for searches, Catfish's real strengths are its useful options, both for presentation and for tying in with my desktop's filemanager. With a couple of commandline switches, Catfish can display thumbnails of various filetypes, use larger icons in search results, use various wrappers for opening and working with files, or even use powerful regex search methods. No, it won't have the awesome preview capabilities of Gloobus, but you also don't have to install all of Gnome to get similar features.

Right out of the box, Catfish will allow you to open files and folders obtained from your search results just by clicking them. I don't know if that works for all filemanagers, but it works with Thunar, which is all I ask.

I like to use Catfish in combination with another powerful feature of Thunar: custom actions. Since Thunar lacks a built-in search bar (aside from a rudimentary go-to alphabetical list when you press a key), how do you integrate a search utility? One way is by adding search functions to the right-click menu.

1. Open a Thunar window, and go to Edit -> Configure custom actions.
2. Click the plus icon: +. Give the action a helpful title, description, and icon. "Search" is pretty standard among icon sets, so there should always be one available even when you change themes.
3. Add the action command: catfish --path=%F
4. Now go to the Appearance Conditions tab. I left the file pattern as * and checked all boxes, so that no matter where I browse or click, I can launch a Catfish search.
5. Save the new action and exit Thunar. The next Thunar window you launch will let you right-click anywhere in the browser to open a Catfish search.

You can add any commandline switch you like to the catfish command; just run catfish --help to see the available options.

Thunar's custom action feature is pretty nifty; there are all kinds of things you can put in the context menu. It comes with an example to open a terminal in the current directory. You can create actions to launch applications with a root prompt, convert one image type into another, play media, print or email documents, and more. If you can script it, you can write a trigger for it and stick it in the context menu. Just read the custom actions documentation for many more examples of what you can do with Thunar. Neat!

Looking forward

So, will I keep using Pinot and Catfish? Possibly. While I am leery of any process like Pinot that writes so often to my SSD, and I'm not at all happy with its database size compared to my actual directory size, I do like that it's fast, and responsive. It doesn't seem to have the huge memory leaks or lag that Strigi/Nepomuk do in KDE. In fairness, KDE is trying to get us to believe in the power of the "semantic desktop," while Pinot and Catfish just want to create an easy frontend for finding stuff, without worrying about associating them with various files or activities.

As long as the database doesn't get too much larger, or the indexing/monitoring services use too many resources, I'll keep it around. I've got five+ years of accumulated files in various folders, with more constantly being loaded to and from offline backups. Pinot and Catfish can help with my hard drive spring cleaning, and help me locate stuff that I've just plain forgotten about. The older you get, the less you remember, right?

What I'd really like is a search bar built-in to Thunar, maybe in the upper right corner, backed by Pinot. That'd place everything I need right up front, without having to drill down through right-click menus.

* * *

Speaking of Thunar:

Do you use Thunar? Do you use Dropbox? Xfce developer Mike Massonnet posted a message to the xfce-dev list this morning with a link to a new project: Thunar Dropbox. It integrates the Dropbox service right into your favorite lightweight filemanager. No longer do you have to run Nautilus just to use Dropbox easily. Now you can use it within Thunar.

Original post from Planet Gentoo.

Part of today’s KDE Team meeting:

KDE 4.5 status and plans to put it in Portage

We agreed that KDE 4.5.1 is suffering of some important bugs, and after a long discussion we decided to put it in portage, but it will never make it to stable branch. We are mentioning the upstream bugs, as we think that users should be aware of them before updating:

• https://bugs.kde.org/show_bug.cgi?id=247144
• https://bugs.kde.org/show_bug.cgi?id=246931
• https://bugs.kde.org/show_bug.cgi?id=230247 <-The most important

Also, keep in mind that KDE SC 4.5 lacks the KDEPIM suite, so users should use KDEPIM 4.4.5 instead, which is also stable in portage tree.

In case of an update it should be smooth.

The whole summary and log can be found at the KDE project space.

The Qt Team also had a meeting one our later, summary and logs at the Qt project space

=-=-=-=-=
Powered by Blogilo

What: Larry the cow t-shirt graphics contest ...

Where: irc.freenode.net, #gentoo-artwork

Starts: Wed, Sep 01, 2010

Ends: Sun, Oct 31, 2010

Introduction:

Larry the cow is our prized mascot and he is not getting the respect he deserves. Just about every other Linux distribution, their mascot is adorned on t-shirts and other types of schwag, but not our Larry, he cannot even decide his gender. Please help up fix this terrible injustice by entering our contest and provide Larry the graphics he deserves. For more information visit this Forum Post.

The top 3 contestants will receive three t-shirts in their design, donated by the Gentoo Foundation. The judging panel includes Dawid Węgliński, Alex Legler, and your host David Abbott.

Requirments:

Preferred format is scalable vector graphics (SVG) but any of the industry standard vector graphics formats will be accepted.

How to Enter?

Please email your graphics to artwork@g.o

1. By making a submission to the contest, you agree to give unlimited, non-exclusive rights to the Gentoo Foundation for your submission.
2. This may include relicensing or trademarking the content the if required to protect it from unfair commercial usage.
3. You may, at your own discretion, also provide the content to any other party under some form of open license (including, but not limited to the full range of Creative Commons licenses, including re-sampling)
4. The Foundation needs to be informed of any future licensing.

In this Podcast comprookie attempts to explain some tips on staying motivated.

Larry the cow is Gentoo's prized mascot and he is not getting the respect he deserves. Just about every other Linux distribution, their mascot is adorned on t-shirts and other types of schwag, but not Larry, he cannot even decide his gender. Please help up fix this terrible injustice by entering the Gentoo Larry Graphic's Contest and provide Larry the graphics he deserves.

LINKS:
Motivation
http://gentoo-pr.org/node/29

Larry Graphics Contest
http://www.gentoo.org/news/20100901-larry-contest-announcement.xml

OpenRC
http://www.gentoo.org/proj/en/base/openrc/index.xml

Gentoo Live DVD
http://www.gentoo.org/proj/en/pr/releases/10.0/faq.xml

Download

Today I discovered another linux kernel patchset/fork that attempts to bring many features not in mainline together, called pf-kernel.

Quoting from its website:

“pf-kernel is another Linux kernel fork, that provides you with new useful features, that are not merged into mainline. It’s not based on any existing Linux fork or patchset, but some parts of Zen kernel may be merged if there’s no official release of needed patch. The name of this fork is not connected with BSD Packet Filter. «pf» means «post-factum» in the short form.”

At this point the latest patchset includes the following:
* mainline update: 2.6.35.4
* -ck patchset (BFS included)
* BFQ
* TuxOnIce
* LinuxIMQ

Its main advantage over other forks seems to be that it’s regularly updated

I’m using it on my main system without any issues, so I added it to Gentoo’s tree:

* sys-kernel/pf-sources
Available versions:
(2.6.31_p9) (~)2.6.31_p9!b!s
(2.6.32_p16) (~)2.6.32_p16!b!s
(2.6.33_p4) (~)2.6.33_p4!b!s
(2.6.34_p7) (~)2.6.34_p7!b!s
(2.6.35_p7) (~)2.6.35_p7!b!s
{build deblob symlink}
Homepage: http://pf-kernel.org.ua/
Description: Linux kernel fork with new useful features not merged into mainline

Many thanks to Oleksandr for taking the time to create and maintain it

What ties in reckless glibc unmasking GTK+ 2.20 issues Ruby 1.9 porting and --as-needed failures all together? Okay the title is a dead giveaway for the answer: undefined symbols.

Before deepening within the topic I first have to tell you about symbols I guess; and to do so, and to continue further, I’ll be using C as the base language for everyone of my notes. When considering C, then, a symbol is any function or data (constant or variable) that is declared extern; that is anything that is neither static or defined in the same translation unit (that is, source file, most of the time).

Now, what nm shows as undefined (U code) is not really what we’re concerned about; for object files (.o, just intermediate) will report undefined symbols for any function or data element used that is not in the same translation unit; most of those get resolved at the time all the object files get linked in to form a final shared object or executable — actually, it’s a lot more complex than this, but since I don’t care about describing here symbolic resolution, please accept it like it was true.

The remaining symbols will be keeping the U code in the shared object or executable, but most of them won’t concern us: they will be loaded from the linked libraries, when the dynamic loader actually resolve them. So for instance, the executable built from the following source code, will have the printf symbol “undefined” (for nm), but it’ll be resolved by the dynamic linker just fine:

I have explicitly avoided using the fprintf function, mostly because that would require a further undefined symbol, so…

Why do I say that undefined symbols are our worst enemy? Well, the problem is actually with undefined, unresolved symbols after the loader had its way. These are either symbols for functions and data that is not really defined, or is defined in libraries that are not linked in. The former case is what you get with most of the new-version compatibility problems (glibc, gtk, ruby); the latter is what you get with --as-needed.

Now, if you have a bit of practice with development and writing simple commands, you’d be now wondering why is this a kind of problem; if you were to mistype the function above into priltf – a symbol that does not exist, at least in the basic C library – the compiler will refuse to create an executable at all, even if the implicit declaration was only treated as a warning, because the symbol is, well, not defined. But this rule only applies, by default, to final executables, not to shared objects (shared libraries, dynamic libraries, .so, .dll or .dylib files).

For shared objects, you have to explicitly ask to refuse linking them with undefined reference, otherwise they are linked just fine, with no warning, no error, no bothering at all. The way you can tell the linker to refuse that kind of linkage is passing the -Wl,--no-undefined flag; this way if there is even a single symbol that is not defined in the current library or any of its dependencies the linker will refuse to complete the link. Unfortunately, using this by default is not going to work that well.

There are indeed some more or less good reasons to allow shared objects to have undefined symbols, and here come a few:

Multiple ABI-compatible libraries: okay this is a very far-fetched one, simply for the difficulty to have ABI-compatible libraries (it’s difficult enough to have them API-compatible!), but it happens; for instance on FreeBSD you – at least used to – have a few different implementations of the threading libraries, and have more or less the same situation for multiple OpenGL and mathematical libraries; the idea behind this is actually quite simply; if you have libA1 and libA2 providing the symbols, then libB linking to libA1, and libC linking to libA2, an executable foo linking to libB and libC would get both libraries linked together, and creating nasty symbol collisions.

Nowadays, FreeBSD handles this through a libmap.conf file that allows to link always the same library, but then switch at load-time with a different one; a similar approach is taken by things like libgssglue that allows to switch the GSSAPI implementation (which might be either of Kerberos or SPKM) with a configuration file. On Linux, beside this custom implementation, or hacks such as that used by Gentoo (eselect opengl) to handle the switch between different OpenGL implementations, there seem to be no interest in tackling the problem at the root. Indeed, I complained about that when --as-needed was softened to allow this situation although I guess it at least removed one common complain about adopting the option by default.

Plug-ins hosted by a standard executable: plug-ins are, generally speaking, shared objects; and with the exception of the most trivial plugins, whose output is only defined in terms of their input, they use functions that are provided by the software they plug. When they are hosted (loaded and used from) by a library, such as libxine, they are linked back to the library itself, and that makes sure that the symbols are known at the time of creating the plugin object. On the other hand, when the plug-ins are hosted by some software that is not a shared object (which is the case of, say, zsh), then you have no way to link them back, and the linker has no way to discern between undefined symbols that will be lifted from the host program, and those that are bad, and simply undefined.

Plug-ins providing symbols for other plug-ins : here you have a perfect example in the Ruby-GTK2 bindings; when I first introduced --no-undefined in the Gentoo packaging of Ruby (1.9 initially, nowadays all the three C-based implementations have the same flag passed on), we got reports of non-Portage users of Ruby-GTK2 having build failures. The reason? Since all the GObject-derived interfaces had to share the same tables and lists, the solution they chose was to export an interface, unrelated to the Ruby-extension interface (which is actually composed of a single function, bless them!), that the other extensions use; since you cannot reliably link modules one with the other, they don’t link to them and you get the usual problem of not distinguish between expected and unexpected undefined symbols.

Note: this particular case is not tremendously common; when loading plug-ins with dlopen() the default is to use the RTLD_LOCAL option, which means that the symbols are only available to the branch of libraries loaded together with that library or with explicit calls to dlsym(); this is a good thing because it reduces the chances of symbol collisions, and unexpected linking consequences. On the other hand, Ruby itself seems to go all the way against the common idea of safety: they require RTLD_GLOBAL (register all symbols in the global procedure linking table, so that they are available to be loaded at any point in the whole tree), and also require RTLD_LAZY, which makes it more troublesome if there are missing symbols — I’ll get later to what lazy bindings are.

Finally, the last case I can think of where there is at least some sense into all of this trouble, is reciprocating libraries, such as those in PulseAudio. In this situation, you have two libraries, each using symbols from one another. Since you need the other to fully link the one, but you need the one to link the other, you cannot exit the deadlock with --no-undefined turned on. This, and the executable-plugins-host, are the only two reasons that I find valid for not using --no-undefined by default — but unfortunately are not the only two used.

So, what about that lazy stuff? Well, the dynamic loader has to perform a “binding” of the undefined symbols to their definition; binding can happen in two modes, mainly: immediate (“now”) or lazy, the latter being the default. With lazy bindings, the loader will not try to find the definition to bind to the symbol until it’s actually needed (so until the function is called, or the data is fetched or written to); with immediate bindings, the loader will iterate over all the undefined symbols of an object when it is loaded (eventually loading up the dependencies). As you might guess, if there are undefined, unresolved symbol, the two binding types have very different behaviours. An immediately-loaded executable will fail to start, and a loaded library would fail dlopen(); a lazily-loaded executable will start up fine, and abort as soon as a symbol is hit that cannot be resolved; and a library would simply make its host program abort at the same way. Guess what’s safer?

With all these catches and issues, you can see why undefined symbols are a particularly nasty situation to deal with. To the best of my knowledge, there isn’t a real way to post-mortem an object to make sure that all its symbols are defined. I started writing support for that in Ruby-Elf but the results weren’t really… good. Lacking that, I’m not sure how we can proceed.

It would be possible to simply change the default to be --no-undefined, and work around with --undefined the few that require the undefined symbols to be there (we decided to proceed that way with Ruby); but given the kind of support I’ve received before in my drastic decisions, I don’t expect enough people to help me tackle that anytime soon — and I don’t have the material time to work on that, as you might guess.

What: Gentoo Council Meeting of 8 March 2010.

Voting by email

Ideas seemed to converge on how to vote by email but it was noted that this would constitute a change of GLEP39 which the council can't modify without an all-developers vote. Since there were already other changes planned or suggested to GLEP 39 it was decided that the council would work on a new text and submit it to a vote when ready. Calchan has volunteered to gather all ideas and work on the text.

Do we want a policy for changes in metadata.xml?

Adding such information to metadata.xml was considered a bad idea for two reasons: this information is of no use to the users and would bloat the file for no good reason, and it would be a technical answer to a mostly social problem. It was suggested that reducing territoriality could help. Ideas were proposed like making it official that after sending an email to the maintainers and waiting one week anybody could touch a package.

In the end it wasn't clear what exact problem was to be solved. So scarabeus volunteered to animate the discussions on the mailing list. The goal is to find out what the source of the problem is and what solution(s) we can apply.

For more information, read the summary or the complete IRC log.

Observant viewers may notice that I’ve begun uploading some of the stage tarballs. The first of the stages built is the stage 1 tarball for MIPS-I little-endian. Stage 2 is building as I type this, hopefully by this weekend it’ll be uploaded and stage 3 will be on its way.

I’ll let you know when all the MIPS-I little-endian builds are done, that way you won’t wind up downloading a partially uploaded file. That said, should you jump the gun, you should be able to resume the download to fetch the remainder. I’ve started with MIPS-I since that’s the lowest-common-denominator … MIPS-III will be next, followed by MIPS-IV.

I plan to get onto the big-endian port shortly. SGI owners have not been forgotten, just I’ve been busy.

Greetings! Today we have an excellent interview of two fine gentlemen, Mr. David Gallo and Mr. Cassius Adams from SevenL Networks Inc., conducted by our very own Joshua Saddler.

For those of you that have been around awhile, you will recognize the company represented in this interview. SevenL Networks Inc. has been an infrastructure sponsor for over six years now. David and Cassius took some time to fill us in on their use of Gentoo throughout their extensive operations. We hope you enjoy reading the complete interview which you will find here.

Discuss this!

The Gentoo Prefix project is still alive and still kicking. There has not been any major noteworthy highlights so you may not heard from us in some time. The number of users increases and the number of active contributors seems to stay the same or increase much more slowly. Gentoo Prefix was the reason I become a Gentoo Linux developer, so get involved..it is an easy gateway to being a Gentoo Developer if you are interested.

Some interesting things to note that I have been working on:

• My ~x86-linux binpkg repo for Gentoo Linux hosts is still running every night. I use this to easily find simple build errors in packages before they hit too many users.
• I started a ~amd64-linux binpkg repo to add coverage to my nightly automated testing. So, I’ve updated the instructions from the above post. This means that you can install your very own Gentoo Prefix installation on a Gentoo Linux host in 5 minutes for 32bit or 64 bit now.
• While those are updating everynight. I am now bootstrapping everynight too. I set up a small script that debootstraps a Debian Lenny chroot and then sets up an Gentoo Prefix inside the chroot. This will help finding bootstrapping bugs that brand new users may hit. Often times bootstrapping is more sensitive/fragile to tree changes than just updating.
• We are still migrating packages from the Gentoo Prefix tree to the Gentoo Linux tree. This is going slower than planned but there are not too many people working on it. Current: Over ~2000 packages migrated, still over 700 to go in our overlay. (Gentoo Prefix tree has over 7000 packages in it, but not all are tested/keyworded.)