With 2.6.22 wireless drivers got broken again. They need both a driver patch and an Ebuild CONFIG_CHECK update. The CONFIG_CHECK variable is used to check for a configuration option in the kernel. Previously wireless users had to enable

Wireless LAN drivers (non-hamradio) & Wireless Extensions (CONFIG_NET_RADIO).

That option then enabled the hidden option WIRELESS_EXT. Now with 2.6.22 you need to enable that separately:

Symbol: WIRELESS_EXT [=y]
Prompt: Wireless extensions
Defined at net/wireless/Kconfig:4
Depends on: NET && !S390
Location:
-> Networking
-> Networking support (NET [=y])
-> Wireless

Not yet patched drivers
Drivers need updates for 2.6.22 and many upstream driver developers do not release prior to the upstream kernel or shortly after. That is why we need patches to add them to the Ebuilds. If you have such a non working ebuild please get a patch to me through bugs.gentoo.org and assign it to mobile.

mac80211
For some drivers that do not work in kernel 2.6.22 you have the option to use mac80211, you can find it in the sunrise overlay currently:
emerge -va layman
echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf
layman -f -a sunrise

Then depending on the driver you need:
emerge rt2x00-git or
emerge iwlwifi

You do not need to enable mac80211 in the kernel, because it will use the external package provided by Intel.

Open Souce Software is about contributing code to the original sources. Ideally that code would be integrated by the developer quickly. When that is not done good usually a fork happens or a semi-fork(plugin, code-patch ..) happens.

For Gentoo some semi-forks have already happened where the process of integrating contributed code is not good/efficient/quick enough, there we need to improve our processes:

- ebuilds in overlays, we have a lot of overlays today

This increae is clearly due to the fact that we are not able to recruit developers in a reasonable timeframe. Thus they are forced to develop externally and force all of our users to add an overlay for popular applications.

The big step that we need to do here is to offer more external Gentoo developers to get @gentoo.org adresses and the official "Gentoo developer" status. The main problems holding that up as I observe are a) externals being slow on quizzes and b) devrel being slow in checking quizzes. Maybe devrel should put out another call for new recruiters when they know they are short of those.

- gentoo-wiki has for many tasks like my Macbook or Beryl superceeded gentoo.org/doc/en

Here I don't see the downside of having it external. Unlike for ebuilds it is good to have two sources for information.

- the external pkgcore and paludis projects to superceed portage

I think this is a big downside because portage devs have one more reason now to say "no" for contributions - they can just point to the forks. But that does not help much as the are not 100% back-and-forth switch compatible and not a full replacement either. It just confuses our users to have those and does not help the general problem.
For example this bug of me is stalled:
138792 dobin etc. should automatically die on failure

The big step that portage development needs to take is to focus on pkgcore or paludis and drop portage development in favour of that. I think that step will increase the popularity of Gentoo again. No one wants to use a distribution with a really slow package manager.

Today I visited worlds biggest IT trade fair Cebit in Hannover. Happily I represented KDE there on their booth in the Linuxpark that was sponsored by Linux New Media.

After departing my ICE there I had a long way through all the different halls to finally find the KDE booth .. deserted after some waiting where I got the wireless working on my Macbook the other staffers for the booth showed up. We unfolded some posters and set up a Thinkpad to show off KDE on the big LCD.

There I was very excited to see that the kde developer who booted the thinkpad was running Gentoo Linux! While talking it turned out that the four man booth staffing had 3 Gentoo users - that is a rather good ratio. Unfortunately despite the high Gentoo presence we had no Gentoo CDs to give out - our visitors got Kubuntu CDs.

Later when we started some hacking on kde cmake Torsten was also able to join us. From him I learned a lot about how Marble was designed and how he made sure that it is a very fast earth viewer that also works in an offline mode. Now I can lookup where a city is even faster, yay!

In January when I began to study in the university I decided to use MacOS because it allows me to suspend-to-ram - a feature that works only unreliable or not at all on a Linux macbook. Now after working with it for more than a month and joining Gentoo/MacOS I realize that it has been a good choice after all. With Crossover Mac I am able to play Counter Strike with my fellow students. Nowadays gtk+ and qt4 are both available in Native versions for MacOS and most of the basic tools from Linux also work on a Mac.

Native versions of qt4 and gtk+ means that they work without X11 - the need for an additional application is eliminated and qt4 apps look much better becaude they put the menu in the top bar and adhere to the OSX design. Bringing applications over to MacOS and compiling them is fun - and it is a joy every time when something worked and can be copied over to the prefix overlay.

Working with the prefix overlay is fun because it is svn and not cvs like the Gentoo-x86 repository. repoman works on svn here and it is so amazingly fast on svn.

Everything is installed with user privileges in EPREFIX=/Users/stefan/Library/Gentoo. $EPREFIX/usr/bin is added to the path so that I can just run eix-sync as user. Here you can see some output of eix-sync, some error messages including the EPREFIX, the native qt4 application kboard for playing chesss via FICS and gimp on a native gtk+ - all installed by emerge in the prefix. You can also see iTerm and Safari on the screenshot.

as you may have seen we are adding the first git based overlays to overlays.gentoo.org. The overlays team is pleased to give to you the kde and dberkholz overlay. Finally this is done and you can get for example the kde git overlay with highly EXPERIMENTAL kde4 eclasses and ebuilds this way:

layman -a kde

However git support is not complete yet: we still need a trac that can browse the git overlays and possibly a gitweb interface for browsing w/o trac. We are waiting for the infra team to do an update of trac together with jokey which will most likely not be done soon because ramereth is currently away.

Another point is that the project founder, stuart recently left Gentoo. Now we are currently only 2 people to manage all user add and group add or password reset requests. Luckily we have found a 3rd new person to support us: beu. We are trying for some weeks now to get a proper account from the infrastructure team so that he can help with implementing git support and administration.

We are still waiting for infra, and waiting and waiting ... wish us luck

A basic thing before using an overlay is finding the correct one. Unfortunately most portage tools and emerge -s only search local overlays. For eix we implemented a special update-eix-remote tool to add information of remote overlays. It can be used like this:

# echo app-portage/eix >> /etc/portage/package.keywords
# emerge eix
# update-eix
# update-eix-remote update


I like the result very much. For example this allows me to take notice of a newer asterisk ebuild in drizzt's overlay:

$ eix -e asterisk
[U] net-misc/asterisk
     Available versions:  1.0.11_p1 1.2.12.1 1.2.13 1.2.13-r1 1.4.0_beta3[1]
     Installed:           1.2.13-r1
     Homepage:            http://www.asterisk.org/
     Description:         Asterisk: A Modular Open Source PBX System

[1] (layman/drizzt-overlay)

Of course this kind of search can only work when the overlay is present in the global layman list. The global list is kept in Gentoo cvs gentoo/xml/htdocs/proj/en/overlays/layman-global.txt Every Gentoo developer with commit permissions is encouraged to keep this list up to date. I also welcome contributions by non-developers - please send a diff against the current layman-global.txt to overlays@gentoo.org or contact us in IRC #gentoo-overlays with the diff. To generate a diff:
$ diff -u layman-global.txt.orig layman-global.txt > new-overlay.diff

Also the few layman commands to use the overlay:

# emerge -va layman
# echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf
# layman -k -f -L     #you can see all global overlays listed here
# layman -k -a drizzt-bsd

-k disables checks for officialness, -f fetches a new global list, -L lists all overlays, -a adds a new overlay, -S syncs all overlays

Diego,

thanks for pointing out that! The state of consideration in the council was not very clear to me. Apparently members were missing and it was no decision. Sorry

Seemant,

I have fixed your point 1 (license) in my copy and I was working with pylon and halcy0n the past few hours to get the devmanual imported. It is now available in gentoo svn - sorry, anonsvn.gentoo.org does not work yet one of the long standing items in infras queue. Point two first item fixed.

Point 2 second item - the gentoo branding is actually a bit harder to do. This is a point that is rather hard to deal with and a good excuse for delaying putting it up again.

Actually I did not yet fix the license violation in the Gentoo svn because kloeri and wolf31o2 from Gentoo council want the council to handle that at this point.

I am hoping that they can get it up and working again soon

Yesterday Ciaran wrote a mail to several people asking for the devmanual to be changed to comply with the license. Every contributor should be listed in the same size and not one person who has done little with extra strength on the front page.

A 2-minute change you think? Not for Gentoo - In Gentoo everything is more complicated. A quick council decision resulted in putting the page out of action hurting the whole community and now it is on the long queue of things for the infrastructure team to do. Some hope that it will be a matter of days to get it back.

Can we avoid such a thing in future? Yes. Developer (especially those with special rights) need to think more of the results of their action and the community. And we need to learn to solve problems and not run away from them.

Until the people with power decide to make the content again available on devmanual.gentoo.org I have put up a recent copy with license issues fixed on http://dev.gentoo.org/~genstef/devmanual

Recently I did some work for Gnome despite KDE being my primary desktop.

After a nice chat with the Gnome team I bumped gtk+ to 2.10, which uses the new cairo-1.2.0 with many new features. The new gtk+ is hard masked to ensure proper testing of the currently ~arch ebuilds so that they can be marked stable. To get the new gtk+ you have to unmask the new cairo as well as a new glib and pango.
Despite being compatible for applications, gtk+-2.10.0 uses a new directory for the engines and modules. That means you have to rebuild them to work correctly. To inform users about this change I am using the new elog functionality in the postinstall message of gtk+. After updating you can easily rebuild the affected ebuilds using portage-utils:

emerge -va1 $(qfile -qC /usr/lib/gtk-2.0/2.[^1]* )

I have been forced to use the gtk-file-selector in gnome apps like firefox and gimp for some time now. In my opinion it is a lot slower to work with because you need that special [CTRL]+L command to open a window where you can actually type something. Also it does not offer completion or a drop-down-menu, and clicking the way out is also silly because it requires many clicks.

Now finally I have found a solution for this problem! Kgtk allows to use the kde-file-selector in Gtk-applications. It features:
- a dropdown directory-selection,
- where you can type the path yourself aided by completion
- a text box to select the file by typing it
- in my opinion it also has a better design

To install it just emerge -va kgtk and follow the setup steps in the postinstall einfo. I have been trying it out with firefox and gimp, works really good so far. One downside it has: It will only run with kded, so sadly only kde-users be able to try this out.

Recently the mobile herd got a request for a driver to be included on the livecd that has not been marked stable yet because it is new. Current policy says that a driver has to be stable to be included on the livecd. Current policy also says that a driver has to be in the tree for 30 days to be marked stable.

Now the problem is, that many new drivers do not get included on the livecd and many people have to use non-gentoo-livecds to intall their gentoo operating systems. This situation will not change for 2005.0 if the snapshot is to be taken in <1 month. Waiting for 2006.0 as the next stable livecd is a really long time.
However, as the releng team is really loaded with work, it does not seem possible to regularly get experimental livecds with new drivers or new driver-versions on them. A smart way to solve this is to put the drivers as binaries on an usb-key, precompiled for the livecd environment. I will consider putting some drivers precompiled for the 2005.1 livecd on my devspace when there is increasing demand for it after it has been released. Oh, and thanks to John for the idea :)

For a long time now we were able to watch the flamewars between Lovechild and ciaranm. Recently there has been a change, Lovechild got banned in the Gentoo forums by klieber in December 2004 for that post.

Now ian has moved the non-official kernel patchset-threads to "Off the Wall", this move may be provoked by ciaranms permanent "convincing". Ian said to me that he is "at this time [I'm] supporting developers who were calling for help".
Most of the "non-official" users understand why this step was made, but they are not happy with it as "Off the Wall" is usually used for non-gentoo topics.
There is currently a proposal by the users to open up a new forum for gentoo-related but not official projects.
I hope we can get the current situation improved by this move.

Hi,

I am a gentoo developer working on kernel/hardware/mobile/net-dialup ebuilds but also on completely unrelated parts like acroread or lineak. I joined gentoo because I wanted to get my ebuilds from bugzilla in the tree, so I usually try to help others having ebuilds lying around for months in bugzilla.

Currently I am testing the ebuild for the new Acrobat Reader 7.0 to get it to perfection. I got an interesting mail about how I could get the browser plugin to work on both firefox and mozilla, I am still testing. Quite interestingly, the "7.0" we use now is not the final product but an early pre-release to meet tax-deadlines in the Netherlands.